Skip to main content

​
DNSSEC

DNSSEC is on unless you say otherwise. The signer bootstraps the zone and the dnssec block appears on it, carrying the key tags, the algorithm (13, ECDSA P-256 SHA-256), and the DS records.
dnssec: false at create time exists for one situation: this domain is served by another DNS provider at the same time as us. A signed zone puts our DS record at the parent, and that DS covers only the answers we sign — so a validating resolver that happens to ask the other provider gets a signature it cannot verify and fails the lookup. Roughly half your queries, unpredictably, which is worse than either provider on its own. Unsigned is the only configuration that works for that setup today.It is fixed at creation, and there is no switch in the console. Turning signing off later breaks the domain until the DS is withdrawn at the registrar and that withdrawal has propagated — a sequence this API cannot drive for you.
To complete the chain of trust, paste the DS record at your parent registrar:
1

Read the DS records off the zone

The zone’s DNSSEC card lists them under DS records, with the KSK key tag and ZSK key tag beside them.
dnssec.ds_records holds them. Each also carries rdata — the zone-file form of the same record, for registrars that want a single string.
2

Publish it at the registrar

This is the one DNSSEC step that cannot be done from here: only the parent zone’s operator can publish a DS record, and for a public suffix that is your registrar.
3

Validate

Once the DS is live, resolvers can validate the chain from the root down to your records.
Until the DS record is published at the registrar, your zone is signed but not validated — resolvers have no way to reach your keys from the root. Signing without a DS buys nothing.