Hi David,
First of all, thanks for the review!
The changes made in response to it (plus a few minor editorial changes I found
useful) are recorded here:
https://github.com/peterthomassen/draft-ietf-dnsop-cds-consistency/pull/4
I'd appreciate if you can let me know if you agree with them, so I can merge
them. -- Further comments inline.
On 8/30/23 15:58, David Blacka via Datatracker wrote:
From a specification-purity point of view, the concept of multiple providers is
actually not needed or relevant to this draft. Nameservers could be out of
sync for a variety of reasons. This draft could be written without a single
mention of multi-provider (multi-homed?) or multi-signer situations and be
shorter and perhaps clearer. Although, it might be important to point out that
there are more reasons than just being out-of-sync from a single primary source.
On the other hand, knowing that multiple provider setups exist is a strong
motivator for this specification. Without considering multiple provider
setups, we are prone to imagining that all setups are synced from a single
source, and all deviation is temporal and temporary.
Exactly -- in multi-provider setup, the source is diverse. What's more: before
joining a multi-signer constellation, each party has a different set of
DNSKEYs, and they'll need to converge on a merged set that has everyone's
relevant keys (namely, those KSKs that will later be referenced via DS records,
but no cross-provider ZSKs), before publishing corresponding CDS/CDNSKEY RRsets
to update the delegation's DS RRset.
There's a lot of potential for error here, particularly when it's not
automated, or when automation software is new and hasn't yet stood the test of
time (as is expected to be the case). It was in this context that this draft
was conceived, and I think it's a much stronger motivator than merely being
out-of-sync by replication lag (which would only cause benign DS flapping
unless other things are broken, too).
I'd thus like to keep mention of this in the Introduction and Security Considerations. --
The third occurrence of "multi-signer" is in the appendix describing the
various failure modes. I hoped that would be enlightening, but I don't mind dropping it.
Is that what you are proposing?
If the draft is not recast to just not directly mention
multi-homing/multi-provider/multi-signing setups, it should define the term
near the start of the draft. I would prefer using "multi-provider" because I
believe it is both clearer and less encumbered with other meanings in nearby
subjects (like networking), and perhaps covers more situations than
"multi-signer".
I agree with your sentiments about multi-homing, and I've changed them to
"multi-provider".
"Multi-provider" emphasizes the redundancy aspect; the DNSSEC status of the
domain is not relevant. (For example, github.com has a non-DNSSEC multi-provider setup
between NS1 and AWS.)
"Multi-signer", OTOH, describes the special case of multiple signing entities,
which in turn contains the special case of glitch-free provider change (which isn't about
redundancy, but about continuity of operation).
I therefore think there is reason to keep these two terms (but "multi-homing"
can be dropped). The relevant paragraph in the Introduction now says:
[...] adverse consequences can arise in conjunction with the
multi-signer scenarios laid out in [RFC8901], both when deployed
temporarily (during a provider change) and permanently (in a
redundant multi-provider setup).
I also added definitions to the Terminology section:
Multi-provider setup: A constellation where several providers
independently operate authoritative DNS service for a domain,
usually for purposes of redundancy. This includes setups both
with and without DNSSEC.
Multi-signer setup: A multi-provider setup for a DNSSEC-enabled
domain with multiple independent signing entities [RFC8901]. Such
a setup may be permanent (for redundancy) or temporary (for
continuity of DNSSEC operation while changing the provider of a
domain that normally uses a single one).
Does this address your concern?
My last major concern is with section 2.2, CSYNC. RFC 7477 has many rules that
a parental agent must consider before accepting a CSYNC update. It is unclear
how those rules interact with the rules specified in section 2.2. I think what
is meant is this:
Each parent-side nameserver is queried for the CSYNC RRset and the synced
(NS, A, AAAA) RRsets, and that unless all of the CSYNC type map bits and
sync data match, syncing must be aborted.
I think some discussion of how this interacts with the existing rules is
warranted. For example, the type bitmap indicates "A", but the nameservers are
not at/below the delegation, so are ignored. Does it matter to the algorithm
if the child nameservers have different data for the glue records?
The draft does not touch any existing rules; it just mandates that the
responses fetched for CSYNC processing need to be retrieved from several auths
and then checked for consistency.
Applying this to the case you raised: according to RFC 7477 Section 3.2.2, when
the A or AAAA type flags are set, addresses glue records should only be fetched
for in-bailiwick NS records. Section 4.3 emphasizes that even if NS/A/AAAA type
flags are set, the parent will not update out-of-bailiwick glue. The question
of inconsistent address RRsets for out-of-bailiwick NS hosts therefore does not
arise.
However, I agree that this point deserves explicit mention. I added the
following text to 2.2:
Other CSYNC processing rules from [RFC7477] Section 3 remain in place
without modification. For example, when the type bitmap contains the
A/AAAA flags, corresponding address queries are only to be sent "to
determine the A and AAAA record addresses for each NS record within a
NS set for the child that are in bailiwick", while out-of-bailiwick
NS records are ignored. Also, when the NS type flag is present,
associated NS queries and consistency checks are to be performed
before any address queries to ensure "that the right set of NS
records is used as provided by the current NS set of the child".
(Quotes from [RFC7477] Section 3.2.2; see also Section 4.3.)
I have a few minor language tweaks that I noted while reading this draft.
In the abstract:
Parent-side entities (e.g. Registries, Registrars) typically discover these
records by querying them from the child, and then use them to update the
delegation's DS RRset accordingly.
Since we are already talking about both CDS/CDNSKEY and CSYNC, we should
probably be a little more inclusive here:
Parent-side entities (e.g. Registries, Registrars) typically discover these
records by querying them from the child, and then use them to update the
delegation's DS and/or NS RRset accordingly.
Although that also doesn't quite capture everything, either.
Good point, but yeah, this also misses the glue records. Adding them makes it
read cumbersome. I changed it as follows:
[...] Parent-side entities (e.g.
Registries, Registrars) typically discover these records by querying
them from the child, and then use them to update the parent-side
RRsets of the delegation accordingly.
Within the earlier context of the abstract, I think that's clear enough and
more accurate.
In section 2, "Processing Requirements"
When a response cannot be obtained from a given nameserver, the Parental
Agent SHOULD attempt obtaining it at a later time
should be:
When a response cannot be obtained from a given nameserver, the Parental
Agent SHOULD attempt to obtain it at a later time
Done.
I will point that I noted some concern about the overall approach in the IETF
117 dnsops meeting. I don't entirely recall the details of the concerns, but I
think it was about making CDS/et al. more brittle operationally. This would be
true if this draft were not clear about how to handle non-responsive
nameservers.
If I recall correctly, the concern raised about the overall approach was that
with DNSSEC, any one signature suffices to prove origin authenticity, so
(according to this concern) it's not necessary to retrieve it multiple times.
It's even dangerous (so the concern), as requiring consistency across multiple
responses might weaken people's confidence and trust in RRSIGs, generally, so
that perhaps some would start querying even regular records (A etc.) from
several servers and discard them unless consistent.
My position is that this objection is besides the point: while it's correct
that an RRSIG provides conclusive evidence of authenticity for one origin (and
the draft does not challenge that), the issue at stake is precisely that there
are multiple origins. Addressing this is exactly what's necessary so that one
can, with high confidence, trust the resulting DS RRset (and, by implication,
any one RRSIG authenticated with it!).
(Further, I don't think implementers of validating resolvers would fall into this
"trap" and start doing multiple queries by default.)
Peter
(with author hat, under different email address)
--
https://desec.io/
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
