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
Mikael Abrahamsson email: swm...@swm.pp.se
DNSOP mailing list