# 3.4 Ensure That RSASHA1 Is Not Used for the Key-Signing Key in Cloud DNS DNSSEC (Automated) - Source: https://support.icompaas.com/support/solutions/articles/62000233008-3-4-ensure-that-rsasha1-is-not-used-for-the-key-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: It is recommended to avoid using the RSASHA1 algorithm for the key-signing key in Cloud DNS DNSSEC, as this algorithm is deprecated due to its weaker security strength. If RSASHA1 is in use, it requires explicit whitelisting by Google, along with an active Google Cloud support contract. ### Rationale: The RSASHA1 algorithm is no longer considered secure for DNSSEC key-signing due to advances in cryptographic analysis and computational power. Instead, stronger algorithms such as RSASHA256, RSASHA512, or ECDSA should be used to ensure secure domain name resolution and to protect against attacks such as DNS spoofing and cache poisoning. When enabling DNSSEC or creating a DNS zone with DNSSEC, users can choose stronger algorithms for key-signing and zone-signing. If RSASHA1 is already in use, DNSSEC settings must be updated to use a stronger algorithm. ### Default Value: By default, RSASHA1 is not used unless explicitly configured. ### Audit Steps: #### Using Google Cloud CLI: Describe the DNS zone: gcloud dns managed-zones describe ZONE\_NAME --format="json(dnsName,dnssecConfig.state,dnssecConfig.defaultKeySpecs)" 1. Verify that the algorithm property for keyType: keySigning is not set to RSASHA1. ### Remediation Steps: #### Using Google Cloud CLI: If DNSSEC is already enabled for the zone, turn it off: gcloud dns managed-zones update ZONE\_NAME --dnssec-state off Update the DNS zone with a stronger key-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. The RSASHA1 algorithm may only be required for legacy or compatibility reasons. 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.