3

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.

comfreak
  • 1,501
  • 1
  • 21
  • 33
  • After a month this issue still seems to be present, so it is probably not that my connection is being tampered with, but I am still confused about what is causing this weird behaviour. – comfreak Oct 06 '15 at 15:20

2 Answers2

5

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.

Brian
  • 3,476
  • 18
  • 16
DannyAAMtw
  • 66
  • 1
  • 2
  • Thanks for your answer to this rather old question. Since I couldn't upgrade to the newer version (Debian only has 2.72 in its wheezy repo) I decided to switch to unbound which seems to work as well. – comfreak Dec 13 '15 at 18:28
  • A long time ago... but I think useful: it is easy to compile dnsmasq from its source code. – Massimo Jun 15 '19 at 09:33
2

Its happening to me using the latest dnscrypt 2.0.8 and the latest dnssec 2.79; This was temporary and lasted for only 12 minutes.

So it is not limited to earlier versions. According to the section "DNS Pitfalls" in A Case for Comprehensive DNSSEC Monitoring and Analysis Tools (emphasis added):

B. Bogus validation caused by misconfiguration

In this section we describe some of the causes of validation failures from a perspective of misconfiguration. In any case, an RRset deemed bogus also invalidates any dependent RRsets. For example, a bogus DNSKEY RRset means that all of the RRsets whose RRSIGs would be potentially validated by those DNSKEYs are also bogus.

...

Bogus: The validator is unable to form a chain of trust between the RRset and a trust anchor and is unable to securely show that no such chain should exist. Example: an expired RRSIG covering an RRset in the secure.com results a bogus response; likewise, the presence of a DS for the broken.com zone, in which there are no DNSKEYs present, results in a bogus status for any RRset in the zone

While a secure validation is ideal, an insecure outcome is also usable and is equivalent to normal, unauthenticated name resolution. However, a bogus outcome is an indicator that validation failed—either because the DNS data has been tampered with or because of misconfiguration. The response returned to a recursive (i.e., on behalf of another client) query which a validator renders bogus has SERVFAIL error status and contains no DNS data, an indication of general name resolution failure. An end user cannot distinguish a SERVFAIL response caused by data tampering from one caused by misconfiguration. In either case, however, the end result is the same: the name in question cannot be resolved. This study focuses on bogus validation caused by misconfiguration.

Community
  • 1
zepplingradge
  • 21
  • 2