Automated DNSSEC Configuration (CDS scanning)

CDS scanning is a technology for automated DNSSEC bootstrapping, published by the IETF in RFC 8078.

DNS operators who support this protocol publish CDS records at the apex of the DNS zones that they operate, which contain the same information as the DS records they wish to be published in the parent zone. For example:

; in the example.xyz zone
example.xyz. 3600 IN CDS 12345 13 2 50d858e0985ecc7f60418aaf0cc5ab587f42c2570a884095a9e8ccacd0f6545c

An agent, which may be run by either the registry or registrar of the domain, automatically scans for the presence of CDS records, which are then added to the domain registration at the registry:

; in the xyz zone
example.xyz. IN DS 12345 13 2 50d858e0985ecc7f60418aaf0cc5ab587f42c2570a884095a9e8ccacd0f6545c

This secures the delegation of the domain without the need for manual copying and pasting of DS records.

CDS Scanning Policy

CentralNic deployed CDS scanning for the .SK top-level domain in 2020, and this deployment forms the basis of our anticipated rollout of CDS scanning for ccTLDs and gTLDs on our Cloud SRS platform.

1. Scanning is carried out using multiple vantage points, all of which are public DNSSEC-validating resolvers.
2. Only CDS records are checked; CDNSKEY records will be ignored.
3. CDS records are validated using the same logic used to validate DS records: they must be syntatically valid, use algorithms that are present in the IANA registry, and the digest field must have the correct length for the specified digest type.
4. Insecure domains (domains which do not have an existing DS record) are scanned once per week.
5. If one or more CDS records are found for an insecure domain, those records are checked every three hours for the next 72 hours, and if they remain stable, will be added to the database as DS records. However, if any changes to the CDS records are observed during this period, then the timer will reset.
6. Once secured, domains are scanned every 24 hours. The use of validating resolvers ensures that changes to CDS records are validated against the existing DS records. If the CDS records differ from the DS records in the database, then the database will be updated after a further 72 hours. If any changes to the CDS records are observed during this period, then the timer will reset.
7. If the observed CDS records differ from the records in the registry database, then the CDS records will replace the records in the database, irrespective of whether those records were added by a previous CDS scan or EPP, that is, CDS records take priority.
8. It should be noted that since CDS records for secure will be validated against the existing DS records, it is not possible to rectify DNSSEC issues (such as when a DS record has been added to an unsigned domain) using CDS scanning. Corrections to DS records should be made using EPP in these circumstances.
9. Similarly, in the event of an emergency key rollover, EPP should be used to update the delegation.
10. If the CDS record matches the format described in Section 4 of RFC 8078, then DS records will be removed from the database at the end of the 72-hour timer. Example:
    

    example.xyz. 3600 IN CDS 0 0 0 00 ; this will remove the existing DS record

Rollout of CDS scanning

The approximate timeframe for CDS rollout is as follows: