Bind and possible redundancy flaw.

[Kevin Darcy]

Noah McNallie wrote:
> Noah McNallie wrote:
>   
>> Mark Andrews wrote:
>>     
>>>>>     nameservers work out which servers are correctly configured
>>>>>     and which ones arn't.
>>>>>
>>>>>     "dig +trace" doesn't try to do that.
>>>>>
>>>>>     Mark
>>>>>         
>>>>>           
>>>> so it's legit that if a query for a server has a NS listed that has 
>>>> no records for that server, the entire query should immediately fail?
>>>>     
>>>>         
>>>     Put the question in context.  As it is there are so many
>>>     variable left unstated that the answer could be "yes", "no"
>>>     or "maybe".
>>>
>>>     Mark
>>>   
>>>       
>> k, well, it's not too important to get fixed if it's not a normal 
>> scenario. i don't much mind if it gets fixed at all because even if it 
>> was the end of the world i'd be smart enough to get the ips of 
>> anything that was routable to me ;) but just for the sake of curiosity 
>> perhaps, the scenario (although a bit sketchy as it may seem) is 
>> detailed:
>>
>> 2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.0.3.0.7.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa 
>> is the zone
>>
>> this is how that flows:
>>
>> ip6.arpa.               172800  IN      NS      SEC1.APNIC.NET.
>> ip6.arpa.               172800  IN      NS      NS.ICANN.ORG.
>> ip6.arpa.               172800  IN      NS      TINNIE.ARIN.NET.
>> ip6.arpa.               172800  IN      NS      NS.LACNIC.NET.
>> ip6.arpa.               172800  IN      NS      NS-SEC.RIPE.NET.
>> ;; Received 220 bytes from 192.203.230.10#53(E.ROOT-SERVERS.NET) in 
>> 120 ms
>>
>> 0.7.4.0.1.0.0.2.ip6.arpa. 10800 IN      NS      ns2.ipv6.he.net.
>> 0.7.4.0.1.0.0.2.ip6.arpa. 10800 IN      NS      ns1.ipv6.he.net.
>> ;; Received 137 bytes from 202.12.29.59#53(SEC1.APNIC.NET) in 277 ms
>>
>> 5.0.3.0.7.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa. 5000 IN NS ip6.sytes.net.
>> ;; Received 117 bytes from 64.71.189.2#53(ns2.ipv6.he.net) in 122 ms
>>
>> ----
>>
>> ip6.sytes.net points to my solaris/ultrasparc server at home on static 
>> ip assignment. what I had previously done is also had ip6.zapto.org as 
>> a nameserver for the range through he.net's interface to where 
>> ns(1|2).ipv6.he.net would respond with both of them, and this is when 
>> half the internet decided not to succeed on a PTR request for the 
>> range, after removing ip6.zapto.org everything worked fine instantly. 
>> btw, ip6.zapto.org is an A pointing to the A of ns1.earthlink.net 
>> (which had no records because it was simply there so people would not 
>> see one nameserver listend and thing oh yay! ddos! maybe it's his home 
>> server!) and i completely understand that such is not a legit purpose 
>> or reason for the email, it simply made my think further and ask why 
>> half the internet would fail to resolve a query just because one of 
>> the listed name servers has no records pertaining to the query.
>>
>> n0ah
>>
>>
>>
>>     
> sorry that's not the zone, that's the ip i was resolving: 
> http://xzziroz.net/db.xzziroz.5.0.3.0.7.0.f.1.3.7.4.0.1.0.0.2.ip6.arpa
> that should be the zone, i think i was going to add a TXT in there such 
> as TXT  "2001:470:1f07:305::/64 authority"
>   
RFC 1034, Section on Resolvers:

5.3.3. Algorithm

The top level algorithm has four steps:

   1. See if the answer is in local information, and if so return
      it to the client.

   2. Find the best servers to ask.

   3. Send them queries until one returns a response.

   4. Analyze the response, either:

         a. if the response answers the question or contains a name
            error, cache the data as well as returning it back to
            the client.

         b. if the response contains a better delegation to other
            servers, cache the delegation information, and go to
            step 2.

         c. if the response shows a CNAME and that is not the
            answer itself, cache the CNAME, change the SNAME to the
            canonical name in the CNAME RR and go to step 1.

         d. if the response shows a servers failure or other
            bizarre contents, delete the server from the SLIST and
            go back to step 3.

Any standards-conforming full-service resolver will bounce back from 4d to step 3 if it encounters a "lame" server as you have described.

								- Kevin