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

From: Robert Elz <[email-masked]>
Date: Fri, 20 Jun 2003 16:44:14 +0700

Date:        Thu, 19 Jun 2003 21:03:52 -0400
    From:        Michael Richardson <[email-masked]>
    Message-ID:  <[email-masked]>

First, Mark's summary looked fine to me.

But ...

  | As such, what I really want is a dynamic update operation which actually
  | says "install this record with TTL=XXX, deleting the record after YYY"
  | (Clearly, XXX < YYY, and some may argue YYY:=XXX. I'm undecided)

The XXX & YYY relationship isn't important here but XXX << YYY (in the
mathematical << sense, not "shift left") if this were to have any hope
of working.

But yes, that's what almost everyone wanted when dynamic update was
being defined - and a lot of effort was spend attempting to find
something which would actually work like that.   Unfortunately,
nothing reliable could be found, so that is not what exists.

You can try and dream up a protocol to allow this to work, but
first please go and review all the archives from when dynamic
update was being designed, and then again since then whenever anyone
has suggested it since - it is not nearly as simple to make work
properly as it seems it should be - and if it can't be guaranteed
to work, then the host has to deal with it other ways anyway.

  | I have really no problem sending a new update every couple of minutes.
  | In fact, I'd prefer to do this.

Unfortunately, by itself, that doesn't help - that was the original
plan for this (you need to investigate the way the whole DNS works,
including the primary/secondary relationship, and servers that crash at
inconvenient times, to see the problems).

kre

---

From: "D. J. Bernstein" <[email-masked]>
Date: 20 Jun 2003 19:47:34 -0000

tinydns has supported time-to-die since version 0.85 in February 2000.
It automatically reduces the TTL as the time-to-die approaches, and then
eliminates the record. See http://cr.yp.to/djbdns/tinydns-data.html.

The obsolete AXFR replication protocol is unable to copy time-to-die
information. This is one of the many reasons that I recommend rsync for
replication. See http://cr.yp.to/djbdns/tcp.html#intro-axfr.

Client systems running the clueless ``nscd'' program will keep data for
an hour no matter what the TTL says, but at least there's some limit.
Perhaps nscd will be fixed someday.

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

---

From: Ted Lemon <[email-masked]>
Date: Fri, 20 Jun 2003 10:54:05 -0500

> eliminates the record. See http://cr.yp.to/djbdns/tinydns-data.html.

We discussed and rejected time-to-die as a solution to this problem a couple 
of meetings back (I think in Tokyo) because 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.   So I'm very interested to know that somebody has actually 
tried this experiment.

What's your experience with this - do you have any measurements about what 
happens in practice as the time to die approaches?

---

From: "D. J. Bernstein" <[email-masked]>
Date: 20 Jun 2003 22:43:47 -0000

> 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. Exception: some broken
programs like nscd keep the record for a while.

The overall effect is similar to what happens when you manually set a
low TTL. The advantage is that setting a time-to-die allows extra
caching before the time-to-die; a low TTL doesn't. (There's also a
user-interface advantage of scheduling the change in advance, but this
isn't a protocol issue.)

> 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''?