BIND database dump question...

Todd Herr therr at va.rr.com
Fri Feb 23 21:32:40 UTC 2001


Greetings.

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

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

Supporting documentation:
------------------------------------------------------------
BIND 8.2.3
------------------------------------------------------------
dump is from another nameserver in rr.com
------------------------------------------------------------
ARIN lists dns[12].rr.com as authoritative for 24.88.255
------------------------------------------------------------
dns[12].rr.com delegate authority for reverses to other
nameservers in the rr.com hierarchy, and those nameservers
are aware of this and act accordingly (i.e., this is not a
lame delegation, as I understand lame delegations).
------------------------------------------------------------

We've received reports of problems with reverse lookups in
24.88.255.X, and we've been able to duplicate them, but I can't
figure out how to address the problem of root nameservers
(192.36.148.17 is i.root-servers.net, and we saw the same thing
with e.root-servers.net last night) having LAME information, if
that is in fact what I'm seeing.

Can someone help explain the database dump?  I've looked at the
relevant section in DNS and BIND (3rd edition) but it doesn't
mention LAME records in the database dump section.  I understand
that lame servers are those which are not authoritative for those
domains to which authority has been delegated, but that doesn't
seem to be the case here.  Is there something wrong at the root
level?  Who would I speak with about that?

Thanks for any help/clues that you can provide.

-- 
Todd Herr                                                   therr at va.rr.com
The original text in the above message represents the opinions and thoughts
of the author and does not necessarily represent the views of his employer.




More information about the bind-users mailing list