At 0:36 +0100 3/10/09, Anand Buddhdev wrote:
We are aware that around 1% of the servers we have in our list did not resolve to addresses, which resulted in these false positives. We are taking steps to ensure that we eliminate as many of these as possible in future probes.
Servers that cannot be reached are not "lame" per se. The origin of the concern over lameness (excepting the desire for complete correctness by some) was in an old resolver implementation that didn't know that a referral to the root was an indication of lameness and not a referral to be followed. When this old resolver queried a server without a response (including not finding an IP address for the server's domain name), it stopped asking and thus was not a problem. When the resolver got a response and it was a referral to the root problems ensued. In at least three RFCs lame servers are defined to be servers that are not authoritative for the zones they are thought to be authoritative for. To detect that, the querier has to get a response. So, for a server to be considered lame by a resolver (that's the "eye of the beholder" here), the server must have an IP address, be reachable, and respond. For the lame testing I've written, I've always listed servers by IP address and not domain name. That is because some registrants would list multiple NS records with different domains, all pointing to the same IP address. In one instance, three NS records each pointed to three IP addresses, but all sets of the three IP addresses were identical. That is: silly.example. NS ns1.silly.example. silly.example. NS ns2.silly.example. silly.example. NS ns1.silly.example. ns1.silly.example. AAAA ::1 ns1.silly.example. AAAA ::2 ns1.silly.example. AAAA ::3 ns2.silly.example. AAAA ::1 ns2.silly.example. AAAA ::2 ns2.silly.example. AAAA ::3 ns3.silly.example. AAAA ::1 ns3.silly.example. AAAA ::2 ns3.silly.example. AAAA ::3 So, my recommendation when implementing a lame server test - stick to the IP addresses and test them. If there is no IP address available, don't try to test - the problem may lie in the forward map, getting to the forward map, etc., and may just be too confusing to explain. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Getting everything you want is easy, if you don't want much.