DNSSEC


To paraphrase Wikipedia, the Domain Name System Security Extensions (DNSSEC) IETF specifications for securing information provided by the Domain Name System (DNS).

It provides origin authentication of DNS data, data integrity and authenticated denial of existence. It protects DNS resolvers from forged DNS data (from cache poisoning, man-in-the-middle attacks, etc). By protects I mean it enables DNSSEC aware resolvers to detect these attacks.

Although the specifications have been around for sometime in one form or another (with the current specifications being finalised in March 2005), until recently it had seen very limited deployment.

DNSSEC 101

The DNSSEC specifications introduce a number of new DNS resource records that allow it to provide origin authentication of DNS data, data integrity and authenticated denial of existence; these are:
  • An RRSIG-record holds a DNSSEC signature for a resource record set (RRSET - one or more DNS records). The signature is actually computed over the hash of the RRSET, which is then encrypted with the Zone Private Key.
  • DNSKEY – which stores public keys. DNSSEC uses two keys 
    • A Zone-Signing Key (ZSK) and;
    • A Key-Signing Key (KSK).

         All key records are signed with the KSK, and the entire zone is signed with the ZSK.

  • Delegation Signer (DS) record is used to validate a child zone’s key. The KSK is the key for which the parent zone publishes the DS record.
  • NSEC.  Many DNS operators do not allow their zones to be transferred, as the full contents of a zone are considered private, and often provide hackers with clues on how to hack a network. DNSSEC employs the NSEC record to securely deny existence of a zone, by signifying that no records exist between two records that do.
    • NSEC (pointer to next secure record / authenticated denial of existence). 
    • NSEC3 (hashed authenticated denial of existence). NSEC3 in principle works just like regular NSEC, except that it uses cryptographic hashes of domain names. This is to make it harder to enumerate the entire zone to determine the hosts that exist (which was much easier with NSEC).


DNSSEC Issues / Challenges

Management

Additional overhead is required to manage DNSSEC zones over and above that for managing ordinary zones. This includes:

  • Key management, 
  • Key rollover, 
  • Communicating key material to parent zones etc
  • Backup of keys

In view of this DNSSEC may increase operating costs for ISPs and other DNS service providers. Since DNSSEC uses cryptographic primitives, arguably this introduces increased overhead in the act of signing (although this will not occur as often) and in verifying signed zones records.

If however, you outsourced your DNS services to a 3rd party, which many organisations do, then this alleviates the management burden.

With DNSSEC DNS replies are now likely to be larger and many existing security devices such as firewall expect the small DNS packets that are sent of UDP and block TCP based DNS traffic which is required for large DNS responses. This can causes DNS resolution to fail and ultimately lead to a site becoming unavailable to a user behind such a firewall.

Last Mile

At present DNSSEC has not been universally adopted. Although the root and most TLDs now use DNSSEC, the” last mile” is not protected. DNSSEC protection usually ends at the local resolver at a site, it is not typically deployed to client systems or down to the browser level.

Commercials

DNSSEC requires careful planning and therefore upfront investment (not to mention potentially increased ongoing operational expenditure) to deploy, for most organisations, aside from security / risk reduction benefits it is difficult to justify or find a means to recoup your investment.

For some organisations such as financial institutions, there is a direct incentive to deploy as DNSSEC can help to reduce the effectiveness of some types of fraud. Vendors and service providers may also be able to recoup investment by providing software, support and other services to support DNSSEC deployment.

The problem is the value of DNSSEC is proportional to the number of organisations and domains that implement it.

Why deploy DNSSEC

Aside from the obvious benefit of ensuring that DNS answers are authentic and thereby increasing the “trustworthiness” of a domain; DNSSEC can enable new or supplement existing technologies:

  • Email Security - Domain Keys Identified Mail (DKIM http://en.wikipedia.org/wiki/DKIM) provides confidentiality and integrity checking for emails which can reduce spam and phishing. The technology relies on digital signatures – the public keys used to verify the digital signature can be published in DNS. With DNSSEC you can have some assurance the public key is genuine.
  • Certificates - DNS-based Authentication of Named Entities (DANE) allows certificates to be published to DNS. Since DNSSEC creates a trusted network of domain owners you could generate your own  SSL Certificate and sign it using your DNSSEC Zone Signing Key as an alternative to obtaining a certificate from certificate authorities such as Verisign.
  • DNSSEC Signed SSH Public Keys (SSHFP) – SSH client can verify and/or automatically accept DNNSEC-signed SSH fingerprint
  • ROVER or BGP Route Origin Verification – authenticate routing information published through the BGP protocol which is a core part of Internet routing 
  • DNSSEC Signed PGP PKA and DNS CERT
    • PGP and similar ecryption software is often used with email to encrypt and digitally sign emails. PGP could retrieve certificates and public key information via DNSSEC

Deployment Status

DNSSEC was deployed at the root level in July 2010 and since then many of the key country code TLDs have started to implement DNSSEC.

Wikipedia has a list of TLDs and whether they have deployed DNSSEC (and if they support Internationalised Domain Names – IDNs).

The DNSSEC Deployment Initiative has published a PDF document showing deployment status here: https://www.dnssec-deployment.org/wp-content/uploads/2010/06/TLD-deployment-Table1.pdf
The same website also has a animated map of worldwide deployment status of ccTLDs from Jan 2006 to July 2014 (including planned deployment estimates).
https://www.dnssec-deployment.org/index.php/2012/07/dnssec-in-cctlds-past-present-and-future-3/

Geoff Huston periodically publishes in-depth statistics on DNSSEC deployment at his website, the latest one is from October 2012. http://www.potaroo.net/ispcol/2012-10/counting-dnssec-2.html

References

Well that's was a whirlwind tour of DNSSEC, the key deployment challenges, potential benefits and deployment status. In fact I intentionally glossed over the details if you are interested in finding out more about:




Comments

  1. Sebastian19 August 2013 at 01:23

    I think DNSSEC is very important. It should be rapidly incorporated into the client. Especially the ISPs should be faster in the implementation!

    ReplyDelete

Post a Comment

Popular Posts