On 6/28/22 02:56, Paul Wouters wrote:
I thus propose to update RFC 7344 along the lines of (2), such that it is 
REQUIRED to retrieve CDS/CDNSKEY records using queries to all authoritative 
nameservers.

The question is now how to phrase this exactly. Do we want the parent to use
its "external" knowledge of NS records of the child - eg from its WHOIS data?
That would be clean and simple.

Or are we okay that it queries for the NS records to get the list ?
If so, it would need to require DNSSEC for the NS RRset, but there might
be more than one validly signed NS RRset if these nameservers are out
of sync. In that case, which of these is the intended one?

The parental agent has unerring knowledge of the delegation NS records, so I 
think those should be used. This is also what's done for bootstrapping, where 
the child-side NS RRset is not yet trusted.

For the reason you mentioned and for consistency with bootstrapping, I'd 
suggest to choose phrasing that similar to that in the bootstrapping draft, 
such as (inspired by in draft-ietf-dnsop-dnssec-bootstrapping, Section 3.2):

   Query the CDS/CDNSKEY records at the Child zone apex directlyfrom
   each of the authoritative servers as determined by thedelegation's
   NS record set using a trusted DNSresolver and enforce DNSSEC
   validation

or (inspired by bootstrapping Section 3.3):

   The Parental Agent MUST ascertain that queries are only made against
   the proper set of nameservers as listed in the Child's delegation
   from the Parent.

Having this aligned allows CDS/CDNSKEY scanners to use the same query logic for 
bootstrapping and for rollovers.

Does the WG think this is a reasonable thing to pursue?

I think this could be an excellent super short RFC that Updates: 7344.

Sure, I'm volunteering to write up something. I'll wait until Thursday or so, 
in case others share thoughts I should know before I start.

Thanks,
Peter

--
https://desec.io/

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to