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

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

---

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

---

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

---

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

---

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: Robert Elz <[email-masked]>
Date: Fri, 20 Jun 2003 16:44:14 +0700

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

First, Mark's summary looked fine to me.

But ...

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

The XXX & YYY relationship isn't important here but XXX << YYY (in the
mathematical << sense, not "shift left") if this were to have any hope
of working.

But yes, that's what almost everyone wanted when dynamic update was
being defined - and a lot of effort was spend attempting to find
something which would actually work like that.   Unfortunately,
nothing reliable could be found, so that is not what exists.

You can try and dream up a protocol to allow this to work, but
first please go and review all the archives from when dynamic
update was being designed, and then again since then whenever anyone
has suggested it since - it is not nearly as simple to make work
properly as it seems it should be - and if it can't be guaranteed
to work, then the host has to deal with it other ways anyway.

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

Unfortunately, by itself, that doesn't help - that was the original
plan for this (you need to investigate the way the whole DNS works,
including the primary/secondary relationship, and servers that crash at
inconvenient times, to see the problems).

kre

---

From: "D. J. Bernstein" <[email-masked]>
Date: 20 Jun 2003 19:47:34 -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.

The obsolete AXFR replication protocol is unable to copy time-to-die
information. This is one of the many reasons that I recommend rsync for
replication. See http://cr.yp.to/djbdns/tcp.html#intro-axfr.

Client systems running the clueless ``nscd'' program will keep data for
an hour no matter what the TTL says, but at least there's some limit.
Perhaps nscd will be fixed someday.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

---

From: Ted Lemon <[email-masked]>
Date: Fri, 20 Jun 2003 10:54:05 -0500

> 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.   So I'm very interested to know that somebody has actually 
tried this experiment.

What's your experience with this - do you have any measurements about what 
happens in practice as the time to die approaches?

---

From: Bruce Campbell <[email-masked]>
Date: Mon, 23 Jun 2003 16:14:19 +0200 (CEST)

On 20 Jun 2003, D. J. Bernstein wrote:

> Ted Lemon writes:
> Clients throw the record away shortly after the time-to-die, and ask for
> new data when they need it, exactly as desired.

So far, its server-specific, and the information about the exact time for
ttd to take effect isn't transferrable via AXFR ( which can only transfer
offsets via TTL ).

What do clients see from tinydns?  Eg, for a record of 'dying.example.com'
which should expire at T+1500, would it be:

  Client A requesting 'dying.example.com' at time T receives:
	dying.example.com 1500  IN A 192.168.1.2

  Client B requesting 'dying.example.com' at time T+100 receives:
	dying.example.com 1400	IN A 192.168.1.2

?

So, Client A and Client B have _nearly_ the same RR set, just with
different TTLs.  The end effect is that both Client A and Client B will
drop the record from their cache at the appropriate time.  This is good,
right?

So, the next question is, since Client A and Client B received different
(authoritative) responses, does that mean that there were different
versions of the zone 'example.com' at time T and T+100 ?

If yes, there were different versions of the zone at T and T+100, then the
SOA serial needs to be updated, with the consequent flurry of AXFR
requests from the 'example.com' slaves when they noticed the SOA having
changed.

If no, there were not different versions of the zone (and no SOA serial
change) at T and T+100, then we run into problems with the 'example.com'
slaves giving different TTL values for 'dying.example.com' depending on
when they retrieved the zone.

( This space left blank for an 'AXFR is bad, use rsync' comment )

> > 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
>
> Please define ``refresh storm.'' Do you describe TTL-0 records as
> causing ``refresh storms''?

Section 3.4.2 of Vixies 1996 draft (related to implementation of
time-to-die) has the wording:

   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,

   <snip>

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

You could probably do wording such that the only time an SOA serial change
occurs (due to TTL/TTD behaviour) is when an SOA request comes in (so the
version of the zone on your non-time-to-die-internal-magic slave is
correct), but you've still got the problem of differing clients getting
differing versions of RRs in the zone without SOA serial change, which is
not a good precedent.

--==--
Bruce.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 20 Jun 2003 22:43:47 -0000

Clients throw the record away shortly after the time-to-die, and ask for
new data when they need it, exactly as desired. Exception: some broken
programs like nscd keep the record for a while.

The overall effect is similar to what happens when you manually set a
low TTL. The advantage is that setting a time-to-die allows extra
caching before the time-to-die; a low TTL doesn't. (There's also a
user-interface advantage of scheduling the change in advance, but this
isn't a protocol issue.)

---

From: "D. J. Bernstein" <[email-masked]>
Date: 23 Jun 2003 15:09:05 -0000

> versions of the zone 'example.com' at time T and T+100 ?

Of course not; that would be silly. The TTD---which is what caches
actually store anyway---is the same. Queries at different times will
interpret the same TTD as different TTLs, of course, but that doesn't
mean the zone has changed.

If you insist on corrupting the zone by retrieving it through AXFR,
you'll get 2-second TTLs from my AXFR server. Of course, the record also
won't disappear until the next AXFR. The effects on the secondary, and
on clients talking to the secondary, are the same as if you had manually
set a 2-second TTL in the first place.

If you transfer the zone accurately (for example, through rsync), the
secondary will allow more caching before the time-to-die than it would
have with a 2-second TTL, and it will remove the record at exactly the
right time without another transfer.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 23 Jun 2003 17:40:16 +0000

[robert campbell]
> different TTLs.

no.  ttl does not affect rrset identity.  per [rfc2136 1.1.1] et al.

> The end effect is that both Client A and Client B will drop the record
> from their cache at the appropriate time.  This is good, right?

yes.

> versions of the zone 'example.com' at time T and T+100 ?

no.  see above.

> If yes, there were different versions of the zone at T and T+100, then
> the SOA serial needs to be updated, with the consequent flurry of AXFR
> requests from the 'example.com' slaves when they noticed the SOA
> having changed.

no.  any authoritative server could clamp its ttl's for local policy reasons
without affecting zone identity.  they can't be made longer but they could
absolutely be made shorter without invalidating the zone soa:content mapping.

> differing versions of RRs ...

they aren't differing versions of rr's.  ttl is not considered in rr
comparisons.

> ... in the zone without SOA serial change, which is not a good precedent.

see also [rfc2136 3.6].

---

From: Paul Vixie <[email-masked]>
Date: Tue, 24 Jun 2003 16:13:10 +0000

> Still, when new records are created, you have to propagate the
> information outwards.  Rsync, AXFR and IXFR are all unsuitable for
> this in a frequently changing environment due to their associated
> overhead. ...

"sez you."  before it was called dnsext, this wg was called dnsind.  that
stood for Incrementalzonetransfer, Notificationofchanges, and Dynamicupdate;
these were the three features that the powers that were decided were needed
in order to support DHCP and IPv6, which were the New things in ~1994.

the architectural paradigm was to use Update to get things into the master,
Notify to make the slaves aware of these new changes without waiting for an
SOA timer to expire, and IXFR to get these changes distributed to the slaves
without having to transfer all the unchanged data as well.

interestingly, ohta-san preferred a different, masterless model, but he still
did IXFR when consensus went in favour of the i-n-d model.  also interesting
was microsoft, who went for a masterless model using non-DNS channels for
synchronization (but they never did implement healing after a partition event.)

now as to performance.  a company who was bundling BIND8 into a dhcp/dns
integration product stress tested the i-n-d model, and found all kinds of
early (pre-Y2K) data corruption bugs in our IXFR implementation.  their goal
was to be able to shoot thousands of DHCP-originated PTR updates per second
through BIND8 and have the slaves remain synchronized -- and it all works
fine.  therefore i dispute ("sez you") your assertion of "unsuitable".

various other commercial entities, mostly non-BIND based, have also reached
these transaction volumes, using the i-n-d model.  you may not think it's
pretty, but noone has yet found a real world workload that the model can't
address if you use the right hardware and software to support the load.

---

From: Bruce Campbell <[email-masked]>
Date: Tue, 24 Jun 2003 13:29:20 +0200 (CEST)

[ TTD for clients ]

> no.  ttl does not affect rrset identity.  per [rfc2136 1.1.1] et al.

Right.  So it would be easy to implement TTD inside a nameserver (ref
tinnydns), and provide records to clients with appropriate TTLs without
fear of increasing traffic abnormally (the clients won't come back until
the record expires), and, theres no protocol change involved.  End of
argument as far as DNSEXT is concerned.

[ propagating TTD information to slaves ]

> set a 2-second TTL in the first place.

So... if a record is due to expire in 1500 seconds, and you know that the
slave 'should' transfer the zone again via axfr in 1300 seconds (via SOA
values), you will merrily supply a 2 second TTL on said records, thus
causing the slave to incur unneeded traffic from clients who effectively
cannot cache the record at all and must requery for the record each time
they want it.  ( For instance, someone taking 3 seconds to reach a web
page and clicking on the 'Next' link, resulting in the record being looked
up again )

Of course, you'd argue that its because the slaves are using an outdated
protocol, but it strikes me that you've coded your nameserver to be
intentionally irritating.  'Wow'.

Supplying TTLs for expiring records based on the SOA TTL/etc values (with
dropping back to 2 second TTLs for those records which should be expired
before the slaves next refresh themselves) would be more sensible.

Still, when new records are created, you have to propagate the information
outwards.  Rsync, AXFR and IXFR are all unsuitable for this in a
frequently changing environment due to their associated overhead. Dynamic
updates sent from the master to each slave are more prompt, although you
still have the housekeeping of removing the records once they should have
expired (in the absence of remove-after values being able to be sent), and
liable to be lost (but will get picked up on the next zone transfer).
Wait, aren't we back at the start again?

--==--
Bruce.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 24 Jun 2003 19:26:53 -0000

Bruce Campbell writes:
> values), you will merrily supply a 2 second TTL on said records

Correct. Yes, short TTLs cause minor increases in the frequency of DNS
lookups, but long TTLs cause administrative headaches. If the next AXFR
is delayed, the old data will stick around longer than it should. 

> frequently changing environment due to their associated overhead.

Actually, rsync and tinydns-data can make any number of updates to a
multiple-megabyte database in well under a second on a typical computer.