[TriLUG] Slides from last night's DNS Presentation

[Aaron S. Joyner]

Matt Pusateri wrote:

>... 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.
>
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.

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