[dns-operations] Missing .us and GTLD records??

[Luis Uribarri]

Believe it or not, some resolvers do not actually do this, (or at least 
do not appear to act in this way)

>From RFC 1035
>Some fine points:
>
>   - The resolver may encounter a situation where no addresses are
>     available for any of the name servers named in SLIST, and
>     where the servers in the list are precisely those which would
>     normally be used to look up their own addresses.  This
>     situation typically occurs when the glue address RRs have a
>     smaller TTL than the NS RRs marking delegation, or when the
>     resolver caches the result of a NS search.  The resolver
>     should detect this condition and restart the search at the
>     next ancestor zone, or alternatively at the root.

This may have been becasue of recent vulnerability discoveries and/or 
changes in how SLIST is handeled by certian resolvers. (Not necessarily 
BIND) But I have seen live domains go into SERVFAIL mode on some resolvers 
becasue of Glue NS TTL and the Glue A TTL being different in an 
in-baliwick delegation.

I have seen many situations where not being able to find a "name servers 
name", can casue issues.

If everyone in the world was using the exact same DNS Resolver software, 
then issues on  Authoritative servers that caused problems with some 
resolvers but not otthers would not matter.

But for a TLD, everyone in the world has to use the same Auth servers. 
Not everyone uses the same resolver software.

Make the Auth Servers and Auth server delegations they provide bulletproof,
and you don't have to worry about resolvers that behave differently 
"breaking".




On Fri, 21 May 2010, Paul Vixie wrote:

>> Date: Fri, 21 May 2010 13:36:12 -0400 (EDT)
>> From: Luis Uribarri <uribarri at alum.mit.edu>
>>
>> Because now every resolver now has a way of contacting every "name server
>> name" regarless of wheater the IPv6 transport is operational.
>
> this is buffoonery. or are you just trolling? please come back when you have
> read RFC 1035 7.2 and you know what an SLIST is and how it's built/used.
>