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

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

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: (604) 688-4332 ext: 254
>>> > Toll-Free: 1-800-877-1856
>>> > http://www.incognito.com
>>> >
>>> >
>>> >
>>> > -----Original Message-----
>>> > From: Ralph Droms [mailto:[email-masked]]
>>> > Sent: Thursday, June 05, 2003 7:36 PM
>>> > To: [email-masked]; [email-masked]
>>> > 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
>>> > [email-masked]
>>> > https://www1.ietf.org/mailman/listinfo/dhcwg
>>> >
>>>_______________________________________________
>>>dhcwg mailing list
>>>[email-masked]
>>>https://www1.ietf.org/mailman/listinfo/dhcwg
>>
>>
>>--
>>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/>
>
>-- 
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>Edward Lewis                                            +1-703-227-9854
>ARIN Research Engineer
>
>Okay, okay, the previous sig wasn't all that good...

--
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]>(by way of Ted Lemon <[email-masked]>)
Date: Thu, 19 Jun 2003 15:31:18 -0500

On Thursday 19 June 2003 17:06, you wrote:
> Would this be a reasonable summary of the discussion on this topic?
> [...]

Yes.   I think this sums it up nicely.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 19 Jun 2003 21:03:52 -0400

-----BEGIN PGP SIGNED MESSAGE-----

I came to this thread late.

I can understand why this topic came up in the context of DHCP, but it is
really a dynamic update issue. I use nsupdate to update the location
of my laptop. I do this from my dhcp-client, my ppp "ip-up", and from
some manual scripts that I use when all of the above is not useful.
(which is less often, fortunately)

The reason that I say that dhcp is not involved is because it is my
laptop (not the dhcp server) that has the relationship with my forward
domain server.

As such, what I really want is a dynamic update operation which actually
says "install this record with TTL=XXX, deleting the record after YYY"
(Clearly, XXX < YYY, and some may argue YYY:=XXX. I'm undecided)

I have really no problem sending a new update every couple of minutes.
In fact, I'd prefer to do this.

That way, the record goes away sometime after I go away or I loose
connectivity, which is a lot better than the next time I get online!
(And there are lots of places where DNS is forced-proxy, and dyn-update
does not work. I started a list earlier this month, even:
     http://www.sandelman.ca/mcr/hotels/ actually)

In the reverse map space, and in the places where the dhcpd server does
control the forward map, sure - TTL should be less than lease time, and the
dhcpd server SHOULD remove the record when the lease is returned to the pool.
A timed-dynamic update would be easier for that situation too, I think.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: Paul Vixie <[email-masked]>
Date: Fri, 20 Jun 2003 22:13:08 +0000

> > tinydns has supported time-to-die since version 0.85 in February 2000.
> > It automatically reduces the TTL as the time-to-die approaches, and then
> > eliminates the record. See http://cr.yp.to/djbdns/tinydns-data.html.
> 
> We discussed and rejected time-to-die as a solution to this problem a
> couple of meetings back (I think in Tokyo) because we were concerned
> that if you do something like this, the effect is going to be a
> refresh storm as the time to die gets closer.  ...

when the i-d below was proposed, time-to-die was roundly dismissed, for
that reason and plenty of others.

   DNSIND Working Group                                    Paul Vixie (ISC)
   INTERNET-DRAFT                                                  May 1996
   <draft-ietf-dnsind-defupd-00.txt>

   Amends: RFC 1035, [UPDATE]

       Deferred Dynamic Updates in the Domain Name System (DNS DEFUPD)

   Status of this Memo

      This document is an Internet-Draft.  Internet-Drafts are working
      documents of the Internet Engineering Task Force (IETF), its areas,
      and its working groups.  Note that other groups may also distribute
      working documents as Internet-Drafts.

      Internet-Drafts are draft documents valid for a maximum of six months
      and may be updated, replaced, or obsoleted by other documents at any
      time.  It is inappropriate to use Internet-Drafts as reference
      material or to cite them other than as ``work in progress.''

      To learn the current status of any Internet-Draft, please check the
      ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
      Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
      munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
      ftp.isi.edu (US West Coast).

   Abstract

      Not all applications that perform dynamic updates using the protocol
      specified in [UPDATE] want their updates applied immediately.  A case
      in point is [DHCP], wherein the DHCP lease time should control the
      lifetime of associated DNS data even if the DHCP client or server is
      not available at the time the DHCP lease expires.

      The essence of this proposal is that DNS Dynamic Updates should be
      deferrable for some time delay period, after which they will be
      executed normally.  Furthermore, RRs added or updated by a deferred
      update can have expiration times specified for them, as enforced by
      the automatic Dynamic Updates.  Automatic serial number changes (as
      in [UPDATE]), dynamic zone slave notification (see [NOTIFY]) and
      incremental zone transfer (see [IXFR]) will jointly see to it that
      the zone changes are propagated with expedience.

   Expires November 1996                                          [Page 1]

   INTERNET-DRAFT                 DNS DEFUPD                       May 1996

   1 - New Assigned Numbers

      Opcode:   DEFUPD (6?)
      RRtype:   TUU (34?)
      RRtype:   TUE (35?)

   2 - Message Format

   The format and encoding of a DEFUPD is identical to that of UPDATE as
   defined in [UPDATE 2], except that the Opcode is DEFUPD rather than
   UPDATE, and there are two new RR types that can be used in the
   Additional Data section.

   2.1 - Additional Data Section: TUU RR

   In addition to the optional uses described in [UPDATE 2.6], a DEFUPD
   request's Additional Data section can include a TUU (Time Until Update)
   RR as follows:

      Owner:      same as ZNAME (see [UPDATE 2.3])
      Class:      same as ZCLASS (see [UPDATE 2.3])
      Type:       TUU (new RRtype for this protocol)
      TTL:        deferral time, relative, in seconds
      RDLENGTH:   0
      RDATA:      empty

   Of particular note is the TTL, which contains the relative time delay,
   in seconds, starting from the time this DEFUPD is received by the
   primary master, before operations contained in the Update Section (see
   [UPDATE 2.5]) will actually be performed.

   Expires November 1996                                          [Page 2]

   INTERNET-DRAFT                 DNS DEFUPD                       May 1996

   2.2 - Additional Data Section: TUE RR

   In addition to the optional uses described in [UPDATE 2.6], a DEFUPD
   request's Additional Data section can include a TUU (Time Until Expiry)
   RR as follows:

      Owner:      same as ZNAME (see [UPDATE 2.3])
      Class:      same as ZCLASS (see [UPDATE 2.3])
      Type:       TUE (new RRtype for this protocol)
      TTL:        expiry time, relative, in seconds
      RDLENGTH:   0
      RDATA:      empty

   Of particular note is the TTL, which contains the expiration time delay,
   in seconds, starting from the time this DEFUPD is received by the
   primary master, of all RRs added or updated by operations in the Update
   Section (see [UPDATE 2.5]).

   3 - Server Behavior

   A server, upon receiving a DEFUPD request, will first scan the request's
   Additional Data section in search of TUU or TUE RRs.  If no RRs of
   either type TUU or TUE are found, then this request will be processed as
   a normal UPDATE with no special behaviour.  If any TUU or TUE RRs are
   found, then processing continues as follows.

   3.1 - Verify TUU RR

   If any TUU RRs are found in the Additional Data section, this update
   will be processed with Deferral as explained below.  If more than one
   TUU RR is found, signal FORMERR to requestor.  The TUU RR's owner name
   and class are compared to ZNAME and ZCLASS; if a mismatch occurs, signal
   FORMERR to requestor.  The TUU RR's RDLENGTH/RDATA is ignored by
   implementations of this specification, but future specifications may
   make use of this field.

   3.2 - Verify TUE RR

   If any TUE RRs are found in the Additional Data section, this update
   will be processed with Expiry as explained below.  If more than one TUE
   RR is found, signal FORMERR to requestor.  The TUE RR's owner name and
   class are compared to ZNAME and ZCLASS; if a mismatch occurs, signal
   FORMERR to requestor.  The TUE RR's RDLENGTH/RDATA is ignored by
   implementations of this specification, but future specifications may
   make use of this field.

   Expires November 1996                                          [Page 3]

   INTERNET-DRAFT                 DNS DEFUPD                       May 1996

   3.3 - Deferral

   If a TUU RR was specified in the Additional Data section, this update
   will be processed with Deferral.  Deferral means that the update will
   not be applied synchronously to the requestor's transaction cycle, but
   instead will be applied asynchronously at some potentially later time.
   The delay period is measured in seconds and expressed in the TUU's TTL.

   3.3.1 - Store Deferred Update

   Subject to per-server, per-zone, and per-RRset quotas, this UPDATE
   message is stored, persistently, on the name server.  If per-RRset
   quotas are implemented, it is recommended that a DEFUPD ``count
   against'' all RRsets mentioned in the Update Section.  If an
   implementation defined quota is exceeded by this deferred update, or if
   persistent storage is unavailable, signal SERVFAIL to requestor (leaving
   the zone in its former state).  Note that even a deferred update whose
   TUU's TTL is zero (0), specifying immediate application, should be
   subject to quotas if the name server implements quotas.

   3.3.2 - Send Early Response

   Signal NOERROR to requestor.

   3.3.3 - Apply Deferred Update

   When a period of time equal to or greater than the TUU's TTL (measured
   in seconds) has elapsed since a DEFUPD was first received at the primary
   master, the DEFUPD message is applied to the zone as an UPDATE would be,
   except that no error can be signalled to the requestor.  Thus, all
   errors not found and reported at the time the DEFUPD request was
   received are silent, affecting only the continued processing of the
   deferred update.  Note that all sections are processed, including those
   processed before the deferred update were stored.  Thus, prerequisites
   must hold before and after the deferral period.

   Expires November 1996                                          [Page 4]

   INTERNET-DRAFT                 DNS DEFUPD                       May 1996

   3.4 - Expiry Processing

   When a DEFUPD is applied, either during the requestor's transaction
   cycle or following the optional Deferral period, the inclusion of a TUE
   RR in the Additional Data section will cause this update to be processed
   with Expiry.

   Expiry as expressed in the TUE's TTL is the time, in seconds, before all
   RRs added or modified by the Update Section will be automatically
   deleted by the primary master server.  This time is relative to the time
   the DEFUPD message is processed, which might be after the delay period
   specified by a TUU RR.

   3.4.1 - Initial TTL Limits

   The TTL of all added or updated RRs in the Update Section will be
   maximized silently to one half of the Expiry time.  This will cause
   downstream caching name servers to purge RRsets containing this RR at
   least once before expiry.

   3.4.2 - TTL Half Life

   Each time an RR's expiry reaches half of its previous value, that RR's
   TTL will be reduced to half of its previous value, until the TTL reaches
   a value less than or equal to sixty (60), i.e., one minute of real time,
   at which time the TTL will not be automatically reduced further by the
   primary master.  It should be noted that RRs held in a server's memory
   need not be swept for half life processing, as long as the TTL changes
   appear when the RR next becomes externally visible, and as long as the
   ``zone has changed'' processing (see below) is done at the time of the
   half life expiration.

   Whenever the TTL is automatically reduced by this process, the zone will
   be considered ``changed'' for the purpose of automatic SOA SERIAL
   increment (see [UPDATE 3.6]) and real time zone slave notification (see
   [NOTIFY]).

   Expires November 1996                                          [Page 5]

   INTERNET-DRAFT                 DNS DEFUPD                       May 1996

   3.4.3 - Automatic Deletion

   When the time since an RR was added or updated by a DEFUPD with Expiry
   exceeds the TUE's TTL as specified in that update, all RRs added or
   updated by that DEFUPD's Update Section will be automatically deleted by
   the primary master.  This deletion can be deferred until the deleted RRs
   would next become visible, so long as the ``zone has changed''
   processing (see below) is done at the time of expiration (i.e., when the
   automatic deletion is first deferred.)

   Whenever automatic deletion occurs, the zone will be considered
   ``changed'' for the purpose of automatic SOA SERIAL increment (see
   [UPDATE 3.6]) and real time zone slave notification (see [NOTIFY]).

   3.5 - Requirements for Persistence

   Stored deferred updates should persist across name server restarts.

   3.5.1 - Restarts and Deferral

   In the event of a name server restart, all deferred updates whose TUU
   has expired must take effect before any network requests are processed
   using data from the affected zone, and before any Expiry processing
   takes place on RRs in the affected zone.

   3.5.2 - Restarts and Expiry

   In the event of a name server restart, all expiries must be checked as
   of the current time before any network responses are generated using
   data from the affected zone.

   If an RR's expiry time has been reached while the name server was not
   running, that RR will be deleted.  Otherwise, the RR's TTL will be set
   to one half of the time remaining before expiration, and half life
   processing as specified in Section 3.4.2 will be restarted.

   If any RR is deleted or if an RR's TTL is changed during startup, then
   the zone will be considered ``changed'' for the purpose of automatic SOA
   SERIAL increment (see [UPDATE 3.6]) and real time zone slave
   notification (see [NOTIFY]).

   Expires November 1996                                          [Page 6]

   INTERNET-DRAFT                 DNS DEFUPD                       May 1996

   4 - Requestor Behaviour

   A requestor will generate and transmit a DEFUPD request as specified in
   [UPDATE 4], except that TUU and TUE RRs can be included in the
   Additional Data section.

   4.1. The TUU RR, if specified, must have an owner name and class equal
   to the ZNAME and ZCLASS (see [UPDATE 2.3]).  The TTL should be set to
   the delay, measured in seconds, before this update should be processed
   by the primary master.  RDLENGTH should be set to 0, and RDATA should
   therefore be empty.

   4.2. The TUE RR, if specified, must have an owner name and class equal
   to the ZNAME and ZCLASS (see [UPDATE 2.3]).  The TTL should be set to
   the delay, measured in seconds, before all RRs added or changed by the
   Update Section will be automatically deleted by the primary master.
   This delay is measured starting from the time the update is applied,
   which could follow a deferral delay if a TUU RR was also included in
   this update.

   5 - Notes on Resource Consumption

   A TUE RR will require the primary master will initiate an automatic
   update approximately O(log2(TTL)) times over the life of an expiring RR.
   Even for massively sized zones, this is not considered an inappropriate
   load on the primary master server itself.

   The network bandwidth consumed due to the use of TUE RRs is more
   noticeable, although for massively sized zones, the bandwidth
   requirements should flatten somewhat as many RRs will be automatically
   updated during any given cycle of NOTIFY and AXFR/IXFR.

   6 - Security Considerations

   This protocol suffers the same abject and intentional lack of security
   as [UPDATE], from which it inherits its basic semantics.  In the absence
   of DNS Secure Updates, this protocol should not be used outside of an
   enterprise network, and only with great care within an enterprise
   network.

   Expires November 1996                                          [Page 7]

   INTERNET-DRAFT                 DNS DEFUPD                       May 1996

   7 - Discussion Items for DNSIND and Namedroppers

   Should the server's response to a DEFUPD include an opaque cookie called
   a ``deferred update ID'' which could be used in future DEFUPD requests
   to cancel or replace a previous deferred update?

   Should automatic updates caused by a TUE RR be required to be batched up
   and processed at some minimum interval?  For example, if we only checked
   for half life and expiration once per minute, this might drastically
   reduce the number of NOTIFY/AXFR/IXFR cycles caused by any given zone.
   We would have to recommend that all zones in a given server not be
   synchronized to the same timer, lest a server with many zones cause all
   of its zones to change and require NOTIFY/AXFR/IXFR in the same second.

   Astute readers will have noticed that this proposal is a precise
   superset of [UPDATE], and by adding the optional behaviour and
   definitions of TUU and TUE to [UPDATE], we could do away with the
   separate Opcode for DEFUPD.  This was only possible up until the time
   [UPDATE] went to proposed standard, but hopefully the intent was clear.

   8 - References

   [RFC1035]
      P. Mockapetris, ``Domain Names - Implementation and Specification,''
      RFC 1035, USC/Information Sciences Institute, November 1987.

   [IXFR]
      M. Ohta, ``Incremental Zone Transfer,'' Internet Draft, February
      1996, <draft-ietf-dnsind-ixfr-06.txt>.

   [NOTIFY]
      P. Vixie, ``A Mechanism for Prompt Notification of Zone Changes,''
      Internet Draft, March 1996, <draft-ietf-dnsind-notify-07.txt>.

   [UPDATE]
      P. Vixie (Ed), et al, ``Dynamic Updates in the Domain Name System,''
      Internet Draft, March 1996, <draft-ietf-dnsind-dynDNS-09.txt>.

   [DHCP]
      Y. Rechter, ``Interaction between DHCP and DNS,'' Internet Draft,
      February 1996, <draft-ietf-dhc-dhcp-dns-00.txt>.

   Expires November 1996                                          [Page 8]

   INTERNET-DRAFT                 DNS DEFUPD                       May 1996

   9 - Acknowledgements

   Yakov Rechter assisted in the design of this protocol.  Robert Elz
   assisted in the requirements definition.

   10 - Author's Addresses

      Paul Vixie
         Internet Software Consortium
         Star Route Box 159A
         Woodside, CA 94062
         +1 415 747 0204
         <[email-masked]>

   Expires November 1996                                          [Page 9]