Re: Extending UPDATE to add/remove zones

On Oct 16, 2013, at 6:33 PM, Mark Andrews <[email protected]> wrote:

> 
> In message <[email protected]>, Jay Daley writes
> :
>> And what would your solution be to signifying that a zone is to be
>> deleted?  Without one we have to abandon extending UPDATE and burn an
>> opcode.
>> 
>> Jay
> 
> Add zone:
> Zone: <zname> <class> NS
> Update: <aname> <ttl> <class> SOA .....
> 	<rest of initial zone>
> Additional:
> master TXT [port=value] [A=value] [AAAA=value] [key=name[:alg:secret]] [name=name]
> key TXT [key=name[:algorithm:secret]]
> port TXT [port=value]
> allow-transfer TXT <TBD>
> allow-query TXT <TBD>
> allow-update TXT <TBD>
> 
> Delete zone:
> Zone: <zname> <class> NS
> Update: <aname> <ttl> ANY SOA
> 
> The use of type NS in the zone section indicates that this is a whole of zone
> operation.
> 
Mark  and Jay, 

why not burn RRTYPES for these commands ? 

To add a secondary (easier than primary) 
<name> ADDZONE <class> <master server> <port> <keying> 

To create a zone on primary
 <name> NEWZONE <class>  <zone_source>         (Zone source exampe : file:///var/tmp/newzone/name) 
<name> ALLOW <transfer><port> <query> <update>   (This is like a TXT record but with structure in order and number of fields)  
<name> GRANT <seeting up update rules> 

(ALLOW can also be supplied to secondary)

To Remove a zone 
<zone> DELZONE <class> <empty> 

We can keep going 
<zone> ADDFORWARD <forwarders list> 

<zone> DELFORWARD [empty] 
<zone> TAADD <new TA> 
<zone> TADEL <old TA>    (Avoiding using the name "DELTA")


	Olafur


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