1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.
Dismiss Notice

Welcome To SNBForums

SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.

If you'd like to post a question, simply register and have at it!

While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!

Disappointing DNSSEC coverage

Discussion in 'Asuswrt-Merlin' started by dave14305, Oct 21, 2019.

Tags:
  1. dave14305

    dave14305 Very Senior Member

    Joined:
    May 19, 2018
    Messages:
    1,506
    Location:
    USA
    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?
    Code:
    grep "validation result " /opt/var/log/dnsmasq.log* | awk ' { print $NF } ' | sort | uniq -c
      13878 INSECURE
        231 SECURE
    
     
    Last edited: Oct 26, 2019
    martinr likes this.
  2. Mutzli

    Mutzli Senior Member

    Joined:
    Dec 22, 2014
    Messages:
    322
    71932 INSECURE
    12316 SECURE
    not much better results either.
     
  3. Delusion

    Delusion Regular Contributor

    Joined:
    May 4, 2019
    Messages:
    179
    Yes the coverage known to be poor. Is there any benefit to DNSSEC on domains which do not support it?
     
  4. Val D.

    Val D. Very Senior Member

    Joined:
    Jun 16, 2019
    Messages:
    793
    Location:
    Great White North
    Your observation is correct. That is why I don't even bother to check the "Enable DNSSEC support" box.
     
    Delusion likes this.
  5. RMerlin

    RMerlin Super Moderator

    Joined:
    Apr 14, 2012
    Messages:
    31,537
    Location:
    Canada
    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.
     
    jsbeddow and skeal like this.
  6. dave14305

    dave14305 Very Senior Member

    Joined:
    May 19, 2018
    Messages:
    1,506
    Location:
    USA
    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.
     
  7. RMerlin

    RMerlin Super Moderator

    Joined:
    Apr 14, 2012
    Messages:
    31,537
    Location:
    Canada
    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.
     
    jsbeddow, skeal, martinr and 3 others like this.
  8. Makaveli

    Makaveli Very Senior Member

    Joined:
    Nov 4, 2016
    Messages:
    536
    Location:
    Canada
    51644 Insecure
    6758 Secure

    Using firmware DNSSEC not stubby.
     
    Last edited: Oct 21, 2019
    dave14305 likes this.
  9. bbunge

    bbunge Very Senior Member

    Joined:
    Aug 11, 2014
    Messages:
    999
    Location:
    Pennsylvania USA
    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:
    Code:
    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.
     
    martinr and dave14305 like this.
  10. dave14305

    dave14305 Very Senior Member

    Joined:
    May 19, 2018
    Messages:
    1,506
    Location:
    USA
    I believe you prefer to have Stubby do the DNSSEC, so you won't see the logs that dnsmasq generates for DNSSEC queries.
    Code:
    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
     
  11. Val D.

    Val D. Very Senior Member

    Joined:
    Jun 16, 2019
    Messages:
    793
    Location:
    Great White North
    I've never seen this in my system log with DNSSEC enabled.
    Oops, by the time I was writing this @dave14305 explained why.
     
  12. dave14305

    dave14305 Very Senior Member

    Joined:
    May 19, 2018
    Messages:
    1,506
    Location:
    USA
    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.
     
    L&LD likes this.
  13. thelonelycoder

    thelonelycoder Part of the Furniture

    Joined:
    Jan 23, 2014
    Messages:
    5,974
    Location:
    Switzerland
    None of my domains have DNSSEC enabled, simply because the process is tedious with the way my registrar and hoster are set up.
     
  14. MarkRH

    MarkRH Senior Member

    Joined:
    Oct 1, 2015
    Messages:
    238
    Location:
    Oklahoma City, OK
    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.
     
  15. Makaveli

    Makaveli Very Senior Member

    Joined:
    Nov 4, 2016
    Messages:
    536
    Location:
    Canada
    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?
     
  16. dave14305

    dave14305 Very Senior Member

    Joined:
    May 19, 2018
    Messages:
    1,506
    Location:
    USA
    No, Stubby is irrelevant. It’s dnsmasq doing DNSSEC and Diversion enabling the dnsmasq query logging.
     
    Makaveli likes this.
  17. Makaveli

    Makaveli Very Senior Member

    Joined:
    Nov 4, 2016
    Messages:
    536
    Location:
    Canada
    Ah thanks for clarifying.
     
  18. rgnldo

    rgnldo Senior Member

    Joined:
    Nov 12, 2018
    Messages:
    334
    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.
     
    Last edited: Oct 29, 2019
    L&LD, PolarBear and Marin like this.