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

From: Ralph Droms <[email-masked]>
Date: Wed, 02 Jul 2003 14:09:36 -0400

This issue generated much discussion, without any
clear consensus on what to do.

You can review the discussion thread starting at
http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg02092.html

Please review the previous discussion and comment
to the mailing list...

- Ralph

At 03:11 PM 6/6/2003 -0400, Ralph Droms wrote:
>DDNS-DHCP issue:
>
>    The RR TTLs need careful attention so that it never exceeds the
>    expiration time of the lease on the associated address.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 2 Jul 2003 19:18:46 +0000

> >    expiration time of the lease on the associated address.

Most of the discussion on this topic revolved around hypothetical extensions 
to the DNS protocol.   While I am interested in talking about these 
extensions, discussion of them neither represents consensus nor lack of 
consensus on this particular document.   If you exclude the discussion about 
TTD from consideration about consensus, I think you will see a different 
picture.

My own position on this is that the problem is already sufficiently addressed 
in the draft.

---

From: Ralph Droms <[email-masked]>
Date: Wed, 02 Jul 2003 15:40:56 -0400

There was some discussion about whether stale information
in the DNS is a problem in practice.  That is, as I
understand the problem, stale information - specifically,
A RRs in which the IP address associated with domain
name foo.example may have been reassigned via DHCP to
a new host using domain name bar.example - is not
a problem.  This stale information may be held in
resolver caches for as much as 1/3 of the original
lease length if the recommendations in the draft
are followed.

So, am I on the right track so far?

If so, it would be helpful to know *why* this stale
information is not a problem.  Might there be
situations in the future where this stale information
might be a problem?

I agree that the discussion of hypothetical extensions
to existing protocols is out of scope...

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Wed, 2 Jul 2003 20:25:19 +0000

On Wednesday 02 July 2003 19:40, Ralph Droms wrote:
> This stale information may be held in

Yup.

> situations in the future where this stale information

It's not not a problem.   It just not a problem for which there is a solution, 
other than "keep the TTL significantly shorter than the lease time."

---

From: Mark Stapp <[email-masked]>
Date: Wed, 02 Jul 2003 17:26:00 -0400

There was a bit of consensus, I think. It's just that there isn't much that 
can be done by the updater, and so there isn't a great deal of change to be 
made.

I posted a message about the discussion, and there was at least a bit of 
agreement that this was a reasonable summary of what should be done to 
clarify the issue in the draft:

>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

-- Mark

At 02:09 PM 7/2/2003 -0400, Ralph Droms wrote:
>_______________________________________________
>dhcwg mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ralph Droms <[email-masked]>
Date: Thu, 03 Jul 2003 08:40:09 -0400

Mark,

I checked through the dhcwg archive, and I found one response
that was mostly in agreement with your summary
(http://ietf.org/mail-archive/working-groups/dhcwg/current/msg02102.html).
We need some more responses to declare "consensus"...

I have a couple of specific comments about your
summary (in-line).

We might want to discuss whether the DDNS TTL
issues are specific to DDNS-DHCP interactions?  If
not, perhaps those issues should be broken out to a separate
document...

- Ralph

At 05:26 PM 7/2/2003 -0400, Mark Stapp wrote:
>There was a bit of consensus, I think. It's just that there isn't much 
>that can be done by the updater, and so there isn't a great deal of change 
>to be made.
>
>>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.

I agree with the first sentence.

Basing the specification on deployment experience is useful.
To provide appropriate background for future readers who
try to implement DDNS-DHCP interaction, the basis for this
sentence from draft-ietf-dhc-ddns-resolution-05.txt:

    The RR
    TTL on a DNS record added for with a DHCP lease SHOULD NOT exceed
    1/3 of the lease time, and SHOULD be at least 10 minutes.

should be explained.  If I were making decisions about deploying
DDNS updates, I would want to know that these numbers came
from operational experience, and it would help to get whatever
insights might be available into why the stale DNS information
hasn't been a problem in practice.

I'm thinking specifically that, for example, the document might
include text based on this exchange from the mailing list:

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

>>consequences of 'stale' records might be. I'll add text about the 
>>benefits to removing dhcp-added dns records when leases expire.

Does the first sentence include the potential problems from
stale DNS information resulting from the recommended TTLs
even if the DHCP-added DNS records are promptly removed?

kre wrote:

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

If we have consensus that this example of stale information truly isn't
a problem,

Also, if I were thinking about this issue for the first time,
it would occur to me that the problem could be mitigated
by:

* reducing the TTL prior to the expiration of the lease
* setting the TTL to something much shorter than 1/3 of
   the original lease (perhaps even 0), if I expect few
   queries to the dynamically updated name

I understand it's difficult to anticipate every possible
idea (hare-brained or otherwise) that someone might dream
up.  Seems to me it would be a good idea to write down
what we can to give guidance in the future...

>>changes to the dns become universally visible.

It would help future readers a lot, I think, to give
more explanation about why these ranges and defaults
were selected and how they minimize damage.  Otherwise,
the experience and wisdom that went into these recommendations
will be lost...

>>names or addresses in limbo in some way for some period of time after 

OK.