Skip to content
Ask AI about this
Help improve this page

Route 53 domains should have privacy protection enabled

WHOIS records are publicly queryable by anyone on the internet. When privacy protection is disabled, the registrant's personal name, organization, street address, phone number, and email are exposed. This data feeds targeted phishing campaigns, social engineering attacks, and physical security risks. Attackers routinely scrape WHOIS databases to build profiles of infrastructure owners.

Route 53 privacy protection is free for most TLDs and replaces your contact details with those of the registrar's privacy service. Failing to enable it leaves personal contact details visible to anyone running a WHOIS query, with no operational benefit to offset that exposure.

Retrofit consideration

Some TLDs (notably .uk, .ca, and certain ccTLDs) do not support WHOIS privacy through Route 53. Verify TLD eligibility before applying changes.

Implementation

Choose the approach that matches how you manage Terraform.

Use AWS provider resources directly. See docs for the resources involved: aws_route53domains_registered_domain.

resource "aws_route53domains_registered_domain" "this" {
  domain_name = "pofix.click"

  admin_privacy = true
}

What this control checks

The control checks that the aws_route53domains_registered_domain resource has all three privacy arguments set to true: admin_privacy, registrant_privacy, and tech_privacy. In the Terraform AWS provider, these arguments are optional/computed and reflect current AWS domain state, so do not rely on omission as an implicit secure default in policy checks. An explicit false on any one of them causes a failure. A domain passes when all three flags are enabled and WHOIS lookups return the registrar's proxy contact information instead of the actual registrant's details. It fails if any single privacy setting is disabled. The underlying API call is GetDomainDetail, and the corresponding fields are AdminPrivacy, RegistrantPrivacy, and TechPrivacy.

Common pitfalls

  • Unsupported TLDs silently ignored

    Setting admin_privacy = true on an aws_route53domains_registered_domain for .uk, .ca, .de, or other unsupported ccTLDs may be silently rejected or ignored by the registry, with no error surfaced in Terraform. Check TLD support in the Route 53 documentation before assuming the setting applies, and track unsupported TLDs as documented exceptions rather than letting them fail policy checks indefinitely.

  • Defaults mask intent

    The admin_privacy, registrant_privacy, and tech_privacy arguments are often omitted in Terraform configurations and inherited from current AWS state. An imported domain with no explicit privacy arguments can appear compliant until someone adds admin_privacy = false during a refactor, at which point the regression is easy to miss in review. Set all three explicitly to true to make intent clear and prevent accidental drift.

  • Transferred domains may lose privacy

    Domains transferred into Route 53 do not automatically inherit privacy protection. After an aws_route53domains_registered_domain import, run terraform plan to verify that the three privacy flags reflect the desired state. The transfer process can reset them depending on the previous registrar's configuration.

  • GDPR redaction confused with privacy protection

    European registries may redact WHOIS data under GDPR regardless of Route 53's privacy protection setting. This leads teams to assume the control is met when RegistrantPrivacy is still false in the API. Always verify the Route 53 domain detail directly rather than relying on a WHOIS lookup alone.

Audit evidence

An auditor expects to see the output of aws route53domains get-domain-detail --domain-name <domain> showing AdminPrivacy, RegistrantPrivacy, and TechPrivacy all set to true for every domain registered through Route 53. Findings from a CSPM tool, IaC policy checks, or a custom AWS Config rule work as continuous compliance evidence. A WHOIS lookup confirming that contact fields show redacted or proxy data reinforces this.

For domains using TLDs that do not support privacy protection, the auditor should see a documented exception with a risk acceptance noting why the contact information cannot be hidden and any compensating controls in place (such as using a role-based email address and a registered agent address rather than personal details).

Framework-specific interpretation

Tool mappings

Use these identifiers to cross-reference this control across tools, reports, and evidence.

  • Compliance.tf Control: route53_domain_privacy_protection_enabled

  • Powerpipe Control: aws_compliance.control.route53_domain_privacy_protection_enabled

  • Prowler Check: route53_domains_privacy_protection_enabled

Last reviewed: 2026-03-09