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

From: Bruce Campbell <[email-masked]>
Date: Tue, 24 Jun 2003 13:29:20 +0200 (CEST)

[ TTD for clients ]

On Mon, 23 Jun 2003, David Vixie wrote:

> [robert campbell]
> > What do clients see from tinydns?  Eg, for a record of 'dying.example.com'
> > which should expire at T+1500, would it be:
> >
> > So, Client A and Client B have _nearly_ the same RR set, just with
> > different TTLs.
>
> no.  ttl does not affect rrset identity.  per [rfc2136 1.1.1] et al.

Right.  So it would be easy to implement TTD inside a nameserver (ref
tinnydns), and provide records to clients with appropriate TTLs without
fear of increasing traffic abnormally (the clients won't come back until
the record expires), and, theres no protocol change involved.  End of
argument as far as DNSEXT is concerned.

[ propagating TTD information to slaves ]

Paul Bernstein wrote:

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

So... if a record is due to expire in 1500 seconds, and you know that the
slave 'should' transfer the zone again via axfr in 1300 seconds (via SOA
values), you will merrily supply a 2 second TTL on said records, thus
causing the slave to incur unneeded traffic from clients who effectively
cannot cache the record at all and must requery for the record each time
they want it.  ( For instance, someone taking 3 seconds to reach a web
page and clicking on the 'Next' link, resulting in the record being looked
up again )

Of course, you'd argue that its because the slaves are using an outdated
protocol, but it strikes me that you've coded your nameserver to be
intentionally irritating.  'Wow'.

Supplying TTLs for expiring records based on the SOA TTL/etc values (with
dropping back to 2 second TTLs for those records which should be expired
before the slaves next refresh themselves) would be more sensible.

Still, when new records are created, you have to propagate the information
outwards.  Rsync, AXFR and IXFR are all unsuitable for this in a
frequently changing environment due to their associated overhead. Dynamic
updates sent from the master to each slave are more prompt, although you
still have the housekeeping of removing the records once they should have
expired (in the absence of remove-after values being able to be sent), and
liable to be lost (but will get picked up on the next zone transfer).
Wait, aren't we back at the start again?

--==--
Bruce.

--
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: "D. J. Bernstein" <[email-masked]>
Date: 24 Jun 2003 19:26:53 -0000

Bruce Campbell writes:
> values), you will merrily supply a 2 second TTL on said records

Correct. Yes, short TTLs cause minor increases in the frequency of DNS
lookups, but long TTLs cause administrative headaches. If the next AXFR
is delayed, the old data will stick around longer than it should. 

> frequently changing environment due to their associated overhead.

Actually, rsync and tinydns-data can make any number of updates to a
multiple-megabyte database in well under a second on a typical computer.

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