Re: Extending UPDATE to add/remove zones

While this is discussed in dnsext, but there is a lot of good discussion 
on this, I wonder if we should carve out some time during DNSOP to 
discuss this?

tim


On 10/16/13 5:33 AM, Jay Daley wrote:
>  From my previous post on my draft for a new DNS opcode - servezones - I think there is reasonable interest in an in-band mechanism that instructs a nameserver to etiher start or stop serving one or more zones.  The area with less certainty is what that mechanism should be, a new Opcode (but it's only a 4 bit space!) or extending UPDATE.
>
> I'm planing to write a draft that shows how UPDATE could be extended to do this and then we can compare that with my servezones draft and see which is preferred.  To do that I'd like some help in determining the algorithm for how the extended UPDATE is processed.
>
> Here's my starter for 10.
>
> 1.  A new EDNS option code is assigned that changes the behaviour of the UPDATE as follows (alternatively this could be signalled with a ZTYPE different from SOA)
>
> 2.  The ZONE section specifies the zones to be added/removed.  There can be any number of zones listed here to add or remove.  For each zone, if the CLASS is ANY then the zone is to be removed, whereas if it is ANY then the zone is to be added.  This use of CLASS corresponds to the way that it is used to determine if an rrset should be added or removed in the current UPDATE message.
>
> 3.  The pre-requisite section is ignored.
>
> 4.  The Update section can only contain Adds and only when zones are to be added.  If any records are specified here then that means that the zones to be added are masters and these records are all added to those zones before serving begin.   None of these records may be fully qualified so as to ensure that they apply to all the zones listed.  One of these records must be a SOA record with an empty name, which will be replaced with the zone name
>
> 5.  If there is data in the Additional section then that signifies that the zones to be added are slaves.   The records here must be NS records that specify the masters for the zones to be added.  There can only be records here or in the Update section but not both as zones cannot be both masters and slaves.
>
> Is that it? Anything need changing?
>
>
> BTW we could extend this just a little bit more:
>
> 6.  If there is a DNSKEY record in the Additional section then this specifies a TSIG key that this server should use for pulling the zone.  The name for the DNSKEY record is the name of the key as used by TSIG.  This DNSKEY is not added into the zone.
>
>
> Jay
>

_______________________________________________
dnsext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsext