My ISP has assigned the netblock 204.50.168.0/28 to me and my content DNS server is listening on 204.50.168.2. 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 multiple names. This means that there are that much more data in the DNS database, but on the other hand it enables you and your ISP to take advantage of two useful features of djbdns, one that obviates the need for typing in the content DNS server names and maintaining them, and another that allows you to generate all of your data with a single for command in your shell.
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.", "1.168.50.204.in-addr.arpa.", "2.168.50.204.in-addr.arpa.", "3.168.50.204.in-addr.arpa.", "4.168.50.204.in-addr.arpa.", "5.168.50.204.in-addr.arpa.", "6.168.50.204.in-addr.arpa.", "7.168.50.204.in-addr.arpa.", "8.168.50.204.in-addr.arpa.", "9.168.50.204.in-addr.arpa.", "10.168.50.204.in-addr.arpa.", "11.168.50.204.in-addr.arpa.", "12.168.50.204.in-addr.arpa.", "13.168.50.204.in-addr.arpa.", "14.168.50.204.in-addr.arpa.", and "15.168.50.204.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 "a.ns.N.168.50.204.in-addr.arpa.", and A resource record sets for each "a.ns.N.168.50.204.in-addr.arpa." giving the IP address 204.50.168.2. 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 resource record sets for each "N.168.50.204.in-addr.arpa.".
In contrast to example 2, this scheme uses delegation data that are within the bailiwick of both your and 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. The names of your content DNS server are automatically generated, so they do not need to be explicitly specified. Your ISP simply adds the following lines to that file:which it can do with a single command:&0.168.50.204.in-addr.arpa:204.50.168.2:a &1.168.50.204.in-addr.arpa:204.50.168.2:a &2.168.50.204.in-addr.arpa:204.50.168.2:a &3.168.50.204.in-addr.arpa:204.50.168.2:a &4.168.50.204.in-addr.arpa:204.50.168.2:a &5.168.50.204.in-addr.arpa:204.50.168.2:a &6.168.50.204.in-addr.arpa:204.50.168.2:a &7.168.50.204.in-addr.arpa:204.50.168.2:a &8.168.50.204.in-addr.arpa:204.50.168.2:a &9.168.50.204.in-addr.arpa:204.50.168.2:a &10.168.50.204.in-addr.arpa:204.50.168.2:a &11.168.50.204.in-addr.arpa:204.50.168.2:a &12.168.50.204.in-addr.arpa:204.50.168.2:a &13.168.50.204.in-addr.arpa:204.50.168.2:a &14.168.50.204.in-addr.arpa:204.50.168.2:a &15.168.50.204.in-addr.arpa:204.50.168.2:aYour 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.". (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.)for i in `seq 0 15` ; do ./add-childns $i.168.50.204.in-addr.arpa 204.50.168.2 done… if it uses ISC's BIND.
BIND's "zone" file format is a little more cumbersome to manipulate with tools, but 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 a.ns.$ $GENERATE 0-15 a.ns.$ A 204.50.168.2
… 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:which you can do with a single command:.0.168.50.204.in-addr.arpa:204.50.168.2:a .1.168.50.204.in-addr.arpa:204.50.168.2:a .2.168.50.204.in-addr.arpa:204.50.168.2:a .3.168.50.204.in-addr.arpa:204.50.168.2:a .4.168.50.204.in-addr.arpa:204.50.168.2:a .5.168.50.204.in-addr.arpa:204.50.168.2:a .6.168.50.204.in-addr.arpa:204.50.168.2:a .7.168.50.204.in-addr.arpa:204.50.168.2:a .8.168.50.204.in-addr.arpa:204.50.168.2:a .9.168.50.204.in-addr.arpa:204.50.168.2:a .10.168.50.204.in-addr.arpa:204.50.168.2:a .11.168.50.204.in-addr.arpa:204.50.168.2:a .12.168.50.204.in-addr.arpa:204.50.168.2:a .13.168.50.204.in-addr.arpa:204.50.168.2:a .14.168.50.204.in-addr.arpa:204.50.168.2:a .15.168.50.204.in-addr.arpa:204.50.168.2:aThe "PTR" resource records will, of course, be constructed from the '=' records for the domain names themselves:for i in `seq 0 15` ; do ./add-ns $i.168.50.204.in-addr.arpa 204.50.168.2 donewhich you will have already created earlier, when you created the forward lookup domain, by running:=hartnell.example:204.50.168.1 =troughton.example:204.50.168.2 =pertwee.example:204.50.168.3 =baker.example:204.50.168.4 =davidson.example:204.50.168.5 =baker2.example:204.50.168.6 =mccoy.example:204.50.168.7 =mcgann.example:204.50.168.8Since 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 204.50.168.1 ./add-host troughton.example 204.50.168.2 ./add-host pertwee.example 204.50.168.3 ./add-host baker.example 204.50.168.4 ./add-host davidson.example 204.50.168.5 ./add-host baker2.example 204.50.168.6 ./add-host mccoy.example 204.50.168.7 ./add-host mcgann.example 204.50.168.8… 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, although "168.50.204.in-addr.arpa." will be used in this example) in which you place:
followed by the PTR resource records that match the content of your forward lookup domains, that you have elsewhere:$ORIGIN 168.50.204.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. "168.50.204.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 204.50.251.17 $GENERATE 16-255 b.ns.$ A 204.50.251.122 $GENERATE 16-255 c.ns.$ A 204.50.251.189 $GENERATE 16-255 d.ns.$ A 204.50.251.253 $GENERATE 16-255 e.ns.$ A 207.107.254.9 $GENERATE 16-255 f.ns.$ A 207.107.254.120 $GENERATE 16-255 g.ns.$ A 207.107.254.183 $GENERATE 16-255 h.ns.$ A 207.107.254.245Officially, 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 a.ns.$ $GENERATE 0-15 a.ns.$ A 204.50.168.2