Negative Caching TTL

Jim McAtee jmcatee at mediaodyssey.com
Tue Dec 16 23:36:56 UTC 2003


----- Original Message ----- 
From: "Kevin Darcy" <kcd at daimlerchrysler.com>
To: <bind-users at isc.org>
Sent: Tuesday, December 16, 2003 3:28 PM
Subject: Re: Negative Caching TTL


> Jim McAtee wrote:
>
> >Can someone explain to me how to best use negative caching TTL.  It's not
> >clear to me if setting this value in the SOA record affects how our BIND
> >9.2.3 servers answer queries, or if the value is open to interpretation by
> >the receiving DNS client.
> >
> >$TTL 1d
> >@ IN SOA ns1.modyssey.net. admin.modyssey.net. (
> >                2003101701  ; serial
> >                4h          ; refresh
> >                30m         ; retry
> >                14d         ; expire
> >                15m       ) ; negative ttl
> >
> >With the above, will older BIND servers see the default TTL for records as
1
> >day or 15 minutes?
> >
> The *positive* caching TTL (what's in the $TTL directive if not
> explicitly overridden on a record-by-record basis) determines how long a
> caching nameserver will remember the value(s) of a particular RRset (set
> of records) that it received from an authoritative server or a forwarder.
>
> The *negative* caching TTL (the value of the last field of the SOA RR)
> determines how long a caching nameserver will remember that a particular
> RRset *does*not*exist*, when told by an authoritative server or a
> forwarder. Note that there are 2 different variations of negative
> caching: NXDOMAIN = name doesn't own any records at all, NODATA (a
> pseudo-response-code) = name owns records, but not of the type requested
> (see RFC 2308 for more details).
>
> To put it more simply, the positive caching TTL governs the persistence
> of records that *do* exist in your zone; the negative caching TTL
> governs the persistence of negative responses, i.e. the persistence of
> record sets that could but *don't* exist in your zone, so to speak.


I realize all that.  I must not have explained myself very well.

That value in the SOA used to be used for the positive TTL.  My confusion
lies in the fact that I still see SOA records for zones with values of 1 day
negative caching TTL.  I'm not sure whether this is just a leftover in the
data from running older versions of BIND or if it's intentional.

Will a newer BIND caching server see that value and honor it as the actual
negative caching TTL for negative answer?  Similarly, does a very low value
here have any affect on the positive caching TTL when older caching name
servers retrieve records (or does BIND answer with an explicit positive TTL
for each record)?




More information about the bind-users mailing list