DNSmasq dnssec support

[Dantali0n]

Hello all,

So with the most recent version of asuswrt: dnsmasq 2.73 is used. This version of dnsmasq supports dnssec yet it is not configured by default. Wouldn't it be nice to have an option to enable dnssec in the asuswrt backend. Its a simple configuration line according to this dutch article: http://www.sidnlabs.nl/laatste-beri...alidatie-op-de-client-met-behulp-van-dnsmasq/


I just found out that in order for this to work you need to compile dnsmasq with dnssec support, Dont know how much additional trouble that is.

 

[SnakeByte]

I wouldn't mind seeing this too, assuming it doesn't slow things down too much. GoDaddy offsers DNSSEC now, and it's super easy to set up, so adoption rate should climb.

I've been using the dnssec plugins for Chrome and Firefox and they work well enough for web browsing (but of course that wouldn't help the other services like email, etc). They're non-blocking too so you get the page and then a little notification icon at the top with the results of the verification. The one annoying problem using them however is that it causes my Firefox to crash and prompt to send the crash to Mozilla upon closure.
https://chrome.google.com/webstore/detail/dnssec-validator/feijekkdahhnjbhpiffgejphmokchdbo?hl=en

 

[charlie2alpha]

Interesting post. I fiddled around with it in a small Linux based router that I use, it works. But for the ASUS based routers it's not so simple, it requires additional compile time libraries (nettle and gmp). I don't know if @RMerlin wants to consider that, it will take some doing.

 

[RMerlin]

Interesting post. I fiddled around with it in a small Linux based router that I use, it works. But for the ASUS based routers it's not so simple, it requires additional compile time libraries (nettle and gmp). I don't know if @RMerlin wants to consider that, it will take some doing.

The need for additional libraries was the main reason why I've never seriously considered it.

And there's also the fact that I don't know how well it would work on a device that lacks a battery-backed up RTC.

 

[charlie2alpha]

The need for additional libraries was the main reason why I've never seriously considered it.

And there's also the fact that I don't know how well it would work on a device that lacks a battery-backed up RTC.

There is some provision about the time that I found looking at the man page, the "--dnssec-timestamp=<path>" parameter. It requires a file to be able to be stored somewhere, writable by dnsmasq itself. The description is:

Enables an alternative way of checking the validity of the system time for DNSSEC (see --dnssec-no-timecheck). In this case, the system time is considered to be valid once it becomes later than the timestamp on the specified file. The file is created and its timestamp set automatically by dnsmasq. The file must be stored on a persistent filesystem, so that it and its mtime are carried over system restarts. The timestamp file is created after dnsmasq has dropped root, so it must be in a location writable by the unprivileged user that dnsmasq runs as.

The file could be stored in jffs perhaps, or in external USB drive. It could be user selected perhaps. But the fact remains, it still needs 2 additional libs to compile the dnssec support.

 

[RMerlin]

The file could be stored in jffs perhaps, or in external USB drive. It could be user selected perhaps. But the fact remains, it still needs 2 additional libs to compile the dnssec support.

Anyone tried a staticaly linked build? Dunno if dnsmasq lets you chose specific links to be static, while keeping others shared.

 

[charlie2alpha]

Anyone tried a staticaly linked build? Dunno if dnsmasq lets you chose specific links to be static, while keeping others shared.

Well the only other flavor of Linux I use is Gentoo Linux, so everything is compiled from source there. From what I checked, there is actually an option to build it statically so I assume it is possible. Basically, nettle needs to be build with gmp statically linked, and then dnsmasq with that nettle also statically. In theory it should work, I can even find the options that need to be passed to make.

 

[lancethepants]

Here is how dnssec is implemented in tomato.
https://github.com/lancethepants/tomato-dnssec/commit/90e172261242f21e9ba3169d44eafdc051713052

nettle + gmp are statically linked - which increases dnsmasq size - but less so than dynamic linking them.
Eventually Asus would have to implement it, but maybe they would sooner if you did.

 

[RMerlin]

Here is how dnssec is implemented in tomato.
https://github.com/lancethepants/tomato-dnssec/commit/90e172261242f21e9ba3169d44eafdc051713052

nettle + gmp are statically linked - which increases dnsmasq size - but less so than dynamic linking them.
Eventually Asus would have to implement it, but maybe they would sooner if you did.

I'm not opposed to the idea since dnssec is a standard (unlike dnscrypt which is a somewhat proprietary OpenDNS idea), however as it's a new feature and requires development, testing and support, it has a very low priority for me. Just keeping up with Asus's GPL releases is taking an increasing amount of time unfortunately, not to mention the constant addition of new routers with new SDKs (which in turns means new kernel trees, that have each to be maintained in parallel).

 

[Chrysalis]

I will hope john implement's it. As I am having to use 3rd party dns for caching on dnssec requests which isnt ideal for me.

 

[Dantali0n]

Thanks for all the replies, good to see theirs an active community behind all this <3.
Its a shame dnscrypt is proprietery since its more secure in my opinion then dnssec, mainly because requests are still in plain text with dnssec (if im not mistaken) as opposed to dnscrypt which uses ssl.

I understand that maintaining the merlin firmware has higher priorities then implementing new features, and I appreciate all the effort!

 

[lancethepants]

dnssec and dnscrypt are not competing technologies. They perform different functions, and can (and do) work complimentary.

dnssec = dns authentication
dnscrypt = dns encryption/privacy

You can in fact use both simultaneously, there are dnscrypt resolvers with dnssec authentication.
If I had to pick just one, I'd probably go with dnssec, because I'd rather make sure my queries are un-tampered than private.
dnscrypt is not proprietary, it is open. DNS encryption has not yet been standardized, and dnscrypt it one of several technologies vying to become that standard.

 

[reerden]

Thanks for all the replies, good to see theirs an active community behind all this <3.
Its a shame dnscrypt is proprietery since its more secure in my opinion then dnssec, mainly because requests are still in plain text with dnssec (if im not mistaken) as opposed to dnscrypt which uses ssl.

I understand that maintaining the merlin firmware has higher priorities then implementing new features, and I appreciate all the effort!

Like what lancethepants said, dnssec has an entirely different purpose than dnscrypt. Dnssec makes queries secure by guaranteeing that the DNS records haven't been tampered with.

Dnscrypt provides the encryption and privacy, but it doesn't guarantee that the cache of the upstream server hasn't been poisoned . Just that the response from the upstream server hasn't been tampered with.

One of the biggest problems right now of dnssec is the lack of security between the server and the client. Most DNS clients in operating systems don't support dnssec completely. Because of that, it tends to create a false sense of security because all those dnssec test websites report that your connection is 'secure', since the upstream server sends a NXDOMAIN response for invalid records. It doesn't prevent someone from tampering with the response between the client and the server though.

Adding dnssec to the asuswrt firmware would be a huge benefit to security as you can then verify DNS records from client to server, even if your clients won't support dnssec (assuming you use the router as the DNS server on your clients). The only unsecure response would be the one on your local network, but if you can't trust that then you have other security issues.

 

[RMerlin]

Had I known implementing DNSSEC support would have been so tricky, I wouldn't have tried...

First, there's the (expected) clock issues. I initially wanted to go with the method of relying on a file's timestamp, as it seemed the simplest code-wise. There's one catch however: how does dnsmasq knows it can create the initial file safely? It's likely that the first time dnsmasq starts and the file doesn't exist yet, the clock hasn't been set yet. So, you'd get stuck without NTP access. Scratch that idea.

I then decided to go with the same method as used by Tomato. That brings a different issue: since dnsmasq will not enable dnssec timestamp validation until it gets told to refresh its configuration, that means that every time dnsmasq gets restarted (due to a configuration change), it will stop processing timestamps again. So, that wouldn't work either. (@lancethepants - that might be worth checking if that's an issue with Tomato too).

I went with a more intelligent solution: if ntp hasn't been set yet (ntp_ready isn't set to 1), then the config file gets the option to wait until a config refresh. If dnsmasq however gets configured with ntp_ready is set, then don't use any special trick and start immediately to handle timestamp checks. Which exposed another issue: so early during boot, ntp_ready is still set to 1 from the previous boot. (@john9527 , I wonder if that wouldn't create other NTP-related issues...). Easily fixed, I now clear ntp_ready at boot time, along with other temporary nvram settings.

Another issue then: the firmware is already causing dnsmasq to reloads its config files 1-2 times during boot, as various services update it. So once again, dnsmasq is starting prematurely to support time checks... Had to change the reload_dnsmasq() function so it only issues a SIGHUP if ntp_ready is set to 1.

So after a whole evening of plugging issues left and right, I *seem* to have a functional setup.

Bottom line: never say "oh, it's easy, here's the code from Tomato/DD-WRT/OpenWRT". That was an entire night spent just on a feature which, at a first glance, is half useless since I was having a hard time just finding a DNS zone that DID support dnssec. Even heavyweights such as google.com and microsoft.com don't.

 

[john9527]

Which exposed another issue: so early during boot, ntp_ready is still set to 1 from the previous boot. (@john9527 , I wonder if that wouldn't create other NTP-related issues...)

Hmm, I do remember that I made sure npt_ready was always cleared first when ntp is called. I also implemented another var, ntp_sync, which reflects if the ntp sync was ever successful. It looked they were starting to tie other things to ntp_ready, and I thought it was a bit harsh not to start them if just the last sync had failed (changed the reboot scheduler to use this new var since maybe they need a reboot to recover).

 

[lancethepants]

Nice job! I had actually cloned Asuswrt-Merlin and was checking out the code for implementing this. I hadn't expected that you would code it yourself, but you mentioned you weren't explicitly against incorporating it.

The timestamp file option hadn't been implemented when I first incorporated dnssec. I probably wouldn't have gone that route either though, since I wouldn't want to force users to enable /jffs just to use dnssec.

Tomato has two places where a SIGHUP can take place. One is in wan.c when the internet comes up, and after the time is known to have been set. The other one is in services.c. Here it will check if the year is >2000 since the router's startup time will always be <2000. When a dnsmasq configuration change occurs and the time is already set, it will restart dnsmasq, and then will immediately SIGHUP so that DNSSEC timestamps are checked. This covers all cases and indeed tomato will always check timestamps whenever the time has been set. Your implementation is very similar, just checking by some method whether the time has already been set.

 

[PabloAbonia]

Merlin, are you using the timestamp tool built into dnsmasq (see below)? I can't really tell from the previous posts.

I know there have been some concerns regarding security with the use of a timestamp file, but I am not in a position to adequately assess that.

One other thing, it seems that dnsmasq is restarting after being killed which is making configuration testing a bit more difficult. How can I stop it?

Thanks as always, Pablo

--dnssec-no-timecheck
DNSSEC signatures are only valid for specified time windows, and should be rejected outside those windows. This generates an interesting chicken-and-egg problem for machines which don't have a hardware real time clock. For these machines to determine the correct time typically requires use of NTP and therefore DNS, but validating DNS requires that the correct time is already known. Setting this flag removes the time-window checks (but not other DNSSEC validation.) only until the dnsmasq process receives SIGHUP. The intention is that dnsmasq should be started with this flag when the platform determines that reliable time is not currently available. As soon as reliable time is established, a SIGHUP should be sent to dnsmasq, which enables time checking, and purges the cache of DNS records which have not been throughly checked.
--dnssec-timestamp=<path>
Enables an alternative way of checking the validity of the system time for DNSSEC (see --dnssec-no-timecheck). In this case, the system time is considered to be valid once it becomes later than the timestamp on the specified file. The file is created and its timestamp set automatically by dnsmasq. The file must be stored on a persistent filesystem, so that it and its mtime are carried over system restarts. The timestamp file is created after dnsmasq has dropped root, so it must be in a location writable by the unprivileged user that dnsmasq runs as.

 

[RMerlin]

Merlin, are you using the timestamp tool built into dnsmasq (see below)? I can't really tell from the previous posts.

The initial plan was to use dnssec-timestamp, which would be tricky to make work reliably since the very first creation of the file would have to be done when the clock is properly set. If you had just rebooted with a cleaned JFFS partition, dnsmasq would get stuck unable to access the NTP server. That's why my implementationwill end up using dnssec-no-timecheck instead, with additionnal logic so that setting is only used the first time dnsmasq is started and NTP isn't set yet. Once NTP has been properly set, any subsequent restart of dnsmasq will not use that setting.

I know there have been some concerns regarding security with the use of a timestamp file, but I am not in a position to adequately assess that.

If you have the necessary permissions to manipulate that file, then you have the necessary permissions to manipulate the whole router anyway, so there's no security hole involved there.

One other thing, it seems that dnsmasq is restarting after being killed which is making configuration testing a bit more difficult. How can I stop it?

You can't. It's being actively monitored by the watchdog. This was done by Asus in a recent release.

 

[RMerlin]

Nice job! I had actually cloned Asuswrt-Merlin and was checking out the code for implementing this. I hadn't expected that you would code it yourself, but you mentioned you weren't explicitly against incorporating it.

The code itself is (in theory) just a few lines to handle restarting dnsmasq with the proper configuration, and notifying it at the right time. I did use your Makefile recipes however to save up on time just getting the necessary components to build. Now that it's working, I'll start looking into finetuning them.

Tomato has two places where a SIGHUP can take place. One is in wan.c when the internet comes up, and after the time is known to have been set. The other one is in services.c. Here it will check if the year is >2000 since the router's startup time will always be <2000. When a dnsmasq configuration change occurs and the time is already set, it will restart dnsmasq, and then will immediately SIGHUP so that DNSSEC timestamps are checked. This covers all cases and indeed tomato will always check timestamps whenever the time has been set. Your implementation is very similar, just checking by some method whether the time has already been set.

That would work. That's how rstats/cstats determine if they should start accumulating traffic data. This was frequently getting broken in Asuswrt-Merlin however as newer firmware releases from Asus seem to use a much more recent datestamp (my RT-AC88U boots with a datestamp in July 2015 for instance). That's why I'm no longer a big fan of relying on a known datestamp to determine the current clock state, and I prefer to rely on built-in mechanisms. Same with the post-NTP notification: Asus already has a piece of code in rc/ntp where it restarts the Disk Monitor (used for scheduled fs checks) after NTP gets set. That's why I'm inserting the dnsmasq refresh there, rather than in the WAN code.

 

[RMerlin]

Nice job! I had actually cloned Asuswrt-Merlin and was checking out the code for implementing this. I hadn't expected that you would code it yourself, but you mentioned you weren't explicitly against incorporating it.

I was able to save 100 KB on the dnsmasq binary by compiling nettle with mini-gmp BTW.