Classless PTR query issue

[Barry Margolin]

In article <mailman.246.1367950255.20661.bind-users at lists.isc.org>,
 Justin T Pryzby <justinpryzby at users.sourceforge.net> wrote:

> It appears they may have manually added NS records for each of 64 IPs.
> That's messy and inelegant for them, and doesn't work right either.
> The ISP is responding with NS for 90.1.1.1, which means that the next
> query must ask a quesion *below* that: something.90.1.1.1.  That's why
> a CNAME is needed, with an additional, "artificial" subzone, allowing
> proper delegation.  Otherwise, it's a so-called "horizontal" referal.

Actually, this kind of referral works OK -- it's how you find the SOA of 
a subdomain, for instance.

The strictly legal way to implement this in the subdomain's server is to 
have separate zones for each IP:

zone "65.1.1.1.in-addr.arpa" {
  type master;
  filename "1.1.1.65.rev";
};
zone "66.1.1.1.in-addr.arpa" {
  type master;
  filename "1.1.1.66.rev";
};
...

Each of these reverse zone files should then contain a PTR record at the 
apex:

@ IN SOA ...
  IN NS dns1.yourdomain.com.
  IN PTR hostname.yourdomain.com.

In practice, though, what people often do in this case is create a 
1.1.1.in-addr.arpa zone. The problem with this is that the responses 
will claim authority for the /24, even though the ISP is supposed to be 
authoritative. This may cause some servers to reject the responses (or 
worse, cache these authority records and lose the ability to do reverse 
lookups in the rest of the /24).

But you really should point them to RFC2317, and get them to do it right.

-- 
Barry Margolin
Arlington, MA