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

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

[clip...]
Paul Vixie wrote:

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

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

--
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: "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
> To: [email-masked]
> Subject: zone management (Re: let's talk about RFC2136bis )
> 
> > >i think a zone management protocol is badly needed, but 2136 (or
> 2136bis)
> > >is not it.
> >
> > If I could comment,
> 
first
when
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.

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. 

> 
> therefore a zone management protocol, in order to be worthy of a
standard,
> would have to enumerate some common forms of implementation-dependent
> data,

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

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