[prev in list] [next in list] [prev in thread] [next in thread] 

List:       namedroppers
Subject:    Re: NOTIFY Extension? (was Re: (background) Re: Null-key priorityduring   key-clash.)
From:       Kevin Darcy <kcd () daimlerchrysler ! com>
Date:       2000-07-28 23:52:37
[Download RAW message or body]

Edward Lewis wrote:

> At 6:29 PM -0400 7/27/00, Kevin Darcy wrote:
> >I think it's perfectly within the spirit of modern DNS for two nameservers to
> >participate in a mutually-agreed-upon optional extension to the protocol.
> >Isn't
> >that what EDNS options were invented for, after all?
>
> I had interpreted your message to mean extending NOTIFY to be a means to
> notify (stub) resolvers of updates to servers they had contacted.

Sorry, perhaps I wasn't clear. The NOTIFY would only be sent to a resolver that
had asked for it. And generally speaking there wouldn't be any incentive for a
non-caching resolver, like a stub resolver, to ask for the NOTIFY, since it has
no cache entries to refresh.

> Still, outside of grouping name servers into sets begin authoritative for a
> zone, DNS is still an open community protocol.  Before attempting to define
> an extension to NOTIFY as you are suggesting, we'd need to define a way to
> group servers together in a more general set.  (E.g., all the servers
> running in my network - regardless of zone.)

Not to be glib, but isn't this an implementation detail? The implementation just
needs to know the set of who has requested to be NOTIFY'ed and then NOTIFY them
if the RRset changes. How it maintains that knowledge -- what data structures are
used, whether it is maintained in volatile or non-volatile storage, whether it is
purely dynamic or the administrator can also specify addresses which should
*always* receive NOTIFYs for a particular RRset, etc. -- seems to me not a part
of the protocol _per_se_.

Note that in terms of conserving capacity, the server can age out of the dynamic
NOTIFY set any targets that it knows will have already expired their entries
(based on when they last fetched the RRset and what its TTL value was at the
time); those targets will be fetching a new version of the RRset when they need
it anyway, so the NOTIFY is not necessary. This means that the administrator can
tune the amount of storage required for the NOTIFY set indirectly by manipulating
the TTL's on the records. For machines short on memory (or disk space, if that's
where it's storing the NOTIFY set), maybe the TTL's would be tuned down to an
hour, 30 minutes, 15 minutes, or whatever. That's not great, but it's still
better for the Internet DNS infrastructure as a whole than TTL=0, especially in
the case of popular RRset's.


- Kevin



to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.

[prev in list] [next in list] [prev in thread] [next in thread]