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 an Internet-Draft titled “A Framework for DNSSEC Policies and DNSSEC Practice Statements”
http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-dps-framework
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):
- .COM DNSSEC Practice Statement (PDF) – see Verisign DNSSEC repository for more information
- .EDU DNSSEC Practice Statement (PDF)
- .NET DNSSEC Practice Statement (PDF)
Country-code Top-Level Domains (ccTLDs):
- .AT DNSSEC Policy Statement (PDF)
- .CA DRAFT DNSSEC Practice Statement
- .CZ DNSSEC Operation Manual (PDF)
- .JP DNSSEC Practice Statement
- .NL DNSSEC Policy and Practice Statement (PDF)
- .NZ DNSSEC Practice Statement
- .PL DNSSEC Policy and Practice Statement (PDF)
- .SE DNSSEC Practice Statement (PDF)
- .SI DNSSEC Practice Statement (PDF)
Regional Internet Registries (responsible for reverse DNS delegations, i.e. in-addr.arpa):
- AfriNIC – DPS
- RIPE NCC – DNSSEC Policy and Practice Statement
The video below, while from 2010, provides a good introduction to what a DPS is all about:
