Document: draft-ietf-dnsop-cds-consistency
Title: Clarifications on CDS/CDNSKEY and CSYNC Consistency
Reviewer: David Blacka
Review result: Ready with Nits
On August 30, 2023, I did an early review of
draft-ietf-dnsop-cds-consistency-03.
My primary concerns in that review were that the draft should define the
"multi-provider" (or whatever) term, or don't mention it at all; the interaction
with CSYNC records wasn't fully clear; and, handling non-responsive nameservers
wasn't clear.
These have all been addressed. "Multi-provider setup" is defined (along with
"multi-signer setup"); use with CSYNC has been made clear; and there is some
advice on dealing with non-responsive nameservers.
I have a few minor nits and editorial advice.
In the Abstract:
This document specifies that when performing such queries,
parent-side entities has to ensure that updates triggered via
CDS/CDNSKEY and CSYNC records are consistent across the child's
authoritative nameservers, before taking any action based on
these records
s/has/have -- The subject of that sentence is "entities", which is plural, so we
need "have" instead of "has" here.
In Section 3:
To accommodate transient inconsistencies (e.g., replication
delays), implementations MAY be configurable to undertake a
retry of the full process, repeating all queries (suggested
default: enabled). A schedule with exponential back-off is
RECOMMENDED.
I wonder if we should talk about making a configuration or just talk about what
we thing the implementations should actually do?
Perhaps:
Implementations SHOULD/MAY retry the full process when
encountering inconsistencies to account for transient
inconsistencies (e.g., replication delays.)
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
