On 25/11/2022 18.26, Daniel Migault wrote:
So let me know how we came to this lines and I suspect we do share
some similar concerns. A recurrent question and reticence we receive
from MNO and ISPs regarding DNSSEC is that they are really scared
about having the cache with incoherent RRsets in their cache that
causes the validation to fail and in many cases they imagine a
mechanism to prevent and address such incoherent data in the cache.
One of the intentions of this draft is to prevent such mechanisms to
be implemented - mostly as it is likely to generate errors that DNSSEC
experts would not be able to catch or understand - as generated by the
home made solutions. As a result we wanted to minimize the change to
the DNSSEC mechanic and only rely on very simple and standard
mechanisms. 4033 provided one way to limit some incoherencies, and we
also thought of a similar mechanism that was like the one described
in I-D.ietf-dnsop-ns-revalidation which as we saw it ensures
something like a mechanism that refreshes the chain of trust.
I get that in countries with low validation rates [1] it may be
difficult to explain to resolver operators that it should be only the
authoritative side who worries that they "do DNSSEC wrong". Maybe I'm
also personally biased against putting much work to work around mistakes
done on the other side of the protocol.
[1] https://stats.labs.apnic.net/dnssec
What we expect is that the validator proposes this option and as such
the DRO selects that option in the validator if present.
Well, OK.
Well yes, I'm in favor of keeping the supported-algorithm set
centralized internet-wide, instead of trying to start deploying a
decentralized mechanism.
[...]
I mainly wanted to dissuade from early algorithm deprecation on
validator side. [...]
I got your point and agree it might be counter productive to encourage
a mechanism that is not reliable. I propose to remove the text below:
[...]
OK.
I don't see the part about extended errors as problematic (RFC 8914).
It really seems to be getting into (open-source) implementations and it
can help with debugging in some cases, though deploying it is probably
not very important either.
Oh! sure for the TA. My understanding of the text is that it
recommends 5011 for running instances, but that new instances are
configured with up-to-date TA that in most cases are updated by
software update. So yes I agree and will check this appears clearly.
I don't think 5011 is worth doing at all. Maybe in some exceptional use
cases. Well, I haven't heard much about deployment experience with
non-root TAs, so perhaps I just don't know those well.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
