DNS zones should have DNSSEC enabled to protect against DNS cache poisoning and man-in-the-middle attacks.

Why is this an issue?

Domain Name System Security Extensions (DNSSEC) protect against DNS cache poisoning by ensuring the integrity and authenticity of DNS data through digital signatures. Without DNSSEC, an attacker with man-in-the-middle capability on the network can inject spoofed DNS records, causing users to be redirected from intended websites to malicious ones. DNSSEC is based on a chain of trust: each parent DNS zone signs a fingerprint of the child zone’s public key, continuing up to the root zone. This rule raises an issue when a google_dns_managed_zone resource is created without a dnssec_config block.

What is the potential impact?

User redirection and data interception

An attacker who can poison a DNS cache may redirect users from legitimate websites to malicious ones, enabling phishing attacks or interception of sensitive data such as login credentials. This attack can affect any user whose DNS resolver has cached the spoofed record, potentially at a large scale.

How to fix it

Enable DNSSEC by adding a dnssec_config block to the DNS managed zone resource. Choose a robust signing algorithm such as rsasha256; the insecure rsasha1 algorithm should no longer be used.

Code examples

The following code does not configure DNSSEC, leaving DNS records unsigned and exposed to spoofing.

Noncompliant code example

resource "google_dns_managed_zone" "example" { # Noncompliant: dnssec_config is missing
  name     = "foobar"
  dns_name = "foo.example.com."
}

Compliant solution

resource "google_dns_managed_zone" "example" {
  name     = "foobar"
  dns_name = "foo.example.com."

  dnssec_config {
    state = "on"
    default_key_specs {
      algorithm = "rsasha256"
    }
  }
}

Resources

Documentation

Standards