My ISP has assigned the netblock 220.127.116.11/28 to me and my content DNS server is listening on 18.104.22.168. I want to serve up the reverse lookup domains for my IP addresses from my own content DNS server so that I have control over the address to name mappings for them. How should I and my ISP handle this ?
This is one of the two answers to that question.
In this answer, your content DNS server ends up with a single name. This means that there are that much less data in the DNS database, but on the other hand it requires that you and your ISP enter the content DNS server names into the data files explicitly and keep them synchronised yourselves. It is also not so easy to automatically generate the data file content.
Your ISP delegates the reverse lookup names to you by having its content DNS servers serve up referrals for the "0.168.50.204.in-addr.arpa.", "22.214.171.124.in-addr.arpa.", "126.96.36.199.in-addr.arpa.", "188.8.131.52.in-addr.arpa.", "184.108.40.206.in-addr.arpa.", "220.127.116.11.in-addr.arpa.", "18.104.22.168.in-addr.arpa.", "22.214.171.124.in-addr.arpa.", "126.96.36.199.in-addr.arpa.", "188.8.131.52.in-addr.arpa.", "10.168.50.204.in-addr.arpa.", "184.108.40.206.in-addr.arpa.", "220.127.116.11.in-addr.arpa.", "18.104.22.168.in-addr.arpa.", "22.214.171.124.in-addr.arpa.", and "126.96.36.199.in-addr.arpa." domains, pointing to your content DNS server. Your content DNS server in turn serves up a PTR resource record for each "N.168.50.204.in-addr.arpa." pointing to the appropriate domain name.
More specifically: Your ISP's content DNS server serves up NS resource record sets for each "N.168.50.204.in-addr.arpa." pointing to the name "ns.168.50.204.in-addr.arpa.", and a single A resource record set for "ns.168.50.204.in-addr.arpa." giving the IP address 188.8.131.52. Your content DNS server serves up these same resource record sets (unless you are using BIND, which is slightly feature deficient in this area), along with the PTR record sets for each "N.168.50.204.in-addr.arpa.".
In contrast to example 1, this scheme uses delegation data that are not within your content DNS servers' bailiwick (although those data are within the bailiwick of your ISP's content DNS servers).
… if it uses Dan Bernstein's djbdns.With djbdns each referral needs just one line in the tinydns/axfrdns database source file, and there is just one extra line for the address information common to all delegations. Your ISP simply adds the following lines to that file:Your ISP, being the superdomain owner, will already have a '.' or 'Z' record for a suitable superdomain that encloses "N.168.50.204.in-addr.arpa.". and "ns.168.50.204.in-addr.arpa.". (Conceptually, according to the djbdns documentation, this record is necessary. However, given the way that tinydns and axfrdns actually operate, the existence of this record is in practice irrelevant.)&0.168.50.204.in-addr.arpa::ns.168.50.204.in-addr.arpa &184.108.40.206.in-addr.arpa::ns.168.50.204.in-addr.arpa &220.127.116.11.in-addr.arpa::ns.168.50.204.in-addr.arpa &18.104.22.168.in-addr.arpa::ns.168.50.204.in-addr.arpa &22.214.171.124.in-addr.arpa::ns.168.50.204.in-addr.arpa &126.96.36.199.in-addr.arpa::ns.168.50.204.in-addr.arpa &188.8.131.52.in-addr.arpa::ns.168.50.204.in-addr.arpa &184.108.40.206.in-addr.arpa::ns.168.50.204.in-addr.arpa &220.127.116.11.in-addr.arpa::ns.168.50.204.in-addr.arpa &18.104.22.168.in-addr.arpa::ns.168.50.204.in-addr.arpa &10.168.50.204.in-addr.arpa::ns.168.50.204.in-addr.arpa &22.214.171.124.in-addr.arpa::ns.168.50.204.in-addr.arpa &126.96.36.199.in-addr.arpa::ns.168.50.204.in-addr.arpa &188.8.131.52.in-addr.arpa::ns.168.50.204.in-addr.arpa &184.108.40.206.in-addr.arpa::ns.168.50.204.in-addr.arpa &220.127.116.11.in-addr.arpa::ns.168.50.204.in-addr.arpa +ns.168.50.204.in-addr.arpa:18.104.22.168
… if it uses ISC's BIND.BIND's "zone" file format is shorter, but a little more cumbersome to modify with tools. However, what is required is still nowhere near as cumbersome as the hoops that RFC 2317 would have your ISP jump through. In the "zone" file for the reverse lookup domain, your ISP adds:$ORIGIN 168.50.204.in-addr.arpa. $GENERATE 0-15 $ NS ns ns 1D IN A 22.214.171.124
… if you use Dan Bernstein's djbdns.With djbdns the contents of the tinydns/axfrdns database source file are the same as those used by your ISP, merely with '&' records changed to '.' records. You thus simply add the following lines to that file:.0.168.50.204.in-addr.arpa::ns.168.50.204.in-addr.arpa .126.96.36.199.in-addr.arpa::ns.168.50.204.in-addr.arpa .188.8.131.52.in-addr.arpa::ns.168.50.204.in-addr.arpa .184.108.40.206.in-addr.arpa::ns.168.50.204.in-addr.arpa .220.127.116.11.in-addr.arpa::ns.168.50.204.in-addr.arpa .18.104.22.168.in-addr.arpa::ns.168.50.204.in-addr.arpa .22.214.171.124.in-addr.arpa::ns.168.50.204.in-addr.arpa .126.96.36.199.in-addr.arpa::ns.168.50.204.in-addr.arpa .188.8.131.52.in-addr.arpa::ns.168.50.204.in-addr.arpa .184.108.40.206.in-addr.arpa::ns.168.50.204.in-addr.arpa .10.168.50.204.in-addr.arpa::ns.168.50.204.in-addr.arpa .220.127.116.11.in-addr.arpa::ns.168.50.204.in-addr.arpa .18.104.22.168.in-addr.arpa::ns.168.50.204.in-addr.arpa .22.214.171.124.in-addr.arpa::ns.168.50.204.in-addr.arpa .126.96.36.199.in-addr.arpa::ns.168.50.204.in-addr.arpa .188.8.131.52.in-addr.arpa::ns.168.50.204.in-addr.arpa +ns.168.50.204.in-addr.arpa:184.108.40.206
The "PTR" resource records will, of course, be constructed from the '=' records for the domain names themselves:which you will have already created earlier, when you created the forward lookup domain, by running:=hartnell.example:220.127.116.11 =troughton.example:18.104.22.168 =pertwee.example:22.214.171.124 =baker.example:126.96.36.199 =davidson.example:188.8.131.52 =baker2.example:184.108.40.206 =mccoy.example:220.127.116.11 =mcgann.example:18.104.22.168Since a single record controls both forward and reverse lookups, the content of your forward and reverse lookup domains will remain automatically synchronised as you maintain your database../add-host hartnell.example 22.214.171.124 ./add-host troughton.example 126.96.36.199 ./add-host pertwee.example 188.8.131.52 ./add-host baker.example 184.108.40.206 ./add-host davidson.example 220.127.116.11 ./add-host baker2.example 18.104.22.168 ./add-host mccoy.example 22.214.171.124 ./add-host mcgann.example 126.96.36.199
… if you use ISC's BIND.Again, BIND's "zone" file format is more cumbersome, and doesn't make it as easy to keep the forward and reverse lookups consistent with each other. Moreover, (officially, at any rate) BIND doesn't allow you to publish the delegation information for your reverse lookup domains, in contrast to djbdns which does.
You create a "zone" file for a suitable superdomain that encloses all of the relevant reverse lookup domains (the easiest option being to just use "in-addr.arpa.", since that allows you to expand to cover other IP address ranges relatively easily) in which you place:followed by the PTR resource records that match the content of your forward lookup domains, that you have elsewhere:$ORIGIN in-addr.arpa. @ 1D IN SOA ns hostmaster.in-addr.arpa. ( 0 3600 120 3600 3600 ) @ 1D IN NS ns ns 1D IN A 127.255.255.1$ORIGIN 168.50.204.in-addr.arpa. 1 1D IN PTR hartnell.example. 2 1D IN PTR troughton.example. 3 1D IN PTR pertwee.example. 4 1D IN PTR baker.example. 5 1D IN PTR davidson.example. 6 1D IN PTR baker2.example. 7 1D IN PTR mccoy.example. 8 1D IN PTR mcgann.example.
You will have to modify these PTR records by hand whenever you modify the A resource records in the "zone" files for your forward lookup domains. BIND provides no mechanism for automatically keeping forward and reverse lookups the inverses of each other.
The first three records are simply there to make BIND happy about loading the "zone" from the database file. (Would that it did not require them! But - alas! - it would complain were they not there.) Your content DNS server will serve those resource records up to the world (the "NS" resource records in the authority section of responses and the "SOA" resource record in "no such name" responses) but the world will ignore them, so this does not matter one iota. A correctly operating resolving proxy DNS server must discard those records because their names are outside of your content DNS server's bailiwick. "in-addr.arpa." is not delegated to your content DNS server, only subdomains within it are.
You should also not use this BIND server itself for your proxy DNS service as well as for your content DNS service, because it will not provide proxy DNS service for other reverse lookup domains. But if you have followed the recommended practice, that is given by many including by books about BIND, you won't be doing that anyway.
It is possible, but not recommended (the recommended course of action being to separate the two DNS services), to cause your BIND server to switch hats and to perform query resolution by delegating all of the other reverse lookup domain names back to your ISP's content DNS server. If you had chosen "168.50.204.in-addr.arpa." as the "zone" apex, for example, you would have to delegate 240 such domain names:(If you consider the case for "in-addr.arpa." as the "zone" apex, you can see why separating the services is the better course to take. This is a non-problem if the services are separate, as is automatically the case with softwares such as djbdns.)$ORIGIN 168.50.204.in-addr.arpa. $GENERATE 16-255 $ NS a.ns.$ $GENERATE 16-255 $ NS b.ns.$ $GENERATE 16-255 $ NS c.ns.$ $GENERATE 16-255 $ NS d.ns.$ $GENERATE 16-255 $ NS e.ns.$ $GENERATE 16-255 $ NS f.ns.$ $GENERATE 16-255 $ NS g.ns.$ $GENERATE 16-255 $ NS h.ns.$ $GENERATE 16-255 a.ns.$ A 188.8.131.52 $GENERATE 16-255 b.ns.$ A 184.108.40.206 $GENERATE 16-255 c.ns.$ A 220.127.116.11 $GENERATE 16-255 d.ns.$ A 18.104.22.168 $GENERATE 16-255 e.ns.$ A 22.214.171.124 $GENERATE 16-255 f.ns.$ A 126.96.36.199 $GENERATE 16-255 g.ns.$ A 188.8.131.52 $GENERATE 16-255 h.ns.$ A 184.108.40.206
Officially, BIND doesn't allow you to publish the delegation data for your reverse lookup domains, since there is no way to tell it (as there is with djbdns) that the relevant resource record sets are not "zone cuts". If this were not the case, you would publish your delegation data by appending the following to your "zone" file:$ORIGIN 168.50.204.in-addr.arpa. $GENERATE 0-15 $ NS ns ns 1D IN A 220.127.116.11