I have domains signed by all combinations of signing algorithms and DS digests as well as Nsec variants Ds-n.alg-m-nsec.dnssec-test.org
Replace n with 1..4 M with 1..14 Nsec is one of Nsec nsec3 none Ólafur sent from phone On Oct 15, 2016 17:29, "Geoff Huston" <g...@apnic.net> wrote: > > > On 16 Oct. 2016, at 2:53 am, Mikael Abrahamsson <swm...@swm.pp.se> > wrote: > > > > On Sat, 15 Oct 2016, Ralf Weber wrote: > > > >> Geoff Houston did some research here some years ago and just did an > update to his findings. You might want to look at: > >> http://www.potaroo.net/ispcol/2016-10/ecdsa-v2.html > > > > Do we know how many experiments failed because the resolver erroneously > reported error for ECDSA signed domains? > > > >> From reading Geoffs text, it's not obvious to me that this error case is > > caught by his tests? > > 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. > > thanks, > > Geoff > > > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
