For Top-Level Domains (TLDs) supported on registry systems operated by Tucows Registry as Back-End Registry Services Provider

i. Document Control

i.i Version History

Effective Date: 10 March 2026

1. Introduction

This DNSSEC Practice Statement (DPS) conforms to the template included in RFC 6841.

1.1 Overview

The Domain Name System Security Extensions (DNSSEC) enhance the security of the Domain Name System (DNS) by providing cryptographic origin authentication and data integrity for DNS data. DNSSEC enables validating resolvers to verify that DNS responses are authentic and have not been modified in transit.

This DNSSEC Practice Statement (DPS) defines the policies, procedures, technical controls, and governance framework under which DNSSEC is implemented and operated for the Top-Level Domain (TLD) identified in this document.

This DPS is established in accordance with RFC 6841 (Framework for DNSSEC Policies and DNSSEC Practice Statements), RFC 4033, RFC 4034, RFC 4035, RFC 5155, RFC 5910, and other applicable DNSSEC-related standards and ICANN requirements.

This document is intended to provide transparency to ICANN, IANA, registrars, registrants, relying parties, auditors, and other stakeholders regarding the security posture, operational controls, and key management lifecycle practices governing DNSSEC for the TLD.

Unless otherwise stated, this DPS applies to all signed zones operated under the authority of the Registry Operator and technically implemented by Tucows Registry acting as Back-End Registry Services Provider.

1.2 Document Name and Identification

Document Title: DNSSEC Practice Statement (DPS) version 2026-03-10

Applicable TLDs: such TLDs as serviced by Tucows Registry

Registry Operator: as per the applicable ICANN Registry Agreement

Back-End Registry Services Provider: Tucows Registry

Version: 2.0

Effective Date: 10 March 2026

Review Cycle: Annual (or as otherwise required by contractual or regulatory obligation)

Document Classification: Public

Authoritative Source: http://tucowsregistry.com/dnssecpractice

Community and Applicability

The target communities for this document include: authors and users of applications throughout the public Internet using DNSSEC validation, with a need to evaluate the level of trust to apply to Tucows TLDs and their child domains; registrars and registrants of domains in TLDs using the registry back end services of Tucows Registry, relying parties intending to use this DNSSEC data to configure trust anchors; and reviewers and auditors interested in comparing operations  with the policies and processes described here.

1.3.1 Registry Operator

The Registry Operator retains ultimate responsibility for DNSSEC policy oversight, contractual compliance with ICANN, risk management, and approval of operational controls. The Registry Operator ensures that DNSSEC operations are conducted in accordance with applicable registry agreements, industry standards, and internal governance frameworks.

1.3.2 Back-End Registry Services Provider (Tucows Registry)

Tucows Registry is responsible for the technical and operational implementation of DNSSEC. This includes generation, activation, rollover, and destruction of Key Signing Keys (KSKs) and Zone Signing Keys (ZSKs); secure key storage within FIPS-compliant Hardware Security Modules (HSMs); TLD zone signing; DS submission to IANA for root zone publication; acceptance and processing of DS records from accredited registrars; and secure distribution of signed zone data.

1.3.3 Accredited Registrars

Accredited registrars interact with the registry using EPP (including RFC 5910 DNSSEC extensions) or other approved secure mechanisms. Registrars are responsible for authenticating registrants, securely managing Delegation Signer (DS) record submissions, and ensuring proper authorization prior to DNSSEC modifications.

1.3.4 Registrants

Registrants are responsible for generating, protecting, and maintaining DNSSEC key material for their delegated zones and for providing accurate DS records to their sponsoring registrar. The registry does not validate proof of possession of private keys unless explicitly stated elsewhere in this DPS.

1.3.5 Relying Parties

Relying parties include DNSSEC-validating resolvers and applications that depend on DNS authenticity. Relying parties are expected to rely on the root trust anchor and validate the chain of trust from the root zone through the TLD to subordinate zones.

1.3.6 Applicability

This DPS applies exclusively to DNSSEC operations for the TLD(s) covered by this document and to all associated key lifecycle, operational, physical, and technical controls implemented by Tucows Registry on behalf of the Registry Operator.

Tucows Registry is the authority for execution and any change to the policies and procedures discussed in this DPS.

This DPS is reviewed at least annually and updated as required to reflect changes in operational practices, contractual obligations, security requirements, or applicable technical standards.

Material changes to this DPS are subject to internal governance review and approval by authorized registry management.

Where this DPS is publicly available, updated versions shall be published with a revised version number and effective date. Superseded versions shall be retained in accordance with document retention policies 

2. Specification Administration

2.1 Specification Administration Organization

Registry Operator: The entity designated by ICANN as the operator of a specific TLD under the applicable Registry Agreement.

Back-End Registry Services Provider: Tucows Registry

2.2 Contact Information

Registry Operator:  The Registry contact information can be found on the specific NIC.TLD website.

Tucows Registry Contact:

        Tucows Registry

        96 Mowat Avenue

        Toronto

        Ontario M6K 3M1

Email: trs-support@tucows.com

Website: https://www.tucowsregistry.com

The mechanism to communicate changes in the DPS will be decided on a case by case basis, considering the impact on the stakeholder community and the nature of the changes themselves.

2.3 Specification Change Procedures

This DPS shall be reviewed at least annually and updated as appropriate based on:

Environmental Changes or operational changes Identification of relevant changes in the business, technological, operational or regulatory environment.

Results of Compliance Audits Whenever the results of a compliance audit highlights improvements to either Policy or Operational aspects of this DPS

Periodic Review: As the result of a periodic review of the general policy.

3. Publication and Repositories

3.1 Repositories

Information on the DNSSEC keys used to sign the zones for which the Tucows systems are authoritative is provided via a TLS secured website. The specific URL to the repository will be linked from the Tucows public home page.

3.2 Publication of Public Keys

Tucows will publish its Key Signing Keys in two formats.

Trust Anchor (DNSKEY) format: This format can be directly included into a BIND resolver as a trust-anchor. It is equal to the specification of the DNSKEY resource record except for the TTL and class parameters, which are intentionally left out.

Delegation Signer (DS) format: In this format, the public key is presented in a hash representation according to the DS Resource Record specification. There is no TTL or class parameter provided in this format.

3.3 Access Controls on Repositories

 All keys are available with PGP signatures generated with the current Tucows key. Validation of both the X.509 TLS certificate of the website as well as the PGP signature of the trust-anchor files is recommended. The PGP key will be signed by Tucows as the responsible party; signatories will be senior personnel for easy validation.

4. Operational Requirements

4.1 Registration of DS Records

The gTLD zones maintained by Tucows Registry may follow a thick registry model or  a minimum data set under ICANN Registration Data Policy. The Registrar is responsible for collecting the required DNSSEC data from the Registrant to be used in the parent zone by the Registry.  Registrars transmit DS data for registrants using EPP DNSSEC extensions (RFC 5910 or successor) or approved secure channels. Tucows is responsible for the correct, timely generation of signed DNS data and for distributing it to DNS service providers for its zones.

4.2 Method to Prove Possession of Private Key

The registrant is responsible for correctness of submitted key material.   

4.3 Removal of DS Records

The Registrar is responsible for receiving and processing the request to remove DS resource records from the Registrant. This information is then transmitted to Tucows for execution.

The Registrant may contact the Registrar and request removal of the DS resource records via the regular channels set forth by the Registrar for this purpose

Registrars process requests to remove DS records and transmit the change to the registry for execution.

4.4 Emergency DS Removal

Invalid DS keys may be removed from the DNS or the Registry database by Tucows.

All changes to the Registry information happen in near real time, so the process for Emergency requests is the same as for regular requests.

5. Facility, Management, and Operational Controls

5.1 Physical Controls

5.1.1 Site Location and Construction

Tucows Registry operates from multiple sites in North America and Europe within secured data center facilities. 

5.1.2 Physical Access

As per Tucows Security Policy, all the facilities providing DNSSEC-related services have restricted access, limited to authorized personnel. Specific measures depend on the facility and the level of access required, and may include smartcards, biometrics, and other methods for access control by Tucows, its contractors or third-party data center operators.

 5.1.3        Power and air conditioning

All facilities have Uninterruptible Power Supply (UPS) capabilities and air conditioning. The external data center sites have redundant systems in place in the event of a power failure.

5.1.4        Water exposures

To avoid the risk of water exposure, all Tucows facilities are on elevated floors. Data bearing facilities require evidence of proper water controls along with other environmental controls discussed in this document.

5.1.5        Fire prevention and protection

All facilities have fire detectors and gas extinguishers.

5.1.6        Off-site backup

System software and applications configuration are backed-up to storage systems spread across multiple data centers.

For purposes of recovery from disaster in which all HSMs at all sites fail, material needed to reconstitute an uninitialized HSM is also backed up. All private key backups are encrypted with an internal HSM key, which is backed up separately at HSM initialization time. For both the KSK and the ZSK, these backups are in the form of smart cards kept at a secure off-site facility. All private key backups are encrypted with an internal HSM key, which is backed up separately.

5.2 Procedural Controls

5.2.1 Trusted Roles

Activation data needed to make use of the private keys inside the HSMs is split into smart cards controlled by multiple key individuals with assigned responsibilities. 

5.2.2 Dual Control / Separation of Duties

Key management operations use dual control and separation of duties where appropriate.   

5.3 Personnel Controls

Personnel involved in DNSSEC operations are subject to role-based access control, training, and onboarding/offboarding procedures.   

5.3.1        Qualifications, experience, and clearance requirements

Engineers taking part in the Trusted Roles have to have been working for the company for no less than one year and must have the qualifications necessary for the role they have been appointed to.

Managers taking part in the Trusted Roles need to have been working for the company for no less than a year.

5.3.2        Training requirements

Before an individual is issued a security card, he or she must observe one regular key roll over process. There can be any number of observers for any given regular key roll over process.

5.3.3        Contracting personnel requirements

No person outside of the specified Trusted Roles can get access to the signer systems. If necessary, a team can perform certain tasks with the guidance of an external contractor. At no time is the contractor allowed to be the person performing the tasks on the system.

5.3.4        Documentation supplied to personnel

The regular procedures for backup and restore are available to all personnel involved. If major alterations to those procedures are made, the engineers of those teams will be informed accordingly.

5.4 Audit Logging Procedures

5.4.1        Types of events recorded

Physical access to the facilities used for our signing systems is logged automatically on enter and exit. The main operation site requires personnel to be specifically granted permission to enter the suite in which the equipment is located and they will have to sign-in using a valid identification (passport, drivers license, etc.). 

Log messages from the signer systems will be sent securely to a logging system and recorded for audit purposes.

5.4.2        Protection of audit log

Audit logs of our main operation site are kept by an external data center operator. These logs are not available to any of our employees and cannot be modified at the request of any of our employees.

5.5 Compromise and Disaster Recovery

Any relevant events relating to the secure operation of our systems will be announced through the appropriate channels at the time. Tucows and its contractors will invoke the relevant plans, including operations as described above and communications, in accordance with industry best practice.6. Technical Security Controls.

5.5.1        Incident and compromise handling procedures

If an event leads to, or could lead to, a detected security compromise, we will perform an investigation to determine the nature of the incident. If we suspect the incident has compromised the private component of an active key, an emergency key roll-over procedure will be performed.

5.5.2        Entity private key compromise procedures

Upon the suspected or known compromise of a key, we will assess the situation, develop an action plan and implement the action plan with approval from the Information Security Officer and Senior Management. When we perform an emergency roll-over for a compromised KSK, we will continue to operate this key for at least the minimum time specified to retrieve our public key trust anchors in the AUP.

6. Technical Security Controls

6.1 Key Pair Generation and Installation

6.1.1 Key Pair Generation

Both the Key Signing Key (KSK) and Zone Signing Key (ZSK) are generated via Hardware Security Modules (HSMs) in the signer systems. Parameters such as key length and cryptographic algorithm are set in accordance with Best Current Practice in similar systems and will be updated from time to time as appropriate.

6.1.2 Public Key Delivery

The public key is retrieved from the signer system and then published as detailed in the section Publication and Repositories on page 4. The process employs cryptographic protections to insure the integrity of the public key, as explained in the Security Policy for this level of classification.

6.1.3        Key Usage Purposes

A key must only be used for one zone and cannot be reused.

6.2 Private Key Protection and Cryptographic Module Controls

HSMs are used to protect private keys and enforce strong authentication and authorization.

6.2.1 Cryptographic Module Standards and Controls

Tucows employs HSMs with at least the following certifications:

-FIPS 140-2 Level 3

-Common Criteria EAL 4+

-Robust tamper-resistant hardware protecting key material even when archived.

-Strong authentication of administrators and dual controls through the use of advanced quorum techniques to mitigate the threat of single “super users”.

-Advanced separation of duties of key management activities between DNS,IT and security •        Centralized key management to support multiple DNS servers.

• Scalability to add HSMs dynamically and balance load as capacity requirements increase.
• High availability and disaster recovery with unlimited secure key backup and retrieval.
• Cryptographic CPU offloading to improve DNS server performance.

6.2.2 Private Key Backup

For purposes of disaster recovery in which all HSMs at all sites fail, material needed to reconstitute an uninitialized HSM is backed up. All private key backups are encrypted with an internal HSM key, which is backed up separately at HSM initialization time.

For both the KSK and the ZSK, these backups are in the form of smart cards kept at a secure off-site facility.

Key material is securely transferred among HSMs, which provides resilient storage. The private key will also be stored into smart cards. Access to the backups in any form requires authorization from Senior Management.

6.2.3 Method of Activating Private Keys

Activation data needed to make use of the private keys inside the HSMs is split into smart cards controlled by multiple corporate officers and operations staff.

Cards are to be stored in tamper evident containers by each user. Guidelines on initialization and handling of smart cards are based on manufacturer’s instructions for the HSMs and best practices used in support of DNSSEC elsewhere, including the root zone.

Key activation requires the use of smart cards.

6.2.4    Private Key Transfer Into or From a Cryptographic Module

Private keys can only be transferred off the system in encrypted form and restored to the back- up system by the teams described in the Trusted Roles section, as explained in the Key Backup section above. 

6.2.5 Method of Destroying Private Keys

Tucows uses The HSM’s provided functionality for the secure destruction of all key material.

Defective smart cards are retained until the keys they secure have been phased out. Then they are disposed of according to this policy.

6.2.6  Other Aspects of Key Pair Management

Tucows will only publish the public keys currently relevant to the operation of its zones. No archive of public keys past their revocation is available.

Past or revoked key pairs are destroyed and not archived.

6.2.7 Computer Security Controls

Tucows ensures that the systems maintaining key software and data files are Trustworthy Systems secure from unauthorized access. In addition, Tucows limits access to production servers to those individuals with a valid business reason for such access. General application users do not have accounts on production servers. All this follows the current Security Policy.

6.2.8 Network Security Controls

Systems holding the signing infrastructure are inside a dedicated VLAN inside our network infrastructure. The only communications channel to those systems is through firewalls, which are limited to the minimal capabilities necessary for the operation of the system.

6.3.9  Network Security Controls

Systems holding the signing infrastructure are inside a dedicated VLAN inside our network infrastructure. The only communications channel to those systems is through firewalls, which are limited to the minimal capabilities necessary for the operation of the system.

6.3.10 Timestamping

The signer systems securely synchronize their system clocks with trusted time sources inside and outside our network.

6.4 Life Cycle Technical Controls

6.4.1 System Development Controls

As explained above, the signer systems employ ISC’s BIND 9 or BIND 10 interfacing with HSMs that provide secure storage and processing involving private key material.

Only production-ready versions of BIND 9 or BIND 10 as well as the HSMs are used for Tucows, after thorough testing in our OT&E platform.

7. Zone Signing

7.1 Key Lengths, Key Types, and Algorithms  

Tucows utilizes key lengths, types and algorithms considered as best practices at the time.

At the time of this writing, DNSSEC system for Tucows TLDs defaults to ECDSA Curve P-256 as per [RFC-6605]. The DS signature algorithm will be SHA-256 hashes as per [RFC-4509].

7.2 Authenticated Denial of Existence  

Tucows uses NSEC3 [RFC-4034] , RFC-9726] to authenticate denial of existence of resource records, using SHA-1 algorithm, with no extra iterations, and empty salt, as recommended by [RFC-9276].

7.3 Key Rollover  

ZSKs are rolled over quarterly, with each ZSK cycle lasting ninety (90) days plus rollover time. They are published ten (10) days before use and remain published ten (10) days after the new key is in use for signing, to account for cached entries in the DNS and to facilitate rollover.

KSKs are rolled approximately every two to five years as appropriate, such as when there is a change in Best Common Practice for signature algorithms or parameters or the current key is believed to be compromised, HSM upgrade or replacement, or to exercise rollover mechanisms. New KSKs are propagated into the root as part of the regular KSK exchanges with ICANN.

A new KSK is published in the zone 60 days prior to use and remains published 20days after it is no longer used to sign.

The timing of KSK rollovers is chosen to center around normal quarterly ZSK rollover cycles to limit the size of the DNSKEY RR set to no more than three (3) keys at any one time (i.e., old KSK, new KSK and current ZSK). Furthermore, only the KS signatures over the DNSKEY RR set will be generated. These measures keep root zone referral response packet sizes as small as possible.

7.4 Signature Lifetime and Re-signing Frequency  

The RRSIG resource record in all zones under Tucows management has a lifetime of less than one day. Zones can be resigned every 5 minutes to 30 minutes depending on various external factors.

7.5 Verification of Resource Records

Tucows operates monitoring systems that check DNSSEC signature validity. Alarms are raised when anomalies are detected.

7.6 Resource Record TTLs

DNSKEY        Equal to the TTL used for the SOA record

NSEC        Equal to the TTL used for the SOA record

RRSIG        Equal to the lowest TTL of the record set covered

DS        Equal to the TTL of the NS record set

8. Compliance Audit

8.1 Frequency of Compliance Audit

Every two years after the complete implementation of this DPS, a Compliance Audit will be performed to verify that practices remain compliant with the contents and intent of the DPS.

8.2 Identity and Qualifications of Auditor

The Compliance Audit will be performed by an independent entity with qualifications and experience with DNSSEC operations.

8.3 Topics Covered by Audit

The audit scope includes compliance with this DPS, security controls, and alignment with current best practice. 

8.4 Actions Taken as a Result of Deficiency

Deficiencies or gaps in compliance with the DPS or deviations from the current industry best practices are to be collected in a findings reports that will be delivered to Tucows and ISC’s management teams, who will assess and prioritize any findings and respond promptly with an action plan to bring the identified issues to resolution.

9. Legal Matters

9.1 Fees

No fees are charged for DNSSEC-related functions. 

9.2 Financial Responsibility

The Registry Operator and Tucows Registry accept no financial responsibility for improper use of trust anchors or signatures under this DPS.

9.3 Term and Termination

This DPS remains in effect until replaced by a newer version.

9.4 Limitation of Liability

Neither Tucows Registry, nor their agents shall be liable for any financial loss, or loss arising from incidental damage or impairment, resulting from its performance of its obligations hereunder. No other liability, implicit or explicit, is accepted.

9.5 Dispute Resolution

Disputes among DNSSEC participants shall be resolved pursuant to provisions in the applicable agreements among the parties.

9.6 Governing Law

This DPS shall be governed by the laws of Los Angeles, California.

10. References

RFC 4034 – Resource Records for the DNS Security Extensions

RFC 4509 – Use of SHA-256 in DNSSEC DS Resource Records

RFC 5910 – EPP DNSSEC Mapping

RFC 6841 – A Framework for DNSSEC Policies and DNSSEC Practice Statements

Appendix A. Acronyms

Appendix B. Definitions

Terms not otherwise defined herein shall have the meaning assigned in applicable RFCs.

DNSSEC - The set of IETF standards that provide origin authentication and data integrity to DNS data through digital signatures.

Key Signing Key (KSK) A DNSSEC key pair used to sign the DNSKEY RRset of a zone.

Zone Signing Key (ZSK) A DNSSEC key pair used to sign all authoritative RRsets in a zone other than the DNSKEY RRset.

Delegation Signer (DS) Record A resource record in the parent zone that contains a hash of a child zone’s KSK and forms part of the DNSSEC chain of trust.

DNSKEY Record A DNS resource record that contains a public key used in DNSSEC validation.

RRSIG Record A DNS resource record containing the digital signature associated with a signed RRset.

Authenticated Denial of Existence A DNSSEC mechanism (NSEC or NSEC3) used to cryptographically prove the non-existence of a DNS name or record.

Trust Anchor A configured public key that a resolver uses as a starting point for validating the DNSSEC chain of trust.

Registry Operator The entity designated by ICANN as the operator of a specific TLD under the applicable Registry Agreement.

Back-End Registry Services Provider An entity that provides technical registry services, including DNSSEC operations, on behalf of the Registry Operator. 

Registrar An ICANN-accredited entity authorized to sponsor domain names and submit registry transactions via EPP.

Registrant The holder of record of a domain name within the TLD.

Relying Party An entity that performs DNSSEC validation and relies on DNS data for security decisions.

Trusted Role A role assigned to personnel with authorized access to DNSSEC key management systems or cryptographic material.

Hardware Security Module (HSM) A tamper-resistant cryptographic device used to generate, store, and manage cryptographic keys.

Key Rollover The process of replacing an active DNSSEC key with a new key in accordance with defined procedures.

Pre-Publication Method A DNSSEC key rollover method in which a new key is published before being used for signing.

Double-Signature Method A DNSSEC key rollover method in which both old and new keys sign the zone during the transition period.

Dual Control A control mechanism requiring at least two authorized individuals to perform sensitive operations.

Separation of Duties A control principle ensuring that no single individual has authority to complete all stages of a critical process.

Incident An event that may compromise the confidentiality, integrity, or availability of DNSSEC systems or key material.

Was this article helpful? If not please submit a request here