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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]