Professional Cloud Network Engineer
Configure DNSSEC Key Signing and Zone Signing is the process of enabling and fine-tuning DNS Security Extensions (DNSSEC) for a managed zone in Cloud DNS. This involves selecting cryptographic algorithms and key lengths for the Key Signing Key (KSK) and Zone Signing Key (ZSK), which are the two types of keys used to generate digital signatures for DNS records. The KSK signs the DNSKEY record set, establishing a chain of trust to the parent zone, while the ZSK signs the rest of the zone’s resource records for performance.
You enable DNSSEC for a managed zone using the gcloud dns managed-zones update command with the --dnssec-state on flag. At this point, you must specify the algorithm and key length for both the KSK and ZSK. If you provide any of these parameters, you must provide all four: --ksk-algorithm, --zsk-algorithm, --ksk-key-length, and --zsk-key-length. Cloud DNS supports a limited set of algorithms: RSASHA256, RSASHA512, ECDSAP256SHA256, and ECDSAP384SHA384, each with specific allowed key lengths. If you do not specify an algorithm, Cloud DNS defaults to RSASHA256 with a 2048-bit KSK and a 1024-bit ZSK.
The choice between RSA and ECDSA algorithms involves a tradeoff between compatibility, performance, and response size. RSA algorithms like RSASHA256 are widely supported by older DNS resolvers and registries. ECDSA algorithms like ECDSAP256SHA256 produce much smaller signatures, which leads to faster computation and smaller DNS response packets, but they are only supported by newer resolver systems. Using different algorithms for the KSK and ZSK is generally discouraged as it can reduce compatibility and may cause validation failures with some resolvers, even though the RFC standard permits it.
To change DNSSEC settings like the signing algorithm after it is already enabled, you must first disable DNSSEC for the zone, make the changes, and then re-enable it. A critical operational dependency exists with your domain registrar: if you want your domain to resolve while DNSSEC is disabled in Cloud DNS, you must first deactivate DNSSEC at the registrar to prevent validation failures for clients. Cloud DNS manages the automated creation, rollover, and signing operations for both KSKs and ZSKs, generating the Resource Record Signatures (RRSIGs) that protect the zone’s data.
Alongside key configuration, you must choose a denial-of-existence type, which is set independently of the algorithms. The options are NSEC or NSEC3. NSEC3 is the default and offers limited protection against "zone walking" attacks that try to enumerate all records in your zone, but it produces slightly larger responses than NSEC, which offers no such protection. For NSEC3, Cloud DNS uses fixed parameters: opt-out is disabled, and it uses one additional hash iteration with a 64-bit salt.
Google Cloud DNS provides Domain Name System Security Extensions (DNSSEC) support for public managed zones to protect domain name resolution against spoofing and cache poisoning. DNSSEC creates a cryptographic chain of trust by signing DNS resource records with digital signatures, allowing resolving name servers to verify that DNS responses are authentic and unmodified. DNSSEC can be enabled directly on authoritative public zones, but Cloud DNS private managed zones do not support DNSSEC.
Enabling DNSSEC on a Cloud DNS managed public zone activates automatic cryptographic signing for the zone’s resource record sets. Administrators can enable DNSSEC when creating a new managed public zone or by updating an existing public zone, setting the DNSSEC state to on, off, or transfer. When configuring an existing public zone, Cloud DNS imposes a limit where DNSSEC cannot be enabled or disabled on zones containing more than 3,000 resource record sets. To sign an existing zone exceeding 3,000 records, an administrator must create a new DNSSEC-enabled zone with the same DNS name, populate the records, and delegate traffic to the new zone’s name servers.
Activating DNSSEC for public resolution requires linking the Cloud DNS public zone to the parent zone by publishing a Delegation Signer (DS) record at the domain registrar. Administrators retrieve the DS record generated by Cloud DNS using the Google Cloud console or by filtering for key signing keys with the command-line interface. The registrar publishes this DS record in the parent zone, establishing the cryptographic chain of trust that external validating resolvers use to verify DNS responses. Because DNS records and DS entries rely on caching and time to live (TTL) values, complete propagation of the DS record across global resolvers can take 24 hours or longer.
Deactivating DNSSEC requires a strict order of operations to prevent validating resolvers from failing resolution for the domain. An administrator must first remove all DS records from the parent zone at the domain registrar before disabling DNSSEC in Cloud DNS. The administrator must then wait at least 24 hours for the DS record removal to propagate across all resolver caches worldwide. Only after confirming that resolvers no longer see the DS record can the Cloud DNS zone’s DNSSEC state be safely switched to off.
DNSSEC resolution failures occur primarily when the configuration is mistyped or when an incorrect DS record is published in the parent zone. Administrators can cross-check and validate their DNSSEC deployment before and after registrar updates using diagnostic tools such as:
When DNSSEC validation fails, resolvers reject untrusted responses and return a SERVFAIL status to querying clients. Administrators can inspect DNS query logs in Cloud Logging and query response metrics in Cloud Monitoring to identify error rates and pinpoint whether resolution issues stem from configuration errors, signature validation problems, or network egress issues.
DNSSEC state transitions in Cloud DNS involve moving zones through different security states while maintaining the chain of trust. A zone can exist in three DNSSEC states: off (DNSSEC disabled), on (DNSSEC fully active with automatic key rotation), and transfer (a transitional state used during migration that stops automatic key rotation and allows DNSKEY import). To enable DNSSEC for a managed zone, you use the gcloud dns managed-zones update command with the --dnssec-state on flag, optionally specifying algorithms for both the key signing key (KSK) and zone signing key (ZSK), along with the denial-of-existence type.
When enabling DNSSEC, you must choose signing algorithms and denial-of-existence types that determine how DNS records are cryptographically signed and how the server proves that records do not exist. Cloud DNS supports four algorithms: RSASHA256 (the default for both KSK and ZSK), RSASHA512 (not widely supported), ECDSAP256SHA256 (recommended for smaller response sizes), and ECDSAP384SHA384 (limited support). If you specify any algorithm or key length arguments, you must provide all of them (--ksk-algorithm, --zsk-algorithm, --ksk-key-length, --zsk-key-length). The denial-of-existence type can be either NSEC (smaller responses but no protection against zone walking) or NSEC3 (the default, which provides limited protection against zone enumeration). You should avoid using different algorithms for the KSK and ZSK, as some validating resolvers may fail validation for zones where DNSKEY algorithms are not used to sign all records.
Disabling DNSSEC requires coordination with your domain registrar to prevent validation failures. Before disabling DNSSEC at Cloud DNS, you must first deactivate DNSSEC at your domain registrar to ensure that DNSSEC-validating resolvers can still resolve names in the zone; otherwise, queries will fail because resolvers expect signed responses. The process involves removing the DS record at your registrar, then changing the DNSSEC state to off in Cloud DNS. If you want to change DNSSEC settings (such as algorithms) after DNSSEC is already enabled, you must first disable DNSSEC, make your changes, and then re-enable it.
The transfer state facilitates migrating DNSSEC-signed zones between operators without breaking the chain of trust. Cloud DNS uses the Double-DS KSK rollover variant described in RFC 6781, where both the old and new operators publish signed records for each other’s public keys during the transition. This creates cross-trust such that validating resolvers can use records from either operator to validate responses. To migrate a zone to Cloud DNS, you create a new zone in transfer state, import the zone file without DNSSEC records, retrieve DNSKEY records from both operators, add both sets of DNSKEY records to the new zone, add a second DS record at the registrar, wait for cache expiration, update name server delegations, and then change the state from transfer to on. The zone must not remain in transfer state for more than one to two months. If the new operator does not support migration, you must deactivate DNSSEC at the registrar, perform the transfer, and then re-enable DNSSEC.
Enabling DNSSEC for delegated subdomains requires creating DS records in the parent zone that point to the subdomain’s key signing key. You obtain the DS record by running gcloud dns dns-keys describe for the KEY_SIGNING key (typically ID 0) and using the --format "value(ds_record())" output. Then you add both DS and NS records for the subdomain through a Cloud DNS transaction. The NS record values must match the name server shard assigned to the delegated subdomain, which is visible in the registrar setup dialog. This establishes a secure chain of trust from the parent zone through the DS record to the subdomain’s signed zone.
StudyCerts
StudyCertstransfer state allows migrating a DNSSEC-signed zone between operators without breaking the chain of trust, using the Double-DS KSK rollover variant (RFC 6781), and the zone must not remain in transfer state for more than one to two months.NSEC produces smaller DNS responses but does not protect against zone walking, meaning an attacker can enumerate all records in the zone. NSEC3 is the default in Cloud DNS and provides limited protection against zone walking by hashing record names, but it produces slightly larger responses. Cloud DNS uses fixed NSEC3 parameters: opt-out is disabled, one additional hash iteration, and a 64-bit salt.
Use ECDSA algorithms (ECDSAP256SHA256 or ECDSAP384SHA384) when you want smaller signature sizes, which lead to faster computation and smaller DNS response packets. However, ECDSA is only supported by newer resolver systems, while RSA algorithms like RSASHA256 are widely supported by older resolvers and registries. Using different algorithms for the KSK and ZSK is discouraged because it can cause validation failures with some resolvers.
First, remove all DS records from the parent zone at the domain registrar. Second, wait at least 24 hours for the DS record removal to propagate across all resolver caches. Third, after confirming resolvers no longer see the DS record, switch the Cloud DNS zone’s DNSSEC state to off. If you disable DNSSEC in Cloud DNS before removing the DS record, validating resolvers will fail resolution for the domain.
Prepare and test your skills
Prepare and test your skills