.GODADDY - DNSSEC Policy
This is the DNSSEC policy of Afilias, the Back End Service Provider for the .GODADDY TLD.
This document was created using the template provided under the current practicing documentation. This document comprises the practices utilized by Afilias to operate DNS zones as it relates to the DNS Security Extensions. Unless stated otherwise within this document, these statements pertain to all TLD zones under Afilias auspice that have been signed.
1.2. Document name and identification
Afilias DNSSEC Practice Statement (DPS)
1.3. Community and Applicability
This section describes the various “stakeholders” of the functionality provided by DNSSEC and a signed TLD.
1.3.1. The TLD Registry
Afilias operates in two distinct modes: (1) As a Registry Operator (RO), where the TLD has been directly delegated to Afilias by ICANN, and (2) as a Back End Service Provider (BESP), where Afilias operates and performs the functions of maintaining the zone, on behalf of another entity (which acts as the RO). In the case where Afilias is the RO for a zone, Afilias is also acting as the BESP.
The Registry is expected to perform the following functions:
Generate the Key Signing Keys (KSK) for the zone.
Generate the Zone Signing Keys (ZSK) for the zone.
Sign the ZSK using the KSK.
Sign the relevant Resource Records of the zone using the ZSK.
Update the ZSK and KSK as needed.
Send Delegation Signer (DS) Resource records to ICANN for inclusion into the root zone.
Receive DS Resource Records from accredited registrars, and update the zone accordingly.
Update the WHOIS information accordingly.
1.3.2. Accredited Registrars
Registrars that are accredited by a given TLD RO are required to make changes to the zone using one of two mechanisms: (1) via EPP, or (2) via a Web Administration Tool. The Web Administration Tool is an Afilias provided front end to EPP, so, in effect, all changes to the registry are made via EPP. For DNSSEC, registrars are expected to maintain Delegation Signer (DS) records with Afilias on behalf of their customer, the registrant.
Registrants are responsible for ensuring that their second level zones are properly signed and maintained. They must also generate and upload DS records for their signed zones to their registrar (who, in turn, sends these into Afilias).
1.4. Specification Administration
1.4.1. Specification administration organization
Afilias maintains this specification.
1.4.2. Contact Information
Questions or concerns regarding this DPS, or the operation of a signed TLD should be sent to the Afilias Customer Support Center. They can be reached via:
Phone: +1 416.646.3306
1.4.3. Specification change procedures
The DPS is reviewed periodically and updated as appropriate.
All changes are reviewed by operations and security teams and submitted to executive management for approval. Once accepted, procedures are updated, and appropriate personnel are trained on any new or changed practice. Once all preparatory work has been completed, the DPS is published and becomes effective as of its publication.
2. PUBLICATION AND REPOSITORIES
This DPS can be found at http://www.afilias.info/dps
Only the Afilias Operations department has the ability to update the contents of the website. ACLs on the file are Read-Only.
2.2. Publication of key signing keys
The “chain of trust” is maintained for Afilias TLD zones by sending DS records to ICANN for inclusion in the root zone delegation of the TLD. These DS records correspond to at least one active KSK in the zone. As such, no publication of an additional trust anchor is required.
3. OPERATIONAL REQUIREMENTS
3.1. Meaning of domain names
Policies regarding restrictions on domain names within a given zone are specified by the registry operator, and vary from TLD to TLD.
3.2. Identification and authentication of child zone manager
Registry Operators must first give express permission to Afilias to permit DNSSEC for child zones in a given TLD. Only registrars (on behalf of their registrants) are permitted to activate DNSSEC for a child zone. To activate DNSSEC, a registrar must submit a Delegation Signer (DS) record either via the Web Administration Tool, or via EPP (according to RFC 5910).
For EPP, each registrar has unique credentials to access the TLD registry, which are verified before EPP transactions of any kind can be conducted. For the Web Administration Tool, certificates are used to uniquely identify each registrar.
3.3. Registration of delegation signer (DS) resource records
DS records are sent to the registry by the registrar via EPP (specifically, according to RFC 5910). Once submitted to the TLD registry, the WHOIS data is changed, and the zone changes are automatically propagated out to the DNS infrastructure.
3.4. Method to prove possession of private key
It is the responsibility of the accredited registrar to ensure the integrity of the data submitted to Afilias. There is no requirement that a corresponding DNSKEY already be published in a zone before a DS record is submitted to the parent. This makes proof of possession of a private key unpredictable.
Afilias therefore does not perform any tests to prove possession of a private key.
3.5. Removal of DS record
3.5.1. Who can request removal
Only the sponsoring registrar for a domain name can add, change, or delete DS records for that domain name. Registrars must provide an Auth-Info code to verify any change for this domain name.
3.5.2. Procedure for removal request
DS records are removed using the appropriate EPP command, as specified by RFC 5910. Only the Sponsoring Registrar can request a DS record be removed, and then only if they include the correct Auth-Info code.
3.5.3. Emergency removal request
Because this is facilitated via EPP, and the system is updated continuously, there is no additional