Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-dnssec-validator-requirements

[Vladimír Čunát <[e-mail]>]

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.