Re: [DNSOP] Dnsdir early review of draft-ietf-dnsop-cds-consistency-03

[Peter Thomassen <[e-mail]>]

Hi David,

I've merged the below changes into the draft, now available on the datatracker as -04.

Thanks,
Peter


On 9/7/23 18:52, Peter Thomassen wrote:
> 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)
> 

-- 
Like our community service? 💛
Please consider donating at

https://desec.io/

deSEC e.V.
Kyffhäuserstr. 5
10781 Berlin
Germany

Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525