Hi Libor,
On 6/26/23 13:56, libor.peltan wrote:
My concerns are based on following situation. Imagine that:
- two servers publish inconsistent CDNSKEY+CDS records for some reason, e.g.
misconfiguration. This is the exact thing that the draft tries to address.
- this persists for quite some time, which is highly probable, as DNS is
usually a slowly-changing environment.
- the parent queries both servers and detects the inconsistency. So it does
nothing and tries later. It is the same. It tries again, but still the same.
- it tries once more and it happens that some stumble on the network causes
that one of the queries/responses/connections times out and one of the
CDNSKEY+CDS scans fails.
- the parent concludes that one of the servers in unreachable and the other
one is consistent with itself, accepting his CDNSKEY+CDS. This is the very
thing that your draft is trying to defend against, but fails in this case.
I would think about defining some form of "permanent unreachability" and ignore
the servers only in that case. Everything would become much more complicated, but I think
it is the right thing to do. And if not, it should be argumented that the risk is
reasonably acceptable.
That's a fair point that I had not appreciated -- thank you for raising it!
Viktor told me off list that it is also in line with his thoughts on
reachability (he had commented on related aspects earlier, so I reached out).
So, how about replacing the second paragraph of Section 2 with the following:
OLD:
In all cases, consistency is REQUIRED across received responses only.
Nameservers that appear to be unavailable SHOULD be disregarded as if
they were not part of the NS record set.
NEW:
In all cases, consistency is REQUIRED across received responses only.
When a response cannot be obtained from a given nameserver, the
Parental Agent SHOULD attempt obtaining it at a later time, before
concluding that the nameserver is permanently unreachable and
removing it from further consideration. A retry schedule with
exponential back-off is RECOMMENDED.
This leaves the duration of the retry period to the operator. I'm fine with
specifying something (it may actually help interoperability across TLDs), I'm
just not sure what's a good value. Three days?
I labeled the retry mechanism "SHOULD", not "MUST", because even without this mechanism,
the consistency requirements provide *some* protection. Do we want to say that
"better-than-nothing" implementations that don't keep this state are in violation of the spec?
It would be great if someone who has a CDS scanner could comment.
Thanks,
Peter
--
https://desec.io/
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
