Fix GCP DNSSEC RSASHA1 Deprecated Algorithm

TL;DR

This check flags GCP Cloud DNS zones that sign records with the deprecated RSASHA1 algorithm for DNSSEC. RSASHA1 relies on SHA-1, which is cryptographically broken, weakening the chain of trust that DNSSEC exists to protect. Fix it by recreating the zone's DNSSEC config with a modern algorithm like RSASHA256 or ECDSAP256SHA256.

DNSSEC is supposed to be the thing that stops attackers from forging DNS answers and silently redirecting your users to a server they control. It does that by signing your DNS records with a private key, so resolvers can verify the answer hasn't been tampered with. But a signature is only as trustworthy as the algorithm behind it. If you signed your zone with RSASHA1, you built that trust on SHA-1, a hash function that has been demonstrably broken for years.

The dns_rsasha1 check looks at the DNSSEC configuration of your GCP Cloud DNS managed zones and reports any zone whose key signing key (KSK) or zone signing key (ZSK) uses the rsasha1 algorithm.

What this check detects

Cloud DNS lets you enable DNSSEC on a managed zone and choose the algorithm used to generate the signing keys. The available algorithms include RSASHA1, RSASHA256, RSASHA512, ECDSAP256SHA256, and ECDSAP384SHA384. This check inspects the dnssecConfig.defaultKeySpecs on each zone and fails if any key spec is set to rsasha1.

In practice, a flagged zone looks like this when you describe it:

gcloud dns managed-zones describe example-zone --format="json(dnssecConfig)"

{
  "dnssecConfig": {
    "defaultKeySpecs": [
      {
        "algorithm": "rsasha1",
        "keyLength": 2048,
        "keyType": "keySigning",
        "kind": "dns#dnsKeySpec"
      },
      {
        "algorithm": "rsasha1",
        "keyLength": 1024,
        "keyType": "zoneSigning",
        "kind": "dns#dnsKeySpec"
      }
    ],
    "kind": "dns#managedZoneDnsSecConfig",
    "nonExistence": "nsec3",
    "state": "on"
  }
}

If you see "algorithm": "rsasha1" in either key spec, the zone is affected.

Note: DNSSEC uses two key types. The key signing key (KSK) signs the DNSKEY record set and is the key referenced by your DS record at the parent zone. The zone signing key (ZSK) signs the actual resource records. Both need to use a strong algorithm, because a weak KSK undermines the entire chain even if the ZSK is strong.

Why it matters

SHA-1 collision attacks moved from theoretical to practical in 2017 with the SHAttered research, and chosen-prefix collisions followed in 2020, bringing the cost of an attack down to a few tens of thousands of dollars. For a hash function that underpins a security control, that is well past the point of acceptable.

The whole point of DNSSEC is to give resolvers a cryptographic guarantee that a DNS answer is authentic. RSASHA1 weakens that guarantee in a few concrete ways:

Forgery risk. A weak signing algorithm makes it more feasible for an attacker to craft a forged record that passes validation, which is the exact attack DNSSEC is meant to prevent.
Cache poisoning that survives validation. If an attacker can produce a record that validates, they can redirect traffic for your domain to infrastructure they control, capturing credentials, intercepting email via forged MX records, or serving malware.
Compliance failures. SHA-1 is deprecated by NIST (SP 800-131A) and disallowed in many compliance regimes. A DNSSEC zone signed with RSASHA1 is an easy finding in an audit.
Resolver behavior drift. As resolvers tighten their algorithm support, RSASHA1 signatures may eventually be treated as insecure or bogus, which can break resolution for validating clients.

Warning: A common failure mode is enabling DNSSEC, ticking the compliance box, and never checking the algorithm. A zone with RSASHA1 gives you the operational overhead of DNSSEC with a meaningfully weaker security guarantee, which is the worst of both worlds.

How to fix it

Cloud DNS does not let you change the algorithm on a zone with DNSSEC already enabled. You have to turn DNSSEC off, set the new key specs, then turn it back on. Because turning DNSSEC off temporarily breaks the chain of trust, and changing keys means rotating the DS record at the parent, you need to sequence this carefully to avoid a resolution outage.

Danger: Disabling DNSSEC and re-enabling with new keys changes your DNSKEY and therefore your DS record. If your registrar's DS record points at the old key while the zone is signed with a new one, validating resolvers will return SERVFAIL for your domain. Do not remove the old DS record at the registrar until the new keys are live and propagated.

Step 1: Confirm the current state

gcloud dns managed-zones describe example-zone \
  --format="json(dnssecConfig)"

Step 2: Turn off DNSSEC on the zone

gcloud dns managed-zones update example-zone \
  --dnssec-state off

Wait for this to settle before the next step. The zone is now unsigned.

Step 3: Re-enable DNSSEC with a modern algorithm

The simplest approach is to let Cloud DNS use its current default key specs, which are RSASHA256, by re-enabling DNSSEC with the on state:

gcloud dns managed-zones update example-zone \
  --dnssec-state on

If you want to explicitly set the algorithm and key lengths, define the key specs directly. ECDSAP256SHA256 is a strong, compact choice that produces smaller signatures than RSA:

gcloud dns managed-zones update example-zone \
  --dnssec-state on \
  --ksk-algorithm ecdsap256sha256 \
  --ksk-key-length 256 \
  --zsk-algorithm ecdsap256sha256 \
  --zsk-key-length 256

For an RSA-based option that maximizes resolver compatibility, use RSASHA256:

gcloud dns managed-zones update example-zone \
  --dnssec-state on \
  --ksk-algorithm rsasha256 \
  --ksk-key-length 2048 \
  --zsk-algorithm rsasha256 \
  --zsk-key-length 1024

Note: ECDSAP256SHA256 is widely supported by modern validating resolvers and produces much smaller DNSKEY and RRSIG records, which helps avoid DNS over UDP fragmentation issues. RSASHA256 is the more conservative pick if you need to support older resolvers. Both are acceptable. Neither uses SHA-1.

Step 4: Get the new DS record

After re-enabling DNSSEC, retrieve the new DS record from the KSK so you can update it at your registrar:

gcloud dns dns-keys list \
  --zone example-zone \
  --filter="type=keySigning" \
  --format="json(keyTag,digests,algorithm)"

Take the digest and key tag and submit the new DS record to whichever registrar or parent zone holds your domain. The exact field format varies by registrar, but you'll typically provide the key tag, algorithm number, digest type, and digest value.

Step 5: Verify the chain of trust

Once the new DS record has propagated, validate end to end:

dig +dnssec example.com SOA @8.8.8.8

delv example.com @8.8.8.8

Look for the ad (authenticated data) flag in the dig output and a "fully validated" line from delv. If you see SERVFAIL, the DS record at the parent likely does not match the live KSK yet.

Tip: Use the DNSViz visualizer to inspect the full delegation chain for your domain. It clearly shows mismatched DS records, algorithm details, and validation breaks across every level, which makes debugging a botched rotation far faster than reading dig output by hand.

Fixing it with Terraform

If you manage Cloud DNS with Terraform, set the algorithm explicitly in the dnssec_config block so the correct algorithm is enforced from the start:

resource "google_dns_managed_zone" "example" {
  name     = "example-zone"
  dns_name = "example.com."

  dnssec_config {
    state         = "on"
    non_existence = "nsec3"

    default_key_specs {
      algorithm  = "ecdsap256sha256"
      key_length = 256
      key_type   = "keySigning"
    }

    default_key_specs {
      algorithm  = "ecdsap256sha256"
      key_length = 256
      key_type   = "zoneSigning"
    }
  }
}

Warning: Changing default_key_specs on an existing zone forces Terraform to disable and re-enable DNSSEC, which rotates your keys and DS record. Plan the change during a maintenance window and coordinate the registrar DS update, the same as you would with the CLI flow above. Run terraform plan first and read the diff carefully.

How to prevent it from coming back

The reason RSASHA1 zones exist at all is usually that DNSSEC was enabled years ago when defaults were different, or it was copied from an old template. Stop both with guardrails.

Enforce the algorithm in policy-as-code

If you use OPA or Conftest against your Terraform plans, reject any zone that uses rsasha1:

package dns.dnssec

deny[msg] {
  resource := input.resource_changes[_]
  resource.type == "google_dns_managed_zone"
  spec := resource.change.after.dnssec_config[_].default_key_specs[_]
  spec.algorithm == "rsasha1"
  msg := sprintf("Zone %s uses deprecated RSASHA1 for DNSSEC", [resource.name])
}

Add a CI/CD gate

Run that policy in your pipeline before any DNS change is applied:

terraform plan -out=plan.tfplan
terraform show -json plan.tfplan > plan.json
conftest test plan.json --policy policy/

Audit existing zones on a schedule

Sweep every project for RSASHA1 zones so legacy configs don't sit unnoticed:

for project in $(gcloud projects list --format="value(projectId)"); do
  for zone in $(gcloud dns managed-zones list --project="$project" --format="value(name)"); do
    algo=$(gcloud dns managed-zones describe "$zone" --project="$project" \
      --format="value(dnssecConfig.defaultKeySpecs[].algorithm)" 2>/dev/null)
    if echo "$algo" | grep -q "rsasha1"; then
      echo "RSASHA1 found: project=$project zone=$zone"
    fi
  done
done

Tip: Lensix runs the dns_rsasha1 check continuously across all of your connected GCP projects, so you don't have to maintain the loop above or remember to run it. New zones that get created with a weak algorithm surface as a finding automatically, well before an auditor or attacker finds them.

Best practices for Cloud DNS and DNSSEC

Default to ECDSAP256SHA256 for new zones. Smaller signatures, strong security, and broad modern resolver support. Use RSASHA256 only when you have a specific compatibility requirement.
Never use RSASHA1 or any SHA-1 based algorithm for signing, anywhere in your stack.
Keep DS records in sync. A correct algorithm means nothing if your registrar's DS record points at the wrong key. Validate after every key change.
Use NSEC3 over NSEC to avoid zone walking, which lets attackers enumerate every record in your zone.
Monitor for SERVFAIL spikes after any DNSSEC change. A jump in validation failures is the clearest signal that a rotation went wrong.
Treat DNSSEC changes like a deployment. Plan, stage, verify, and have a rollback path. The blast radius of a broken chain of trust is your entire domain.

RSASHA1 is a quiet liability. The fix is a one-time rotation, and once you put the policy gate and continuous check in place, it stays fixed.

DNSSEC Uses Deprecated RSASHA1 in GCP Cloud DNS