Domain Name Systems (DNS) are vulnerable by default to various types of attacks.

One of the biggest risks is DNS cache poisoning, which occurs when a DNS accepts spoofed DNS data, caches the malicious records, and potentially sends them later in response to legitimate DNS request lookups. This attack typically relies on the attacker’s MITM ability on the network and can be used to redirect users from an intended website to a malicious website.

To prevent these vulnerabilities, Domain Name System Security Extensions (DNSSEC) ensure the integrity and authenticity of DNS data by digitally signing DNS zones.

The public key of a DNS zone used to validate signatures can be trusted as DNSSEC is based on the following chain of trust:

Ask Yourself Whether

The parent DNS zone (likely managed by the DNS registrar of the domain name) supports DNSSEC and

There is a risk if you answered yes to this question.

Recommended Secure Coding Practices

It’s recommended to use DNSSEC when creating private and public DNS zones.

Private DNS zones cannot be queried on the Internet and provide DNS name resolution for private networks. The risk of MITM attacks might be considered low on these networks and therefore implementing DNSSEC is still recommended but not with a high priority.

Note: Choose a robust signing algorithm when setting up DNSSEC, such as rsasha256. The insecure rsasha1 algorithm should no longer be used.

Sensitive Code Example

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

Compliant Solution

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

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

See