No announcement yet.

DNSSEC in dnsmasq/NGFW

This topic is closed.
  • Filter
  • Time
  • Show
Clear All
new posts

  • DNSSEC in dnsmasq/NGFW

    DNSSEC has been available in dnsmasq since about version 2.56

    Here is a little background documentation:

    DNSSEC validation and caching.
    Dnsmasq needs to be compiled with this enabled, with:
    make dnsmasq COPTS=-DHAVE_DNSSEC
    this adds dependencies on the nettle crypto library and the
    gmp maths library.

    It's possible to have these linked statically with:
    which bloats the dnsmasq binary, but saves the size of
    the shared libraries which are much bigger.

    To enable, DNSSEC, you will need a set of
    trust-anchors. Now that the TLDs are signed, this can be
    the keys for the root zone, and for convenience they are
    included in trust-anchors.conf in the dnsmasq
    distribution. You should of course check that these are
    legitimate and up-to-date. So, adding
    to your config is all that's needed to get things
    working. The upstream nameservers have to be DNSSEC-capable
    too, of course. Many ISP nameservers aren't, but the
    Google public nameservers ( and are.
    When DNSSEC is configured, dnsmasq validates any queries
    for domains which are signed. Query results which are
    bogus are replaced with SERVFAIL replies, and results
    which are correctly signed have the AD bit set. In
    addition, and just as importantly, dnsmasq supplies
    correct DNSSEC information to clients which are doing
    their own validation, and caches DNSKEY, DS and RRSIG
    records, which significantly improve the performance of
    downstream validators. Setting --log-queries will show
    DNSSEC in action.

    If a domain is returned from an upstream nameserver without
    DNSSEC signature, dnsmasq by default trusts this. This
    means that for unsigned zone (still the majority) there
    is effectively no cost for having DNSSEC enabled. Of course
    this allows an attacker to replace a signed record with a
    false unsigned record. This is addressed by the
    --dnssec-check-unsigned flag, which instructs dnsmasq
    to prove that an unsigned record is legitimate, by finding
    a secure proof that the zone containing the record is not
    signed. Doing this has costs (typically one or two extra
    upstream queries). It also has a nasty failure mode if
    dnsmasq's upstream nameservers are not DNSSEC capable.
    Without --dnssec-check-unsigned using such an upstream
    server will simply result in not queries being validated;
    with --dnssec-check-unsigned enabled and a
    DNSSEC-ignorant upstream server, _all_ queries will fail.

    Note that DNSSEC requires that the local time is valid and
    accurate, if not then DNSSEC validation will fail. NTP
    should be running. This presents a problem for routers
    without a battery-backed clock. To set the time needs NTP
    to do DNS lookups, but lookups will fail until NTP has run.
    To address this, there's a flag, --dnssec-no-timecheck
    which disables the time checks (only) in DNSSEC. When dnsmasq
    is started and the clock is not synced, this flag should
    be used. As soon as the clock is synced, SIGHUP dnsmasq.
    The SIGHUP clears the cache of partially-validated data and
    resets the no-timecheck flag, so that all DNSSEC checks
    henceforward will be complete.

    The development of DNSSEC in dnsmasq was started by
    Giovanni Bajo, to whom huge thanks are owed. It has been
    supported by Comcast, whose techfund grant has allowed for
    an invaluable period of full-time work to get it to
    a workable state.

    from:, version 2.69

    Implementing in NGFW:
    In #config/network/advanced/dns_and_dhcp - Custom dnsmasq options:

    # Validate DNS replies and cache DNSSEC data. When forwarding DNS queries, dnsmasq requests the DNSSEC records needed to validate the replies. 
    # The replies are validated and the result returned as the Authenticated Data bit in the DNS packet. In addition the DNSSEC records are stored in the cache, 
    # making validation by clients more efficient. Note that validation by clients is the most secure DNSSEC mode, but for clients unable to do validation, 
    # use of the AD bit set by dnsmasq is useful, provided that the network between the dnsmasq server and the client is trusted. 
    # Dnsmasq must be compiled with HAVE_DNSSEC enabled, and DNSSEC trust anchors provided, see --trust-anchor. 
    # Because the DNSSEC validation process uses the cache, 
    # it is not permitted to reduce the cache size below the default when DNSSEC is enabled. 
    # The nameservers upstream of dnsmasq must be DNSSEC-capable, ie capable of returning DNSSEC records with data. If they are not, 
    # then dnsmasq will not be able to determine the trusted status of answers and this means that DNS service will be entirely broken.
    # * NOTE: Your upstream DNS server must support DNSSEC.
    # Set the size of dnsmasq's cache. The default is 150 names. Setting the cache size to zero disables caching. Note: huge cache size impacts performance.
    # * big enough to be useful
    Note: In dnsmasq, a "huge cache size" is essentially unobtanium on modern hardware. A previously hard-coded 10,000 name clipping value was removed a couple of years ago.
    Personal experience with dnsmasq as a caching DNS server for a few
    hundred fairly active clients shows no notable performance impact even
    when allowing the maximum cache size to be > 100,000 (query reply time
    from cache is on the order of < 5 msec). It may always be that I miss
    something but even when dnsmasq's cache would be 10 (or more) times
    slower, it would still be much faster than when we'd periodically ask
    upstream servers.

    - from

    However, there is no need to approach that (now a logged warning) 10,000 limit, either.
    So with the previous cache size, less than 4% of queries cause eviction
    of a name from the cache before the time-to-live expires and it
    disappears anyway. Only a small fraction of those will be re-queried so
    the number of extra cache-misses is in the noise. I'd say that the cache
    size you had before was pretty much optimal, but in response you tried
    to increase it to more than the total number of cache insertions ever,
    during that run of dnsmasq.


    The local copy of dnsmasq here, which is handling a network of a dozen
    machines, has a tiny cache, and very similar stats. It just doesn't need
    to be any bigger. (and that instance is doing DNSSEC, so the cache
    holding all sorts of DNSSEC records too.)

    cache size 600, 50/28526 cache insertions re-used unexpired cache entries.

    Simon Kelley simon at

    Use of these options is not supported by Untangle. Use at your own risk.
    This configuration was developed for my purposes, on my system, based on my experience and opinions.
    It is provided for informational and educational purposes only. It is not advice on what you should do.
    Certain options, if copied directly, are likely to stop DNS/DHCP from working on your local network.
    It is provided to spur research into the use of these options for your own purposes. Understand them before you implement any of it.

    Most of the comment text was copied from the man pages at:

    There is more valuable documentation at:
    Last edited by Jim.Alles; 09-29-2020, 11:43 AM.
    If you think I got Grumpy

  • #2
    A suggestion for a DNSSEC option in the GUI of SD-WAN is now available for up-voting at:
    If you think I got Grumpy


    • #3
      The problem is....

      StatDNS provides DNS and Domain Name statistics, tools, and knowledge base

      148340942 .com domains... 2566372 of them signed...

      That's what? Almost 2%?
      Rob Sandling, BS:SWE, MCP, Microsoft Certified: Azure Administrator Associate
      Phone: 866-794-8879 x201
      Email: [email protected]


      • #4
        Ok, it isn't going to mitigate all of the risks, but there are still benefits that are not obvious in those statistics.

        Zones may be signed, as well.

        91% of TLDs having DS records isn't too shabby.

        Regardless, I still think the greatest threat to an individual is in the first hop to the ISP (last mile), particularly with cable systems.

        I wouldn't think DoH, DoT have much adoption with DNS services beyond the large DNS providers. Sure browsers on clients have gained traction by fiat, but doesn't it end at those servers?

        Granted, as far as my personal use case, DNSCrypt might be of more value
        but DNSSEC is already baked in and useable.
        Last edited by Jim.Alles; 10-13-2020, 08:52 AM.
        If you think I got Grumpy


        • #5
          The thing is... DNSSec solves the authentication problem at least. ISPs and what not can't be MITM'ing things because now we know the zone has been mucked with.

          But if you want to mask your traffic and keep prying hands off your DNS queries your best solution is your own DNS resolver that goes straight to root hints. You could go double paranoid and ride that entire structure over a VPN tunnel and you'd be as anonymous as technology affords.
          Rob Sandling, BS:SWE, MCP, Microsoft Certified: Azure Administrator Associate

          Phone: 866-794-8879 x201
          Email: [email protected]


          • #6
            haha if I were paranoid, I doubt that I would be able to function on the Internet.

            "Just because I am paranoid, doesn't mean that they aren't after m - my data"
            If you think I got Grumpy


            • #7
              Originally posted by sky-knight View Post
              ISPs and what not can't be MITM'ing things because now we know the zone has been mucked with.
              Yes, ISP's themselves have been a bit of a threat*, just as VPN services can be now. It just gets shifted around a bit, like sand dunes.

              * EDIT: Even OpenDNS previously mucked with returns to redirect traffic - "Redirecting DNS for Ads and Profit". But they did completely discontinue that behavior some time ago.

              Last edited by Jim.Alles; 10-13-2020, 09:44 AM.
              If you think I got Grumpy


              • #8
                Ugh... don't get me started on OpenDNS, Cisco really gutted that once wonderful company.

                The redirected advert thing I thought was an interesting idea, because it would have afforded a free to the user security product which... well was quite a compelling idea. Sadly, in hindsight it floated about as well as Untangle's reRouter idea.

                Funny isn't it... we're OK with this thing being changed in the name of policy and security, but THAT thing... well that's just not kosher. Humans are weird.
                Rob Sandling, BS:SWE, MCP, Microsoft Certified: Azure Administrator Associate
                Phone: 866-794-8879 x201
                Email: [email protected]