About the DNSSEC Deployment Initiative

UPDATE: As of August 2014 this website is now supported by the Internet Society Deploy360 Programme as part of their efforts to accelerate the global deployment of DNSSEC.

The DNSSEC Deployment Initiative works to encourage all sectors to voluntarily adopt security measures that will improve security of the Internet’s naming infrastructure, as part of a global, cooperative effort that involves many nations and organizations in the public and private sectors.

Until 2104 the DNSSEC Deployment Initiative was supported by the U.S. Department of Homeland Security Science and Technology (S&T) Directorate.  Deploying DNSSEC is an important element in the U.S. cybersecurity policy, which, given the global nature of the Internet, necessarily transcends national boundaries.  Given this global nature of DNSSEC deployment, the Internet Society has now become the home for the work produced by the DNSSEC Deployment Initiative.

About DNSSEC

DNSSEC introduces security at the infrastructure level through a hierarchy of cryptographic signatures attached to the DNS records.  Users are assured that the source of the data is verifiably the stated source, and the mapping of name to IP address is accurate.  DNSSEC-compliant name servers also provide denial of existence, that is, they tell a user that a name does not exist.  There are two dominant strategies: (1) a process that zone operators can initiate for digitally signing their own zones by employing public-private key pairs and (2) a chain of trust between parent and child that enables the system eventually to become trustworthy.

The specification calls for four new resource record types (Resource Record Signature [RRSIG], DNS Public Key [DNSKEY], Delegation Signer [DS], and Next Secure [NSEC]) in addition to new information in the packet header.  The information in the header used by DNSSEC indicates that the response to a query passed checks on the server side.  A zone administrator who wishes to deploy DNSSEC first generates a key pair, consisting of a public key and a private key.  The public key is stored in a DNSKEY record; the private key is stored offline.  The private key is used to digitally sign the records and the resulting digital signature is stored in a RRSIG record.

A zone operator may have to complete one or two more steps, depending on the content of the zone file: NSEC records hold information about the next record in the zone and must be added.  This enables the response that no record exists.  If the zone includes delegations, then a Delegation Signer (DS) record must also be added in the parent zone for a given child.  So a zone that contains children must include DS records for the children.  A zone that has signed its records and added the NSEC and, if necessary, the DS records may go into business as a self-signed DNSSEC-compliant zone, also known as an “island of security.”  This is a zone that contains signed records – or is considered a “signed zone” – but is the child of a parent that cannot vouch for the authenticity of the child’s key.

The combination of RRSIG and the child’s public key in a DNSKEY record allows a validation of the source of the data.  The simplest DNSSEC sequence is to obtain the DNS information queried for together with the signature associated with that information (contained in the RRSIG) and to use the public key in the DNSKEY to perform the validation (i.e., prove that the signature was made by the holder of the private key).  However, the power of DNSSEC lies in a second step that allows the signed zone to be vouched for, preferably by its parent but if not, by another authenticating entity.  This sequence creates the chain of trust up to the “trust anchor,” which is the starting point in the chain.  A DNSSEC aware resolver validates the information it receives in response to a query by using the public keys to check the signed records.

Read more about it:

DNSSEC – DNS Security Extensions.  Web site that provides excellent and important background information for a general and technically literate audience on the history and development of the protocol, and useful tools.

M. Gieben, DNSSEC, The Internet Protocol Journal, 7 [2] (June 2004).  Verified January 20, 2005.  Offers a useful introduction to the protocol.

DNSSEC: What is it and what does it do? Prepared by NIC-SE, the first ccTLD in the world to deploy DNSSEC.

Important RFCs:

RFC 3658 O. Gudmundsson.  Delegation Signer Resource Record. December 2003.

RFC 3755 S. Weiler.  Legacy Resolver Compatibility for Delegation Signer (DS). May 2004.

RFC 4033 R. Arends, R. Austein, M. Larson, D. Massey, S. Rose.  DNS Security Introduction and Requirements. October 10, 2004.

RFC 4034 R. Arends, R. Austein, M. Larson, D. Massey, S. Rose.  Resource Records for the DNS Security Extensions. October 10, 2004.

RFC 4045 R. Arends, R. Austein, M. Larson, D. Massey, S. Rose.  Protocol Modifications for the DNS Security Extensions. October 10, 2004.

RFC 4310 S. Hollenbeck.  Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP). November 2005.

RFC 5011 M. StJohns.  Automated Updates of DNS Security (DNSSEC) Trust Anchors.  September 2007

RFC 5155 D. Blacka.  DNS Security (DNSSEC) Hashed Authenticated Denial of Existence.  March 2008

RFC 5702 J. Jansen.  Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC.  October 2009