Bind and possible redundancy flaw.
Kevin Darcy
kcd at chrysler.com
Thu Feb 21 22:01:05 UTC 2008
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
More information about the bind-users
mailing list