On 15/12/2022 23.36, Daniel Migault wrote:
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.
So I think what you're suggesting is that 8914 will be implemented,
without even the choice being left to the operator. If that the case,
would you like the text instead of SHOULD say something like MAY if
not supported by default by the implementation ?
For Knot Resolver we implemented EDE in responses and so far there's
been no motivation to offer opt-out. (It's just a few bytes, and
unknown EDNS should be ignored.)
I don't have strong feelings about the text; "SHOULD implement RFC 8914"
sounds OK. It's certainly nice to implement at least some basic
distinction, e.g. signalling that SERVFAIL comes from a DNSSEC error.
Further details could help with debugging various issues.
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.
I need to take the time to reconsider that. I am a bit overloaded but
expect to come back to this point more specifically. I got your point
in any case and the scenario we have is a zone that does not want to
rely on the parent zones in case something goes wrong in these parent
zones. The other aspect is also that we did ot want to give the
impression DNSSEC only works with the root KSK as a TA. But as ai
mentioned I will come back with that.
OK. In my opinion you depend on parent's health a lot anyway
(unavoidably), though yes - DNSSEC can be the most fragile part.
--Vladimir
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
