
* Add check for security standard mismatch * Fix security standard mismatches * Fix Resources/Standards links for secrets rules * Fix check * Fix links and update security standard mapping * Fix maintanability issue * Apply review suggestions * Apply suggestions from code review Co-authored-by: Egon Okerman <egon.okerman@sonarsource.com> * Fix typo Co-authored-by: Egon Okerman <egon.okerman@sonarsource.com> --------- Co-authored-by: Egon Okerman <egon.okerman@sonarsource.com>
75 lines
2.7 KiB
Plaintext
75 lines
2.7 KiB
Plaintext
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 https://en.wikipedia.org/wiki/Man-in-the-middle_attack[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:
|
|
|
|
* The parent DNS zone adds a "fingerprint" of the public key of the child zone in a "DS record".
|
|
* The parent DNS zone signs it with its own private key.
|
|
* And this process continues until the root zone.
|
|
|
|
|
|
== Ask Yourself Whether
|
|
|
|
The parent DNS zone (likely managed by the DNS registrar of the domain name) supports DNSSEC and
|
|
|
|
* The DNS zone is public (contains data such as public reachable IP addresses).
|
|
|
|
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 https://en.wikipedia.org/wiki/SHA-1[insecure] `rsasha1` algorithm should no longer be used.
|
|
|
|
|
|
== Sensitive Code Example
|
|
[source,terraform]
|
|
----
|
|
resource "google_dns_managed_zone" "example" { # Sensitive: dnssec_config is missing
|
|
name = "foobar"
|
|
dns_name = "foo.bar."
|
|
}
|
|
----
|
|
|
|
== Compliant Solution
|
|
[source,terraform]
|
|
----
|
|
resource "google_dns_managed_zone" "example" {
|
|
name = "foobar"
|
|
dns_name = "foo.bar."
|
|
|
|
dnssec_config {
|
|
default_key_specs {
|
|
algorithm = "rsasha256"
|
|
}
|
|
}
|
|
}
|
|
----
|
|
|
|
== See
|
|
|
|
* https://cloud.google.com/dns/docs/dnssec-config[GCP Documentation] - Manage DNSSEC configuration
|
|
* CWE - https://cwe.mitre.org/data/definitions/345[CWE-345 - Insufficient Verification of Data Authenticity]
|
|
* CWE - https://cwe.mitre.org/data/definitions/353[CWE-353 - Missing Support for Integrity Check]
|
|
|
|
|
|
ifdef::env-github,rspecator-view[]
|
|
|
|
'''
|
|
== Implementation Specification
|
|
(visible only on this page)
|
|
|
|
=== Message
|
|
|
|
Make sure creating a DNS zone without DNSSEC enabled is safe here.
|
|
|
|
|
|
endif::env-github,rspecator-view[]
|