1. CNAME Delegation: Zones

Prior to 2015/03/16, this document had some broken thoughts; I seem to recall that I noticed an error, fixed that error (or attempted to, anyway) and I seem to think I might have been rushing. The following is what I hope is more clear and to the point (I'm having doubts but it should be better than what it was).

When I set up this on my end I ran in to the problem of: is this the right zone name? It appears to work but yet I am not certain of it. There is a certain ambiguity (because there are multiple ways to handle naming the zone) in RFC 2317. It isn't intentional and it isn't misleading as such but my hope is that this should give you enough information. I by no means promise this will work in all cases. However, there is one key point that I will get to and it might be enough to answer the question even if the below looks different. This key point would have saved me a lot of grief if I thought of it (it was made worse because of what I describe in the Secondary DNS Servers and Troubleshooting section). I made it much more difficult than it had to be.

For this document, I'm going to assume your IP block is 10.0.0.96/29 and so the first IP (e.g. to query) is 10.0.0.97. The below shows this and what it meant to me. It may very well be that more than one zone name works and it may very well be that different ISPs do this differently (as RFC 2317 suggest). The main idea is by looking up how your ISP names your IPs, you can name the zone in what should work. Part of my issue was as I describe in troubleshooting - it add confusion to the matter and, because of DNS cache (and time of), some of it was a waiting game.

As for configuring the zone, this is going to vary based on what your DNS server is (e.g. BIND) and what environment you're in (e.g. Linux). It is also out of the scope of this document. This document might not be helpful to others. The fact the RFC has multiple schemes combined with the fact I (at least initially) did a very poor job at writing this document (because I was exhausted), it certainly wouldn't surprise me. It is a simple to understand solution, though.

The idea is your provider is using RFC 2317 so you should find out what the CNAME of your IPs are. Then you can determine the zone name by the result. In the following I am omitting extra information and below it I will include how I interpret the actual output (while you wouldn't normally have this output for the block I use, you could set it up if you wanted - if you do, though, please do use BIND views or equivalent so as to not pollute the DNS pool).

$ dig cname -x 10.0.0.97
;; QUESTION SECTION:
;97.0.0.10.in-addr.arpa. IN CNAME
;; ANSWER SECTION:
97.0.0.10.in-addr.arpa. 7200 IN CNAME 97.96.0.0.10.in-addr.arpa.

In the example, you query the CNAME of the in-addr.arpa address (reverse the octets and add '.in-addr.arpa', essentially). The -x option to dig simplifies this latter process: dig will do the work for you (less error prone in typing, if nothing else). The answer says what the CNAME is. Put another way, '97.0.0.10.in-addr.arpa' is an alias for '97.96.0.0.10.in-addr.arpa'. The key point I refer to above has to do with how DNS works, and in particular zones (not the same as domains but often has the same information - the difference is subtle). That means the following: In the above, '97' is only relevant to '97.96.0.0.10.in-addr.arpa' in the zone '96.0.0.10.in-addr.arpa'. (Outside of that zone, it could be any number of things that it refers to. This is no different to having the same name for an A record in zone example.com as example.org.) So that would be the zone in this example.

2. Secondary DNS Servers & Troubleshooting

I am including this because of one thing that tripped me up. It shouldn't have but 'should' and 'reality' are not always equivalent. It is likely that when you are querying your DNS server, if you are in your network (as opposed to a remote network), you will be trusted. As such, you don't have to rely on DNS itself; you can directly query the PTR record of your IP and you will see the CNAME and the PTR record. However, from a remote host you likely don't have that privilege and so you may very well have the secondary server refuse your query (but if you were to log in on to that network and query it you would likely see the same as if you were on your end, querying your server). This very issue is what made me question myself multiple times, on whether I had things configured properly (zone name in particular). All it took was distraction (and I have a lot of that) and you don't think of things as clearly (which adds to frustration especially if the administrator of the slave DNS server is unable to respond for some time!).

The point then is: DNS uses what some might call black magic. While a host might query the PTR record it will find the answer because of the way DNS refers hosts to hosts. If you do a direct query though it might 'appear' to be wrong (even though everything is working perfectly). In the example in the first section, as long as you know the alias (CNAME) then you can query the PTR record of THE CNAME itself. This would be like (I'm not showing the results as there really is no need) :

$ dig ptr 97.96.0.0.10.in-addr.arpa

3. Conclusion

I think this is one of those things that is generally so simple that it is made difficult because it seems too easy so must not be the case (in truth, if you are certain something will go bad then it likely will). Hopefully this simplifies things for some people. I don't promise it to work in all cases. Indeed, there are always exceptions to the rules and rules are not always consistent.