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:
- Some people say the cryptography is weak. Since in the original design of the protocol, state-of-the-art cryptography was used – as you do. However, DNSSEC was designed in 1997 were cryptography was not as advanced as it is today. Amendments to the original RFC have been made and specified modern cryptography for the protocol. Now RSA keys with sufficient lengths can be used and elliptic curve cryptography (which generates small signatures and is very fast) is available. So DNSSEC is up to date and can use latest and good cryptography.
- Some people say that DNSSEC makes (Distributed) Denial-of-Service attacks possible – so called Amplification Attacks. These work in that way, that a DNS request is being sent to a DNS recursor on the Internet which then responds with a long response. That way, an attacker can generate more traffic than he has bandwidth available and use that extra bandwidth to DoS other systems on the Internet. DNSSEC makes DNS responses larger since the extra signatures. However, on the DNS recursor that I am running on the Internet (and that many people use) I have never seen somebody try using a DNSSEC-secured domain for any DoS attacks. There are other long responses or ANY queries (which return all known records for a domain name) which create equally large packets. So in short: DNSSEC does not help to mitigate those attacks, but they are possible without DNSSEC. Therefore I think this argument is unfounded.
- Some say it is worthless if not implemented on the client. This is probably half-true. DNS should be validated on the client as well. But this brings validating to the edge of each network that is secured by an IPFire box. That would require that DNS forging is now happening in your local network than from the Internet which is way more difficult for an attacker to achieve. And everything that makes things more difficult for an attacker is a good thing already – even if not perfect.
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.