Hi Ondřej,
On 6/24/25 14:53, Ondřej Caletka wrote:
Our implementation first asks a validating resolver for the CDS RRSET of each domain, so
we get a first pass from a "random" authoritative server. If this CDS RRSET
already matches the current DS state, then we abort - because even if another
authoritative server would return a different CDS RRSET it would mean the CDS RRSETs are
inconsistent anyway.
If the CDS RRSET does indicate a change request to the status quo, we fetch ALL
IP addresses for each nameserver hostname (from our own delegation data i.e.
glue records if we have them) and also through a validating resolver. Then we
ask each of these IPs directly for the CDS RRSET and compare the result to the
initial answer from the resolver.
This seems to be a sensible approach. It will likely detect multi-signer
inconsistencies while not being very resource intensive.
Thank you for raising this point in the original post of this thread! Indeed,
this aspect was underspecified.
It looks like the approach described by Oli is considered reasonable, so I've
added words along those lines to the draft:
NEW
In order to determine plausible consistency of CDS/CDNSKEY or CSYNC
RRsets across the child's nameservers, the Parental Agent MUST fetch
all IP addresses for each nameserver hostname as listed in the
Child's delegation from the Parent, using a validating resolver at
one vantage point, and including glue records if available. Before
acting on any CDS/CDNSKEY or CSYNC record for the child, the Parental
Agent MUST have established plausible consistency by querying all of
these IP addresses for the record set(s) in question, as per the
guidelines spelled in the following subsections.
Glad you insisted on this, better late than never! :-)
I'm going to submit a new revision of the draft with this change. Chairs, no
other changes resulted from WGLC besides this one (and two trivial editorial
clarifications, which will be evident from the diff).
Cheers,
Peter
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
