Hi,
From the draft:
For example, a single provider may (accidentally or
maliciously) cause another provider's trust anchors and/or
nameservers to be removed from the delegation.
This is exactly what happened in my test environment when putting BIND 9
to the multi-signer test where one server chooses to keep the CDS and
CDNSKEY RRset published, keeping it in sync with the DS RRset, and the
other removes the CDS and CDNSKEY records as soon as you detect that the
desired DS RRset is published.
The existing documents lack any words on where specifically to query for
CDS/CDNSKEY, and also what to do in case of inconsistencies.
Therefor, I support adoption of this draft and am willing to review.
Matthijs
On 6/7/23 17:52, Tim Wicinski wrote:
All,
We've had this document in DNSOP for a bit and Peter has presented three
different meetings. When I went back and looked at the minutes, the
feedback was good. But when the chairs and Warren discussed it, we had
confused ourselves on this document, which is our bad. We decided to
stop confusing ourselves and let the working group help us out.
What I did was to pull the comments on this document from the minutes of
the meetings and include them below to make it easier to remember what
was said.
This starts a Call for Adoption for draft-thomassen-dnsop-cds-consistency
The draft is available here:
https://datatracker.ietf.org/doc/draft-thomassen-dnsop-cds-consistency/
<https://datatracker.ietf.org/doc/draft-thomassen-dnsop-cds-consistency/>
Please review this draft to see if you think it is suitable for adoption
by DNSOP, and send any comments to the list, clearly stating your view.
Please also indicate if you are willing to contribute text, review, etc.
This call for adoption ends: 21 June 2023
Thanks,
tim wicinski
For DNSOP co-chairs
Minutes from past meetings on "Consistency for CDS/CDNSKEY and CSYNC is
Mandatory"
----
114
Mark: CDS records are no different than any others
One NS might be down, which would stop the
Peter: This is telling the parent how to act when faced with
inconsistent information
Viktor: There might be hidden masters
Don't want to get stuck
Peter: Wording could be changed to allow servers down
Ben: There is a missing time constant
When do I recheck if I get an inconsistent set?
Peter: 7344 doesn't put any time limit
Ben: Should suggest some time to retry when there is an
inconstancy
115
Wes: Supports this
Likes mandating checking everywhere
Ralf: Supports this
Can't ask "all" servers in anycast
What if you don't get a response
Peter: Ask each provider
Is willing to add in wording about non responses
Paul Wouters: This wasn't in CSYNC, our bug
Viktor: Concern was hidden masters and nameservers that are gone
and are never going to come back
116
Viktor: Corner case: if someone is moving to a host that doesn't
do DNSSEC
Peter: Could add a way to turn off DNSSEC on transfer
Johan Stenstram: Breaks the logic that "if it is signed, it is
good"
Doesn't like "if this is really important"
Let's not go there
Authoritative servers are proxies for the registrant
Out of sync is reflection on the registrant: business issues
Wes: CSYNC was for keeping DNS up and running
CSYNC can't fix the business problems
Peter: Agrees that one signature should be OK
Other parts of the spec also suggest asking multiple places
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
