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

From: Wes Hardaker <[email-masked]>
Date: Sun, 14 Jul 2013 07:34:31 -0700

Paul Wouters <[email-masked]> writes:

> Comments:

Sorry for the late response; working no too many drafts at once.

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

Because I was envisioning tools that manage the CSYNC record
independently of the zone itself being managed.  EG, for zones that
update their SOA regularly (say hourly) for data additions and removal,
they don't need to be concerned with always making sure the CSYNC SOA is
updated too.  They can if they want, but using a > clause means the
site-specific data management tools don't need to be rewritten.  Only
the CSYNC tool and/or signing tools need to deal with that.
 
>    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.

Yep.  Thanks.

(huh; I had already fixed it in my text.  And here I didn't think I had
edited it since publication!)

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

Good point; added and thanks.

> This will prevent flipflopping when one NS server is out of sync and
> presenting old data.

Note that there is a state-keeping choice on behalf of the parental
agent, though...  So choose a parental agent that advertises themselves
as keeping state.

> 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)

Added that all data needs to be validated as "secure".

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

Added:

	<t>Parental agents MAY refuse to perform NS updates if the
	replacement records fail to meet NS record policies required
	by the parent zone (e.g. "every child zone must have at least
	2 NS records").</t>

> 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)

Actually, no it's right.  If you notice above that it says the child has
published DS records for their own zone below the cut point.  It's
functionally "CDS" without the "C" because there is an external bit
saying to look for real DS records in the child.  Obviously, these
records are never used during normal processing.

Although, that brings up a good point to people that were considering
wanting to use DS records in the child at the first place: if the
authoritative child zone server is also a recursive server for some
clients behind it (heavily discouraged, but still seen very commonly in
practice), there is no way for a validating stub resolver using the
recursive resolver to get the real DS records signed by the parent.  So
I don't think we can actually do what the draft states at this point.

(but then, I'm not sure that doing DS/DNSKEY bits is the right choice
when compared to CDS)

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

Well, the CSYNC draft does exactly that: splits the choice between two
bits so parents and children can get the job done using either DS or
DNSKEY.  You're right, however, that we could use the CSYNC DS bit to
indicate "do CDS" instead.  However, the existence of the CDS record
alone, since it's special, doesn't really require an external bit to
indicate "go forth and copy" like the other record types.  The existence
of the CDS record is the "go forth and copy" bit.

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

Well, there is so much out-of-band startup that is required to register
a new zone anyway, I don't think that we're adding anything substantial
to that.  All registrars should have a policy and practice statement (if
not that, at least a reputation) that is seen when the child comes to
register a new zone.  I don't think it's possible to easily encode
policy into a record, so I'm somewhat against even trying.  It's a very
slippery slope, as there are many many other policy statements that need
publishing too.
-- 
Wes Hardaker
Parsons