This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH][BZ #13928] Use minimum ttl value from dns query


On Thu, 29 Mar 2012 20:40:23 -0400
"Carlos O'Donell" <carlos@systemhalted.org> wrote:
> No, that's certainly not correct.
> 
> You have to consider each step in the link independently and look at
> the TTL for each link.
> 
> The CNAME TTL should be used as the TTL for the CNAME record.
> 
> The A|AAAA TTL should be used as the TTL for the A|AAAA record.
> 
> Making the TTL of the CNAME *anything but* the TTL of the CNAME seems
> wrong and misleading.
> 
> In your example for BZ#13928 you have:
> 
> * A default TTL of 1200 (20 minutes)
> * An A record with default TTL named "ad"
> * A CNAME record with 60s TTL named "cad" pointing at "ad"
> * A CNAME record with 15s TTL named "bad" pointing at "cad"
> 
> After the *first* lookup nscd should have the following in the cache:
> 
> * An A record "ad" 1.0.0.1 with TTL 20 minutes.
> * A CNAME record "cad"->"ad" with TTL 60s.
> * A CNAME record "bad"->"cad" with TTL 15s.
> 
> You then modify the A record on the server to be 1.0.0.2 and wait 30
> seconds.
> 
> You hit the server.
> 
> * "bad" is in the cache, but it expired 15s ago.
> * You query the server and get back "bad"->"cad"
> * "cad" is in the cache and it is not expired yet and it is
> "cad"->"ad"
> * "ad" is in the cache and it is not expired yet and it is 1.0.0.1.
> 
> I don't understand why you think this should return 1.0.0.2 after only
> 15 seconds.
> 

All of what you said would have been perfect if:

1) We could query just a single dns resource from the server and update
the 'stale link' as it were, like a caching dns server would
2) nscd was implemented to cache host names as a caching dns server.

Neither of them are true however. A dns query for any host name will
return the complete resource set that describes it, i.e. its aliases as
well as the final A records that define it. So if an alias in the
middle has a smaller TTL (and assuming that nscd can do this), you
still have to make a full query at that lowest TTL to get the updated
resource set.

nscd does not act like a caching dns server and hence it does not
really store resource sets like a DNS server would and cannot request
individual resources independently. Instead, it stores a query result
as a hostent, which is essentially a host name, its list of aliases and
list of addresses. nscd needs to decide on the amount of time it can
afford to wait before it has to consider this record stale and reload
the value from the dns server. This is where the TTL comes into play.

Now since the single record that nscd has can consist of multiple
linked DNS resources and nscd has to decide on a time when it considers
this record as stale, it should be obvious that the minimum TTL among
the resources be used because it is at that minimum TTL that the
record in nscd cache is no longer valid.

--
Siddhesh


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]