Subject: [dnsext] Fw: a new draft on zone creation

From: "Cindy Wang" <[email-masked]>
Date: Mon, 8 Feb 2010 13:57:09 +0800

Dear all,
The draft is moved to: 
http://www.ietf.org/id/draft-wang-dnsext-newzone-notify-00.txt 

Sorry for the mess ^_^

2010-02-08

Cindy Wang
DNS Lab, CNNIC Labs
China INterent Network Information Center (CNNIC)
Phone: 8610-58813074
Email: [email-masked]
MSN: [email-masked]

发件人： Cindy Wang
发送时间： 2010-02-08 10:34:14
收件人： namedroppers
抄送： 
主题： a new draft on zone creation

Dear all,

We have a draft with,
Title:A mechanism for synchronization across name servers on zone creation
Abstract:
This memo describes the NEWZONE_NOTIFY opcode for DNS, by which a 
primary master server advises a set of slave servers that there is a 
zone has been created and that a query should be initiated to 
discover the new zone data.

This draft also specifies a mechanism for the slave servers to 
achieve authenticated synchronization of zone data as well as zone 
synchronization information with the primary when a zone is created 
on the primary.

please find the text at: http://www.ietf.org/id/draft-ietf-dnsext-newzone-notify-00.txt.

Thank you for your attention and sorry for the not so good format. ^_^

Thank you.

2010-02-08 

Cindy Wang
DNS Lab, CNNIC Labs
China INterent Network Information Center (CNNIC)
Phone: 8610-58813074
Email: [email-masked]
MSN: [email-masked]

---

From: Joe Abley <[email-masked]>
Date: Mon, 8 Feb 2010 06:08:43 -0500

Hi Cindy,

> http://www.ietf.org/id/draft-wang-dnsext-newzone-notify-00.txt

Thank you for writing up this idea.

A couple of things occurred to me as I read your text:

1. It seems like it would be useful to be able to specify additional data along with the simple message "you may pull new zone Z from master M". For example, it might be of value to specify zone-specific metadata like query/transfer ACLs, or server-specific metadata like TSIG keys to be used.

2. You don't specify a corresponding mechanism to drop a zone, or to modify zone or server metadata. See also draft-ietf-dnsop-name-server-management-reqs.

3. It seems like it would be an advantage to be able to specify more than one zone in a single message.

4. It seems like there are possible use-cases for the kind of prerequiste handling described in RFC 2136, e.g. add zone A iff you have already added zone B.

5. The workflow described in section 5.1 seems to make use of address-based ACLs. Presumably TSIG would be another option?

6. The proposal seems to require the server originating the NEWZONE_NOTIFY to retain state per message which is cleared upon an apex IN/NS query or an AXFR from the target server. These seem like poor mechanisms for an acknowledgement, since there are other reasons that a remote server might send such queries. 

7. It seems like this general approach has significant overlap with DNS UPDATE (RFC 2136), although it is focussed on provisioning zones rather than zone contents. If an in-band approach to zone provisioning is desirable, I wonder whether it might be simpler to map the data models onto a namespace (e.g. a new class, or a specified zone in an existing class) and use DNS UPDATE to manage it. This has echoes of the ISC/Vixie metazone concept.

Joe