In article <mailman.246.1367950255.20661.bind-us...@lists.isc.org>, Justin T Pryzby <justinpry...@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 _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users