Enable DNSSEC for KeyDNS zones

• Zone is not existing in KeyDNS: Add the DNS zone to KeyDNS with the command AddDNSZone. To enable DNSSEC support, add the parameter 'signed=1' to the AddDNSZone command.
• Zone is already existing in KeyDNS: Use the command ModifyDNSZone with the additional parameter 'signed=1' to enable DNS support for your existing DNS zone. You can set signed=0 to disable DNSSEC support of a DNSSEC enabled zone. Please ensure in this case, that the delegation signer in the parent zone is not present anymore.
  • Sign the zone
  • After DNS changes have been propagated, update the parent zone. The information can be obtained by the StatusDNSZone command. Please always use the KSK (flag: 257) to update the parent zone

Key rollover

KeyDNS DNSSEC supports two kinds of key rollovers:

• Zone signing key (ZSK) rollover
  • The ZSK rollover is finished automatically.
  • The ZSK being rolled automatically every 90 days.
• Key signing key (KSK) rollover
  • Needs interaction with the parent zone.
  • Can be manually initiated with the ModifyDNSZone command parameter: rollover=KSK.
  • Can be finished (after parent zone update) with the parameter:finishkskrollover=<keytag>. The <keytag> defines the dnssec key whose rollover should be finished. The relevant keytag is returned by the command StatusDNSZone as the first part of the 'keydsdata sha256' parameter (where keydata flag: 257, keystatus: ready).
  • The first KSK rollover of a newly added DNSSEC zone can be initiated after the KSK key status has changed to 'active'.
  • The KSK is not being rolled automatically.

Only one ZSK and one KSK rollover can be active at the same time. To update the domain name with the relevant keydata or DS (delegation signer) data, please follow the CentralNic Reseller manual. Please use always the KSK (flag: 257) and not the ZSK for updating the parent zone.

DNSSEC policy

In effect until Friday 31st January 2025

Signatures:

• Refresh: 4-daily
• Validity: 14 days
  

Denial of non existence:

• NSEC3

Keys:

• KSK: Algorithm 8, Length: 4096
• ZSK: Algorithm 8, Length: 2048

New frontend DNSSEC signing policy

The new policy shall be effective from Monday 3rd February 2025.

Signatures:

• Refresh: We re-sign the zone every Thursday at 00:00 UTC.
• Validity: 7 days

Denial of non existence:

• NSEC3

Keys:

• KSK: Algorithm 13, Length: 4096
• ZSK: Algorithm 13, Length: 4096 (90 days rollover)

Signing existing zones (delay until max TTL's expired):

• caching + max (SOAminimum of zone, max TTL of zone records) (seconds)
• Let's say a zone has the following 4 records:
  • example.com 600 IN SOA ns1.example.com admin.example.com 2013022001 86400 7200 604800 300
  • example.com 300 IN NS ns1.example.com
  • example.com 300 IN NS ns2.example.com
  • example.com 1200 IN A 127.0.0.1

In the examples mentioned above, the SOAminimum of the zone is 300 (last value in the SOA record), meanwhile the max TTL across all records is 1200 (the A record).
So the delay will be:
=caching + max(300, 1200)
=caching + 1200

The reasons behind the new policy:

• Using a safer algorithm
• Keeping up with new recommendations
• Providing enough support in resolvers
• Smaller DNSSEC answers (from: RSASHA256 to: ECDSA Curve P-256 with SHA-256)

DNSSEC capable name servers

All our servers are DNSSEC capable. To find out more about our Anycast infrastructure, please visit: