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

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.

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg