# 3.5 Ensure That RSASHA1 Is Not Used for the Zone-Signing Key in Cloud DNS DNSSEC (Automated) - Source: https://support.icompaas.com/support/solutions/articles/62000233009-3-5-ensure-that-rsasha1-is-not-used-for-the-zone-signing-key-in-cloud-dns-dnssec-automated- - Section: [Solutions](https://support.icompaas.com/support/solutions) › [GCP Benchmarks](https://support.icompaas.com/support/solutions/62000112667) › [GCP Knowledge Bases](https://support.icompaas.com/support/solutions/folders/62000169178) - Last updated: 2026-05-29 - Publisher: iCompaas, Inc. (https://www.icompaas.com) ### Profile Applicability: Level 1 ### Description: The RSASHA1 algorithm has been deprecated and removed from general use by Google. If still in use, it requires explicit whitelisting by Google and a support contract. Zone-signing algorithms should be strong and follow recommended security practices to ensure the integrity of DNSSEC-protected zones. ### Rationale: Using RSASHA1 for zone-signing poses significant security risks as it is considered cryptographically weak. Stronger algorithms like RSASHA256, RSASHA512, or ECDSA should be used for zone-signing to prevent potential attacks like DNS spoofing or cache poisoning. To update an existing DNSSEC-enabled managed zone with a stronger algorithm, DNSSEC must first be disabled and then reconfigured. ### Default Value: By default, RSASHA1 is not used unless explicitly configured. ### Audit Steps: #### Using Google Cloud CLI: Describe the DNS zone to review the algorithm used for zone-signing: gcloud dns managed-zones describe ZONE\_NAME \\ --format="json(dnsName,dnssecConfig.state,dnssecConfig.defaultKeySpecs)" 1. Confirm that the property algorithm for keyType: zoneSigning is not set to RSASHA1. ### Remediation Steps: #### Using Google Cloud CLI: If DNSSEC is already enabled, turn it off: gcloud dns managed-zones update ZONE\_NAME --dnssec-state off Re-enable DNSSEC with a stronger zone-signing algorithm: gcloud dns managed-zones update ZONE\_NAME \\ --dnssec-state on \\ --ksk-algorithm KSK\_ALGORITHM \\ --ksk-key-length KSK\_KEY\_LENGTH \\ --zsk-algorithm ZSK\_ALGORITHM \\ --zsk-key-length ZSK\_KEY\_LENGTH \\ --denial-of-existence DENIAL\_OF\_EXISTENCE 1. Replace placeholders with appropriate values: - KSK\_ALGORITHM: RSASHA256, RSASHA512, ECDSAP256SHA256, ECDSAP384SHA384 - KSK\_KEY\_LENGTH: 1024, 2048 (for RSA-based algorithms), or 256, 384 (for ECDSA-based algorithms) - ZSK\_ALGORITHM: Same options as KSK\_ALGORITHM - ZSK\_KEY\_LENGTH: Same options as KSK\_KEY\_LENGTH - DENIAL\_OF\_EXISTENCE: nsec or nsec3 ### References: 1. [Google Cloud: DNSSEC Advanced Options](https://cloud.google.com/dns/dnssec-advanced#advanced_signing_options) ### Additional Information: 1. RSASHA1 may still be required for legacy systems or compatibility. 2. The remediation commands require gcloud CLI version 221.0.0 or later. ### CIS Controls:

Control

Description

IG 1

IG 2

IG 3

4.2 Secure Configuration for Network Devices

Maintain secure configuration standards for network devices and review them annually or after major changes.

✅

✅

✅

11.1 Standard Security Configurations

Ensure that all authorized network devices follow secure and documented configurations.

✅

✅


## Related compliance guidance - [SOC 2 compliance: a practical implementation guide for cloud-native SaaS teams](https://support.icompaas.com/compliance/soc-2-trust-services-criteria): Configuration checks like this one are the technical half of a SOC 2 / ISO 27001 programme — the guide shows where they fit, what else an auditor expects, and how to evidence them. - [ISO/IEC 27001:2022 compliance: a practical implementation guide](https://support.icompaas.com/compliance/iso-27001-2022): ISO 27001 Annex A.8 (technological controls) is where cloud hardening evidence lands; the guide shows how to run the ISMS around it.