Re: [nscp] Updating zone *content* in-scope or not?

[Jeffrey Hutzelman <[e-mail]>]

--On Monday, September 20, 2010 02:24:30 PM -0400 Edward Lewis 
<[e-mail]> wrote:

> At 18:27 -0400 9/17/10, Jeffrey Hutzelman wrote:
>> As I see it, zone content management should be in scope for the
>> to-be-developed protocol, and needs to be one of the things we consider
>> as we design that protocol, even if actually defining how it works is
>> not one of the first things we work on.
>
> Have you read RFCs 1995, 1996 and 5936 for inter-authority server
> coordination of zone content and RFCs 2136 and 3007 for altering the
> content?

No, I've never read any DNS-related RFC's, and I don't understand a thing 
about how the system works.  I certainly have never operated a nameserver, 
let alone operated a moderately complex system of servers supporting 
several dozen zones and over 25K names for over a decade.  And I've never, 
ever written a line of DNS-related code.

I think it should be quite clear that while zone transfers and IXFR (and 
the associated notification mechanisms) are effective for distributing zone 
data to slaves, they are not a management mechanism.  Since we're here to 
talk about management, and the immediate question is whether and to what 
extent management of zone content should be in scope, I fail to see how the 
existance of zone distribution mechanisms, incremental or otherwise, is 
relevant.

Certainly DDNS is useful for one-off updates.  It works well for updates 
from DHCP servers, or from clients/end-users.  It even works well for 
management, if your operation is simple enough that you can simply declare 
that the nameserver is the ultimate source of authority and all updates are 
done by administrators manually issuing DDNS updates.  Unfortunately, for 
_automatic_ management, such as keeping up to date with an external source 
that is the true authority while simultaneously accepting some kinds of 
update dynamically from users, DDNS is woefully inadequate.  I covered some 
of this in my first message on the topic, which apparently people didn't 
bother to read before telling me I was an idiot or that I needed to justify 
my argument:


> To make loading generated zone data work well, I need to keep metadata
> alongside each record indicating where it came from, so I can distinguish
> changes made by DDNS clients from situations where the zone simply
> doesn't match the current version of the generated data.  Today I do that
> by keeping a specially-formatted TXT record alongside each "real" record,
> so they can be updated at the same time (as part of the same (atomic)
> DDNS update).  I'd much rather do zone content management outside the DNS
> protocol, with the server not only keeping my record-origin metadata but
> also providing me with information about when a record was last updated
> and by what client, which doesn't appear in the DNS.


Let me make my position crystal-clear, if I can:

I'm not arguing that support for managing zoen content needs to happen now. 
I _am_ arguing that it needs to be able to happen in the future.  If I see 
work proceeding in a direction that would make it difficult or impossible 
to add record-level management operations, I will object.  If I see a 
proposed charter that is designed to forestall such objections now and 
forever by ruling record-level management out of scope, I will object to 
_that_.


> Certainly the specified mechanism(s) have their limitations, but that's
> not what I think is needed to be discussed now.

On the contrary, what we're discussing now is the scope of the proposed 
working group.  If there's an argument to be made that certain work should 
be out of scope because it's adequately addressed by existing protocols, 
then the limitations of such protocols are certainly relevant to the 
discussion.

-- Jeffrey T. Hutzelman (N3NHS) <[e-mail]>
   Carnegie Mellon University - Pittsburgh, PA