Bind and possible redundancy flaw.

[Noah McNallie]

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