After searching for complete example of configuring reverse in-addr.arpa delegation for my /27 prefix, I finally ended up with working example in BIND 9.9.8-P3.
In this post I’ll show how it is configured in BIND (FreeBSD is OS, but this is not relevant in this example).
Some theory
Before we start configuring BIND, we need to remember that beside TLDs we usually know (.com, .net, etc.) we have also .arpa TLD (address and routing parameter area) which is infrastructure top-level domain. Under it we have in-addr. and ip6. domains used for reverse domain name resolution, IPv4 and IPv6 respectively.
While resolving IP 192.168.0.1 to a hostname, we’ll first ask one of the root servers (a.root-servers.net) who is responsible for in-addr.arpa zone, it will point us to one of the nameservers for IPv4 reverse zone (a.in-addr-servers.arpa). Later on we’ll ask that server who’s responsible for 192.in-addr.arpa zone, and it will point us to one of the name servers responsible for that zone (tinnie.arin.net). From there most probably we’ll get directly pointed to nameservers of ISP (ns1.some-isp.net) who has this domain object registered in IANA database.
Note: in this example I’ll use 192.168.0.0/24 for classful reverse delegation and 192.168.0.0/27 for classless reverse delegation. If you would try to resolve PTR record for it by doing DNS query, you would end up being forwarded to “blackhole” IANA NS servers getting NXDOMAIN as status.
Classful reverse delegation (/24, /23, /22…)
So it looks pretty straight forward for /24 networks.
DOMAIN object
Our ISP have to have one registered in IANA database (ARIN, RIPE…)
domain: 0.168.192.in-addr.arpa descr: Some ISP company org: ORG-SOMEISP-RIPE admin-c: XXX89-RIPE tech-c: XXX89-RIPE zone-c: XXX89-RIPE nserver: ns1.some-isp.net nserver: ns2.some-isp.net mnt-by: MNT-SOMEISP created: 2008-08-02T06:12:41Z last-modified: 2010-07-17T17:08:33Z source: RIPE
BIND configuration – classful example ISP
Here is how our BIND config file (named.conf) should look like:
zone "0.168.192.in-addr.arpa" IN { type master; file "master/192.168.0.db"; };
and our zone file “192.168.0.db”:
$TTL 1D @ IN SOA ns1.some-isp.net. hostmaster.some-isp.net. ( 2016032400 ; Serial 3H ; Refresh 3 hours 1H ; Retry 1 hour 3W ; Expire 3 weeks 1D ; Minimum 1 day ) ; IN NS ns1.some-isp.net. IN NS ns2.some-isp.net. $ORIGIN 0.168.192.in-addr.arpa. 1 IN PTR host1.some-isp.net. 2 IN PTR host2.some-isp.net. 3 IN PTR host3.some-isp.net.
Testing with “host” command
Here is what we get while using host command to resolve IP to hostname:
$ host 192.168.0.1 1.0.168.192.in-addr.arpa domain name pointer host1.some-isp.net.
Classless reverse delegation (/25, /26, /27…)
Comparing to classful reverse delegation example above, this looks bit different.
In example we’ll suppose that ISP gave us prefix 192.168.0.0/27 for our own usage. As displayed on picture, requester for hostname within our range 192.168.0.0/27 will get pointed to our DNS in order to resolve 192.168.0.1 to hostname:
The DOMAIN object ISP owns looks the same, so there are no changes.
But our ISP will have to make some changes in configuration in its zone file for 192.168.0.0/24 (192.168.0.db).
BIND configuration – classless example ISP
Let’s look what is different in configuration comparing to classfull reverse delegation…
Zone file “192.168.0.db”:
$TTL 1D @ IN SOA ns1.some-isp.net. hostmaster.some-isp.net. ( 2016032400 ; Serial 3H ; Refresh 3 hours 1H ; Retry 1 hour 3W ; Expire 3 weeks 1D ; Minimum 1 day ) ; IN NS ns1.some-isp.net. IN NS ns2.some-isp.net. $ORIGIN 0.168.192.in-addr.arpa. $ORIGIN 0-31.0.168.192.in-addr.arpa. 0-31 NS dns.ournetwork.net. $GENERATE 0-31 $.0.168.192.in-addr.arpa. CNAME $.0-31.168.192.192.in-addr.arpa. 32 IN PTR host1.some-isp.net. 33 IN PTR host2.some-isp.net. 34 IN PTR host3.some-isp.net.
Since we “own” 192.168.0.0/27 network, we are responsible how will we create PTR records within our /27 zone. That is why ISP had to tell BIND that for 0-31.0.168.192.in-addr.arpa zone (which we own) it should redirect the requester to our NS (dns.ournetwork.net).
Another thing is that ISP also has to create CNAME records for each host in our 0-31 range. I used $GENERATE macro since I didn’t want to create each entry separately.
192.168.0.0/27 network includes network address 192.168.0.0 and broadcast address 192.168.0.31, for the rest of addresses in 192.168.0.0/24 (31 – 255) zone the ISP will define his own PTR records (or point to another NS server).
BIND configuration – classless example Customer
After ISP pointed 192.168.0.0/27 zone to our NS, it’s time to configure our NS to be able to handle reverse 192.168.0.0/27 zone.
named.conf:
zone "0-31.0.168.192.in-addr.arpa" IN { type master; file "master/192.168.0.0-31.db"; };
BIND understands this zone syntax, as well as if we would have written it as “0/27.0.168.192.in-addr.arpa”. I like to use range syntax more.
and finally our zone file (192.168.0.0-31.db):
$TTL 1D @ IN SOA dns.ournetwork.net. hostmaster.ournetwork.net. ( 2016032419 ; Serial 3H ; Refresh 3 hours 1H ; Retry 1 hour 3W ; Expire 3 weeks 1D ; Minimum 1 day ) ; IN NS dns.ournetwork.net. $ORIGIN 0-31.0.168.192.in-addr.arpa. 1 PTR host1.ournetwork.net. 2 PTR host2.ournetwork.net.
Finally we defined our own PTR records in zone 192.168.0.0/27 we own. Now let’s test it with host command:
$ host 192.168.0.1 1.0.168.192.in-addr.arpa is an alias for 1.0-31.0.168.192.in-addr.arpa. 1.0-31.0.168.192.in-addr.arpa domain name pointer host1.ournetwork.net.
Links
- Classless in-addr.arpa delegation RFC2317
- BIND name server software BIND
- General information and examples about DNS http://www.zytrax.com/books/dns/