BIND database dump question...

[Jim Reid]

>>>>> "Todd" == Todd Herr <therr at va.rr.com> writes:

    Todd> Would the BIND experts hereabouts please interpret this
    Todd> entry from a named database dump (i.e., kill -2 <named PID>):

First of all, stop sending signals to the name server to control
it. Use ndc.

    Todd> $ORIGIN 88.24.in-addr.arpa.  
    Todd> 255 518316 IN NS DNS1.RR.COM. ;Cr=addtnl LAME=516 [192.36.148.17] 
    Todd>     518316 IN NS DNS2.RR.COM. ;Cr=addtnl LAME=516 [192.36.148.17]

It's simple. The server will cache for 518316 seconds the fact that
dns1.rr.com and dns2.rr.com serve the 255.88.24.in-addr.arpa zone.
It learnt that from 192.36.148.17 which is one of the in-addr.arpa
name servers, i.root-servers.net. Your server found that those two
servers for 255.88.24.in-addr.arpa were lame.

    Todd> ARIN lists dns[12].rr.com as authoritative for 24.88.255

Correct. But those servers are not authoritative for that reverse
zone. Therefore they are lame and there is a lame delegation. It's your
servers that are lame, not the parent zone's which is what you seemed
to be hinting at.

    Todd> dns[12].rr.com delegate authority for reverses to other
    Todd> nameservers in the rr.com hierarchy, and those nameservers
    Todd> are aware of this and act accordingly (i.e., this is not a
    Todd> lame delegation, as I understand lame delegations).

If this is your understanding of lame delegations, it is a wrong one.
The parent zone says "for lookups of 255.88.24.in-addr.arpa,
dns[12].rr.com are the authoritive servers. Go ask them." But those
servers are not answering authoritatively for that zone. That makes
them lame. And you can't delegate something that's been delegated to
you. You can delegate subdomains of that delegation, but not the
delegation itself. If you want ns[34].southeast.rr.com - or is that
ns[12].nc.rr.com? - to serve 255.88.24.in-addr.arpa, get the
in-addr.arpa zone changed to point their NS records for the delegation
there rather than the currently lame dns[12].rr.com servers. Or you
could just make less work for everyone by configuring dns[12].rr.com 
to serve 255.88.24.in-addr.arpa as you were supposed to.

Those two name servers (dns[12].rr.com) are bizarrely messed up. If
they're asked for the NS records for 255.88.24.in-addr.arpa, they
return non-authoritative answers that the name servers are
ns3.southeast.rr.com and ns4.southeast.rr.com. [They should of course
include themselves in that answer because that's what the parent zone
says are the servers for 255.88.24.in-addr.arpa.] But when they are
asked for the SOA record for 255.88.24.in-addr.arpa they return
non-authoritative answers with NS records for ns1.nc.rr.com and
ns2.nc.rr.com in the Authority Section.