Subject: Re: DDNS-DHCP [6]: Relationship between DNS TTL and DHCP lease length

From: Bruce Campbell <[email-masked]>
Date: Mon, 23 Jun 2003 16:14:19 +0200 (CEST)

On 20 Jun 2003, D. J. Bernstein wrote:

> Ted Lemon writes:
> > What's your experience with this - do you have any measurements about what
> > happens in practice as the time to die approaches?
>
> Clients throw the record away shortly after the time-to-die, and ask for
> new data when they need it, exactly as desired.

So far, its server-specific, and the information about the exact time for
ttd to take effect isn't transferrable via AXFR ( which can only transfer
offsets via TTL ).

What do clients see from tinydns?  Eg, for a record of 'dying.example.com'
which should expire at T+1500, would it be:

  Client A requesting 'dying.example.com' at time T receives:
	dying.example.com 1500  IN A 192.168.1.2

  Client B requesting 'dying.example.com' at time T+100 receives:
	dying.example.com 1400	IN A 192.168.1.2

?

So, Client A and Client B have _nearly_ the same RR set, just with
different TTLs.  The end effect is that both Client A and Client B will
drop the record from their cache at the appropriate time.  This is good,
right?

So, the next question is, since Client A and Client B received different
(authoritative) responses, does that mean that there were different
versions of the zone 'example.com' at time T and T+100 ?

If yes, there were different versions of the zone at T and T+100, then the
SOA serial needs to be updated, with the consequent flurry of AXFR
requests from the 'example.com' slaves when they noticed the SOA having
changed.

If no, there were not different versions of the zone (and no SOA serial
change) at T and T+100, then we run into problems with the 'example.com'
slaves giving different TTL values for 'dying.example.com' depending on
when they retrieved the zone.

( This space left blank for an 'AXFR is bad, use rsync' comment )

> > we were concerned that if you do something like this, the effect is
> > going to be a refresh storm as the time to die gets closer
>
> Please define ``refresh storm.'' Do you describe TTL-0 records as
> causing ``refresh storms''?

Section 3.4.2 of Vixies 1996 draft (related to implementation of
time-to-die) has the wording:

   3.4.2 - TTL Half Life

   Each time an RR's expiry reaches half of its previous value, that RR's
   TTL will be reduced to half of its previous value, until the TTL reaches
   a value less than or equal to sixty (60), i.e., one minute of real time,

   <snip>

   Whenever the TTL is automatically reduced by this process, the zone will
   be considered ``changed'' for the purpose of automatic SOA SERIAL
   increment (see [UPDATE 3.6]) and real time zone slave notification (see
   [NOTIFY]).

You could probably do wording such that the only time an SOA serial change
occurs (due to TTL/TTD behaviour) is when an SOA request comes in (so the
version of the zone on your non-time-to-die-internal-magic slave is
correct), but you've still got the problem of differing clients getting
differing versions of RRs in the zone without SOA serial change, which is
not a good precedent.

--==--
Bruce.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 23 Jun 2003 15:09:05 -0000

> versions of the zone 'example.com' at time T and T+100 ?

Of course not; that would be silly. The TTD---which is what caches
actually store anyway---is the same. Queries at different times will
interpret the same TTD as different TTLs, of course, but that doesn't
mean the zone has changed.

If you insist on corrupting the zone by retrieving it through AXFR,
you'll get 2-second TTLs from my AXFR server. Of course, the record also
won't disappear until the next AXFR. The effects on the secondary, and
on clients talking to the secondary, are the same as if you had manually
set a 2-second TTL in the first place.

If you transfer the zone accurately (for example, through rsync), the
secondary will allow more caching before the time-to-die than it would
have with a 2-second TTL, and it will remove the record at exactly the
right time without another transfer.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>