Yesterday a customer of ours reported they couldn’t get to mypay.dfas.mil. Upon looking into it I see both of my Unbound servers are returning SERVFAIL. Given the type of sight this is I suspected this to be a possible DNSSEC issue. I verified there’s an issue here:
•dfas.mil/DNSKEY:This RRset is not covered by any RRSIG.
•dfas.mil/MX:DNSKEYs exist for algorithm(s) 8, 7 in the dfas.mil zone, but the dfas.mil/MX RRset was not signed by any DNSKEY with algorithm(s) 7.
•dfas.mil/SOA:DNSKEYs exist for algorithm(s) 8, 7 in the dfas.mil zone, but the dfas.mil/SOA RRset was not signed by any DNSKEY with algorithm(s) 7.
•dfas.mil/TXT:DNSKEYs exist for algorithm(s) 8, 7 in the dfas.mil zone, but the dfas.mil/TXT RRset was not signed by any DNSKEY with algorithm(s) 7.
I tested resolution against both DNS-OARC’s BIND and Unbound DNSSEC public servers:
BIND 9 149.20.64.20 2001:4f8:3:2bc:1::64:20
Unbound 149.20.64.21 2001:4f8:3:2bc:1::64:21
Their Unbound server fails just as mine do, but their BIND server returns the A record. I’m reluctant to disable DNSSEC validation over this one domain, considering there appears to be an actual problem. Considering BIND as well as Google’s public DNS are validating this site OK I figured it was worth bringing up.
Yesterday a customer of ours reported they couldn’t get to
*mypay.dfas.mil*. Upon looking into it I see both of my Unbound
servers are returning SERVFAIL. Given the type of sight this is I
suspected this to be a possible DNSSEC issue. I verified there’s an
issue here:
Unbound checks that the chain of trust uses the correct algorithm, as
advertised by the DS record. The DS record advertises algorithm 7
(only). The DNSKEY record set has keys for 7 and 8. The MX record is
signed with only 8.
Unbound is strict here, the DS record states that this chain of trust
must be present (MUST in the RFC). It is not, bogus.
Bind is more lenient here, and a signature whose algorithm was not
advertised is fine.
Just to add, it looks like they may have moved to NSEC3 recently. I've seen big problems when sites do this - lots of people seem to forget that changing key algorithms is a KSK rollover and comes with very tight TTL constraints; I note the TTLs on the DNSKEY in-zone are 86400. I bet they got over-keen and resigned too quickly.
Unbound checks that the chain of trust uses the correct algorithm, as
advertised by the DS record. The DS record advertises algorithm 7
(only). The DNSKEY record set has keys for 7 and 8. The MX record is
signed with only 8.
Unbound is strict here, the DS record states that this chain of trust
must be present (MUST in the RFC). It is not, bogus.
I realize this has been the subject of some discussion over the past
several years. RFC 6840 [1] updates RFC 4035 to specify that this
requirement applies to signers, not to validators:
This requirement applies to servers, not validators. Validators
SHOULD accept any single valid path. They SHOULD NOT insist that all
algorithms signaled in the DS RRset work, and they MUST NOT insist
that all algorithms signaled in the DNSKEY RRset work. A validator
MAY have a configuration option to perform a signature completeness
test to support troubleshooting.