Adding Trust & Security to Internet Interactions with DNSSEC

DNSSEC does two things: It ensures you’re talking to the right online resource, and it verifies that the information you receive has not been tampered with.

Probably the most important core protocol we have on the Internet is DNS (Domain Name System), which is a service that resolves names which we humans can memorize easily (e.g. www.dotmagazine.online, or www.eco.de) into numbers which are things that machines can deal with easily. This makes DNS a fundamentally important service for the functioning of the Internet.

To give you an example: If you want to go to your bank, and you type the domain name into your browser, then a DNS server will receive the query: What IP address is associated with that name? The DNS server will reply with the IP address, and the browser will know where to go to.  

But when DNS was invented, nobody considered the possibility that somebody else might have an interest in intercepting DNS information and maybe tricking your browser into accepting a wrong IP address – the IP address of a different server which could be used to impersonate, for example, your bank. If you hand over your personal identification data to log in to this look-alike website, then the person controlling the “bad” server would be able to capture that information and use it in an attack against the real bank website.  

So, in order to protect DNS replies and to protect applications posing DNS queries, DNSSEC was invented. It's a cryptographic technology that signs every reply with something a DNSSEC-capable computer, or resolver in this case, is able to validate.  

Adding trust and security to online interactions – talking to the right resource

So, what in a nutshell does DNSSEC do? It secures what you do on the Internet. It adds security where it really is needed. Everybody believes that DNS replies are to be trusted – but they're not, unless they're DNSSEC-signed.

When you receive a DNSSEC-signed message (as long as your machine is able to verify the information) you will know that you're talking to the right resource and you will know that you've been given the right address. Or, if it’s the wrong address, the resolver will suppress the information and the connection will fail.

So DNSSEC basically is something – due to its sheer logic – that everybody should want to have, because it's all about knowing who you're talking to.

Encryption is only one side of the coin – what can happen when there’s no authentication?

At the same time, we are still witnessing exploits on the Internet. We've just seen a really large exploit that would have been impossible if the targeted and abused domains had been using DNSSEC and not only DNS. In the case of this particular attack, someone was able to hack the DNS servers and reroute people to wrong servers. And the people logged in to websites that pretty much looked like the right websites, and they handed over sensitive information. What we're talking about here is espionage, and this particular attack is said to have originated in Iran. The attackers hacked many DNS servers, created SSL certificates to impersonate governmental websites, and tricked people from other governments and countries into to logging in with their personal credentials at what seemed to be their own governmental websites. The website visitors handed over their authentication data, and then the spies were able to go to the real website, log in there using these credentials, read their mailboxes – the list goes on. What was at issue here was particularly sensitive information.  

Of course, the same style of attack could just as easily be used to get hold of a company's banking credentials, or for gaining access to confidential company information.  

Now, while this attack would still have been possible if the certification authority had used DNSSEC on their certificate licensing machines, if all access points were using DNSSEC, and if all smartphones and other end devices were verifying DNSSEC, this attack would not have gone unnoticed. Everybody would have known, nobody would have been fooled by it.

If it’s so good, why isn’t everyone already doing it?

DNSSEC adds complexity to DNS and many people who run DNS servers – unless they work with DNS every day – have simply put up a DNS server and added a bit of information, and it seems to just magically work. They don't really know why, but it just keeps on working. And when we ask them to add DNSSEC on top as a security layer, they kind of bail out, because it turns out that they don't understand it. They think it's too complex, so they try to avoid the topic. 

But there are also a range of myths doing the rounds about DNSSEC. One criticism of DNSSEC is that it doesn't encrypt your information. What the critics actually want is for the query and the reply to be encrypted, so that nobody else is able to know what has been queried and what has been replied. While I understand that requirement, it's not on the table when we talk about DNSSEC. This seems to be a fundamental misunderstanding of the function of DNSSEC. Just because it uses public key cryptography does not mean that it offers encryption. Its purpose is quite simply validation, not privacy. And incidentally, encryption on its own is not everything – you’ve got to be talking to the right resource too: authentication must come first.

Why you should implement DNSSEC

A further myth is that it is cost-intensive. It isn’t. And it works.

And you need it as a basis technology to gain other things. Things like trusted bank transactions. If you do your bank transactions online you should ask your bank if their webservers and if their DNS is DNSSEC-signed. You might end up being tricked into going to a different location, placing your bank account log-in information at the mercy of unscrupulous individuals. Here, it really is about money.

The next thing is, if you are part of a country’s critical infrastructure, then you on the one side should be serving information about your resources that can be validated, and at the same time you should be using DNSSEC when you transmit information to others, to make sure you're talking to the right parties. As I said before, DNSSEC does two things: it ensures you’re talking to the right resource, and it verifies that the information you receive has not been tampered with. And this is the basis for creating trust.

Authentication and encryption through DANE – ensuring a secure handshake

A use case that builds on top of DNSSEC is DANE. DANE is a standard that, in the first instance, identifies services that encrypt transport. The problem with transport layer security is that it's very secure once an encrypted session has been established, but the process of establishing the encrypted session is unsecure. This is where the man-in-the-middle attack comes in. Somebody might trick you into going to a different, wrong resource, and starting an encrypted session with that wrong resource. And you pass over sensitive information to that resource because you believe you're doing it in the right way – because everything is encrypted. The thing is, yes, you're right: you're encrypting – but you're talking to the wrong resource.

DANE fixes that. DANE uses DNSSEC as a resource to allow you to validate information you've been given. The process enables the exchange of information that helps you to verify you are talking to the right resource. Usually it's the fingerprint of the certificate of the resource you want to talk to. And this information is exchanged via DNSSEC. You are able to validate that you've been given information you can trust. And there's no way of spoofing that.

The second use case for DANE is that the mere existence of a DANE record tells the client that the server MUST offer encryption. This shields the communication from the risk of a “Downgrade Attack”, which can occur if the client recognizes that a server is not encrypting, and automatically “downgrades” to unencrypted transport.

So if you want to ensure properly secure online transactions or email transmission transport on the Internet, you want to use DANE. In order to do that, you need to use DNSSEC, and you should also offer it for others to use when they are communicating with you or your online resources.

The restore dilemma

The problem with DNSSEC is that it has about the same level of sex appeal as a backup. Nobody wants to do backups, but everybody wants the restore function. And that's the same with DNSSEC. While nobody gets excited about doing DNSSEC, everyone really wants to talk to the right resource, nobody wants to be tricked. So in order to gain one thing, you need to do the other.

DNSSEC is standardized, and it’s mature software. There are tools out there to support implementation. All it takes is that you need to tell the people who run your DNS server to run DNSSEC. It's not complicated. But it does add another layer of complexity that needs to be dealt with.

If you need information on how to do it, you can talk to us at eco, or you can also talk to your national office for IT security.

Patrick Koetter is an email expert, and a board member of sys4 AG, which is specialized in email, DNS, and the development of highly secure platforms and services. He contributes his knowledge and experience to eco as an expert and as Leader of the Competence Groups Email and Anti-Abuse.