Subject: Re: [Fwd: Re: Requirements for Service Discovery]

From: Stuart Cheshire <[email-masked]>
Date: Mon, 19 Aug 2002 18:51:28 -0700

Robert Elz wrote:

>When something that is in the list of names returned in that magic PTR
>record lookup, and the device (whatever) is summarily removed from the
>network (unplugged, crashes, ...) and never returns, what causes its
>name to ever be removed from the list?

A question for Robert:

DNS UPDATE currently specifies no time-out, refresh period, or other 
garbage collection mechanism to purge old records created by long-dead 
clients.

Do you see this as:
(a) a wonderful feature of the DNS UPDATE mechanism, to be cherished, or
(b) an oversight in the DNS UPDATE mechanism, which should be fixed

I'm not looking for a protracted digression here; I'm not looking for 
qualifications and caveats, just a clear unambiguous "yes/no" statement 
of your opinion, if possible.

Thanks.

Stuart Cheshire <[email-masked]>
 * Wizard Without Portfolio, Apple Computer
 * Chairman, IETF ZEROCONF
 * www.stuartcheshire.org

---

From: Robert Elz <[email-masked]>
Date: Tue, 20 Aug 2002 20:15:49 +0700

Date:        Mon, 19 Aug 2002 18:51:28 -0700
    From:        Stuart Cheshire <[email-masked]>
    Message-ID:  <[email-masked]>

  | DNS UPDATE currently specifies no time-out, refresh period, or other 
  | garbage collection mechanism to purge old records created by long-dead 
  | clients.

Correct.

  | Do you see this as:
  | (a) a wonderful feature of the DNS UPDATE mechanism, to be cherished, or
  | (b) an oversight in the DNS UPDATE mechanism, which should be fixed

Neither of those.

(b) is easy to handle - this certainly wasn't an oversight, when dynamic
updates were being designed there was a lot of work spent on attempting
to achieve exactly what you're suggesting should be done, records that
get inserted for a time, and if they're not refreshed, vanish (or something
else more or less equivalent to that)

So "an oversight" it certainly isn't.

(a) it isn't either - no-one believes that it is great that there's no
way to add something to the DNS for a limited period, and then have it
go away all by itself.

  | I'm not looking for a protracted digression here; I'm not looking for 
  | qualifications and caveats, just a clear unambiguous "yes/no" statement 
  | of your opinion, if possible.

The problem is that it is essentially impossible to make work.

The principle problem is not how one would manage to tell the primary
server that the data was supposed to vanish, but how that server would
pass along that information to secondary servers.  AXFR (sometimes now
IXFR, but that makes no difference) is the most common way that the servers
for a zone communicate, and AXFR transfers the RRs and only the RRs, no
additional data.   There's nowhere in there where "this record should vanish
after a day" can be shoehorned in.

One might think that the primary server could do all the work, make the
data vanish, increment the serial number, then notify the secondary servers
of the zone change - at which point the secondary servers would refresh
their copies of the zone, and the data would be gone.

But even this has two problems - first, up to the point of the notify,
while the primary server could have been answering queries with progressively
shorter TTLs so that caches won't be keeping the data beyond its validity
date - but secondary servers know nothing of this, and would be answering
queries with the initial TTL of the RR up to the instant it is deleted.
Whether this is a serious problem or not depends upon why you're wanting
the record to be deleted - if it is just cleaning up old cruft, then it
doesn't matter at all - but those aren't all of the reasons that people
wanted this ability.

More seriously, something has to deal with the possibility that the
primary server might no longer be functioning at the time the deletion
is supposed to happen - another server might have replaced it.

In any case, all of this means that any kind of automated RR deletion
doesn't work, and really can't be made to work reliably in the DNS as
we know it (some different protocol set might have different outcomes,
but aren't relevant).

Because of that, if records are to be deleted, there really needs to be
something else that is going to take on the responsibility of making
sure that it actually happens, because even if the DNS is attempting to
do it, it isn't always going to be successful.

Then, once you accept the need for such an agent, any argument for having
the DNS do any of it simply vanishes - if the agent is able to clean up
in the hard cases, it can do so in the easy ones as well.

This has been a (very brief) summary of my recollection of the discussions
that took place in the DNSIND working group (the predecessor to dnsext)
when dynamic updates was being designed.   I think I have it more or less
complete - but do feel free to go back and check ancient namedroppers
archives (sometime mid 90's this would have been I think, look a year or two
before the date of the dynamic updates doc - maybe a bit more, that doc
was done and sat for ages waiting for a security mechanism to appear to
make it safe enough for anyone to use).   Namedroppers has been the list
for DNS development since before I was involved (that is, a very long time
now).  Just about everything should be in its archives...

kre