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

From: Robert Elz <[email-masked]>
Date: Thu, 19 Jun 2003 18:19:16 +0700

Date:        Wed, 18 Jun 2003 09:12:03 -0400
    From:        Ralph Droms <[email-masked]>
    Message-ID:  <[email-masked]>

  | That is, the important problem to avoid is cached DNS
  | information about an address that has been assigned
  | to a different host.

Maybe there's something missing here, but I don't understand why
this is supposed to be an important problem.

That is, reworded, to make sure my understanding is correct, the
problem to be avoided is having a name referring to an address that
is now to be assigned to a different name ?

Who cares?

I mean, it is nice to have everything cleaned up, but there's nothing
that can be done that can possibly guarantee that there isn't another
name around referring to a particular address (there's no practical way
to locate one - that would require IQUERY which we don't have...)

The problem that you want to avoid, is having an old address still
associated with the name to which a new address is being assigned.
That's because it starts to be a gamble which address you will get
when the name is looked up (depending upon which server happens to
respond, and which cache contains what information).

  | Based on Ed's take on the problem, an alternative solution
  | to the TTL problem is to:
  | 
  | * the DHCP server adds an RR for host H with TTL set
  |   to some fixed value t
  | * the DHCP server removes the RR when the lease on the
  |   address assigned to H expires at time T

At this point, the old address for H is still potentially floating around
the DNS until T+R+r*n+t (worst case, T+E+t) - where R is the "refresh"
timer in the SOA, 'r' is the retry timer, n is the number of refresh
retries it takes (n >= 0), and 'E' is the zone expire timer).

  | * the DHCP server does not make the address previously
  |   assigned to H available for reassignment until T+t

That achieves nothing useful in any practical sense.

What is needed would be to not assign H a new (different) address
until after (at least T+t) (but to be ultra safe, T+E+t).

Of course, doing that means causing H to be without an address for
something (which in some zones) may be as long as a month.   Hardly
practical.

  | Another observation - is it possible that the issue of
  | stale cached DNS information has never been an issue
  | in practice because DNS information installed by a DHCP
  | server is rarely used, so that stale DNS information
  | is insignificant?

Most likely, yes.   If 't' isn't set very large (which for dynamically
assigned addresses it should not be) and the DNS servers communicate
with each other properly, the only effect is that someone attempting
to contact the host with the dnuamic address, by name, might fail for
a while after a new assignment has been made.   Most hosts with dynamic
addresses aren't contacted by name anyway.

  | If the RRs installed by the DHCP server are rarely queried,
  | another alternative would be to simply set the TTL to 0,
  | or to set the TTL initially to t, and then t seconds
  | before the expiration of the lease on the address, set
  | the TTL to 0.

Those can help, but the 't' interval isn't really the one to worry
about, the hard case is where a secondary server has the old information
and then loses contact with the primary server - and you have to wait for
its copy of the zone to expire before it stops handing out the bad
address.

  | It seems that the guidance currently given in
  | draft-ietf-dhc-ddns-resolution-05 will lead to a period
  | of time equal to 1/3 the original lease time during
  | which cached DNS data may associate a DNS name with
  | an IP address that has been reassigned to a different
  | host.  This potential problem may not have been realized
  | in practice because the DNS information about a host
  | updated by a DHCP server is rarely queried.

That potential problem hasn't been realised because no-one would
care in the slightest if it happened.   This is simply irrelevant.

I'm sure the problem of attempting to contact a host, and being told
to try its previous address, has been seen, but rarely.

kre

--
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: Thu, 19 Jun 2003 12:40:56 -0500

> is now to be assigned to a different name ?

Let's say machine X has an SMTP listener, and machine Y also has an SMTP 
listener.   Machine X gets an IP address, Z, from the DHCP server.   Then the 
owner of Machine X wanders away, leaving the lease active.   The lease 
expires, and then machine Y gets the address.   But there is still an A 
record for machine X pointing at IP address Z.   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.   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.

Of course, I would say that this is a broken configuration anyway - you really 
want to use protocols that verify who they're talking to if you have a mobile 
computer.   But that's the basis for caring about this sort of thing, and 
while I don't think we can completely solve the problem, it's worth setting 
things up to minimize the damage that occurs in cases like this.

---

From: Ralph Droms <[email-masked]>
Date: Thu, 19 Jun 2003 17:33:07 -0400

I agree with Ted ... in fact, I had a conversation about
exactly this problem earlier today.

In theory, any application shouldn't depend on just DNS to
identify and establish contact with the correct endpoint
(server).  In practice, we have many such applications
deployed today, so we should be careful not to provide
another path for breakage...

- Ralph

At 12:40 PM 6/19/2003 -0500, Ted Lemon wrote:
>_______________________________________________
>dhcwg mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Robert Elz <[email-masked]>
Date: Fri, 20 Jun 2003 04:38:25 +0700

Date:        Thu, 19 Jun 2003 12:40:56 -0500
    From:        Ted Lemon <[email-masked]>
    Message-ID:  <[email-masked]>

  | 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

---

From: Mark Stapp <[email-masked]>
Date: Thu, 19 Jun 2003 18:06:23 -0400

Would this be a reasonable summary of the discussion on this topic?

1. the looseness of the coupling among primary, secondary, and caching dns 
servers makes it unrealistic to guarantee that no query will see stale 
records. the deployment experience that we have does not indicate that this 
is a problem.

2. this section of the draft should make the issues about dns ttls and 
caching more explicit, so that it's clearer what the operational 
consequences of 'stale' records might be. I'll add text about the benefits 
to removing dhcp-added dns records when leases expire.

3. the simple ttl guidelines that are in the draft are present to give 
implementors (and administrators) some clue about reasonable ranges and 
defaults. the guidelines are meant to help folks avoid hare-brained 
configurations (what Robert calls "minimizing damage"); the guidelines 
aren't intended to provide a guarantee about how long it may be before 
changes to the dns become universally visible.

4. it's not worthwhile to impose new requirements on DHCP servers to put 
names or addresses in limbo in some way for some period of time after 
leases expire.

-- Mark

---

From: Edward Lewis <[email-masked]>
Date: Thu, 19 Jun 2003 19:55:15 -0400

>records.  the deployment experience that we have does not indicate that this

That's certainly true.  My suggestion neglected the fact that a slave 
server could be out of date with respect to a master.  (It's a 
problem less and less though with NOTIFY, but it's a possibility 
still.)

>2. this section of the draft should make the issues about dns ttls and caching
>more explicit, so that it's clearer what the operational consequences of
>'stale' records might be. I'll add text about the benefits to removing
>dhcp-added dns records when leases expire.

Yup.

>configurations (what Robert calls "minimizing damage"); the guidelines aren't
>intended to provide a guarantee about how long it may be before changes to
>the dns become universally visible.

Yup.

>4. it's not worthwhile to impose new requirements on DHCP servers to put names
>or addresses in limbo in some way for some period of time after leases expire.

Perhaps, I suppose that it isn't DHCP's problem if the DNS has too 
much persistence...;)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

...as graceful as a blindfolded bull in a china shop...