[dns-operations] Strange behavior of google public resolver

[Mark Andrews]

> On 18 Apr 2019, at 11:45 pm, Bryan Hughes <bhughes at tiggee.com> wrote:
> 
> Taras - 
> 
> What's going on with your KSK's in this domain? KeyID 35973 using algo 10 is invalid (http://dnsviz.net/d/rv.ua/dnssec/), KeyID 613 using a very old algo 3 is valid. For what it's worth, Google DNS SERVFAILs for me when I break the KSK on a test domain. Perhaps they are at times validating on KeyID 613 (and subsequent NOERROR response) and the rest of the time failing to validate KeyID 35973?

I would expect inconsistent behave from anycast resolvers which have different
sets of supported algorithms on the different instances with this zone.  I don’t
know how 8.8.8.8 is configured but there will be times when this is the case
as you can’t upgraded all servers at the same time without disrupting service.

If don’t support either algorithm the answer should be insecure (NOERROR).
If you just support algorithm 3 then the answer should be secure (NOERROR).
If you just support algorithm 10 then the answer should be bogus (SERVFAIL).
If you support algorithms 3 + 10 they the answer should be secure (NOERROR,
via algorithm 3).

If you support algorithms 3 + 10 and have local policy which says to verify
all supported algorithms, as signalled in the DS RRset, then you should get
bogus (SERVFAIL).

For the record this zone, correctly, fails to validate with BIND 9.14
as DSA support was removed in this change.

5045.   [func]          Remove support for DNSSEC algorithms 3 (DSA)
                        and 6 (DSA-NSEC3-SHA1). [GL #22]

And logs messages like these:

19-Apr-2019 09:46:24.330 view secure: validating rv.ua/DNSKEY: starting
19-Apr-2019 09:46:24.330 view secure: validating rv.ua/DNSKEY: attempting positive response validation
19-Apr-2019 09:46:24.330 view secure: validating rv.ua/DNSKEY: no valid signature found
19-Apr-2019 09:46:24.330 view secure: validating rv.ua/DNSKEY: falling back to insecurity proof
19-Apr-2019 09:46:24.330 view secure: validating rv.ua/DNSKEY: checking existence of DS at 'ua'
19-Apr-2019 09:46:24.330 view secure: validating rv.ua/DNSKEY: checking existence of DS at 'rv.ua'
19-Apr-2019 09:46:24.330 view secure: validating rv.ua/DNSKEY: insecurity proof failed
19-Apr-2019 09:46:24.330 view secure: validator @0x7fd174b08600: dns_validator_destroy

> On Thu, Apr 18, 2019 at 7:22 AM Taras Heichenko <tasic at hostmaster.ua> wrote:
> 
> 
> > On Apr 18, 2019, at 13:07, Jim Reid <jim at rfc1035.com> wrote:
> > 
> > 
> > 
> >> On 18 Apr 2019, at 10:46, Stephane Bortzmeyer <bortzmeyer at nic.fr> wrote:
> >> 
> >> Of course, it would be better to move away from DSA, but it shouldn't
> >> make a SERVFAIL, just a lack of validation
> > 
> > ? If DSA signatures can't be validated, SERVFAIL is the correct response.
> 
> Then why does google resolver sometimes give the answer with NSes?
> Sometimes it can validate DSA signature and sometimes not?
> 
> > 
> > _______________________________________________
> > dns-operations mailing list
> > dns-operations at lists.dns-oarc.net
> > https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> > dns-operations mailing list
> > https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> 
> --
> Best regards
> 
> Taras Heichenko
> tasic at hostmaster.ua
> 
> 
> 
> 
> 
> 
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-operations mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-operations mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka at isc.org