[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: Keith Moore <moore@cs.utk.edu>
cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se
From: Robert Elz <kre@munnari.OZ.AU>
Date: Thu, 09 Aug 2001 00:17:09 +0700
In-Reply-To: <200108081656.MAA14715@astro.cs.utk.edu>
Sender: owner-dnsop@cafax.se
Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary

    Date:        Wed, 08 Aug 2001 12:56:41 -0400
    From:        Keith Moore <moore@cs.utk.edu>
    Message-ID:  <200108081656.MAA14715@astro.cs.utk.edu>

  | actually, it's not.   if that were the case, we could never change
  | a name-to-address binding without first setting TTL to zero (or
  | providing a mechanism that allows them to diminish to zero)
  | and waiting for older TTLs to expire.

That's the way it should be done, yes.  And it is the way that people
who really care about keeping things working make changes where that
is needed, but ...

  | it's somewhat more realistic to say that a TTL indicates (for an address 
  | record) that any services referred to by the DNS name will continue to be 
  | available at that IP address until the TTL expires, if they're available 
  | at all.

that's fine too.   When I reread my words I see that I didn't really
say the right thing, what I should have said, rather than "that the
data isn't going to change" is "that the data is going to remain valid"
and as long as you can keep reaching the address that you were given,
that's OK, even if some other application, doing a new query (and not
hitting the cache for whatever reason) would get a different answer.

(and if I were a pedantic nerd, I'd make that "data are going to remain
valid", or better, since a TTL applies to an RR "datum is going to remain
valid", but I won't do either of those...)

However...

  | it's even more realistic to say that TTL indicates the amount of time
  | for which the DNS administrator is willing to accept that the services
  | associated with the DNS name will be effectively unavailable, should 
  | he/she need to change the addresses.

That's not an unfair description of what often happens, mostly through
ignorance of how things should be done though.  Fortunately, with v6
(whatever DNS RR format is chosen) having multiple addresses assigned to
an interface is designed as a normal case, rather than an unusual one.
There should rarely be a need to make an old address go away before its old
DNS data has had a chance to naturally expire, so the IPv4 style of
"old address out, new address in" as a indivisible operation should gradually
fade away, as the new methodology becomes familiar.

kre


Home | Date list | Subject list