DNSSEC

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

Contents

• Purpose
• Key pairs and cryptography
• Signatures
• Trust
• Signing your zone with DNSSEC-Tools
• Metaname key policy
• Further reading

Purpose

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

• An authoritative DNS server for westpac.co.nz
• A recursive DNS server at Xtra (or any other ISP)

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:

• a private key, and:
• a public key

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.

• plaintext is data that's not encrypted
• ciphertext is data that has been encrypted
• plaintext encrypted with the public key can only be decrypted with the private key
• plaintext encrypted with the private key can only be decrypted with the public key

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

• Make a text file in BIND zone file format that contains your zone records, for example:

  cat <<EOF > db.example.co.nz
  @    IN  SOA  ns1.example.co.nz. \
   hostmaster.example.co.nz. \
   (000001 10800 3600 604800 3600);
  @    IN  NS   ns1.example.co.nz.
  @    IN  NS   ns2.example.co.nz.
  @    IN  A    10.9.1.1
  www  IN  A    10.9.1.1
  EOF
  

• Issue the command:

  zonesigner -usensec3 -genkeys \
   -zone example.co.nz \
   db.example.co.nz
  

• Keep all of the files that are generated and inspect the following files:
  • db.example.co.nz.signed - the signed zone
  • dsset-db.example.co.nz. - the DS records ready to be published in the parent zone
• Deploy the signed zone to your DNS servers
• Check that your DNS server can serve the key material faithfully with:

  unbound-host \
   -t DNSKEY example.co.nz.
  

• Check that your domain is secure:

  unbound-host -v \
   -f dsset-example.co.nz. \
   example.co.nz.
  

• Publish the DS records, then test with:

  dig +dnssec \
   @149.20.64.20 YOUR-DOMAIN-NAME
  

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:

• Key parameters:

  • Each DNS zone has its own keyset
  • KSKs are 2048 bit RSA or stronger
  • ZSKs are 1024 bit RSA or stronger
  • Digests are SHA256 or stronger
  • ZSKs are rolled monthly, KSKs annually

• Key protection:

  • DNS servers have no access to private keys (offline signing)
  • Zones are signed by a hardened host used exclusively for the purpose. All requests for zone signings are logged
  • Key sets are backed up monthly via SSH (2048 bit RSA) to storage that is encrypted with a strong pass phrase

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

• About DNSSEC at the DNC
• RFC4033
• RFC4034
• RFC4035
• RFC5155
• RFC6781
• RFC7583
• Sign your zone with DNSSEC-Tools