DNSSEC Signing on the Secondary

Keep your hidden primary unsigned and let the secondary sign the zone. No keys on your server, no signature expiry to watch.

Two places a zone can be signed

With a hidden primary, you can sign your zone in one of two places:

AspectSigned on your primarySigned on the secondary
Where the keys liveOn your serverWith the secondary
Who renews signaturesYouThe secondary
Who rolls the ZSKYouThe secondary, automatically
What your primary servesA signed zoneA plain, unsigned zone
Who publishes the DSYou, at the registrarYou, at the registrar

Signing on the primary gives you full control, but you also carry the risk. If your signing job stops, the signatures expire after some days or weeks and validating resolvers stop answering for your domain. That failure is silent until the day it happens.

Signing on the secondary removes that job from your server. You edit an ordinary zone, and the secondary signs every version it transfers. This is called inline signing.

How inline signing works on hiddenprimary.ch

  1. Your primary serves the unsigned zone, as before.
  2. We transfer it and sign it with ECDSAP256SHA256 (algorithm 13).
  3. All our public nameservers serve the same signed copy.
  4. We renew the signatures and roll the zone-signing key (ZSK) automatically.
  5. You publish one DS record at your registrar. It points to our key-signing key (KSK) and does not change when the ZSK rolls.

Every change you make on the primary is signed as soon as it is transferred. You do not need to reload anything or touch a key.

Turn it on

  1. Make sure your primary serves the zone without DNSKEY records at the apex. If it has keys, turn signing off there first. The next section explains why.
  2. In the portal, open the zone, go to the DNSSEC tab, and click Enable DNSSEC. Or use the API:
terminal
$ curl -X POST https://hiddenprimary.ch/v1/zones/1/dnssec/enable \
  -H "Authorization: Bearer $HP_KEY"
  1. Copy the DS record from the DNSSEC tab. The tab also shows it split into Key Tag, Algorithm, Digest Type and Digest, because most registrar forms ask for these fields separately.
  2. Enter the DS at your registrar. Until you do, the zone is signed but not anchored: resolvers treat it as unsigned, and it keeps resolving.

If your primary already signs the zone

A zone can have only one signer in this setup. If the zone we transfer already contains DNSKEY records at the apex, we detect that and serve your signatures unchanged. Keys and signing stay on your primary, and the DS at your registrar stays as it is. In that state, we refuse to turn on our own signing: our keys would not match the DS you published, and validating resolvers would reject the zone.

To move the signing to us, you have to change the DS as well. Follow Change a DS record without SERVFAIL for the safe order.

The serial on our nameservers differs from yours

Signing changes the zone, so a signed zone gets its own SOA serial. The serial our nameservers show is therefore not the serial in your file. To check that a change arrived, compare a record you changed:

terminal
$ dig +dnssec +short TXT example.ch @ns1.hiddenprimary.ch

We watch the DS for you

Every hour, we compare the DS at your registrar with the key we sign with, as public resolvers see it. The DNSSEC tab shows the result:

  • No DS yet: the zone is signed but not anchored. It resolves, without DNSSEC protection.
  • DS mismatch: the DS points to a key we do not sign with. Validating resolvers fail the zone. Replace the DS with ours.
  • Orphaned DS: a DS is published, but the zone is not signed. Validating resolvers fail the zone. Remove the DS, or turn signing back on.

If you use webhooks, the events dnssec_ds_alert and dnssec_ds_resolved tell you when the state changes.

Next Steps