Disappointing DNSSEC coverage

[dave14305]

I've been using DNSSEC with Stubby and was curious about how often I'm "protected" by DNSSEC. Since I run Diversion with logging, I scanned my dnsmasq logs for the number of INSECURE, SECURE or BOGUS results. I was very disappointed to see that most of my home's queries were INSECURE, and only a small handful SECURE.

This is probably a skewed sample because I run Diversion and any other shady domain names were probably blocked before being forwarded for DNSSEC validation, so I wasn't expecting too many BOGUS returns. And due to the log rotation by Diversion, there's only 3 days of logs to query on. (EDIT: My understanding of Diversion log rotation was incorrect).

But since we spend a lot of time here trying to protect our DNS queries, it still feels like the early adoption phase of DNSSEC.

Does anyone else want to share their "ratio" of results?

grep "validation result " /opt/var/log/dnsmasq.log* | awk ' { print $NF } ' | sort | uniq -c
  13878 INSECURE
    231 SECURE

 

[Mutzli]

71932 INSECURE
12316 SECURE
not much better results either.

 

[Delusion]

Yes the coverage known to be poor. Is there any benefit to DNSSEC on domains which do not support it?

 

[Val D.]

and only a small handful SECURE

Your observation is correct. That is why I don't even bother to check the "Enable DNSSEC support" box.

 

[RMerlin]

The last figure I saw quoted was that less than 1% of domains were protected by DNSSEC.

And your numbers might be more optimistic than the average because my domain is covered by DNSSEC, which means the regular new firmware checks will be run against a signed zone.

I wish there would be less noise about DoT/DoH, and more emphasis on DNSSEC. DNSSEC is far more important in securing the core of the Internet. Compromise a DNS zone, and you pretty much control everything that uses that domain name.

 

[dave14305]

The last figure I saw quoted was that less than 1% of domains were protected by DNSSEC.

And your numbers might be more optimistic than the average because my domain is covered by DNSSEC, which means the regular new firmware checks will be run against a signed zone.

I wish there would be less noise about DoT/DoH, and more emphasis on DNSSEC. DNSSEC is far more important in securing the core of the Internet. Compromise a DNS zone, and you pretty much control everything that uses that domain name.

Unfortunately, DoT/DoH is the only measure that we can be sure is doing something right now, based on that 1% figure. But I certainly agree that the integrity of DNS is more important (for the greater good) than confidentiality of any single user.

The needs of the many outweigh the needs of the few...or the one.

 

[RMerlin]

Unfortunately, DoT/DoH is the only measure that we can be sure is doing something right now, based on that 1% figure.

Activism is the only answer for now. That's why I'm generally quite vocal about DNSSEC, DoT and DoH, trying to emphasize the need for more domain names to start using DNSSEC to secure their zone. It has a fairly steep learning curve in some cases, depending on your registrar and which TLD you use, and unfortunately it's often an obstacle to more widespread adoption. But ensuring the public understands the need for DNSSEC is a starting point.

 

[Makaveli]

51644 Insecure
6758 Secure

Using firmware DNSSEC not stubby.

 

[bbunge]

I am going to step out on that crumbly ledge and say that the Diversion log shows nothing about DNSSEC . As I understand Diversion, it is an add blocker that filters URL's after they have been looked up by resolvers.
DNSSEC is a means of securing/verifing DNS lookups between resolvers. "DNSSEC works by digitally signing records for DNS lookup using public-key cryptography. The correct DNSKEY record is authenticated via a chain of trust, starting with a set of verified public keys for the DNS root zone which is the trusted third party. Domain owners generate their own keys, and upload them using their DNS control panel at their domain-name registrar, which in turn pushes the keys via secDNS to the zone operator (e.g., Verisign for .com) who signs and publishes them in DNS." See https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions and https://www.icann.org/resources/pages/dnssec-what-is-it-why-important-2019-03-05-en

On our routers it may be difficult to put a metric on DNSSEC success or failure. One thing to look for is in the system log:

Oct 21 18:51:13 dnsmasq[237]: Insecure DS reply received for 70.100.in-addr.arpa, could be bad domain configuration or lack of DNSSEC support from upstream DNS servers

The "Insecure DS reply received" is one indication that DNSSEC is working.
Right now DoH/DoT along with DNSSEC just may be the best way to insure a good lookup. I am sure there is someone who will say I am wrong and that is OK. I am just making a statement which I will not argue.

 

[dave14305]

I am going to step out on that crumbly ledge and say that the Diversion log shows nothing about DNSSEC . As I understand Diversion, it is an add blocker that filters URL's after they have been looked up by resolvers.
DNSSEC is a means of securing/verifing DNS lookups between resolvers. "DNSSEC works by digitally signing records for DNS lookup using public-key cryptography. The correct DNSKEY record is authenticated via a chain of trust, starting with a set of verified public keys for the DNS root zone which is the trusted third party. Domain owners generate their own keys, and upload them using their DNS control panel at their domain-name registrar, which in turn pushes the keys via secDNS to the zone operator (e.g., Verisign for .com) who signs and publishes them in DNS." See https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions and https://www.icann.org/resources/pages/dnssec-what-is-it-why-important-2019-03-05-en

On our routers it may be difficult to put a metric on DNSSEC success or failure. One thing to look for is in the system log:

Oct 21 18:51:13 dnsmasq[237]: Insecure DS reply received for 70.100.in-addr.arpa, could be bad domain configuration or lack of DNSSEC support from upstream DNS servers

The "Insecure DS reply received" is one indication that DNSSEC is working.
Right now DoH/DoT along with DNSSEC just may be the best way to insure a good lookup. I am sure there is someone who will say I am wrong and that is OK. I am just making a statement which I will not argue.

I believe you prefer to have Stubby do the DNSSEC, so you won't see the logs that dnsmasq generates for DNSSEC queries.

Oct 19 22:02:23 dnsmasq[17751]: query[A] www.snbforums.com from 192.168.1.121
Oct 19 22:02:23 dnsmasq[17751]: forwarded www.snbforums.com to 127.0.0.1
Oct 19 22:02:24 dnsmasq[17751]: dnssec-query[DS] snbforums.com to 127.0.0.1
Oct 19 22:02:24 dnsmasq[17751]: reply snbforums.com is no DS
Oct 19 22:02:24 dnsmasq[17751]: validation result is INSECURE
Oct 19 22:02:24 dnsmasq[17751]: reply www.snbforums.com is 104.25.234.15
Oct 19 22:02:24 dnsmasq[17751]: reply www.snbforums.com is 104.25.235.15
...
Oct 19 23:05:28 dnsmasq[17751]: query[A] time.nist.gov from 127.0.0.1
Oct 19 23:05:28 dnsmasq[17751]: forwarded time.nist.gov to 127.0.0.1
Oct 19 23:05:28 dnsmasq[17751]: dnssec-query[DS] nist.gov to 127.0.0.1
Oct 19 23:05:28 dnsmasq[17751]: reply nist.gov is DS keytag 3933, algo 7, digest 1
Oct 19 23:05:28 dnsmasq[17751]: reply nist.gov is DS keytag 47499, algo 7, digest 1
Oct 19 23:05:28 dnsmasq[17751]: reply nist.gov is DS keytag 3933, algo 7, digest 2
Oct 19 23:05:28 dnsmasq[17751]: reply nist.gov is DS keytag 47499, algo 7, digest 2
Oct 19 23:05:28 dnsmasq[17751]: dnssec-query[DNSKEY] glb.nist.gov to 127.0.0.1
Oct 19 23:05:28 dnsmasq[17751]: reply glb.nist.gov is DNSKEY keytag 19565, algo 7
Oct 19 23:05:28 dnsmasq[17751]: reply glb.nist.gov is DNSKEY keytag 36090, algo 7
Oct 19 23:05:28 dnsmasq[17751]: reply glb.nist.gov is DNSKEY keytag 45708, algo 7
Oct 19 23:05:28 dnsmasq[17751]: reply glb.nist.gov is DNSKEY keytag 5780, algo 7
Oct 19 23:05:28 dnsmasq[17751]: validation result is SECURE
Oct 19 23:05:28 dnsmasq[17751]: reply time.nist.gov is <CNAME>
Oct 19 23:05:28 dnsmasq[17751]: reply ntp1.glb.nist.gov is 129.6.15.26

 

[Val D.]

One thing to look for is in the system log:

I've never seen this in my system log with DNSSEC enabled.
Oops, by the time I was writing this @dave14305 explained why.

 

[dave14305]

Activism is the only answer for now. That's why I'm generally quite vocal about DNSSEC, DoT and DoH, trying to emphasize the need for more domain names to start using DNSSEC to secure their zone. It has a fairly steep learning curve in some cases, depending on your registrar and which TLD you use, and unfortunately it's often an obstacle to more widespread adoption. But ensuring the public understands the need for DNSSEC is a starting point.

It was very eye-opening when I was experimenting with Unbound as a recursive resolver on the router, and using DNSSEC. When there is so much focus on the public recursive resolvers like Cloudflare, Quad9, Google, OpenDNS, etc. you can really forget how the whole DNS system works. Watching the recursive queries and the DNSSEC validation was really cool.

 

[thelonelycoder]

None of my domains have DNSSEC enabled, simply because the process is tedious with the way my registrar and hoster are set up.

 

[MarkRH]

Is this dnsmasq log enabled by default? It must not be since it doesn't exist on my router.

Anyway, mine is probably skewed to more positive results since my own websites all have DNSSEC enabled on them. Used the Zone Editor in cPanel at webhost to enable DNSSEC and copied the information to NameCheap's Advanced DNS settings. It was pretty easy to do.

 

[Makaveli]

Is this dnsmasq log enabled by default? It must not be since it doesn't exist on my router.

Anyway, mine is probably skewed to more positive results since my own websites all have DNSSEC enabled on them. Used the Zone Editor in cPanel at webhost to enable DNSSEC and copied the information to NameCheap's Advanced DNS settings. It was pretty easy to do.

As per dave's post above its only there if you are using stubby not the firmware version of DNSSEC.

So which one are you using?

 

[dave14305]

As per dave's post above its only there if you are using stubby not the firmware version of DNSSEC.

So which one are you using?

No, Stubby is irrelevant. It’s dnsmasq doing DNSSEC and Diversion enabling the dnsmasq query logging.

 

[Makaveli]

No, Stubby is irrelevant. It’s dnsmasq doing DNSSEC and Diversion enabling the dnsmasq query logging.

Ah thanks for clarifying.

 

[rgnldo]

Understanding DNSSEC
DNSSEC supplements the hierarchical nature of the DNS with cryptographic characteristics that make it possible to verify the authenticity of information stored in the DNS. This validation makes it possible for resolvers to be assured that when they request a particular piece of information from the DNS, that they do in fact receive the correct information as published by the authoritative source.

This assurance is made possible using cryptographic signatures included in the DNS by a source organization. These signatures are calculated on a complete Resource Record set, not individual Resource Records. The signatures are published in a DNSSEC-specific resource record type called RRSIG. For example, setting aside the requisite infrastructure, by publishing the signature for an A record, the source organization makes it possible for resolvers on the Internet to verify that the A record contains authentic data and is correct as published. A DNS server is only signing data for which it is authoritative, for example, the DNS server does not sign NS records that delegate subdomains from its zone.

A client computer with an embedded stub resolver sets the DNSSEC OK (DO) bit to 1 in outbound queries when it wants to use DNSSEC to verify the authenticity of DNS information. When a DNSSEC enabled DNS server receives a query with DO=1, it uses locally stored or received RRSIG records to cryptographically verify the authenticity of the DNS information. The verification result is communicated to the stub resolver using the Authenticated Data (AD) bit in the DNS response; where AD=1 indicates the DNS data is authentic, and AD=0 indicates that DNSSEC verification failed.


Difference between DNS and DNSSEC
From a network perspective, DNS and DNSSEC are very similar. DNSSEC requires an expanded set of DNS capabilities, and while DNS may have worked without them, DNSSEC will not.

For example, DNSSEC message sizes will be larger than DNS messages without DNSSEC, and that is managed with the help of the EDNS. This is simply the result of additional information being contained within the DNS responses. Without DNSSEC, DNS packets are typically less than 512 bytes in length. With DNSSEC, many DNS packets will exceed 512 bytes and may approach 4096 bytes. Additionally, end-to-end EDNS must be supported to carry the DO, AD, and other DNSSEC-specific header flags.
Because of the increased packet size, DNS with DNSSEC may use TCP more often then DNS without DNSSEC.


Potential Networking Challenges with DNSSEC Deployment
The networking-specific challenges from DNSSEC are largely the result of the differences mentioned previously: increased packet sizes, EDNS requirements and the more frequent use of TCP. Many firewall devices incorrectly limit DNS responses to 512 and prohibit DNS over TCP. These challenges and potential remedies are described in the next section of this document.

https://tools.cisco.com/security/center/resources/dnssec_best_practices

In my opinion, in addition to DNSSEC validation, a good DNS server must provide EDNS, QNAME MINIMIZATION, and recursion options. So far unbound is the solution that most supports dnssec. Projects such as OpenWRT, DD-WRT, PFSense, OPNSense are already advanced in this regard.