Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-child-syncronization-04.txt

From: Wes Hardaker <[email-masked]>
Date: Mon, 01 Dec 2014 10:04:10 -0800

神明達哉 <[email-masked]> writes:

> On Wed, Nov 26, 2014 at 4:52 PM,  <[email-masked]> wrote:
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>  This draft is a work item of the Domain Name System Operations Working Group of the IETF.
>>
>>         Title           : Child To Parent Synchronization in DNS
>>         Author          : Wes Hardaker
>>         Filename        : draft-ietf-dnsop-child-syncronization-04.txt
>>         Pages           : 14
>>         Date            : 2014-11-26
>
> I previously made some comments on the draft in response to the IETF
> last call:
> http://www.ietf.org/mail-archive/web/dnsop/current/msg12278.html

Huh.  I don't remember reading that message at all.  I see it now,
though, and will go look at addressing your comments and responding shortly.
-- 
Wes Hardaker
Parsons

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 01 Dec 2014 13:31:23 -0800

神明達哉 <[email-masked]> writes:

> From a quick check some of them still seem to be open.  And, as far as
> I remember there has been no response to my comments, so I'm not sure
> if they were considered/discussed but dismissed or simply overlooked.

First, apologies again for missing these comments during last call.
Multiple people missed it for some reason.

Here's a summary of your comments and what I've done to address them.
My comments/actions are prefixed by "WJH:"

* DONE 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.

  WJH: I've put in a forward reference in the introduction.  I'm
  not worried about the abstract as much, as any serious reader
  will likely read on anyway.  And the point of the term was to
  make sure we don't say something confusing like "parent" when
  there is more than one.  There is no standard term, and the best
  that the WG came up with (thanks to Olafur) is the new term.
  But a forward reference in the introduction definitely makes
  sense.

      This document specifies how a child zone in the DNS ([RFC1034],
  -   [RFC1035]) can publish a record to indicate to a parental agent that
  -   it can copy and process certain records from the child zone.  The
  -   existence of the record and any change in its value can be monitored
  -   by a parental agent and acted on depending on local policy.
  +   [RFC1035]) can publish a record to indicate to a parental agent (see
  +   section Section 2 for a definition of "parental agent") that it can
  +   copy and process certain records from the child zone.  The existence
  +   of the record and any change in its value can be monitored by a
  +   parental agent and acted on depending on local policy.

* DONE 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.

   WJH: good point; I've added this to the operational
   considerations section:

   4.5.  Removal of the CSYNC records

      Children MAY remove the CSYNC record upon noticing that the parent
      zone has published the required records, thus eliminating the need
      for the parent to continually query for the CSYNC record and all
      corresponding records.  By removing the CSYNC record from the child
      zone, the parental agent will only need to perform the query for the
      CSYNC record and can stop processing when it finds it missing.  This
      will reduce resource usage by both the child and the parental agent.

* DONE 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

   WJH: That's a valid concern.  I don't think we need to address
   the exact way this should be handled, as that can be
   implementation dependent.  So I've changed it to a SHOULD and
   added the following bit of text as well:

       If the SOA records from the first and last steps have different
       serial numbers (for example, because the zone was edited and
       republished during the interval between steps 1 and 4), then the
   -   CSYNC record obtained in the second set MUST NOT be processed.  The
   -   operation MAY be restarted or retried in the future.
   +   CSYNC record obtained in the second set SHOULD NOT be processed
   +   (rapidly changing child zones may need special consideration or
   +   processing).  The operation MAY be restarted or retried in the
   +   future.

* NOFIX 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.

   WJH: I'm sort of on the fence with this one.  But in the end,
   since keeping state itself isn't a requirement (and arguably
   shouldn't be), then force a MUST there doesn't make a whole lot
   of sense since one solution for ensuring compliance is not to
   keep state!  It seems to me, just like some of the other issues
   above, that operational considerations may insert some
   restrictions we haven't thought of yet.

   Anyone else have an opinion here?

* DONE 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.

   WJH: good point; no it should just be the RDATA section.

   Here's the new sentences in question:

       NS records found within the child's zone should be copied
    verbatim (with the exception of the TTL field, for which the
    parent MAY want to select a different value) and the result
    published within the parent zone should be an exact matching
    set of NS records.

   ...

       The A and AAAA type flags indicates that the A and AAAA
    address glue records for in-bailiwick NS records within the
    child zone should be copied verbatim (with the exception of
    the TTL field, for which the parent MAY want to select a
    different value) into the parent's delegation information.

* DUP 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.

   WJH: I think this was addressed based on concerns by the IESG
   as well.  Specifically: "Parental agents MUST NOT perform NS
   updates if there are no NS records returned in a query, as
   verified by DNSSEC denial of existence protection."

* NOFIX 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.

   WJH: The level of dedication of the parental agent certainly
   comes into play.  If the parental agent is choosing a random NS
   to query, and that NS is out of date then a problem certainly
   will occur (specifically: a timing issue will arise until the
   parental agent eventually queries an up to date one).  However,
   note that the draft is not implementing a push mechanism anyway
   so timeliness is probably not going to be fast in the first
   place.

   Section 4.2 already covers this the best we can, I think.

* DONE 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.

   WJH: There are really two separate problems here:

   1) the operational issues of a child using a nameserver in the
      control of a grandchild.  To address this, I've added a new
      section in the operational considerations section:

   +4.6.  Parent/Child/Grandchild Glue Synchronization
   +
   +   When a child needs to publish a CSYNC record that synchronizes NS and
   +   A/AAAA glue records and the NS record is actually pointing to a child
   +   of the child (a grandchild of the parent), then it is critical that
   +   the glue records in the child point to the proper real addresses
   +   records published by the grandchild.  It is assumed that if a child
   +   is using a grandchild's nameserver that they must be in careful
   +   synchronization.  Specifically, this specification requires this to
   +   be the case.

   2) And the harder problem of how to handle the SOA transaction
      synchronization across multiple domains.

      I think to address this, we need to add a similar SOA
      transaction query for the grandchild inside the greater one
      of the child.

      The only other option is to not support this case at all
      (all records must be in the child solely).  So, how about
      the following replacement text:

      1.  Query for the child zone's SOA record

      2.  Query for the child zone's CSYNC record

      3.  Query for the child zone's data records, as required by the CSYNC
          record's Type Bit Map field

          *  Note: if any of the resulting records being queried are not
             authoritative within the child zone but rather in a grandchild
             or deeper, SOA record queries must be made for the
             grandchildren as well.

      4.  Query for the collected SOA records again, starting with the
          deepest and ending with the SOA of the child's.

      If the SOA records from the first, middle and last steps for a given
      zone have different serial numbers (for example, because the zone was
      edited and republished during the interval between steps 1 and 4),
      then the CSYNC record obtained in the second set SHOULD NOT be
      processed (rapidly changing child zones may need special
      consideration or processing).  The operation MAY be restarted or
      retried in the future.

* DUP 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.]

    Yep, this is already been taken care of due to an IANA comment.

* DONE Editorial nits
   - Section 2: s/these/three/
    The CSYNC RRType contains, in its RDATA component, these parts: an
    WJH: caught already

   - Section 2: s/Section Section/Section/ (there are several instances
     of this error)
    data is processed is described in Section Section 3.
    WJH: caught already

   - Section 2: s/any anything/anything/ (?)
    if any of the validation results indicate any anything other than
    WJH: new catch, thank you!
-- 
Wes Hardaker
Parsons

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 1 Dec 2014 20:36:36 -0500

> On Dec 1, 2014, at 4:31 PM, Wes Hardaker <[email-masked]> wrote:
> 
See RFC7344 as definition of Parental Agent

>  +   parental agent and acted on depending on local policy.

Olafur

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 02 Dec 2014 11:12:12 -0800

> See RFC7344 as definition of Parental Agent

It's already in there as a reference, and the definition in the sync
draft is a copy of the 7344 text.  The problem mentioned was that it's
still not a "common" term.  Though it's getting more and more common as
we keep using it.
-- 
Wes Hardaker
Parsons

---

From: 神明達哉 <[email-masked]>
Date: Tue, 2 Dec 2014 11:39:32 -0800

At Mon, 01 Dec 2014 13:31:23 -0800,

> Multiple people missed it for some reason.

No problem, I know it happens.  Thanks for the prompt response to my
second call:-)

> * DONE Section 1 (introduction), the first paragraph:
[...]
>   safely use it without first giving the definition. [...]
>
>   WJH: I've put in a forward reference in the introduction. [...]
>

I'm okay with this.  We might also refer to RFC7344 explicitly from
where this document defines the term, but I'd leave it to you.

>    RRsets specified in CSYNC only to confirm they are still the latest?
[...]
>       will reduce resource usage by both the child and the parental agent.

Works for me.

>    very high rate. [...]

Okay with me.

>    restrictions we haven't thought of yet.

I wouldn't be opposed to that.

>    Here's the new sentences in question: [...]

Works for me.

>    manually configured. [...]
>

Works for me.

>    I'm afraid this setup requires more discussion.  In the following
[...]
>       section in the operational considerations section: [...]

I'm fine with that text.

>              or deeper, SOA record queries must be made for the

The parental agent will first need to identify the name of the
grandchild zone and its server addresses to send this second SOA query by
sending some additional queries, since these addresses (records) may
not be in the parent zone as glue.  This might be obvious from the
context, but I think it's worth noting explicitly.

We might also say the parental agent may (MAY?) just give up the
synchronization attempt if it detects the need for the search in
grandchildren due to the operational complexity.  But that's not a
strong opinion; I'd leave it to you.

--
JINMEI, Tatuya

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 04 Dec 2014 13:41:05 -0800

[... lots of agreement snipped; thanks! ...]

> strong opinion; I'd leave it to you.

Ok, how about this:

       *  Note: if any of the resulting records being queried are not
          authoritative within the child zone but rather in a grandchild
          or deeper, SOA record queries must be made for the
          grandchildren.  This will require the parental agent to
          determine where the child/grandchild zone cuts occur.  Because
          of the additional operational complexity, parental agents MAY
          choose not to support this protocol with children making use
          of records that are authoritative in the grandchildren.

(I liked the idea of the MAY)

-- 
Wes Hardaker
Parsons

---

From: 神明達哉 <[email-masked]>
Date: Thu, 4 Dec 2014 14:02:29 -0800

At Thu, 04 Dec 2014 13:41:05 -0800,

>           of records that are authoritative in the grandchildren.

Looks good to me.

--
JINMEI, Tatuya

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 05 Dec 2014 23:02:22 -0800

> Looks good to me.

Awesome, thanks!
-- 
Wes Hardaker
Parsons