On Thu, 13 Jun 2013, Wes Hardaker wrote:
Subject: [DNSOP] request draft-hardaker-dnsop-csync be adopted as a WG item
A new version of I-D, draft-hardaker-dnsop-csync-00.txt has been successfully submitted by Wes Hardaker and posted to the IETF repository.
This document specifies how a child zone in the DNS can publish a record that can indicate that a parental agent may copy and process certain records from the child zone. The existence and change of the record may be monitored by a parental agent to either assist in transferring or automatically transfer data from the child to the parent.
Interesting draft. I'm not yet sure if I prefer this over the CDS draft or not, or whether this draft should exclude DNSKEY/DS sync. I like that this draft could potentially solve all parent-child record syncing. Comments: 2.1.1.1 talks about the serial in the CSYNC record. Why did you prefer a "soft" link between that and the SOA serial, instead of a "hard" link? Or why is there is a need for a serial? Shouldn't it directly relate to the SOA serial? You seem to think one would need a "minimal SOA serial" to process the CSYNC record, but wouldn't the CSYNC record always be correctin the _current_ zonefile? I don't see how prepublishing a CSYNC with a current serial + 1 would be of any benefit. The following CSYNC RR shows an example entry for "example.com" that indicates the NS, A and AAAA records should be processed for the zone using a minimum SOA serial number of 66. example.com. 3600 IN CSYNC 73 1 A NS AAAA Did you mean to write "66" in the RRDATA? Or did I misunderstand something? Since you later write 0x42, I think you mean 66 here. 2.2.1 talks about fetching the SOA, CSYNC, data and again SOA record. I think you need to state that you should also aboard if the CSYNC/SOA serial obtained is lower then a previously processed CSYNC/SOA action. This will prevent flipflopping when one NS server is out of sync and presenting old data. This section should also indicate processing MUST be aborted if there was no full path of trust from the parent to the child (ie. we need DNSSEC authenticated data) 2.2.2.1. The NS type It should note that parent policy might result in rejecting the proposed change at the child, for example if only 1 NS record would be left. 2.2.2.4. The DS type I kinda lost track here. It's pretty confusing. Also because the "DS type" would really need to query DNSKEY, as the child is not publishing DS records. (eg "Queries should be sent to the child zone for all the DS records" is wrong) It talks quite a bit about whether to sync (C)DS or DNSKEY. In some sense, perhaps to facilitate parents that insist on creating the DS from DNSKEY, and parents that insist on getting a DS RRdata from child, to split the DS type here into CDS and DNSKEY type, where the latter means "create DS from DNSKEY". Although that would mean large parts of the CDS draft would not really be used, if the CSYNC scheduling part is used. 2.3.3. support at parent. If it is important that we know if the parent supoprts CSYNC and with what parameters, should be define a RRtype for that which the parent can publish? I'm hesitant to state in a protocol document that we need something and suggest adding a human/manual procedure for that, when it can be avoided. Paul _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
