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

Bruce Campbell <bc-namedroppers@vicious.dropbear.id.au> Tue, 24 June 2003 17:11 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24782 for <dhcwg-archive@odin.ietf.org>; Tue, 24 Jun 2003 13:11:34 -0400 (EDT)
Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5OHB8016387 for dhcwg-archive@odin.ietf.org; Tue, 24 Jun 2003 13:11:08 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UrK0-0004GE-3D for dhcwg-web-archive@optimus.ietf.org; Tue, 24 Jun 2003 13:11:08 -0400
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24629 for <dhcwg-web-archive@ietf.org>; Tue, 24 Jun 2003 13:10:30 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UrIw-00042U-EO; Tue, 24 Jun 2003 13:10:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Um2D-00076w-Kr for dhcwg@optimus.ietf.org; Tue, 24 Jun 2003 07:32:25 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12293 for <dhcwg@ietf.org>; Tue, 24 Jun 2003 07:32:09 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Um1x-0002IS-00 for dhcwg@ietf.org; Tue, 24 Jun 2003 07:32:09 -0400
Received: from birch.ripe.net ([193.0.1.96]) by ietf-mx with esmtp (Exim 4.12) id 19Um1m-0002HD-00 for dhcwg@ietf.org; Tue, 24 Jun 2003 07:31:59 -0400
Received: from x22.ripe.net (x22.ripe.net [193.0.1.22]) by birch.ripe.net (8.12.9/8.11.6) with ESMTP id h5OBTKRT004063; Tue, 24 Jun 2003 13:29:20 +0200
Date: Tue, 24 Jun 2003 13:29:20 +0200
From: Bruce Campbell <bc-namedroppers@vicious.dropbear.id.au>
X-X-Sender: bc@x22.ripe.net
To: namedroppers@ops.ietf.org
cc: dhcwg@ietf.org
Subject: Re: [dhcwg] DDNS-DHCP [6]: Relationship between DNS TTL and DHCP lease length
In-Reply-To: <20030623174016.B97901396A@sa.vix.com>
Message-ID: <Pine.LNX.4.44.0306241204050.10688-100000@x22.ripe.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Id: <dhcwg.ietf.org>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>

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



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