Subject: [DNSOP] request draft-hardaker-dnsop-csync be adopted as a WG item

From: Wes Hardaker <[email-masked]>
Date: Thu, 13 Jun 2013 10:58:31 -0700

Because I think it'll be helpful to the world at large.  That's why.

Thoughts?

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.

Filename:	 draft-hardaker-dnsop-csync
Revision:	 00
Title:		 Child To Parent Synchronization in DNS
Creation date:	 2013-06-05
Group:		 Individual Submission
Number of pages: 13
URL:             http://www.ietf.org/internet-drafts/draft-hardaker-dnsop-csync-00.txt
Status:          http://datatracker.ietf.org/doc/draft-hardaker-dnsop-csync
Htmlized:        http://tools.ietf.org/html/draft-hardaker-dnsop-csync-00

Abstract:
   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.

-- 
Wes Hardaker
Parsons

---

From: Paul Wouters <[email-masked]>
Date: Tue, 18 Jun 2013 14:14:44 -0400 (EDT)

On Thu, 13 Jun 2013, Wes Hardaker wrote:

> Subject: [DNSOP] request draft-hardaker-dnsop-csync be adopted as a WG item

>   transferring or automatically transfer data from the child to the

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

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 19 Jun 2013 16:00:43 -0700

> this draft could potentially solve all parent-child record syncing.

Thanks; it's the latter problem that I was actually trying to solve.
The DS additions, as mentioned in the draft, were added late just as a
"food for thought" experiment.  Personally, I agree more with the CDS
draft that a CDS record would need to be signed by the SEP-bit key, or
else the security model of the SEP-bit is greatly changed.  But, I
understand that others have argued against this saying that there is
really very few zones where the keys are protected differently or
"owned" differently.  So, if that's the case then CSYNC should be a
suitable mechanism?  Hence, the thought experiment.
 
I'll get back to you about your other comments, but I appreciate
(already) you writing them up.  Thank you!
-- 
Wes Hardaker
Parsons