Subject: [DNSOP] Working Group Last Call for draft-ietf-dnsop-child-syncronization

From: Tim Wicinski <[email-masked]>
Date: Wed, 02 Apr 2014 15:14:41 -0400

All,

This is the beginning of the Working Group Last Call on Child To Parent 
Synchronization in DNS.
The London update showed that this work is complete and ready to move 
forward.

The document can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-child-syncronization/
http://www.ietf.org/id/draft-ietf-dnsop-child-syncronization-00.txt

Please take a moment to review the final versions and send up any comments.

This document willhave a 2 week period for comments, closing on April 
16th, 2014.

thanks
tim

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 07 Apr 2014 14:29:05 +0900

Tim Wicinski wrote:

> This is the beginning of the Working Group Last Call on Child To
> Parent Synchronization in DNS. The London update showed that this
> work is complete and ready to move forward.

The following paragraph:

   Some resource records (RRs) in a parent zone are typically expected
   to be in-sync with the source data in the child's zone.  The most
   common records, to date, that should match are the nameserver (NS)
   records and any necessary associated address "glue" records (A and
   AAAA).  These records are referred to as "delegation records".

does not make much sense, because parent zone, today, is already
free to update glue by itself. That is, if multiple child zones
sharing an NS report different glues, the parent zone must check
the current most information.

The problem is a little more serious. That is, in case when a
child zone do not provide glue and another provide false glue,
the parent zone MUST always check and provide the current most
glue information.

Moreover, though the draft says:

   Clients deploying
   CSYNC MUST ensure their zones are signed, current and properly linked
   to the parent zone with a DS record that points to an appropriate
   DNSKEY of the child's zone.

it is more difficult than making referral NSes and glues up to date.

Though one may argue that DS inconsistency is more serious to cause
validation failures, which motivates child zone administrators
seriously maintain the consistency, inconsistencies of referral
NSes and glues may also be serious. Or, if they are not so serious,
it means there are no reason to synchronize only to waste operational
efforts for inessential no problems.

That is, the draft does not have much operational value, I'm
afraid.

                                                    Masataka Ohta

PS

I feel terminology of "agent" in the draft is annoying. "parent
zone" or "parent zone administrator" should be more consistent
with the terminology of rfc1034.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 7 Apr 2014 13:01:31 -0400

I wanted to echo this.  I hadn’t been so detailed in my review...

On Apr 7, 2014, at 1:29, Masataka Ohta <[email-masked]> wrote:

> I feel terminology of "agent" in the draft is annoying. 

I strongly agree with that.  Parental “Agent” is too broad.

> "parent

The latter term is closer, but “administration.”  However, I don’t think the original RFCs gave much consideration to “how the data was assembled for the zone” so I wouldn’t stick to only those terms.

Parent Provisioning System is more in line with operational terminology, it would be a component of the Parent Zone Administration.  I know that the use of “provisioning” isn’t commonplace, it’s what I’ve become used to seeing.  Perhaps there’s a better term for that.

---

From: Matthijs Mekking <[email-masked]>
Date: Tue, 15 Apr 2014 10:46:14 +0200

Hi,

Some feedback:

1. Introduction, last paragraph.
To me, the mentioning of not addressing DNSSEC bootstrapping comes out
the blue. One sentence later it mentions it is not intended for DNSSEC
synchronization at all. I'd prefer a rewrite of this last paragraph:

    "This specification was not designed to synchronize DNSSEC
     security records, such as DS RRsets. For such a solution, see the
     complimentary solution [REF] for maintaining security delegation
     information. In addition, this specification does not address how
     to perform bootstrapping operations, including to get the required
     initial DNSSEC-secured operating environment in place."

2.1.1.1. The SOA Serial Field
First, this document talks about serial being greater than... It might
be good to reference RFC 1982 serial number arithmetic that defines
serial comparison.

Second, I don't like having a special value of 0 to indicate something.
0 is a valid serial number, which is now not allowed to be used in
restrictions. Perhaps it is better to define a new flag in the Flags
Field that says a serial restriction is being advertised.

2.2.1. Processing Procedure
I am feeling slightly uncomfortable too that you cannot get the data and
the SOA in the same response. I am not sure how to make that
uncomfortable feeling go away, but perhaps Edward's suggestion to add a
note on this is enough.

Best regards,
  Matthijs

On 04/02/2014 09:14 PM, Tim Wicinski wrote:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Petr Spacek <[email-masked]>
Date: Tue, 22 Apr 2014 18:15:46 +0200

> Field that says a serial restriction is being advertised.
I support this proposal.

Couple nits I have noticed:

- Term "DNS Publisher" is not used in the whole text except it's definition 
and section 5. Acknowledgments :-)

- I'm bit nervous about "should be processed" in section:
2.2.2. CSYNC Record Types
    This document defines how the following record types may be processed
    if the CSYNC Type Bit Map field indicates they should be processed.

Did you mean SHOULD? Or maybe MUST?

- Document structure seems a bit too nested to me.

Compare draft-ietf-dnsop-child-syncronization-00:

  1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
      1.1.  Terminology Used in This Document  . . . . . . . . . . . .  3
    2.  Definition of the CSYNC RRType . . . . . . . . . . . . . . . .  4
      2.1.  The CSYNC Resource Record Format . . . . . . . . . . . . .  4
        2.1.1.  The CSYNC Resource Record Wire Format  . . . . . . . .  4
        2.1.2.  The CSYNC Presentation Format  . . . . . . . . . . . .  6
        2.1.3.  CSYNC RR Example . . . . . . . . . . . . . . . . . . .  6
      2.2.  CSYNC Data Processing  . . . . . . . . . . . . . . . . . .  7
        2.2.1.  Processing Procedure . . . . . . . . . . . . . . . . .  7
            2.2.2.1. The NS type
           ^^^^^ 4th level is not in TOC but is present in the text

... with draft-ietf-dnsop-delegation-trust-maintainance-11:
    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
      1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
      1.2.  Requirements Notation . . . . . . . . . . . . . . . . . .   4
    2.  Background  . . . . . . . . . . . . . . . . . . . . . . . . .   4
      2.1.  DNS Delegations . . . . . . . . . . . . . . . . . . . . .   4
      2.2.  Relationship Between Parent and Child DNS Operator  . . .   5
        2.2.1.  Solution Space  . . . . . . . . . . . . . . . . . . .   6
        2.2.2.  DNSSEC key change process . . . . . . . . . . . . . .   7
    3.  CDS / CDNSKEY (Child DS/ Child DNSKEY) Record Definitions . .   7
      3.1.  CDS Resource Record Format  . . . . . . . . . . . . . . .   8
      3.2.  CDNSKEY Resource Record Format  . . . . . . . . . . . . .   8
    4.  Automating DS Maintainance With CDS/CDNSKEY records . . . . .   8
      4.1.  CDS / CDNSKEY Processing Rules  . . . . . . . . . . . . .   8
    5.  CDS / CDNSKEY Publication . . . . . . . . . . . . . . . . . .   9
    6.  Parent Side CDS / CDNSKEY Consumption . . . . . . . . . . . .   9
      6.1.  Detecting a Changed CDS / CDNSKEY . . . . . . . . . . . .   9
        6.1.1.  CDS / CDNSKEY Polling . . . . . . . . . . . . . . . .  10
        6.1.2.  Other Mechanisms  . . . . . . . . . . . . . . . . . .  10
      6.2.  Using the New CDS / CDNSKEY Records . . . . . . . . . . .  11
        6.2.1.  Parent Calculates DS  . . . . . . . . . . . . . . . .  11
    7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12

IMHO moving section  2.2.  CSYNC Data Processing and 2.3.  Operational 
Considerations to top-level sections (3., 4.) would make it more readable.

- Typo: "I.e,"

Have a nice day!

-- 
Petr^2 Spacek

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 22 Apr 2014 15:42:03 -0700

Masataka Ohta <[email-masked]> writes:

Sorry for the delay in getting to this discussion, it's been a busy few
weeks and I'm just catching up.

> the current most information.

Sure, the parent zone is in control of what it publishes so it can.  But
there is no indication to a separated parent and child that the parent
*should* be updating the records.

I'm not sure why you're saying the paragraph doesn't make sense because
the parent "is already free to update glue by itself".  I didn't say it
wasn't, but generally that most parent/child relationships today don't
make the assumption that the data in the child should be copied to the
parent (let alone, making sure it's signed and correct).

The CSYNC record is simply a signaling mechanism saying "yep, these
(signature-verified) records are for production use; please copy
upward".

> the parent zone MUST always check and provide the current most

The CSYNC record should only be copying glue from in-zone glue
records.  Updating glue that falls outside the child zone is not
something that is under the perview of current parent/child
relationships today and this document doesn't propose to change that.

> it is more difficult than making referral NSes and glues up to date.

Right, but it's a bootstrap requirement.  The zone must be secure for
CSYNC to operate properly in a protected fashion.

The CDS record should be used to update the DS record.

> with the terminology of rfc1034.

That wording is actually borrowed from the CDS document
(draft-ietf-dnsop-delegation-trust-maintainance), and I understand it's
a new term it is important to note that the entity updating the zone
records for the child may not be the parent zone itself.  In the RRR
model it is the registrar, and the parent zone administrator is the
registry.  So "parental agent" refers to "whomever is handling the data
updates for the parent zone", which may or may not be the zone
administrator.

-- 
Wes Hardaker
Parsons

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 22 Apr 2014 15:43:59 -0700

> I strongly agree with that.  Parental “Agent” is too broad.

The choice was to keep consistent terminology with:

  http://tools.ietf.org/html/draft-ietf-dnsop-delegation-trust-maintainance-11

I don't think we want these terminology sets to deviate.
-- 
Wes Hardaker
Parsons

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 22 Apr 2014 16:00:38 -0700

>      initial DNSSEC-secured operating environment in place."

I've used your wording, thank you for it!

I'll get to your other comments a bit later.
-- 
Wes Hardaker
Parsons

---

From: Tim Wicinski <[email-masked]>
Date: Sun, 27 Apr 2014 07:37:32 -0400

> I don't think we want these terminology sets to deviate.

We don't want the terminology to deviate, nor do we want the 
Capitalization to deviate either.   I have an editor note to go back 
over the draft verifying this.

tim

---

From: Edward Lewis <[email-masked]>
Date: Mon, 28 Apr 2014 09:04:37 -0400

On Apr 27, 2014, at 7:37, Tim Wicinski <[email-masked]> wrote:
> We don't want the terminology to deviate, nor do we want the Capitalization to deviate either.   I have an editor note to go back over the draft verifying this.

Is it better for a draft intended for standards track be terminology consistent with a draft headed for informational or consistent with de jure operations terminology?

(I’m not saying “use my wording” I am saying that parental agent is not a term of art in practice.  A term used in practice would be better.  I used parent provisioning system but there may be another term.)

---

From: Joe Abley <[email-masked]>
Date: Mon, 28 Apr 2014 16:01:53 -0400

> (I’m not saying “use my wording” I am saying that parental agent is not a term of art in practice.  A term used in practice would be better.  I used parent provisioning system but there may be anot…

I think there's quite probably no existing term for "the entity you as the registrant of a particular zone interact with in order to effect changes in the delegation of that zone".

Given that the taxonomy here is wide (we could mean a domain registry, or a zone administrator, or a sponsoring registrar, or a reseller of a sponsoring registrar, or ...) it makes sense to define a pithy term and use it.

"Parental agent" seems fine to me. "Parent provisioning system" seems like it must mean something different from that, since it looks like the name of a system rather than an entity (i.e. it looks like it refers to machinery operated by or for a parent, rather than the parent itself).

Joe