Bind and possible redundancy flaw.

[Mark Andrews]

> 22:45 < n0ah> hey guys, i think i've found a potential bind flaw
> 22:48 < n0ah> it seems that if I have a NS in my list of name servers 
> that has no records for the domain being queried, half the internet
>               will not resolve the query at all, ie say i have two name 
> servers for an ip range, if the 2nd listed contains no records,
>               half the internet will fail the lookup 100%, though with 
> dig +trace it does the right thing, if the second server with no
>               records is queried
> 22:48 < n0ah> the second server with no records will loop back around 
> and give root records, then back to arin records for the ip range,
>               then back to the good name server, and the query succeeds
> 22:48 < n0ah> i know that makes it sound like a client issue, though i'm 
> not sure how bind is dealing with this recursively
> 22:49 < n0ah> but it seems some i've tried to do the query with the 
> second in the list, and it'll just fail everytime as long as there is
>               an NS with no records listed as a nameserver
> 22:49 < n0ah> quite a few
> 22:49 < n0ah> some servers handle it just fine (using the same client, 
> such as dig, querying their nameservers direcetly)(
> 22:50 < n0ah> this does not seem redundant, how will these places handle 
> a large failure (which is what it's supposed to be all built off
>               of the idea).. what if a 4th nameserver expires on a zone 
> refresh.. and due to routing it can't talk to the parent name
>               server to get the zone for whatever the timeout is, 24 
> hours is common
> 22:50 < n0ah> then, which ever of these users can access the 4th server 
> (it seems if a server isn't accessible, bind will just goto the
>               next and it's no problem)
> 22:51 < n0ah> will get failed queries because the 4th is up, though the 
> 4th has no records
> 22:52 < n0ah> i'll look for the bind mailing list, i get a feeling this 
> channel is pretty quiet
> 
> n0ah

	nameservers work out which servers are correctly configured
	and which ones arn't.

	"dig +trace" doesn't try to do that.

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org