Subject: zone management (Re: let's talk about RFC2136bis )

From: Paul Vixie <[email-masked]>
Date: Tue, 11 Mar 2003 15:15:31 +0000

> >i think a zone management protocol is badly needed, but 2136 (or 2136bis)
> >is not it.
> 
> If I could comment,

it's ietf, everybody can comment.  however, knowing only that your first
name is "dave" and that your e-mail address is [email-masked] does
not exactly fill me with the kind of warmth i'd like to experience when
evaluating a proposal.  (can maybe you spruce up your .signature a bit?)

> If "zone management" is restricted to the implementation independent
> tasks of adding or dropping of zones, then could we develop a draft
> that goes something like:
> 
> For an add:
> 
> Master loads zone and sends a "zone add" directive to the slaves.
> Slaves receive the "zone add" and add the zone via a zone tranfer
> (provided the human has decided to trust the master)
> 
> For a drop:
> 
> Master drops a zone and sends a "zone drop" directive to the slaves.
> Slaves receive the "zone drop" and drop the zone.
> 
> I realize that there are many other tasks associated with zone
> management depending on the implementatin. The protocol could set part
> of the packet(s) aside for implementation specific data that can be
> safely ignored by servers that may not understand things like views or
> acl's, for example.
> 
> I know this is way over simplified, but, would that be the bulk of it?

in my opinion, no.  there are implementation-dependent zone metadata
elements (such as backing store or data source... zone file or sql table
name or whatever) which, when unspecified, leave the zone in an error
state (all queries would be answered SERVFAIL).  i don't think a protocol
which is only reliably capable of creating an error state is a good idea.

therefore a zone management protocol, in order to be worthy of a standard,
would have to enumerate some common forms of implementation-dependent data,
like "master file name" and "slave file name" and "sql table name" and 
"active directory domain name" and so on.  implementors from mydns, 
nominum, ultradns, isc/bind, and so on would all have to contribute.  the
nonimplementors in the crowd would have to participate in order to ensure
that the result was both complete and extensible.

it's a big effort.  the minimal size of the effort is larger than what you
proposed, in my opinion.)

(and 2136bis will NOT address this area at all, since the lack of zone
management features in 2136 is not due to editorial error or oversight,
and has not led any implementor to scratch their head wondering what the
document means.)

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

---

From: Paul Vixie <[email-masked]>
Date: Wed, 12 Mar 2003 15:14:09 +0000

> Well, maybe zone management was the wrong term for what I was
> suggesting.  After reading your comments, I agree that zone management
> would necessarily have implementation-dependent components.
> 
> Maybe Zone Provisioning is better choice of words.  This topic goes back
> to a discussion on the bindusers list starting back in sep-2002.  It was
> suggested that Notify could be used for the purpose of auto provisioning
> of zones on slaves.  
> 
> If this topic has already been pummeled here, please let me know.  If
> not, and it seems like something worth pursuing, I would be interested
> in working on the development. 
> 
> ...
> ..., would a zone provisioning protocol be worth pursuing?

i think so, yes.  it would be better to base it on update than on notify,
in my opinion.

---

From: bert hubert <[email-masked]>
Date: Wed, 12 Mar 2003 17:03:57 +0100

> i think so, yes.  it would be better to base it on update than on notify,

Many PowerDNS users use our 'supermaster' feature as poor man's zone
provisioning, even though it does not provide for any deprovisioning support
and has other major problems.

So it appears that there is a real desire for a zone provisioning protocol.

I'm willing to commit resources towards helping create such a spec and
implement an implementation in PowerDNS while hopefully interoperating with
other servers out there.

Supermaster is described on:
http://doc.powerdns.com/slave.html#SUPERMASTER

Regards,

bert 

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://lartc.org           Linux Advanced Routing & Traffic Control HOWTO
http://netherlabs.nl                         Consulting