Re: let's talk about RFC2136bis

[Kevin Darcy <kcd@daimlerchrysler.com>]

Paul Vixie wrote:

> > > ...  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) 
Which is an implementation detail, IMO.

> or if it's a slave server, the list of
> axfr targets, or etc.  
I'm only considering master servers.

> 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].
Agreed. The algorithm would need to be tweaked slightly. Addition of an 
SOA RR would need to be a special case that bypasses (or inverts?) the 
usual "does this zone already exist?" checks. This doesn't seem major to me.

> 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 disagree with "fundamental". Nothing really changes as far as the wire 
format is concerned, nor the initial parsing of the request packet, nor 
the response from the server. As mentioned above, a small tweak would 
need to be made to the processing algorithm, and only in the case of an 
SOA add (deletes would still need to check for the existence of the 
zone, as per normal). Perhaps you forgot to mention it, but there would 
also have to be some explicit language to the effect that the NS records 
for the child zone would need to be added in the same update request as 
the SOA "add" (since an SOA without NS records does not make for a legal 
zone).

> i think a zone management protocol is badly needed, but 2136 (or 2136bis)
> is not it.
And I'm not proposing a whole zone management protocol, only the lifting 
of one restriction in Dynamic Update that could be *part* of a zone 
management subsystem. This is not an all-or-nothing scenario. I see 
nothing wrong with part of the zone management subsystem using Dynamic 
Update, and the rest being done out-of-band. It doesn't have to all be 
done with a single protocol.

Perhaps I should mention that my homegrown DNS maintenance system is 
based almost *entirely* on Dynamic Update. About the only part that 
isn't possible to do via Dynamic Update is zone creation and deletion. 
So, while it may seem "natural" to you that SOA addition and deletion 
should remain a special case for Dynamic Update, for me (and potentially 
others evolving in parallel or following my example) Dynamic Update is 
the "rule", and the prohibition against SOA adds or deletes is the 
"exception". And one which appears to have no solid justification, once 
the security issue is resolved.

                                                                       
                                       - 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.
archive: <http://ops.ietf.org/lists/namedroppers/>