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

    Date:        Wed, 18 Jun 2003 09:12:03 -0400
    From:        Ralph Droms <rdroms@cisco.com>
    Message-ID:  <4.3.2.7.2.20030618091029.00b76578@funnel.cisco.com>

  | 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

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