Subject: Re: let's talk about RFC2136bis

From: <[email-masked]>
Date: Mon, 10 Mar 2003 22:40:36 -0500

---- Original message ----
>Date: Mon, 10 Mar 2003 21:43:08 +0000
>From: Paul Vixie <[email-masked]>  
>Subject: Re: let's talk about RFC2136bis   
>To: [email-masked]
>
>> >...  what else has anybody got against 2136 that they'd like to see
>> >fixed in 2136bis?
>
>> Remove the more-or-less arbitrary restriction on dynamic addition or
>> deletion of SOA RRs. The "security improvements" changes you've proposed
>> above would seem to moot the security-based objections to this, and the
>> only other objections of which I'm aware -- concerns (one might say FUD)
>> over how dynamic zone-creation/removal would work in practice -- confuse
>> (IMO) implementation issues with protocol ones.
>
>the restriction isn't arbitrary.  at the moment, data needed for a zone
>to exist has to be transmitted out of band, since there is no defined
>format in any standard protocol for carrying things like zone data source
>(file name, sql table name, etc) or if it's a slave server, the list of
>axfr targets, or etc.  then there's the problem of the zone section -- an
>soa by definition does not go into an existing zone, so the zone section
>would have to specify the new zone, which would not exist at the time of
>[rfc2136 3.1].
>
>adding soa creation/deletion in 2136bis would not be a case of removing
>a restriction (arbitrary or not), it would be a fundamental change to the
>data model.  i don't think we should attempt this in a "bis" document since
>we're really just trying to fix the things that implementors have found
>unclear or misleading or inconsistent or just plain wrong.
>
>i think a zone management protocol is badly needed, but 2136 (or 2136bis)
>is not it.

If I could comment,

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?

Dave...

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

--
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: Tue, 11 Mar 2003 15:15:31 +0000

> >i think a zone management protocol is badly needed, but 2136 (or 2136bis)

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:
> 
> 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:
> 
> 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.
> 

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.)

---

From: "David Botham" <[email-masked]>
Date: Tue, 11 Mar 2003 12:40:05 -0500

[clip...]

> evaluating a proposal.  (can maybe you spruce up your .signature a
bit?)

Yes, perhaps a small introduction would be a good thing.  Sorry about
that.

My name is David Botham.  I work for a VAR/Consulting firm in Atlanta,
GA, e^deltacom.  One of the areas I specialize in is the DNS.  I once
thought I knew a lot about the DNS, until I subscribed to a couple DNS
related mailing lists.  Now I know that the real DNS gurus have
forgotten more about DNS that I will probably ever learn.

Most of my implementation experience is with BIND4, 8, 9 on Solaris and
Linux.  I have also worked with NT's DNS, W2K's DNS, MetaIP, and Network
Registrar (when it was American Internet).  

I have read the RFC's and continue to put the pieces together as I go.

Is that helpful?

Dave...

[clip...]

---

From: "David Botham" <[email-masked]>
Date: Tue, 11 Mar 2003 18:33:27 -0500

> -----Original Message-----
> From: [email-masked] [mailto:owner-
> [email-masked]] On Behalf Of Paul Vixie
> Sent: Tuesday, March 11, 2003 10:16 AM
> Subject: zone management (Re: let's talk about RFC2136bis )
> 

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 have to enumerate some common forms of implementation-dependent

Yes, but, would a zone provisioning protocol be worth pursuing?

---

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

> ...
> ..., 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