DNSSEC

This document is a simple explanation of DNSSEC and is not a substitute for reading the real documentation.

Contents

Purpose

Criminals want to steal Westpac customer IDs and passwords, so they break in to and control either:

When your web browser asks Xtra's DNS server for the IP address of westpac.co.nz, the criminals serve the IP address of their server, which looks exactly like the Westpac site. You type in your customer ID and password and log in. The fake Westpac site then makes a note of your credentials and then says "Sorry, our web site is unavailable at this time due to technical issues. Please come back later". The criminals can then log in to the real Westpac site using your credentials and transfer all of your money to a numbered bank account in Switzerland.

When both DNS servers and your computer support DNSSEC and the criminals take control, your computer can't look up an IP address for westpac.co.nz so you can't get to the Westpac site in order to give away your password.

Please note that Westpac and Xtra are only examples and that any web site or ISP is vulnerable to this attack.

Key pairs and cryptography

A key pair is made up of:

The private key is kept secret. If someone gains access to the private key then that key is compromised. The public key by contrast should be published.

This is called asymmetric cryptography. Symmetric cryptography by contrast uses the same key both to encrypt and decrypt.

Signatures

Data is encrypted with the private key. Anyone able to decrypt the ciphertext using the public key can be certain that the data is authentic since:

  1. Data that can be successfully decrypted with the public key can only have been encrypted with the matching private key
  2. the private key is only available to the originator

This is a signature.

A signed zone is one where the RRs have been signed. When a DNSSEC resolver looks up a record from a DNSSEC server, the signatures are sent along with the RRs so that the resolver can authenticate the RRs. The public key used to sign the records is also stored as a record on the DNSSEC server.

Trust

An adversary that has taken control of a DNS server could make their own key pair, sign DNS records that point to their corrupt server and publish the key they used to sign the records. A DNSSEC resolver however knows that the key is bad because it can check the authenticity of keys as well as of records.

A DNSSEC resolver trusts the public key that it obtains from the DNSSEC server if it can establish a chain of trust to a trust anchor. A trust anchor is a key that the resolver already has that is known authentic. There are so many web sites on the Internet that it's impossible for every resolver to store a trust anchor for every web site so instead a chain is built to the root zone (the zone that parents TLDs such as .com, .nz and so on) so the resolver need store a trust anchor only for the root zone.

Signing your zone with DNSSEC-Tools

Test that the signed zones validate with both the DNSSEC debugger web site and also the DNSSEC validator plugin for your browser.

Metaname key policy

The following policy applies to signed zones managed as part of Metaname's hosted DNS service:

Metaname does not recognise nor will take in to consideration the use of any keys as trust anchors. It is recommended that Metaname keys are not used as trust anchors.

Customers with signed zones served by Metaname's hosted DNS infrastructure will be notified 30 days in advance of any change to this policy.

Further reading