On Sun, 16 Oct 2016, Geoff Huston wrote:
so I have three tests:A: a validly-signed ECDSA P-256 domain B: an invalidly-signed ECDSA P-256 domain C: an unsigned control now if the resolver does NOT recognise ECDSA we should see a fetch for A, B and C (as they treat both A and B as if they were unsigned) if the resolver recognises ECDSA we will see a fetch of A and C but not B and if the resolver incorrectly returns SERVFAIL when it sees ECDSA (which I presume is what DNSMASQ 2.71 is doing) then we should see only C and not A or B The report generated uses these definitions to determine if a user is passing their queries to ECDSA-aware resolvers So thats the long answer to yes, this error is caught by these tests, and the error is put into the “does not do ECDSA” bucket.
Ok, thanks! It seems to me that anyone not loading A or B, but loads C, is of high interest. They're obviously behind a broken resolver.
Could you please try to create two buckets out of the "does not do ECDSA", one being "doesn't understand ECDSA, loads invalid resources" and "doesn't load ECDSA resources regardless of valid or not".
I'm very interested in the last of these two, because they're hindering rollout of new algorithms. I'd like to understand how big this breakage is.
-- Mikael Abrahamsson email: swm...@swm.pp.se
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
