DNS is also used to look up hostnames by IP address.
- Why is that useful?
- First of all, in the RFC 1033, RFC 1912 Section 2.1, it specify that every reachable machine on the Internet should have a name, and such name should be linked to a number. So it is required in the standard.
- Secondly, it provide a way to check if the address provided by DNS response is indeed correct. If forward lookup and reverse lookup do not match, you know there is something wrong. So for debugging.
- Also, domain names are arbitrarily assigned while ip addresses are geographically allocated. At least, the bound between two of them provide a bit of extra information on the domain.
Now read RFC 2317 about classless in-addr.arpa delegation.
- Does this mechanism also work for separate IP adresses?
No. It must be ip chunks. It breaks through the classful ip blocks, but still need the addresses to be continuous.
In the RFC we can see that the solution accepts syntax like classless ip blocks.
$ORIGIN 2.0.192.in-addr.arpa. @ IN SOA my-ns.my.domain. hostmaster.my.domain. (...) ;... ; <<0-127>> /25 0/25 NS ns.A.domain. 0/25 NS some.other.name.server. ; 1 CNAME 1.0/25.2.0.192.in-addr.arpa. 2 CNAME 2.0/25.2.0.192.in-addr.arpa. 3 CNAME 3.0/25.2.0.192.in-addr.arpa.
It is not bounded with oct ip blocks. But still need the blocks to be continuous. For seperate ip addresses, for example. 123.123.123.123 and 123.123.200.200, it is not possible to efficiently put them into one block. We can use route summary to make it 123.123.0.0/16, but this is not practically possible since there are too many IPs in-between which belong to other organizations.
I setup my revers zone in the same way I setup the forward zone.
Firstly, edit the named.conf
nano /etc/named.conf // reverse for my zone zone "80/28.106.100.145.in-addr.arpa" in { type master; notify no; file "80.106.100.145.in-addr.arpa.db"; };
The 80/28.106.100.145 is my assignment ip chunk 145.100.106.80.28 in the reversed classless order.
Then create and edit the zone file for it
touch 80.106.100.145.in-addr.arpa.db $TTL 1h $ORIGIN 80/28.106.100.145.in-addr.arpa. @ IN SOA rome.studlab.os3.nl. hostmaster.rome.studlab.os3.nl. $ 20100921 ;serial 10h; refresh 5h; retry 1d; expire 2h; min ) @ in NS rome.studlab.os3.nl. ; 81 in PTR webservice.rome.practicum.os3.nl. 82 in PTR ns.rome.practicum.os3.nl. 83 in PTR mail.rome.practicum.os3.nl. 84 in PTR idea.rome.practicum.os3.nl.
- If Niels had been here and he had not yet implemented the reverse zone delegation, what information would you need to give him so that he can implement it?
My machine name is required.
Delegating your own zone
- How did you set up the subdomains and their delegation?
- What con figuration options did you add or change?
Since I am delegating the zone, I do not have control over it afterward, I do not have to create a zone file for that. But I will act as a slave for that zone, and receive zone file tranfer. I have to edit the rome.practicum.os3.nl zone file to reflect the fact that I've delegated the sub-domain to other people
; sub-domain definitions $ORIGIN pizza.rome.practicum.os3.nl. ; we define two name servers for the sub-domain @ IN NS rome.studlab.os3.nl. @ IN NS ns1.luxembourg.practicum.os3.nl. ;partner's dns ns1.luxembourg.practicum.os3.nl in A 145.100.104.50 ; glue
Setting up a slave server
- How did you set up the slave nameserver?
- What confi guration options did you add or change?
here is the named.conf. My server act as the slave.
// slave for subdomain pizza.rome.practicum.os3.nl zone "pizza.rome.practicum.os3.nl" { type slave; file "slave.pizza.rome.practicum.os3.nl"; masters {145.100.104.50;}; };
- What happens if the primary nameserver for the subdomain fails?
- Considering that the slave nameserver is also the delegating nameserver, explain why this is essentially a bad setup?
The slave server will use the cached result before the expiration.
Zone transfers
- Use the BIND tools (for instance DIG) to initiate a zone transfer from your primary nameserver to your slave.
use dig to do the zone transfer
root@rome:/etc/named# dig @ns1.luxembourg.practicum.os3.nl pizza.rome.practicum.os3.nl axfr ; <<>> DiG 9.7.2 <<>> @ns1.luxembourg.practicum.os3.nl pizza.rome.practicum.os3.nl axfr ; (1 server found) ;; global options: +cmd ; Transfer failed.
- Describe the process.
- What information did the slave server receive?
The slave server, in this case my server, will ask the specific NS server (master) for the specified zone (request target).
- My server (slave) will check the SOA and try to find out if the serials number is updated.
- if serials number is updated, then slave will send out the request for zone transfer. if not, the zone transfer will not happen.
- Slave receives the whole zone file, the same as the one on the master.
The zone transfer is a big chunk of data compare to normal DNS packet. It should not happen too often to avoid extra burden.
- What changes did you have to make to your con figuration?
- I created ACL, and put everyone in the lab into this ACL
- I should allow-transfer {} to the IP addresses.
acl "allowedip" {
ip address of the lab;
};
allow-transfer {allowedip};
allow-recursion {allowedip};
Now only machine with IP address of the allowed ip, so lab machines, can ask the server to do recursion and transfer for it.
Extra Assignments
- make BIND run in a chroot environment.
- what do all those parameters in the SOA record do, and what use could fiddling with them have?
- check that the SOA parameters work as advertised by experimenting with the cache
- only allow your nameserver to respond to recursive queries from 145.100.96.0/20
- use ACL's of views to limit who can request what from your nameserver
server
