20161003

Bind9 and the Mysterious PTR resolution failure

I run a sort-of cagey DNS setup.  I have a hidden primary that isn't exactly hidden, but is certainly not well-advertised.  Couple this with the fact that I run both internal and external views (so that my internal clients can resolve the same names the external clients resolve, but end up with IPs that are actually valid and usable), and the glorious RFC-2317 (which is really damn cool, if you think about it), and there is a recipe for a wonderfully ornery problem.

So, here's the deal.  I contact my ISP and say I want to get PTR records.  They say it's money or they can delegate.  I think, "Cool!  I get my first PTR delegation!"  But not so fast, because I don't have a /24, and anything smaller than a /24 is either managed by them, or can be RFC-2317'd.  The RFC basically recommends how to set up CNAMEs for all the in-addr.arpa records, and point them to a customer's DNS.  In this case, they're pointing to my DNS server, which isn't great, but is at least a start.

Once my DNS server and the ISP's DNS were prepped, everything seemed fine...from the outside.  From the inside, no results.  Why?  Well, it turns out the dual-view I have in place was doing its job.  When my internal client did an nslookup against the IP, the ISP returned (as it should) the CNAME that pointed to my domain.  nslookup did what any good resolver does, and recursed.  I had assumed that the DNS server would recurse for me, which was totally wrong.  I know, dumbass.

The recursion led my local resolver (nslookup) to seek out my DNS server to resolve its own domain.  The DNS server said, "Sure, I actually handle that domain - OH, you're an internal view client, and I have no DNS names that match that query in my internal view."  And then failure.

So, the short lesson here is: when you run internal and external views, make sure they match, especially where the PTR records are concerned!!