Skip to main content

⭐ Repository → 📁 Compliance Engine → 📁 CloudAware → 📁 Google → 📁 Cloud DNS

🛡️ Google Cloud DNS Managed Zone DNSSEC Key-Signing Algorithm is RSASHA1🟢

Logic​

Similar Policies​

Description​

Open File

Description​

NOTE: Currently, the SHA1 algorithm has been removed from general use by Google, and, if being used, needs to be whitelisted on a project basis by Google and will also, therefore, require a Google Cloud support contract.

DNSSEC algorithm numbers in this registry may be used in CERT RRs. Zone signing (DNSSEC) and transaction security mechanisms (SIG(0) and TSIG) make use of particular subsets of these algorithms. The algorithm used for key signing should be a recommended one and it should be strong.

Rationale​

Domain Name System Security Extensions (DNSSEC) algorithm numbers in this registry may be used in CERT RRs. Zonesigning (DNSSEC) and transaction security mechanisms (SIG(0) and TSIG) make use of particular subsets of these algorithms.

The algorithm used for key signing should be a recommended one and it should be strong. When enabling DNSSEC for a managed zone, or creating a managed zone with DNSSEC, the user can select the DNSSEC signing algorithms and the denial-of-existence type. Changing the DNSSEC settings is only effective for a managed zone if DNSSEC is not already enabled. If there is a need to change the settings for a managed zone where it has been enabled, turn DNSSEC off and then re-enable it with different settings.

... see more

Remediation​

Open File

Remediation​

From Google Cloud CLI​

  1. If it is necessary to change the settings for a managed zone where it has been enabled, DNSSEC must be turned off and re-enabled with different settings. To turn off DNSSEC, run the following command:

         gcloud dns managed-zones update ZONE_NAME --dnssec-state off

  2. To update key-signing for a reported managed DNS Zone, run the following command:

         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

Supported algorithm options and key lengths are as follows.

        Algorithm           KSK Length          ZSK Length 
        ---------           ----------          ---------- 
        RSASHA1             1024,2048           1024,2048 
        RSASHA256           1024,2048           1024,2048 
        RSASHA512           1024,2048           1024,2048 
        ECDSAP256SHA256     256                 256

... see more

policy.yaml​

Open File

Linked Framework Sections​

SectionSub SectionsInternal RulesPoliciesFlagsCompliance
💼 CIS GCP v1.2.0 → 💼 3.4 Ensure that RSASHA1 is not used for the key-signing key in Cloud DNS DNSSEC - Level 1 (Manual)1no data
💼 CIS GCP v1.3.0 → 💼 3.4 Ensure That RSASHA1 Is Not Used for the Key-Signing Key in Cloud DNS DNSSEC - Level 1 (Manual)1no data
💼 CIS GCP v2.0.0 → 💼 3.4 Ensure That RSASHA1 Is Not Used for the Key-Signing Key in Cloud DNS DNSSEC - Level 1 (Automated)1no data
💼 CIS GCP v3.0.0 → 💼 3.4 Ensure That RSASHA1 Is Not Used for the Key-Signing Key in Cloud DNS DNSSEC - Level 1 (Automated)1no data
💼 Cloudaware Framework → 💼 Cryptographic Configuration8no data
💼 FedRAMP High Security Controls → 💼 AC-18 Wireless Access (L)(M)(H)45no data
💼 FedRAMP High Security Controls → 💼 CM-2 Baseline Configuration (L)(M)(H)3126no data
💼 FedRAMP High Security Controls → 💼 CM-6 Configuration Settings (L)(M)(H)212no data
💼 FedRAMP High Security Controls → 💼 CM-7 Least Functionality (L)(M)(H)31833no data
💼 FedRAMP High Security Controls → 💼 CM-9 Configuration Management Plan (M)(H)8no data
💼 FedRAMP Low Security Controls → 💼 AC-18 Wireless Access (L)(M)(H)5no data
💼 FedRAMP Low Security Controls → 💼 CM-2 Baseline Configuration (L)(M)(H)25no data
💼 FedRAMP Low Security Controls → 💼 CM-6 Configuration Settings (L)(M)(H)11no data
💼 FedRAMP Low Security Controls → 💼 CM-7 Least Functionality (L)(M)(H)29no data
💼 FedRAMP Moderate Security Controls → 💼 AC-18 Wireless Access (L)(M)(H)25no data
💼 FedRAMP Moderate Security Controls → 💼 CM-2 Baseline Configuration (L)(M)(H)326no data
💼 FedRAMP Moderate Security Controls → 💼 CM-6 Configuration Settings (L)(M)(H)112no data
💼 FedRAMP Moderate Security Controls → 💼 CM-7 Least Functionality (L)(M)(H)333no data
💼 FedRAMP Moderate Security Controls → 💼 CM-9 Configuration Management Plan (M)(H)8no data
💼 ISO/IEC 27001:2022 → 💼 8.9 Configuration management12no data
💼 NIST CSF v1.1 → 💼 PR.IP-1: A baseline configuration of information technology/industrial control systems is created and maintained incorporating security principles (e.g. concept of least functionality)426no data
💼 NIST CSF v2.0 → 💼 DE.CM-09: Computing hardware and software, runtime environments, and their data are monitored to find potentially adverse events137no data
💼 NIST CSF v2.0 → 💼 ID.AM-08: Systems, hardware, software, services, and data are managed throughout their life cycles21no data
💼 NIST CSF v2.0 → 💼 PR.AA-05: Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of duties91no data
💼 NIST SP 800-53 Revision 5 → 💼 AC-18 Wireless Access55no data
💼 NIST SP 800-53 Revision 5 → 💼 CM-2 Baseline Configuration725no data
💼 NIST SP 800-53 Revision 5 → 💼 CM-6 Configuration Settings412no data
💼 NIST SP 800-53 Revision 5 → 💼 CM-7 Least Functionality923no data
💼 NIST SP 800-53 Revision 5 → 💼 CM-9 Configuration Management Plan18no data
💼 PCI DSS v3.2.1 → 💼 1.1 Establish and implement firewall and router configuration standards7139no data
💼 PCI DSS v3.2.1 → 💼 1.1.6 Documentation of business justification and approval for use of all services, protocols, and ports allowed, including documentation of security features implemented for those protocols considered to be insecure.127no data
💼 PCI DSS v3.2.1 → 💼 1.1.7 Requirement to review firewall and router rule sets at least every six months.9no data
💼 PCI DSS v3.2.1 → 💼 1.3.1 Implement a DMZ to limit inbound traffic to only system components that provide authorized publicly accessible services, protocols, and ports.619no data
💼 PCI DSS v3.2.1 → 💼 1.3.2 Limit inbound Internet traffic to IP addresses within the DMZ.19no data
💼 PCI DSS v3.2.1 → 💼 1.3.5 Permit only “established” connections into the network.19no data
💼 PCI DSS v3.2.1 → 💼 1.4 Install personal firewall software or equivalent functionality on any portable computing devices that connect to the Internet when outside the network, and which are also used to access the CDE.8no data
💼 PCI DSS v3.2.1 → 💼 1.5 Ensure that security policies and operational procedures for managing firewalls are documented, in use, and known to all affected parties.8no data
💼 PCI DSS v3.2.1 → 💼 2.2 Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards.5330no data
💼 PCI DSS v3.2.1 → 💼 2.5 Ensure that security policies and operational procedures for managing vendor defaults and other security parameters are documented, in use, and known to all affected parties.8no data
💼 PCI DSS v4.0.1 → 💼 1.1.1 All security policies and operational procedures identified in Requirement 1 are documented, kept up to date, in use, and known to all affected parties.8no data
💼 PCI DSS v4.0.1 → 💼 1.2.1 Configuration standards for NSC rulesets are defined, implemented, maintained.34no data
💼 PCI DSS v4.0.1 → 💼 1.2.5 All services, protocols, and ports allowed are identified, approved, and have a defined business need.27no data
💼 PCI DSS v4.0.1 → 💼 1.2.6 Security features are defined and implemented for all services, protocols, and ports that are in use and considered to be insecure, such that the risk is mitigated.27no data
💼 PCI DSS v4.0.1 → 💼 1.2.7 Configurations of NSCs are reviewed at least once every six months to confirm they are relevant and effective.9no data
💼 PCI DSS v4.0.1 → 💼 1.4.2 Inbound traffic from untrusted networks to trusted networks is restricted.19no data
💼 PCI DSS v4.0.1 → 💼 1.5.1 Security controls are implemented on any computing devices, including company- and employee-owned devices, that connect to both untrusted networks and the CDE.8no data
💼 PCI DSS v4.0.1 → 💼 2.1.1 All security policies and operational procedures identified in Requirement 2 are documented, kept up to date, in use, and known to all affected parties.8no data
💼 PCI DSS v4.0.1 → 💼 2.2.1 Configuration standards are developed, implemented, and maintained.11no data
💼 PCI DSS v4.0 → 💼 1.1.1 All security policies and operational procedures identified in Requirement 1 are documented, kept up to date, in use, and known to all affected parties.8no data
💼 PCI DSS v4.0 → 💼 1.2.1 Configuration standards for NSC rulesets are defined, implemented, maintained.2434no data
💼 PCI DSS v4.0 → 💼 1.2.5 All services, protocols, and ports allowed are identified, approved, and have a defined business need.1527no data
💼 PCI DSS v4.0 → 💼 1.2.6 Security features are defined and implemented for all services, protocols, and ports that are in use and considered to be insecure, such that the risk is mitigated.627no data
💼 PCI DSS v4.0 → 💼 1.2.7 Configurations of NSCs are reviewed at least once every six months to confirm they are relevant and effective.9no data
💼 PCI DSS v4.0 → 💼 1.4.2 Inbound traffic from untrusted networks to trusted networks is restricted.719no data
💼 PCI DSS v4.0 → 💼 1.5.1 Security controls are implemented on any computing devices, including company- and employee-owned devices, that connect to both untrusted networks and the CDE.8no data
💼 PCI DSS v4.0 → 💼 2.1.1 All security policies and operational procedures identified in Requirement 2 are documented, kept up to date, in use, and known to all affected parties.8no data
💼 PCI DSS v4.0 → 💼 2.2.1 Configuration standards are developed, implemented, and maintained.11no data
💼 SOC 2 → 💼 CC5.2-2 Establishes Relevant Technology Infrastructure Control Activities7no data