Recursive caching servers behavior with lame server answers

[Kevin Darcy]

Tony Schenk wrote:

>I've been doing snoops to see exactly what information comes back in
>packets from "lame" authoratative servers and I'm confused about
>something that is probably pretty basic.
>
>In most cases, my caching/recursive name server *knows* the delegation
>is lame because the putative server reveals the correct authoritative
>server list (which he is not a part of). Why not just follow those NS
>records and get the answer? From what I can see(BIND 9.3.1), it repeats
>the original request (to the original lame server), gets the same list
>of NS records, and returns a SERVFAIL to the downstream requesting name
>server.
>
Why would you think that the NS records from a lame nameserver are any 
more accurate or trustworthy than the delegating NS records from the 
parent zone's nameservers? BIND should be throwing away the NS records 
returned from the lame nameserver. The only reason I can think of why 
BIND would *retry* the query to that same lame nameserver would be if it 
couldn't reach any of the other delegated nameservers, and is trying one 
last time in a last-ditch effort before giving up, in case the lameness 
was only temporary.

                                                                         
                                             - Kevin