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

Robert Elz <kre@munnari.OZ.AU> Thu, 19 June 2003 21:46 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 RAA20615 for <dhcwg-archive@odin.ietf.org>; Thu, 19 Jun 2003 17:46:41 -0400 (EDT)
Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5JLkEj12612 for dhcwg-archive@odin.ietf.org; Thu, 19 Jun 2003 17:46:14 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T7EU-0003HL-Hv for dhcwg-web-archive@optimus.ietf.org; Thu, 19 Jun 2003 17:46:14 -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 RAA20550 for <dhcwg-web-archive@ietf.org>; Thu, 19 Jun 2003 17:46:10 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T7CB-0003pm-00 for dhcwg-web-archive@ietf.org; Thu, 19 Jun 2003 17:43:51 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19T7CA-0003ph-00 for dhcwg-web-archive@ietf.org; Thu, 19 Jun 2003 17:43:50 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T7EI-00039l-GO; Thu, 19 Jun 2003 17:46:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T7Dy-00038o-Ec for dhcwg@optimus.ietf.org; Thu, 19 Jun 2003 17:45:42 -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 RAA20514 for <dhcwg@ietf.org>; Thu, 19 Jun 2003 17:45:38 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T7Bf-0003pJ-00 for dhcwg@ietf.org; Thu, 19 Jun 2003 17:43:19 -0400
Received: from ip25.coe.tnet.co.th ([203.146.155.25] helo=fuchsia.home) by ietf-mx with esmtp (Exim 4.12) id 19T7Bc-0003pF-00 for dhcwg@ietf.org; Thu, 19 Jun 2003 17:43:17 -0400
Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id h5JLiqlw018239; Fri, 20 Jun 2003 04:44:52 +0700 (ICT)
Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h5JLcPF14809; Fri, 20 Jun 2003 04:38:27 +0700 (ICT)
From: Robert Elz <kre@munnari.OZ.AU>
To: Ted Lemon <mellon@fugue.com>
cc: dhcwg@ietf.org, namedroppers@ops.ietf.org
Subject: Re: [dhcwg] DDNS-DHCP [6]: Relationship between DNS TTL and DHCP lease length
In-Reply-To: <200306191240.56057.mellon@fugue.com>
References: <200306191240.56057.mellon@fugue.com> <4.3.2.7.2.20030618091029.00b76578@funnel.cisco.com> <14436.1056021556@munnari.OZ.AU>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 20 Jun 2003 04:38:25 +0700
Message-ID: <22680.1056058705@munnari.OZ.AU>
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>

    Date:        Thu, 19 Jun 2003 12:40:56 -0500
    From:        Ted Lemon <mellon@fugue.com>
    Message-ID:  <200306191240.56057.mellon@fugue.com>

  | So now, machine Q connects to Z because of that A record, and tries
  | to drop mail for X on Y.   Y will either bounce it immediately,
  | or bounce it after it notices that the A record for X is pointing at it.

And if the A record had been deleted, the mail would just have bounced.
That's a lot of diffrence...  (yes, I know in the latter case there could
be a lower priority MX, which would take the mail, but then it would ...)

  | So we'd really like it if the time that the A 
  | record goes away and the time that the lease goes away are fairly close 
  | together, so that the chances of this happening are slim.

No problem with that, I agree that cleanup is a good idea, and getting rid
of old stuff ought be done.

I just don't see the particular problem as being anything so serious that
it warrants particular attention.

That is, the more serious problem is not being able to connect to a host
that you should be able to connect to, because you were given an out of
date address, than not being able to connect to a host that you cannot
possibly connect to anyway, because its address is now in use by someone
different.

  | Of course, I would say that this is a broken configuration anyway

Agree, but broken or not, those are configurations that people use, so if
it did cause serious problems, we'd need to worry about, and fix them.
I just don't see the problems as so serious that anyone needs to devote
much attention to them.

Or, put it another way, anyone, anywhere, can stick any address in a A
(or AAAA) record.   That can easily cause some random other name to refer
to a host which has its own name mapped to the same address.   This is with
or without DHCP being involved.   You cannot possibly hope to make that
name go away, or change its A record (you cannot even find it).

I suspect though, that if the dhcp server, when updating the DNS, does the
best job it can to make sure that old addresses aren't floating around for
the name it is managing, that will (by some happy co-incidence) also cause
the problem that was mentioned as being serious (which isn't) to get solved
at the same time.

That is, there are 2 names involved, each being managed by a separate instance
of the state machine - rather than having one of those attempt to clean up
the other one (by not allowing the address to be allocated for an extra
delay period - which would be a nightmare in some address deprived 
environments) just allow each to clean up after itself.   That way the old
address for name X gets deleted, when the lease expires, or as close to that
as practical, which also means that X no longer has the address that we want
to now assign to Y, and we don't have to delay that assignment to make it
happen.

kre


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