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

[Ralph Droms <[e-mail]>]

I originally posed the issue:

   The RR TTLs need careful attention so that it never
   exceeds the expiration time of the lease on the
   associated address.

Ed Lewis has suggested an alternative wording (based on his
e-mail, included below):

   The RR TTLs need careful attention so that cached DNS
   information is never in conflict with the current
   assignment of an IP address to a host.

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

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
* the DHCP server does not make the address previously
  assigned to H available for reassignment until T+t

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?  Put another way, do we have any
experience with DDNS updates for a host that has obtained
its IP address through DHCP and that is the target of
frequent DNS queries; for example, a host running a
web server whose address is found through a DNS query?

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.

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.

- Ralph


At 08:19 PM 6/11/2003 -0400, Edward Lewis wrote:
>Let's face it, DNS doesn't handle change well.  And, worse yet, neither does security.  That and DHCP , the reason we are here, loves change.
>
>One problem is that we are once again (to DNS'ers) mixing relative time (TTLs) and absolute time (a lease is from fixed time A to fixed time B).  (I realize a lease can be extended, renewed, etc., but at any moment, it's a fixed span.)  The same problem exists in DNSSEC's signature records and their validity spans.  The concrete dilemma is - if I set the TTL to be (B-A)/3, as suggested, then the PTR/A[AAA] record will have the same value whether t=A or t=B.
>
>The best thing would be for a merge of the DNS server and DHCP server so that the TTL is always set to (B-NOW)-fudge, which is what we really want.  'Course, if we also wanted DNSSEC, we'd have to sign on the fly (which is why I mentioned security above).
>
>I'd suggest that if the DHCP server has a period of time in which it will not reassign/reallocate an address after a lease has been allowed to elapse, that this is the period to use for the TTL.  It represents the amount of time that erroneous information in a DNS cache can exist and not be of harm to an active node.
>
>The DNS data is just as "dirty" but if the DHCP hasn't given the address to another node, there's a win in there somewhere.
>
>At 15:48 -0400 6/6/03, Mark Stapp wrote:
>>I've replied to Patrick; I'm not quite sure what more to do with issue [6].
>>
>>The draft recommends using a ttl that's a fraction of the lease time, and recommends removing rrs promptly when the lease expires. There have been at least a couple of exchanges about this over the years, and the conclusion has always been that it's not possible to come up with a single set of values that are appropriate in every situation. Also, it's not possible to compel updaters to perform additional updates to 'back down' rrs' ttls as a lease approaches its expiration - that'll kill the dns server. As I noted in the other email I sent, the recommendations that are in the draft are the most up-to-date ones that I've been offered.
>>
>>We do have quite a bit of deployment experience with dhcp updates to dns, and this has not been an issue, as far as I can recall. I also don't recall any email to the wg indicating that this has been an issue in anyone else's experience. If someone has followed these recommendations and has found problems with them, then by all means let's come up with better recommendations.
>>
>>-- Mark
>>
>>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.
>>>
>>>This issue was anticipated by Patrick Cosmo:
>>>
>>>On Fri, 6 Jun 2003, Cosmo, Patrick wrote:
>>>
>>> > I have found some minor issues with the
>>> > <draft-ietf-dhc-ddns-resolution-05.txt>, I apologize if they have already
>>> > been brought up.
>>> >
>>> > In particular, this statement in section 5. (DNS RR TTLs) on page 5:
>>> >
>>> > "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."
>>> >
>>> > 1. This sentence has some bad grammar ("for with" : ... record added for
>>> > with a DHCP lease ...).
>>> >
>>> > 2. The statement is contradictory if the lease time is less than 30 minutes.
>>> > When the lease time is less than 30 minutes, which suggestion takes
>>> > precendence? : min. 10 minutes, or max or 1/3 lease time?
>>> >
>>> > 3. The section seems intended to suggest a reasonable TTL for these records,
>>> > but doesn't seem to pull through or suggest much of anything (IMHO) other
>>> > than "it should be a function of lease time, and it should be configurable".
>>> >
>>> >
>>> > Patrick Cosmo
>>> >
>>> > Senior Product Engineer
>>> > Incognito Software Inc
>>> > Vancouver: [phone] ext: 254
>>> > Toll-Free: 1-800-877-1856
>>> > http://www.incognito.com
>>> >
>>> >
>>> >
>>> > -----Original Message-----
>>> > From: Ralph Droms [mailto:[e-mail]]
>>> > Sent: Thursday, June 05, 2003 7:36 PM
>>> > To: [e-mail]; [e-mail]
>>> > Subject: [dhcwg] Issues in DDNS-DHCP interaction drafts
>>> >
>>> >
>>> > The following drafts have passed WG last call:
>>> >
>>> > [1] A DNS RR for Encoding DHCP Information (DHCID RR)
>>> >     <draft-ietf-dnsext-dhcid-rr-06.txt>
>>> >
>>> > [2] The DHCP Client FQDN Option
>>> >     <draft-ietf-dhc-fqdn-option-05.txt>
>>> >
>>> > [3] Resolution of DNS Name Conflicts Among DHCP Clients
>>> >     <draft-ietf-dhc-ddns-resolution-05.txt>
>>> >
>>> > Several issues regarding these drafts have been identified
>>> > during the AD review prior to IESG review for Proposed
>>> > Standard status.  I will initiate discussion threads on
>>> > each of these issues later today with e-mail to both
>>> > the dhcwg and namedroppers mailing lists.  Please respond
>>> > just to the dhcwg mailing list to avoid duplicate postings...
>>> >
>>> > - Ralph
>>> >
>>> > _______________________________________________
>>> > dhcwg mailing list
>>> > [e-mail]
>>> > https://www1.ietf.org/mailman/listinfo/dhcwg
>>> >
>>>_______________________________________________
>>>dhcwg mailing list
>>>[e-mail]
>>>https://www1.ietf.org/mailman/listinfo/dhcwg
>>
>>
>>--
>>to unsubscribe send a message to [e-mail] with
>>the word 'unsubscribe' in a single line as the message text body.
>>archive: <http://ops.ietf.org/lists/namedroppers/>
>
>-- 
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>Edward Lewis                                            [phone]
>ARIN Research Engineer
>
>Okay, okay, the previous sig wasn't all that good...


_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg