mats> For the *delegation* to be lame it is not enough for one name mats> server to be ``broken''. The entire set must be such that the path mats> to the child zone content is not available.
mats> For individual name servers it could be meaningful that say that mats> it is a *lame name server* in relation to a certain zone. Paul> I like this distinction. Agree that calling just one server not working Paul> is a lame name server. Paul> Still want better clarity for lame delegation on if we really care why Paul> we aren't getting auth/AA responses from at least one nameserver. If no Paul> listed nameserver gives auth/AA, I'd call that a clear criteria for lame Paul> delegation, regardless of the underlying reason, at least as far as a Paul> recursive server should care. Paul> Humans debugging may care but I don't see a "better" definition of lame Paul> server really informs that debugging process. I agree with you. The first step is to see that the delegation is lame or the server is lame. That is enough to conclude that the service is not provide at all (lame delegation) or from that server (lame server, repectively. The second step is to analyze why – no IP address avaiable, the IP address not reachable, server not responding with a DNS response, unexpect RCODE value or not authoritative. And the second step is for how to resolve the lameness. Yours, Mats --- Mats Dufberg mats.dufb...@internetstiftelsen.se<mailto:mats.dufb...@internetstiftelsen.se> Technical Expert Internetstiftelsen (The Swedish Internet Foundation) Mobile: +46 73 065 3899 https://internetstiftelsen.se/
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
