Dnsmasq returns (false) “bogus” result for DNSSEC validation

debian-jessiednsmasqdnssec

I'm running a local Debian 8.1 installation with a DNSSEC-validating DNS-Resolver called dnsmasq (version 2.72-3+deb8u1).

I set it up to return a SERVFAIL if it isn't able to validate a DNSSEC-enabled domain, i.e. if the domain has a DNSSEC entry it must validate correctly in order to be forwarded on to the client.

While I was browsing today I wanted to visit the rather famous site of the IETF but I couldn't because the domain couldn't be resolved. I checked with the commandline to verify this and I got indeed a SERVFAIL. I checked with the Google DNS server (8.8.8.8) and got no SERVFAIL but the IP address.

After that I enabled logging for each dns request and checked the results. It seems that my feeling was right and the DNSSEC validation failed, even though it got the same response from the DNS forwarders like I got from Google.

Here the corresponding lines of my syslog:

Sep  5 13:27:13 dnsmasq: query[A] www.ietf.org from 192.168.1.10
Sep  5 13:27:13 dnsmasq: forwarded www.ietf.org to 81.3.21.188
Sep  5 13:27:13 dnsmasq: forwarded www.ietf.org to 178.63.73.246
Sep  5 13:27:13 dnsmasq: dnssec-query[DNSKEY] ietf.org to 81.3.21.188
Sep  5 13:27:13 dnsmasq: dnssec-query[DS] ietf.org to 81.3.21.188
Sep  5 13:27:13 dnsmasq: dnssec-query[DNSKEY] org to 81.3.21.188
Sep  5 13:27:13 dnsmasq: dnssec-query[DS] org to 81.3.21.188
Sep  5 13:27:13 dnsmasq: dnssec-query[DNSKEY] . to 81.3.21.188
Sep  5 13:27:13 dnsmasq: reply . is DNSKEY keytag 1518
Sep  5 13:27:13 dnsmasq: reply . is DNSKEY keytag 19036
Sep  5 13:27:13 dnsmasq: reply org is DS keytag 21366
Sep  5 13:27:13 dnsmasq: reply org is DS keytag 21366
Sep  5 13:27:13 dnsmasq: reply org is DNSKEY keytag 19629
Sep  5 13:27:13 dnsmasq: reply org is DNSKEY keytag 21366
Sep  5 13:27:13 dnsmasq: reply org is DNSKEY keytag 9795
Sep  5 13:27:13 dnsmasq: reply org is DNSKEY keytag 12023
Sep  5 13:27:13 dnsmasq: reply ietf.org is DS keytag 45586
Sep  5 13:27:13 dnsmasq: reply ietf.org is DS keytag 45586
Sep  5 13:27:13 dnsmasq: reply ietf.org is DNSKEY keytag 45586
Sep  5 13:27:13 dnsmasq: reply ietf.org is DNSKEY keytag 40452
Sep  5 13:27:13 dnsmasq: dnssec-query[DNSKEY] cloudflare-dnssec.net to 81.3.21.188
Sep  5 13:27:13 dnsmasq: dnssec-query[DS] cloudflare-dnssec.net to 81.3.21.188
Sep  5 13:27:13 dnsmasq: dnssec-query[DNSKEY] net to 81.3.21.188
Sep  5 13:27:13 dnsmasq: dnssec-query[DS] net to 81.3.21.188
Sep  5 13:27:13 dnsmasq: reply net is DS keytag 35886
Sep  5 13:27:13 dnsmasq: reply net is DNSKEY keytag 45464
Sep  5 13:27:13 dnsmasq: reply net is DNSKEY keytag 35886
Sep  5 13:27:13 dnsmasq: reply cloudflare-dnssec.net is DS keytag 537
Sep  5 13:27:13 dnsmasq: reply cloudflare-dnssec.net is BOGUS DNSKEY
Sep  5 13:27:13 dnsmasq: validation result is BOGUS
Sep  5 13:27:13 dnsmasq: reply www.ietf.org is <CNAME>
Sep  5 13:27:13 dnsmasq: reply www.ietf.org.cdn.cloudflare-dnssec.net is 104.20.0.85
Sep  5 13:27:13 dnsmasq: reply www.ietf.org.cdn.cloudflare-dnssec.net is 104.20.1.85

Now I am not sure if the domain is temporarily misconfigured or my connection is being tampered with or if my DNS server is misconfigured, even though every other domain so far worked fine, including "ietf.org" (without the www).

If someone could help me trace the issue, I would be thankful.

Best Answer

That's due to CloudFlare(CDN provider of IETF) choosing ECDSAP256SHA256 as their signature algorithm. Dnsmasq has implemented ECDSA since 2.69, however it was broken and not fixed until 2.73 which was released in March 2015. Thus, you'll need a newer dnsmasq or patched version to resolve it correctly.

From the dnsmasq change log in the 2.73 section:

Fix broken DNSSEC validation of ECDSA signatures.

From the Cloudflare DS record set:

cloudflare.net. 86400 IN DS 2371 13 2 90F710A107DA51ED78125D30A68704CF3C0308AFD01BFCD7057D4BD0 3B62C68B

The 13 is the algorithm type. Each allowed algorithm in DNSSEC has a specified number. Algorithm 13 is ECDSA with a P-256 curve using SHA-256.

Finally dig +trace ds www.ietf.org includes a CNAME record going through Cloudflare.

www.ietf.org. 1800 IN CNAME www.ietf.org.cdn.cloudflare-dnssec.net.

Related Solutions

Dnssec-keygen key default validation / expiration time

The default Times if you do not set them via params as descriped in the Manual from dnssec-keygen are:

Published: {Time of creation}
Activated: {Time of creation}
Revoked: Not set
Retired: Not set
Deleted: Not set

So if you do not set any Times on the Keys, it will be default last for ever (or until KSK will change and you HAVE to rotate the Key)

U also have the ability to change the dates later via dnssec-settime

Bind9 does not resolve dnssec correctly

The forwarders that you have configured will only cause problems when running a validating resolver as the Opendns servers do not cooperate when doing DNSSEC validation.

I suppose it might mostly work anyway for you as you didn't specify forward only, so named will fall back to resolving things on its own more or less all the time as the forwarders keep failing to produce useful results. But even if it sort of works it will still make a complete mess of your logs.

To demonstrate, if I set forward only and use those same forwarders this is what happens:

named[20057]: error (no valid RRSIG) resolving 'net/DS/IN': 208.67.220.220#53
named[20057]: error (no valid RRSIG) resolving 'net/DS/IN': 208.67.222.222#53
named[20057]: error (no valid DS) resolving 'sigfail.verteiltesysteme.net/A/IN': 208.67.222.222#53
named[20057]: validating @0x7f36805ecb10: sigfail.verteiltesysteme.net A: bad cache hit (net/DS)
named[20057]: error (broken trust chain) resolving 'sigfail.verteiltesysteme.net/A/IN': 208.67.220.2

As you can see, it fails but for entirely the wrong reason. (It failed at the DS for net, not when validating the actually broken signatures at sigfail.verteiltesysteme.net.)

I expect your logs are currently a mix of stuff like the above combined with actually relevant entries from when named falls back to querying properly working servers. Fixing this ought to help troubleshooting.

As for the inconsistent results, I'm not sure that anything in your configuration can really explain that. Are you positive that it's actually that same named instance that answered the query? No strange NAT rules or something like that which would cause clients to transparently talk to some different server or whatnot?

Queries like dig @192.168.10.36 version.bind CH TXT and dig @192.168.10.36 hostname.bind CH TXT could expose such a thing going on.

Best Answer

Related Solutions

Dnssec-keygen key default validation / expiration time

Bind9 does not resolve dnssec correctly

Related Topic