Matt Pusateri wrote:
Actually, you didn't miss anything. What you understood is correct, and is actually perhaps the most useful use of the "lame server" feature. In the case you mentioned, if example.com had *removed* an NS entry, yet you.isp.net had it cached, and you were using your ISP for recursive lookups, it goes something like this.... Wouldn't it also be possible for a server to be lame due to a valid DNS change that hasn't propagated through to all name servers yet. For example, you make a request to your ISP name server since you are using it as a forwarder. They have example.com cached so they give you the NS from their cache.
Your ISP tries to lookup newquery.example.com Your ISP finds 3 cached NS records for example.com Here, two things can happen...
If
Your ISP chooses one of the cached NS records at random, and happens to pick the one that is no longer valid
It queries the server, gets a non-authoritative response, and marks it as lame.
Since it's lame, it won't query it again any more for that domain, until it expires from it's local cache.
It will then choose another of it's cached NS records and try again.
Else...
Your ISP chooses one of the cached NS records at random, and happens to pick one of the still-valid NSes
Hopefully, the new NS has correct NS records. It will return the new NS records as glue along with your query
The name server will see an authoritative update of the NS records, and drop the old no-longer valid record
In the situation where *none* of the records your ISP has cached are valid, it will try them each in turn, mark them as lame, and then eventually fall back to querying the com servers again for example.com. If after getting a response from the com servers back, and all of those responses are lame, it will give up entirely with an error.
Tanner's distinction was useful to understand, but there are situations like what you originally had in mind, they're just very short-lived, as they only happen during maybe a 48 hour window, and are usually involved in the proper functioning of cache updating.
Aaron S. Joyner -- TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug TriLUG Organizational FAQ : http://trilug.org/faq/ TriLUG Member Services FAQ : http://members.trilug.org/services_faq/ TriLUG PGP Keyring : http://trilug.org/~chrish/trilug.asc
