Subject: Re: [DNSOP] Last Call: <draft-ietf-dnsop-child-syncronization-02.txt> (Child To Parent Synchronization in DNS) to Proposed Standard

From: Warren Kumari <[email-masked]>
Date: Fri, 8 Aug 2014 14:05:37 -0400

On Fri, Aug 8, 2014 at 11:16 AM, The IESG <[email-masked]> wrote:
>
> The IESG has received a request from the Domain Name System Operations WG
> (dnsop) to consider the following document:
> - 'Child To Parent Synchronization in DNS'
>   <draft-ietf-dnsop-child-syncronization-02.txt> as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2014-08-22. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>
>    This document specifies how a child zone in the DNS can publish a
>    record to indicate to a parental agent that it may copy and process
>    certain records from the child zone.  The existence of and value
>    change of the record may be monitored by a parental agent and acted
>    on as appropriate.
>
>

I dislike the "I support this document!" type responses to LC's, but
there is some history here, and so I wanted to explicitly say that I
think that this is a good, useful document...

W

>
>
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-dnsop-child-syncronization/
>
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-dnsop-child-syncronization/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 9 Aug 2014 08:59:03 +0200

In general I think this is good stuff, but I do not think the document can be published yet. What I ask for I hope should be easy to fix though.

1. I see, specifically at the end, some confusion (I think) between use of "parent" and "parental agent". I.e. I think the term "parent" is in use for example when discussing out-of-balliwick NS records.

2. It is not described in detail enough how the actual queries should be sent, and allowing the parental agent to do just however they want seems kind of crazy. Either this is built upon the fact a direct query to a server is sent (i.e. not only must the response be signed and validated, but also AA flag must be set on the response) or not. If not, I want some discussion about caching implications.

3. Regarding caching, I specifically want a scenario described when a zone is moving from one DNS provider (one child) to another, and the loosing DNS provider is not cooperating.

4. A step by step example of how a child is changing NS records

5. A step by step example of how a child is changing glue

6. A step by step example of how out-of-balliwick NS records are thought to be treated (just saying they are problematic is not enough for me)

I.e. a lot of what I ask for is to clarify with examples a lot of the text around 4.3. Having such text, together with a SHOULD and not MUST, will definitely not lead to interoperability.

   Patrik

---

From: joel jaeggli <[email-masked]>
Date: Sun, 10 Aug 2014 13:09:15 -0700

> beginning of the Subject line to allow automated sorting.

FYI,

I requested that this last call be rerun due to US incorrectly assigning
the status of informational and therefore a 2 week duration on the original.

The importance of feedback is underscored by it's intended standards
track status.

Thank you
Joel

---

From: Randy Bush <[email-masked]>
Date: Mon, 11 Aug 2014 08:50:23 +0800

as the threat models seem similar why do we need two separate
mechanisms, one for NS 
   draft-ietf-dnsop-child-syncronization-02.txt
and one for DS
   draft-ietf-dnsop-delegation-trust-maintainance-14.txt

randy

---

From: George Michaelson <[email-masked]>
Date: Mon, 11 Aug 2014 11:10:36 +1000

the 02 draft of child syncronization refers to
dnsop-delegation-trust-maint.

are you saying you want one document? they appear to do slightly different
things. One signals DS/DNSKEY update and nothing else. The other has a
flagword capable notation and signals intent about immediacy or SOA timed
change, in and out of baliwick, and the NS list.

I could imagine a net win by the authors banging this into one document.
YMMV

G

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 12 Aug 2014 22:23:57 -0400

>   draft-ietf-dnsop-delegation-trust-maintainance-14.txt

Well there are two things going on here. 

1. Rules for child expressing how to indicate new trust anchor along with acceptance rules for parent 
2. Child signaling to parent please update “these types”  from my zone in the delegation information i.e. NS change or glue changes. 

Warren and I started doing #1 first as that was more critical to our thinking, once people saw that we could update 
TA info with DNSSEC in place a light bulb went off and people realized much of mundane delegation maintenance could be automated. 
While pushing this through we had to fight get people to realize that there are many different relationships between the parties that
	a) operate parent DNS 
	b) operate DNS for child
	c) child 
	d) Intermediary that handles transaction to create the delegation (i.e. registrar) and processes updates from Child. 

When maintaining delegation information strictly speaking only  a) and b) need to be involved but in some cases d) insists to be in the middle 
and frequently forces c) to perform some manual action. 
#1 tried hard to avoid expressing operational models other than polling and I envision that a better automated model will be created 
around CSYNC, which would express if there is a CDS and/or CDNSKEY for parent to consume. 

The WG told DNSOP chairs that they wanted the documents separate even when editors volunteered to merge them. 

	Olafur

---

From: manning <[email-masked]>
Date: Tue, 12 Aug 2014 23:35:25 -0700

If you have not already done so, you should talk to Johan Ihrn.

About 8 years ago, he and a few others hammered much of the parent/child signaling/sync issues that you and Warren
are revisiting now.   There was some documentation, but it never made the IETF.

/bill

---

From: 神明達哉 <[email-masked]>
Date: Thu, 14 Aug 2014 09:14:03 -0700

I followed previous discussions on this draft but don't remember all of
the details, so I may be rehashing some old discussions (in which case
that's not intentional...)

Overall: I think the idea is useful and it's eventually worth
publishing.  But I've noticed a few non-trivial points that may have
to be addressed before publication.

- Section 1 (introduction), the first paragraph:

   This document specifies how a child zone in the DNS ([RFC1034],
   [RFC1035]) can publish a record to indicate to a parental agent that
   it may copy and process certain records from the child zone.  The
   existence of and value change of the record may be monitored by a
   parental agent and acted on as appropriate.

 I vaguely remember someone already pointed this out, but anyway: I'm
 afraid the term "parental agent" is not so widely shared that we can
 safely use it without first giving the definition.  One easy way to
 address this would be to add a forward reference to Section 1.1 at
 the first occurrence of the term.  If possible, it would be even
 nicer if we can avoid using this term until the definition is given
 in Section 1.1.  For the same reason, it would be safer to avoid
 using it in the abstract.

- Section 3 (in general)
  Do we need some way to avoid making the parental agent keep fetching
  RRsets specified in CSYNC only to confirm they are still the latest?
  draft-ietf-dnsop-delegation-trust-maintainance has a way to avoid
  that by removing CDS/CDNSKEY once all parent name servers are
  updated.

- In Section 3.1, it suggests a sequence of CSYNC and other followup
  queries enclosed by SOA queries, and requires serials of the SOAs be
  identical (with a MUST).  I wonder if this is reliable enough for a
  rapidly changing zone, such as those accepting dynamic updates at a
  very high rate.  We might say such cases are out of scope of this
  mechanism, but I personally think such an environment is not so
  deviant that a standard-track protocol can casually ignore.  At the
  very least I would like to see some explicit consideration text on
  the expected limitation (if any) regarding this point

- Section 3.1

   [...]  If
   state is being kept by the parental agent and the SOA serial number
   is less than the last time a CSYNC record was processed, this CSYNC
   record SHOULD NOT be processed.  Similarly, if state is being kept by
   the parental agent and the SOA Serial Field of the CSYNC record is
   less than the SOA Serial Field of the CSYNC record from last time,
   then this CSYNC record SHOULD NOT be processed.

  I'm not sure about the point of these "SHOULD NOT"s.  If it's okay
  with ignoring mismatches with stored state, why would the parental
  agent bother to keep the state in the first place?  Since keeping
  the state itself is optional, it seems to make more sense to use
  "MUST NOT" here.

- Section 3.2

   NS records found within the child's zone should be copied verbatim
   and the result published within the parent zone should be an exact
   matching set of NS records.

  Does "verbatim" indicate that the TTL should also be copied?  The
  same question applies to Section 3.2.2, although "verbatim" isn't
  used in that section.

- Section 3.2: what if the followup NS query results in 'no data'?  Of
  course, this means the child zone is broken, but if the parent also
  removes the NS RRsets, subsequent resolution for the zone will
  immediately fail at the parent zone; on the other hand, if the
  parent just ignores such result and keeps the NS RRset (and if it's
  actually still usable), subsequent resolution will still somehow
  work in many cases in practice.  I don't know if that's the desired
  scenario, and we might rather make it fail sooner rather than
  leaving the half-broken state longer.  In any case, I think it would
  be nicer to mention this case (and what the parent should do) in
  this document.

- Section 4.2
  We may want to be clearer about how the child name servers and their
  addresses are determined to send CSYNC queries if they are not
  manually configured.  That is, this should essentially come from
  the NS and AAAA/A records at the parent zone, and some of these may
  be obsolete or even unusable at the time of query (in fact,
  reflecting such changes is exactly the purpose of these queries).
  This also means the child cannot simply update all NS (or AAAA or A)
  records at once, making the old ones unworkable, and expect the
  parent will catch up with it.  This may be obvious in some sense,
  but may still be worth noting.

- Section 4.3

   Children deploying NS records pointing to domain-names within their
   own children (the "grandchildren") SHOULD ensure the grandchildren's
   associated glue records are properly set before publishing the CSYNC
   record.  I.e., it is imperative that proper communication and
   synchronization exist between the child and the grandchild.

  I'm afraid this setup requires more discussion.  In the following
  configuration:
  parent: example.com.
  child: child.example.com.
    child.example.com. NS ns.grand.child.example.com.
    grand.child.example.com. NS ns.grand.child.example.com.
    ns.grand.child.example.com. AAAA 2001:db8::1
  grand child: grand.child.example.com.
    ns.grand.child.example.com. AAAA 2001:db8::1
  If the AAAA record is changed, the child will update its CSYNC record
  with setting the bit for AAAA.  According to Section 3.1, the parental
  agent will send a query for the AAAA record to the child's name
  server, but it will return a delegation to the grandchild, not the
  requested AAAA itself, let alone its RRSIG.  The parental agent
  could then resolve and verify the AAAA separately, but it breaks the
  "atomicity" of the operation that this section seems to seek by
  enclosing the whole set of queries with two SOA queries.

- Section 6: unfortunately code 61 was already registered for OPENPGPKEY.
   [ To be removed prior to publication: The CDS (59), CDNSKEY (60) and
   the CSYNC records are all conceptually similar - if the code-point 61
   happens to still be Unassigned when the IANA processes this, it would
   be nice if that could be used for this.]

- Editorial nits
  - Section 2: s/these/three/
   The CSYNC RRType contains, in its RDATA component, these parts: an
  - Section 2: s/Section Section/Section/ (there are several instances
    of this error)
   data is processed is described in Section Section 3.
  - Section 2: s/any anything/anything/ (?)
   if any of the validation results indicate any anything other than

--
JINMEI, Tatuya

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 19 Aug 2014 08:17:35 -0700

George Michaelson <[email-masked]> writes:

> are you saying you want one document? they appear to do slightly different things. One signals DS/DNSKEY update and nothing
> else. The other has a flagword capable notation and signals intent about immediacy or SOA timed change, in and out of
> baliwick, and the NS list. 
>
> I could imagine a net win by the authors banging this into one
> document. YMMV

This was heavily discussed in the WG meetings.  The authors actually
don't want them to be merged (and this was the result of the long WG
consensus too).  One deals with the security implications of the
security specific bootstrapping records (the DNSKEY and DS record), and
the other *requires* the use of that record to be already operationally
complete.  The delegation-trust-maintainance document also requires a
different security evaluation when performing the record authorization.
I.E., the CDS record must be signed by the SEP key (KSK), not just
any-old non-SEP key (a ZSK).  The child-synchronization draft doesn't
require this to be true.

So though it *looks* like the problems are similar, there are a bunch of
underpinnings that make them rather different.  Hence the reason we
don't think it's wise to merge them, as it'll actually make it
problematic from a writing and reading perspective: processing of the
records is quite different (and needs to be).

-- 
Wes Hardaker
Parsons