Policy and Guidelines for Automated DNSSEC Provisioning


The Swedish Internet Foundation registry system stores only DS records. We apply the same requirement to this system and will only scan for CDS records. 

We support all three uses of CDS from RFC 8078 section 2 

  1. Enable DNSSEC validation 
  2. Roll the KSK 
  3. Turn off DNSSEC validation

Acceptance policy 

All checks are run daily from three different locations 

The following requirements must be met for all three use cases: 

  • All three locations must receive the same data. 
  • The domain name is in the status ACTIVE (see whois). 
  • The domain is not in Registry Lock (see whois). 
  • The CDS record set does not contain syntactic or semantic errors. 
  • If CDNSKEY records are published, they must match the published CDS records (RFC 7344 section 4). 
  • CDS records should not overwrite more recent updates from EPP. 
  • Maximum 6 CDS records per domain. 
  • DNSSEC validation must succeed for every name server. All nameservers must publish the same CDS RR-set, but not the same DNSKEY RR-set. Therefore validation is checked for each name server respectively. 

Enable DNSSEC validation 

We will implement the RFC 8078 section 3.3 “Accept after Delay” policy.  

  • All name servers are reachable over TCP on all their IP addresses and deliver a consistent CDS RR-set. 
  • The change must be consistently published for more than 72 consecutive hours. 
  • The inception time of the Resource Record Signature (RRSIG) for the CDS RR set is later than the inception time of the last executed change signaled over CDS. 
  • All key algorithms and digest types in the CDS record set must be supported by the registry (see Appendix 1 - Algorithms
  • DNSSEC validation must succeed using the new DS record set. 

Roll the KSK 

According to RFC 8078 section 2.1 "seeing" is the preferred acceptance policy.  

  • The same valid signed CDS RR set must be seen by all three locations. 
  • All key algorithms and digest types in the CDS record set must be supported by the registry (see Appendix 1 - Algorithms)  
  • DNSSEC validation must succeed using the new DS record set. 

Turn off DNSSEC validation 

According to RFC 8078 section 2.1 "seeing" is the preferred acceptance policy.  

  • The same valid signed CDS RR set must be seen by all three locations. 

Please be aware of the correct format of both record types 

CDS 0 0 0 00 

CDNSKEY 0 3 0 AA== (see RFC 8078 Errata) 

RFC 8078 section 4 mandates the usage of the full format as given above.  

Automated Name Server Provisioning 

RFC 7477 describes the CSYNC resource record. It used to signal to the parent that the child would like to synchronize resource records from the child to the parent. 

Requirements for synchronization: 

  • Domain is active 
  • Domain is not in Registry Lock 
  • csync record is valid signed 
  • only ns records are synchronized 
  • glue is synchronized only if needed (independently of the A and AAAA flag in the CSYNC record) 
  • the ns set is valid signed 
  • from three vantage points all name servers give the same result 
  • CSYNC should be ignored if CDS set is different from DS set 

Status Check 

DNS operators can verify the current state of CDS processing for any domain name at https://cds.registry.se
This status page shows the expected processing date for ongoing change requests and additional information for any error preventing a requested change from going forward. 


Appendix 1 - Algorithms 

Key Algorithms 

Algorithm Support 
RSASHA1 No 
RSASHA1-NSEC3-SHA1 No 
RSASHA256 Yes 
10 RSASHA512 Yes 
13 ECDSAP256SHA256 Yes 
14 ECDSAP384SHA384 Yes 
15 ED25519 ??? 
16 ED448 ??? 

Digest Algorithms 

Algorithm Support 
SHA-1  No 
SHA-256 Yes 
GOST R 34.11-94 No 
SHA-384 Yes 


Appendix 2 – References 

RFC 7344 Automating DNSSEC Delegation Trust Maintenance 

RFC 8078 Managing DS Records from the Parent via CDS/CDNSKEY 

RFC 7477 Child-to-Parent Synchronization in DNS