Deploy360 11 July 2012

DNSSEC Policy & Practice Statements (DPS)

Are you responsible for signing your domain with DNSSEC are are looking to understand more of what may be involved?  Are you perhaps with registry or top-level domain (TLD) operator looking to implement DNSSEC across your country-code TLD (ccTLD) or new generic TLD (gTLD)? Or are you with an enterprise seeking to understand the legal and security policies you should have in place if you are signing your own domains?

If so, a great place to start is with the idea of a “DNSSEC Practice Statement” or “DPS.”  A DPS is a document that simply lays out the policies and procedures related to DNSSEC that an organization chooses to implement.  It may be very short and simple – or very long and complex.  The idea is that a DPS can give other people an understanding of how much they can trust your DNSSEC signing.  For someone new to DNSSEC, looking at existing DPS documents can also provide a clear checklist of what you should be thinking about during your implementation.

The best way to get started may be to look at RFC 6841 titled “A Framework for DNSSEC Policies and DNSSEC Practice Statements

This document explains the rationale for a DPS and provides a framework for creating your own.

Alternatively, you may just want to dive into the list of DPS documents below to get an understanding of what these documents are like.  The .SE DPS may be a good place to start, primarily because the .SE team are very involved with the Internet-Draft framework document referenced above.

If you prefer to learn from a video, we have included at the end of this page a 15-minute video from training given by the OpenDNSSEC project in April 2010 where Anne-Marie Eklund-Löwinder from .SE explains the value of a DPS and the components that should be included.

A few notes about the lists below:

  • The lists contain the gTLDs, ccTLDS and RIRs for whom we can find formal DPS documents. Some of the gTLDs, ccTLDs and RIRs who do use DNSSEC are not listed because their domains/zones were signed very early in the DNSSEC rollout before the DPS framework started to become widely used. They may have other DNSSEC deployment information on their sites, but not in the form of a formal DPS.
  • The root of DNS also has multiple DPS documents but they are not explicitly listed below as the root zone is a special case with special precautions. You may find the documents to be an interesting read, though.
  • You will note in the list below that the DPS documents have several different names, but newer documents seem to be standardizing on “DNSSEC Practice Statement.”
  • These lists will continue to be updated as more DPS documents become available. Expect to see them continue to grow as more TLDs sign their domains.

If you are aware of a DPS document we should include, please let us know.

Generic Top-Level Domains (gTLDs):

Country-code Top-Level Domains (ccTLDs):

Regional Internet Registries (responsible for reverse DNS delegations, i.e.

The video below, while from 2010, provides a good introduction to what a DPS is all about:

Related articles

Deploy360 1 March 2019

DNS Privacy Frequently Asked Questions (FAQ)

Almost every time we use an Internet application, it starts with a Domain Name System (DNS) transaction to map...

Deploy360 1 March 2019

IPv6 Security for IPv4 Engineers

This document provides an overview of IPv6 security that is specifically aimed at IPv4 engineers and operators. Rather than...

Deploy360 27 February 2019

Introduction to DNS Privacy

Abstract Almost every time we use an Internet application, it starts with a Domain Name System (DNS) transaction to...