DNSSEC in dnsmasq/NGFW

[Jim.Alles]

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:

make dnsmasq COPTS='-DHAVE_DNSSEC -DHAVE_DNSSEC_STATIC'

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

conf-file=/path/to/trust-anchors.conf
dnssec

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 (8.8.8.8 and 8.8.4.4) 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: http://thekelleys.org.uk/dnsmasq/CHANGELOG, 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.
conf-file=/usr/share/dnsmasq-base/trust-anchors.conf
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
cache-size=1000

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.

Best,
Dominik

- from http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2018q2/012189.html

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 thekelleys.org.uk

From: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2018q2/012198.html

Disclaimer:
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: http://www.thekelleys.org.uk/dnsmasq...smasq-man.html

There is more valuable documentation at: http://www.thekelleys.org.uk/dnsmasq...q.conf.example

[Jim.Alles]

A suggestion for a DNSSEC option in the GUI of SD-WAN is now available for up-voting at:
https://untanglesdwanrouter.featureupvote.com/suggestions/123370/dnssec

[sky-knight]

The problem is....

https://www.statdns.com/

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

That's what? Almost 2%?

[Jim.Alles]

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.
http://stats.research.icann.org/dns/tld_report/

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.

[sky-knight]

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.

[Jim.Alles]

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

Remember,
"Just because I am paranoid, doesn't mean that they aren't after m - my data"

[Jim.Alles]

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.

https://www.ghacks.net/2014/05/30/opendns-shuts-redirect-search-pages-ads/

[sky-knight]

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.