Michael Tremer

Rolling out DNSSEC to the masses
by Michael Tremer, November 18

Hello,

it has been a long time since my last proper post on this blog, but today is finally the day where I found some time to sit down and tell you a short story about DNSSEC.

With IPFire 2.19 – Core Update 106 we finally were able to roll our DNSSEC to everybody. With help of this wonderful piece of software called unbound which has replaced dnsmasq DNSSEC is now supported on all systems (before that DNSSEC was only in use when the upstream name servers validated as well). I am very proud of this and think that this is a huge achievement. In this post I would like to tell you why…

Why DNSSEC?

For many of you, this chapter won’t tell you anything new. DNSSEC is not the newest technology that nobody has ever heard of. It is indeed around for over a decade now and designed to authenticate all sorts of DNS records. It will check a signature that comes with every response to a DNS query and if that signature does not hold a check of a chain of trust, the record is not trusted any more. It could be forged by an attacker or have been altered by some other third-party on the way.

So in short. If you want to surf on ipfire.org, DNSSEC will make sure that you get the correct IP address of our web server and nothing else. Imagine what would happen when somebody sits between you and your bank and you do your online banking on an attacker’s site.

However, there is lots of criticism of DNSSEC. This is now repeated over and over again which does not make it any more true. Without going too deep into this, I would just like to say that most of these arguments are mostly unfounded. I would just like to explain two of the arguments which I heard most often:

Caveats

However, there are a few caveats. When we ran beta testing for the Core Update where we didn’t encounter any of them. Shortly after the release we found out about a few things that cause our users some trouble.

Usage of own top level domains

A rather large number is “illegally” using their own TLDs, for example *.companyname or just *.local which is not allowed according to the standard. DNSSEC does not only prove validity of an existing domain. It also signs responses about the non-existance of a domain. Hence *.companyname cannot exist and the DNS proxy returns an error. .local exists, but when used on your own machines, the signatures that are saved in the root zone do not match your (unsigned) local zone which results in the same error.

This is pretty much what DNSSEC is designed for and working very well. Of course it should not allow resolving any names that are not authenticated any more.

When using some domain like *.companyname.local, handing out DHCP leases with that, unbound will deliver those local records and skip validation. The problems rises again when a second validating resolver – potentially from a branch office – is connecting that resolver and asks for the same name. The second resolver won’t be able to verify that name and will send an error to the requesting client. In Core Update 107 we added an exception which will disable validating for all *.local forwardings so that this wrongly but very commonly used TLD is usable again – but without validation for course.

For those who are using any other made-up TLDs I can only recommend to move away from this and ideally register an own domain (even a dynamic name from a dynamic DNS provider is enough). A clean DNS tree will not cause you any errors. Adding any unsigned domains to the tree will just cause DNSSEC to do what it is supposed to do: Reject them.

Provider woes

In order to validate any signatures, unbound needs to download them for each domain that is accessed. These come with every DNS query where the DO bit (DNSSEC OK) is set. Some provider are operating name servers that strip these signatures away which is of course causing problems. unbound can fall back to the so called “recursor mode” and connect to the authoritative name servers directly and circumventing the ISPs ones.

This works quite well for all ISPs that are a bit ignorant about DNSSEC. But some are worse and hijack every single DNS query and forward it to their own caching name servers so that it never reaches the DNS server it was originally sent to. This is a whole different kind of evil and I personally find that this is illegal practice (probably is in most EU countries) and violates net neutrality.

Luckily DNSSEC detects this and does not trust any of the DNS responses of those servers – which is what the protocol is supposed to do. That however leaves some users of IPFire with no DNS resolution at all. In case you have such a provider, the only option is to disable DNSSEC for the moment (and probably stop using online banking and reading emails) and contact the ISP, organise a group that works together with them to get rid of this “extra service”.

And then there are some DNS providers who filter DNSSEC for their own marketing purposes. Everyone of you can now decide what they value more: Security or an easy to circumvent content filter?

From that experience I can only recommend to use independent name servers that are not operated by an ISP or a larger organisation where we cannot be sure what they are going to do with any of the data they get through processing your DNS queries. The IPFire wiki has a list of providers (good and bad) that have public resolvers. It is up to you to figure out who you trust and of course who doesn’t break DNS for you.

Summary

In summary I am still very proud that we made DNS and therefore every network behind an IPFire box more secure.

In a correctly configured DNS environment this is working perfectly. Some people might have to do some homework and iron out some configuration issues, but as soon as that is done, you will be fine. You wouldn’t notice anything which I find quite nice for some extra security. It should not reduce any user-experience or make things complicated. DNSSEC doesn’t do either of that but brings many advantages with it. Many of your probably have been using this without even knowing.

We decided to not add an “off switch” for DNSSEC anywhere since too many of you will probably use that without thinking. It is a bit like a button that disables the firewall. That probably increases usability when you don’t have to configure any more rules but completely ruins security. So to not tempt you – and because there are really no good reasons to disable this at all – we decided against it.

As usual I am looking forward to receive bug reports in case there are some real problems with DNSSEC and IPFire. There is also some documentation about everything on the IPFire wiki and everyone can contribute more guidance to help out others.

After all it is not very common to roll it our by default in such a large scale and IPFire might be one of the first. So thanks for being with us. I really enjoy pioneering new technology together with all of you.

Michael Tremer

IPFire 2.19 - Core Update 107 is available for testing
by Michael Tremer, November 1

The next Core Update with number 107 is available for testing and mainly comes with a fix for the Dirty COW vulnerability in the Linux kernel. Please help us testing!

Dirty COW

This update patches the IPFire Linux kernel against a recently disclosed vulnerability called Dirty COW. This is a local privilege escalation bug which could be used by a local attacker to gain root privileges.

Misc.


As always, we would like to ask all users to participate in testing which will highly improve the quality of this update.

Please report any bugs to our bug tracker and provide any feedback on our development mailing list.

Michael Tremer

IPFire 2.19 - Core Update 106 is available for testing
by Michael Tremer, October 21

Finally, the next Core Update with number 106 is available for testing. It comes with a number of exciting new features, many bug fixes and a few security improvements. Please help us testing!

Change of the DNS Proxy

IPFire used dnsmasq as DNS proxy before which is now replaced by unbound. The latter is in contrast to the former software that is specifically designed as an DNS forwarding proxy or DNS recursor and implemented DNSSEC from early on.

Because of our decision to enable DNSSEC by default and various problems in dnsmasq we have been toying with the idea of replacing it for a very long time. Unfortunately development resources are tight and because of this being a substantial part of the system and hooked into many other things, this was a very time-consuming project.

Finally, this new solution should now bring various advantages:

Performance

unbound is multi-threaded and IPFire will start one thread per CPU core that is available. That will allow execution of multiple queries in parallel which should increase responsiveness and throughput.

The cache size is adjusted based on memory available on the system. Bigger systems will have a significantly bigger DNS cache which will speed up browsing especially in larger environments like universities with a large number of clients.

Better DNSSEC reliability

DNSSEC is enabled by default (as it was before). However, unbound does not rely on the upstream servers being validating resolvers, too. This will bring DNSSEC to many more users. DNS servers are now tested before being passed on for use and any malfunctioning DNS servers won’t be used. Status of this can be seen on the user web interface.

Please see this list of various DNS services on the Internet for more details.

If none of the DNS servers configured or received from the provider can be used, unbound will fall back to full recursor mode.

With the next key rollover of the DNS root zone, IPFire will automatically download and validate the new key according to RFC5011.

Enhanced Features

DHCP leases will be published into the local DNS zone as before. Static leases are imported as well which is a new feature. Everything IP address will resolve to its hostname by publishing PTR records.

Misc

Updated Packages

This update installs a large number of updated packages:

Add-ons

Updated Packages


As always, we would like to ask all users to participate in testing which will highly improve the quality of this update.

Please report any bugs to our bug tracker and provide any feedback on our development mailing list.

Michael Tremer

IPFire 2.19 - Core Update 105 is available for testing
by Michael Tremer, September 23

With the last Core Update just being released a few days ago, it is time for the next one already. IPFire 2.19 – Core Update 105 patches a number of security issues in two cryptographic libaries: openssl and libgcrypt

OpenSSL Security Fixes

IPFire is now shipping openssl in version 1.0.2i which patches all of the above security vulnerabilities.

libgcrypt Security Flaws

Felix Dörre and Vladimir Klebanov from the Karlsruhe Institute of Technology found a bug in the mixing functions of Libgcrypt’s random number generator: An attacker who obtains 4640 bits from the RNG can trivially predict the next 160 bits of output. This bug exists since 1998 in all GnuPG and Libgcrypt versions and is filed under CVE-2016-6316.


As always, we would like to encourage you to help us testing this release and we would like to roll it out to everyone as soon as possible.

Hottest posts 2017 2016 2015 2014 2013 2012 2011