Describe a hosted zone's DNSSEC status.
curl --request GET \ --url https://stratum.example.com/v1/projects/example/dns/zones/example/dnssec \ --header 'Authorization: Bearer <token>'Reports whether the zone is signed and, crucially, whether it is ANCHORED — a signed zone with no DS in its parent is treated by every validating resolver as unsigned. Returns the DS to publish when this install does not serve the zone’s parent. Everything here is public key material, readable by anyone who can describe the zone.
Authorizations
Section titled “Authorizations”Parameters
Section titled “Parameters”Path Parameters
Section titled “Path Parameters”Responses
Section titled “Responses”The zone’s DNSSEC status.
A hosted zone’s DNSSEC status. For a zone delegated under the domain this install serves, nothing here needs acting on: the DS is published into the parent zone automatically. It exists for the case automation cannot reach — a zone whose parent lives at an external registrar — where Stratum can only hand over the DS and say that nothing is anchored until somebody publishes it.
object
The DESIRED state: whether signing was asked for. Whether the zone is signed and anchored right now is state.
The OBSERVED state.
insecure — not signed. pending_ds — signed, but no DS is published in any parent, so validating resolvers still treat the zone as unsigned. secure — DS published; the chain of trust is complete. withdrawing — the DS has been withdrawn and the zone keeps signing until it expires from resolver caches. Its keys are retired only then; stopping sooner would make the zone unreachable rather than unsigned.
The on-wire name this zone is signed at, and the owner name of its DS. Empty for a zone that is not delegated.
Whether this install serves the zone’s parent and so publishes the DS itself. When false, publishing it is the operator’s job.
True when the chain of trust is waiting on a human.
One line stating what is true on the wire and what, if anything, to do.
When the DS was withdrawn from the parent. Set only while withdrawing.
When a ZSK roll was requested. Present while one is in flight: a replacement key is published but not yet signing, and is promoted once the DNSKEY rrset has had time to propagate. Cleared on completion. ZSK-specific on purpose. A KSK roll runs a different schedule and the two can be in flight at once, so a single “a roll is happening” field could not tell a caller which window they are waiting on.
When a KSK roll was requested. A KSK roll is a double-DS sequence: the parent publishes the outgoing and incoming DS together, and the new key only starts signing once the DS TTL has elapsed.
When the parent began holding BOTH DS records for a KSK roll.
This — not kskRotationRequestedAt — is what the promotion clock runs from, so it is the field that answers “how much longer”. The gap between the two is the time the data plane took to mint the key and the control plane to publish its DS.
The delegation signer that anchors this zone in its parent, in the several shapes registrars ask for it. Present whenever the zone has an active key-signing key.
object
The DS owner name — the zone’s served FQDN, not its logical name.
DNSSEC algorithm number. 13 is ECDSAP256SHA256, the only one emitted.
Digest algorithm. 2 is SHA-256.
Hex digest of the DNSKEY.
The RDATA alone — <keytag> <algorithm> <digesttype> <digest> — which is what most registrar forms take.
The complete record, for a registrar that accepts one.
The zone’s active key-signing key, which the DS is a digest of. Provided for registrars that ask for a key rather than a digest.
object
257 — a key-signing key (ZONE with the SEP bit set).
Always 3.
Base64, as it appears on the wire.
The zone’s whole key inventory, oldest first within each role: what is signing, what is staged behind it, what has been stood down, and when each retired key becomes safe to remove. Absent on a zone that has never been signed.
One key in a zone’s DNSSEC key inventory. A zone holds more keys than the one signing it. A rollover publishes the successor BEFORE it signs, so that every resolver has it cached when the first signature from it arrives, and keeps the outgoing key published AFTER it stops signing, so that signatures already in caches remain verifiable. Both are normal, and neither is visible from the DS or the active DNSKEY alone.
object
ksk signs the DNSKEY rrset and is what the parent’s DS points at; zsk signs everything else.
The key’s tag on the wire. An RRSIG names the key that made it by this tag, so it is how a signature in a capture is traced back to a row here.
DNSSEC algorithm number (13 = ECDSA P-256 SHA-256).
signing — makes new RRSIGs. pre_published — in the DNSKEY rrset but signing nothing: the successor waiting out its propagation window during a roll. retired — stopped signing, and published only until the signatures it made can no longer be in any cache.
Whether the key is in the zone’s DNSKEY rrset right now. True for every key except a retired one past prunableAt.
When the key became visible in the DNSKEY rrset.
When the key stopped signing. Present only on a retired key.
When the key can be deleted without making any signature it produced unverifiable — retiredAt plus the retired-key publish window.
Deleting a key before this makes cached answers BOGUS rather than unsigned: a resolver holding an RRSIG whose key has vanished can neither verify the answer nor fall back to trusting it. Present only on a retired key; a signing or pre-published key has no such time.
Example
{ "state": "insecure", "keys": [ { "role": "ksk", "state": "signing" } ]}Resource not found.
object
The findings of a rejected IAM policy document (custom and resource policies).
One finding of a rejected IAM policy document. A rejection lists every finding, so the author fixes the document in one round trip.
object
The finding, e.g. INVALID_DOCUMENT, UNKNOWN_ACTION, ACTION_NOT_APPLICABLE.
Index of the statement at fault; -1 for the document as a whole.
The offending action, where one is at fault (ACTION_NOT_APPLICABLE).
Field errors, for codes that carry them: each problem at its field
(see FieldError). Documented on the responses that set it, e.g.
approveNodeJoin’s INVALID_INPUT and JOIN_APPROVAL_REFUSED.
Absent otherwise.
One field’s problem, the stage-2 installer API’s shape.
field is the field’s path, message what is wrong with it.
object
The field’s path, e.g. links[0].interface, disks[1].confirm,
mgmt.address or role; empty for the whole request.
Structured facts about the refusal, for codes that carry them. The
shape is fixed per code and documented on the response that answers
it, e.g. IMAGE_POOL_MISMATCH (see ImagePoolMismatchDetails) and
IMAGE_IN_USE. Absent for codes that carry none.
object
Example
{ "issues": [ { "code": "ACTION_NOT_APPLICABLE", "action": "compute:CreateVpc" } ]}