Shell's TechBlabber

…ShelLuser blogs about stuff ;)

DNSSEC: Massively overhyped?

Last year I got a little fed up with the Bind (“Named”) DNS server for reasons which I’ll explain further below, and I started digging into PowerDNS. A pretty solid project for sure and it definitely has some advantages over Bind. However, due to recent changes in the project I came to conclude that managing PowerDNS had become even more tedious than Bind originally was! That’s no good, so I decided to move back and because I was giving my setup a massive overhaul anyway I also started looking into DNSSEC. A topic which was still sitting on my TODO list. Yeah… Very important according to ICANN and ISC. But is it really? I have some serious concerns…

What is DNSSEC?

To answer this we first need to look into what DNS actually is. In short: DNS is a system which translates names into numbers. Specifically: server and domain names get translated into so called IP addresses. An IP address is basically a unique identifier used by the TCP/IP set of protocols in order to identify your computer.

If you’re interested then start with opening up a console (Press Win-R and run cmd.exe on Windows, I’ll assume that you know how to do this if you’re using a Unix-like OS such as MacOS or Linux). On Windows enter this command: ipconfig. On a Unix-like OS you’d use ifconfig. You’ll probably see an IPv4 or maybe even an IPv6 address. That’s the unique address which connects your computer to the network.

The only problem: how are you going to remember this address? Us humans are much better in remembering names than numbers, so…  Therefor the Internet Software Consortium quickly came up with a solution: a Domain Name Server. So basically a server which could associate a name with a number. Easy! So now instead of having to remember (for example) we only need to remember: and the DNS system will do the rest.

The problem with DNS

The problem here is that DNS was never designed to be secure. That is: the software is definitely written with failsaves in mind, but it doesn’t have reliable options which can help you to ensure that the IP address you get actually belongs to the right website. Meaning: if I were to hack a DNS server and then inject it with my bogus data which would tell it that now points to, so then what?

This problem has been researched and eventually ISC came up with the concept of DNSSEC.

DNSSEC: encryption within the DNS

The concept is relatively simple.. It is fully build upon the so called public key principle.

In short: you generate 2 keys, one private and one public. You then share the public key with everyone so that they can use that key to encrypt data which is only meant to be seen by you. Data encypted with your public key can only be decrypted with the associated private key. But you can do more: using the private key you can also generate signatures; small blocks of CRC data which can be verified against the public key. This way people can make sure that certain data is absolutely coming from your end.

This principle is also related to the certificates used for encrypted website traffic. Used with the so called HTTPS protocol. The major difference with HTTPS is that it relies on 3rd parties to validate a certificate. So you basically create a public key (in “HTTPS terms” this is called a certificate signature request), you then sent this to a registrant which will sign the ‘key’ and then you end up with a valid certificate which you can use. This is referred to as using a ‘chain of trust’. The certificate becomes valid once it has been validated (‘signed’) by a trusted 3rd party. Why that 3rd party is trusted? Simple: because your webbrowser or your OS has been told that it is. It keeps a large collection of these certificates and uses that for verification purposes.

But back to DNSSEC… if you have your own domain then you can create a so called encryption key for it which you can then use to sign that domain and every entry in it. DNSSEC also relies on the previously mentioned ‘chain of trust’: after you signed your domain you would then contact the domain registrar which provided said domain and ask them to add your key to their repository and sign it. This will basically provide a “seal of approval” and ensures that your domain is fully valid.

So if your domain data is kept in a rogue DNS server to redirect people to a ditto rogue website then this bogus data would invalidate the signature, thus resulting in the DNS resolvers to give out errors. After all: the attacker can’t easily forge the keys and signatures from your domain registrar.

… or can they?

The massive flaw with DNSSEC

DNSSEC relies on a chain of trust. The so called root servers are the 3rd party which is being given absolute trust and is also used to validate your signatures. Yet herein lies a massive flaw in reasoning. See: your domain records may be signed and all which could give a DNS resolver everything it needs to verify the data and then discover the hack.

But… If the attacker is already capable of injecting bogus data into the DNS server, then why wouldn’t they simply inject it with unsigned data and overwrite yours? See: once your computer has performed its lookup and noticed the presence of encrypted datablocks then sure: it’ll be persuaded to perform an extra check to validate those signatures. But if it doesn’t find any traces of a signature then… why would it even bother with an extra check? There’s no need, this is also not the way DNS was designed in the first place. It asked for the IP address associated with a domain name, it got the address so as far as the client is concerned the lookup process has been successfully finished.

The flaw lies in the fact that in order to verify the signatures you’d have to rely on the same unreliable source which is the DNS server.

Heck, you can take this even further if you want…  Let’s say for the sake of argument that we need to keep the zone signatures because otherwise we’d expect to arrouse suspicion. So we hacked the DNS server and fed it with bogus signature data. The only problem is that a client would try to look up this data and then try to validate it with the root server (the server authoritative for the domain validation).

SO why not spoof that address as well? Heck, why not simply create a self-signed signature and use that? It’s not as if the resolving client would notice anything different. All it would notice is that the domain has been signed and that the signature verifies correctly. It wouldn’t bother with any boring details such as “who signed it”.

Even the documentation is flawed!

As can be expected from a project as extensive as Bind the whole thing is carefulyl documented. Here is the online manual for Bind 9.11, pay special attention to this part; signing the keys. It’s absolutely bogus!

$ ls
10.0.0.x        10.0.1.x        intranet.lan
$ dnssec-keygen -a RSASHA1 -b 768 -n ZONE intranet.lan
dnssec-keygen: fatal: RSA key size 768 out of range

Quite the reliable documentation, wouldn’t you agree? So let’s just pretend the guys at ISC couldn’t know that development regarding encryption has moved on and that we now have much better and more reliable standards. So take 2:

$ dnssec-keygen -a RSASHA512 -b 1024 -n ZONE intranet.lan
Generating key pair…………..++++++ ………………….++++++
$ cat Kintranet.lan.+010+10592.key >> intranet.lan
$ dnssec-signzone -o intranet.lan intranet.lan
dnssec-signzone: fatal: No self-signed KSK DNSKEY found.  Supply an active
key with the KSK flag set, or use ‘-P’.

That’s right: it doesn’t work. See, in order to actually sign something you need a key which is specifically generated for ‘KSK’ purposes. In other words: you need a Key Signing Key. Fortunately the dnssec-keygen program is decently documented and we can soon find out that we’ll need to set a flag for that. So take 3:

$ dnssec-keygen -a RSASHA512 -b 1024 -n ZONE -f KSK intranet.lan
Generating key pair……………………..++++++ ……..++++++
$ cat Kintranet.lan.+010+15423.key >> intranet.lan
$ dnssec-signzone -o intranet.lan intranet.lan
dnssec-signzone: fatal: No non-KSK DNSKEY found; supply a ZSK or use ‘-z’.

And this is about the point where I’m starting to question the purpose here. I mean: if the original documentation doesn’t even bother to mention anything about this and worse yet: uses insecure encryption algorithms and outdated key sizes then yeah: how safe to you expect your domain to become?

Finally: a fully signed domain!

But let’s not give up so quickly. We’ll just generate 2 different keypairs:

$ dnssec-keygen -a RSASHA512 -b 1024 -n ZONE -f KSK intranet.lan
Generating key pair…………………++++++ ……++++++
$ dnssec-keygen -a RSASHA512 -b 1024 -n ZONE intranet.lan
Generating key pair………..++++++ ……++++++
$ cat *.key >> intranet.lan
$ dnssec-signzone -o intranet.lan intranet.lan
Verifying the zone using the following algorithms: RSASHA512.
Zone fully signed:
Algorithm: RSASHA512: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 0 stand-by, 0 revoked

Finally, now I got a fully signed zone. And according to Bind it’s now fully secure:

peter@unicron:/home/peter $ rndc zonestatus intranet.lan
name: intranet.lan
type: master
files: /usr/local/etc/namedb/master/intranet.lan.signed
serial: 201712291
nodes: 50
last loaded: Mon, 26 Mar 2018 05:43:20 GMT
secure: yes

This is even confirmed by dig, which is a DNS lookup tool provided by Bind:

$ dig +dnssec @localhost unicron.intranet.lan

; <<>> DiG 9.12.1 <<>> +dnssec @localhost unicron.intranet.lan
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28475
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

; EDNS: version: 0, flags: do; udp: 4096
; COOKIE: b73a297d3516ca0823586b1a5ab88928e7539397651a4feb (good)
;unicron.intranet.lan.          IN      A

unicron.intranet.lan.   86400   IN      A
unicron.intranet.lan.   86400   IN      RRSIG   A 10 3 86400 20180425044320 20180326044320 54188 intranet.lan. nrdlcmPt9DHYvaTkFomZzBW8S8l2VpYPN78BisZPMmcXbgIHMBQ1RJhU 6eadEEXGWjNnBNcji12bufx0pjl1iVoXOa4xPDc9EJac54j2O4Uot8EB Rl1kkbsso6pyM4KRds7Azyxgg/HPaPq31N2/WEYLdT4Gs3rDCqAcc1Z1 68g=

I’m fully secure, according to Bind. But pardon me for not recognizing any additional advantages here. As I mentioned before: what exactly is stopping a rogue server from simply priming itself with unsigned data? It’s not as if the usage of DNSSEC is mandatory. And even if it was, as also mentioned before: what exactly prevents the server from priming itself with a bogus signed data?

Just think about that for a second: What guarantee’s do you have that my whole demonstration above wasn’t basically one major hack which evolved around providing a fake signature for a rogue domain?

As you can see above the dig tool is fully happy: this is a valid domain, and rndc (DNS server control program) confirms: the domain is “secured”.

So why don’t I feel any safer than I did before?

And what about all that extra data?

$ ls -l intranet.lan*
-rw-rw-r–  1 peter  peter   4774 Mar 26 07:40 intranet.lan
-rw-r–r–  1 peter  peter  54385 Mar 26 07:40 intranet.lan.signed

My unsigned zone file is, as you can see, around 5kb. The signed file is 54kb, which is almost 11 times larger. Data which would also need to be processed by the various DNS servers and DNS clients. And the reason why I consider this yet another design flaw is because DNS servers have quite often been used as the primary source for DoS and DDoS attacks. The system is vulnerable and therefor the DNS traffic is also often limited. Yet here we are: trying to generate out even MORE DNS data!

Finally: what about all those DNS injections?

This is my main reason for my critical comments… DNSSEC was meant to protect the DNS data. And as I demonstrated above I think that it utterly fails in doing so. But to add insult to injury: what about those compromised DNS servers? This methodology tries to secure the DNS data, but not the DNS server!

But if the server can’t be secured then… What exactly is stopping an attacker again? A signature which they can easily forge themselves? How should this make me feel any safer?

In conclusion

As mentioned before I think the whole DNSSEC design has some major design flaws. It doesn’t provide any extra security, but instead tries to direct your attention away from the real problems: 3rd parties being able to inject bogus data.

And to add insult to injury the ISC even provides us with outdated and obsolete documentation while still claiming that DNSSEC is really important. If it was that important then seriously: couldn’t they at least provide us with relevant and updated documentation?

Also: important according to who? Perhaps all those registrars which most likely will charge us some extra in order to sell us a “secured” domain?

Dream on Internet!

March 26, 2018 - Posted by | Editorial, Security, TechBlabber | , , , ,

1 Comment

  1. So a bit of a part 2 (but smaller). This subject also got discussed on some other fora where people told me to also look into Delv vs. Dig. Because that was the de-facto tool to use for DNSSEC and it would clearly showcase its usefulness. Unfortunately I have to disagree.

    The first reason I focused myself on Dig is to highlight the one major flaw in the design: 90% of the clients which do looking don’t even support DNSSEC, so even if your DNS cache does gets hacked then no one will notice.

    The second reason is that diving and showcasing Delv opens up a whole new chapter of its own. Because it will only showcase even more just how poorly designed the whole concept actually is.

    For starters: what about your LAN? If you run a VPN and a LAN then it’s not uncommon to use a private domain for internal needs. Wouldn’t it make sense to apply DNSSEC to it so that you can also secure this from any possible problems? Well, you can’t. Somewhat. If you want to use HTTPS or any other encryption scheme then you can easily apply overrides. For example you could generate a self-signed certificate, apply this to your clients so that this gets trusted and then use this for internal purposes like HTTPS, code signing, e-mail validation, and so on. Its your LAN, so you can be in full control.

    With DNSSEC not so much, apparently they never really thought about this. The only way to set up a fully validated private DNSSEC structure is by running a root server of your own. Because that’s the region which gets ultimately trusted by a DNSSEC capable resolver. There is of course one small problem: what about all the currently available “signatures” in the root block? If you override the root server but without copying all the available data then you’d basically render every official DNSSEC enabled site on the Internet invalid. So basically you have to copy the entire root server structure, then apply that to your LAN and only then will your clients be able to browser the LAN/VPN and the Internet.

    In other words: the only way to set up a private DNSSEC environment is by doing just the thing which DNSSEC is meant to prevent: impersonating another DNS environment and “forging” their records. Fun!

    The weakest link now becomes your upstream

    It gets worse… I already talked about signing and upstreams. Applying DNSSEC means that others have to “sign” your domain keys and the way to do this is through the use of DS records which they need to add to their zone. Usually an automated process. Yeah, so what would happen if the upstream, for whatever reason, removes your DS records from their DNS? Then your website will get invalidated.

    That’s one of my biggest gripes with all this: you rely on an on-going process of adding and removing signatures (“DS records”), so the chance that they accidentally remove your records is always reasonably high. Not even HTTPS does something that stupid: once a certificate (“key”) has been signed then that’s it. It’ll be valid until the expiration date which is also included in the signature. Not here…

    Can it get worse? Of course it can!

    Administrating a DNSSEC environment can become tedious. After all: every time you apply changes to your DNS zone then those will have to be re-signed in order to be validated. This can become a rather tedious process so ISC actually advices you to automate this process:

    auto-dnssec maintain;
    dnssec-update-mode maintain;

    Who cares if hackers could forge your records and poison the cache while trying to push those changes inwards. If they’ll succeed your system will happily sign (and thus validate!) all changes by itself because otherwise the whole system would become soo bothersome….

    For me this really is the final nail in the coffin that is DNSSEC and it completely blows my mind. Here I was thinking that this was all about – protecting – the DNS zone integrity. How are you planning to do that if you just make the server automatically sign whatever it finds?

    So yeah… I am aware of Delv but it only make the whole thing even worse…

    – Makes you fully dependent on the upstream; if they mess up your site becomes invalid.
    – Is such an administrative overhead that you’re even advised to apply it automatically.
    (who cares if this defeats the entire process!)
    – The only way to secure your private (internal) network is by copying a root server.
    (impersonating someone else; just the thing DNSSEC was meant to prevent!)
    – 80 – 90% of all clients don’t support it. So it’s a lot of work and doesn’t do anything.

    And most of all: it doesn’t prevent spoofing! Because if you can override DNS records then what’s stopping one from overriding the DNSSEC and RRSIG records so that it looks as if nothing was signed in the first place?

    Comment by ShelLuser | March 27, 2018

Sorry, the comment form is closed at this time.

%d bloggers like this: