Route 53 Security: IAM Policies and Network Security

Route 53 Security: IAM Policies and Network Security

Amazon Route 53 is a highly available and scalable cloud DNS web service designed to route end users to internet applications. Because Route 53 sits at the heart of how users reach your infrastructure, securing it is critical. A compromised Route 53 configuration can redirect traffic to malicious endpoints, expose internal services, or take down production applications entirely. This tutorial covers the two primary pillars of Route 53 security: IAM policies that control who can manage DNS records, and network security controls that protect DNS resolution and traffic routing.

Why Route 53 Security Matters

DNS is often described as the phonebook of the internet, but in cloud architectures it is much more than that. Route 53 integrates with health checks, traffic policies, failover routing, and alias records that point to load balancers, CloudFront distributions, and S3 buckets. An attacker with write access to your hosted zones could:

• Redirect your domain to a phishing site by modifying A or CNAME records
• Subdomain takeover by pointing dangling records to attacker-controlled resources
• Disable health checks to break failover behavior
• Enumerate internal infrastructure through DNS queries
• Modify DNSSEC signing keys to invalidate your zone

Because DNS changes propagate globally and are cached by resolvers, a malicious change can be difficult to reverse quickly. Prevention through strong IAM policies and network controls is far more effective than reactive remediation.

Understanding Route 53 IAM Policies

AWS Identity and Access Management (IAM) lets you control who can authenticate and what actions they can perform on Route 53 resources. Route 53 supports both identity-based policies (attached to users, groups, or roles) and resource-based policies for certain operations. Most Route 53 security is enforced through identity-based policies.

Key Route 53 IAM Actions

Route 53 exposes a wide range of API actions. The most security-sensitive ones include:

• route53:ChangeResourceRecordSets — modifies DNS records in a hosted zone
• route53:ChangeTagsForResource — modifies tags on hosted zones or health checks
• route53:CreateHostedZone — creates new hosted zones
• route53:DeleteHostedZone — deletes hosted zones
• route53:UpdateHealthCheck — modifies health check configuration
• route53:AssociateVPCWithHostedZone — links private hosted zones to VPCs
• route53:TestDNSAnswer — queries DNS answers, useful for reconnaissance

Read-Only Policy for DNS Administrators

A common starting point is a read-only policy that lets engineers inspect DNS configuration without making changes. This is useful for developers who need to troubleshoot routing issues but should not modify records.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Route53ReadOnly",
      "Effect": "Allow",
      "Action": [
        "route53:Get*",
        "route53:List*",
        "route53:TestDNSAnswer"
      ],
      "Resource": "*"
    }
  ]
}

Scoped Write Access to a Single Hosted Zone

For teams that need to manage records in a specific hosted zone, you can scope permissions using the hosted zone ARN. This follows the principle of least privilege by limiting write access to only the zone the team owns.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowReadOnAllZones",
      "Effect": "Allow",
      "Action": [
        "route53:List*",
        "route53:Get*"
      ],
      "Resource": "*"
    },
    {
      "Sid": "AllowWriteOnSpecificZone",
      "Effect": "Allow",
      "Action": [
        "route53:ChangeResourceRecordSets",
        "route53:ListResourceRecordSets"
      ],
      "Resource": "arn:aws:route53:::hostedzone/Z1D633PEXAMPLE"
    }
  ]
}

Note that ListHostedZonesByName and similar list operations do not support resource-level permissions, which is why the read statement uses "Resource": "*". This is a known Route 53 limitation.

Preventing Deletion of Hosted Zones

Deleting a hosted zone is a destructive action that can take an entire domain offline. You can explicitly deny deletion while still allowing record modifications:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyZoneDeletion",
      "Effect": "Deny",
      "Action": [
        "route53:DeleteHostedZone"
      ],
      "Resource": "*"
    },
    {
      "Sid": "AllowRecordManagement",
      "Effect": "Allow",
      "Action": [
        "route53:ChangeResourceRecordSets",
        "route53:ListResourceRecordSets",
        "route53:GetHostedZone",
        "route53:ListHostedZones"
      ],
      "Resource": "*"
    }
  ]
}

Restricting Record Types with Conditions

You can use the route53:ChangeResourceRecordSetsRecordTypes condition key to restrict which record types a principal can create or modify. For example, you might allow only CNAME and TXT records for a certificate validation team, preventing them from altering A records that route production traffic.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowOnlyCertValidationRecords",
      "Effect": "Allow",
      "Action": "route53:ChangeResourceRecordSets",
      "Resource": "arn:aws:route53:::hostedzone/Z1D633PEXAMPLE",
      "Condition": {
        "StringEquals": {
          "route53:ChangeResourceRecordSetsRecordTypes": ["CNAME", "TXT"]
        }
      }
    }
  ]
}

Restricting Record Names

You can also restrict which record names a principal can modify using the route53:ChangeResourceRecordSetsRecordNames condition key. This is useful for multi-tenant environments where different teams own different subdomains.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowOnlyMarketingSubdomain",
      "Effect": "Allow",
      "Action": "route53:ChangeResourceRecordSets",
      "Resource": "arn:aws:route53:::hostedzone/Z1D633PEXAMPLE",
      "Condition": {
        "StringEquals": {
          "route53:ChangeResourceRecordSetsRecordNames": ["marketing.example.com"]
        }
      }
    }
  ]
}

Controlling Private Hosted Zone Associations

Private hosted zones are linked to VPCs. Controlling which VPCs can be associated with a hosted zone prevents unauthorized network segments from resolving your internal DNS names. The following policy allows associating VPCs only in specific accounts and regions:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowVPCAssociation",
      "Effect": "Allow",
      "Action": [
        "route53:AssociateVPCWithHostedZone",
        "route53:DisassociateVPCFromHostedZone"
      ],
      "Resource": "arn:aws:route53:::hostedzone/Z1D633PEXAMPLE",
      "Condition": {
        "StringEquals": {
          "route53:VPCRegion": "us-east-1"
        },
        "ArnLike": {
          "ec2:Vpc": "arn:aws:ec2:us-east-1:123456789012:vpc/*"
        }
      }
    }
  ]
}

Network Security for Route 53

Beyond IAM, network-level controls determine how DNS queries flow between your VPCs, on-premises networks, and the public internet. Route 53 offers several features that operate at the network layer to protect DNS resolution.

Private Hosted Zones

Private hosted zones allow you to maintain DNS records that are only resolvable from within your VPCs or networks connected via AWS Transit Gateway, Direct Connect, or VPN. This prevents the public from enumerating internal service names. To create a private hosted zone and associate it with a VPC:

aws route53 create-hosted-zone \
  --name internal.example.com \
  --caller-reference "$(date +%s)" \
  --hosted-zone-config PrivateZone=true \
  --vpc VPCRegion=us-east-1,VPCId=vpc-0abc123def456

Once created, only resources within the associated VPC (or peered networks with proper configuration) can resolve records in internal.example.com. This is the foundation of DNS privacy in AWS.

Route 53 Resolver Endpoints

Route 53 Resolver enables hybrid DNS resolution between your VPCs and on-premises networks. Inbound resolver endpoints allow on-premises DNS servers to forward queries to Route 53 for private hosted zone records. Outbound resolver endpoints allow your VPC to forward queries to on-premises DNS servers. Both endpoint types should be deployed in at least two Availability Zones for high availability.

To create an inbound resolver endpoint with security group restrictions:

aws route53resolver create-resolver-endpoint \
  --creator-request-id "$(uuidgen)" \
  --security-group-ids sg-0abc123def456 \
  --direction INBOUND \
  --ip-addresses SubnetId=subnet-0aaa,Ip=10.0.1.10 SubnetId=subnet-0bbb,Ip=10.0.2.10 \
  --name corporate-dns-inbound

The security group attached to the resolver endpoint should only allow inbound UDP and TCP port 53 from trusted CIDR ranges, such as your on-premises network or specific VPC subnets:

aws ec2 authorize-security-group-ingress \
  --group-id sg-0abc123def456 \
  --protocol udp \
  --port 53 \
  --cidr 10.50.0.0/16

aws ec2 authorize-security-group-ingress \
  --group-id sg-0abc123def456 \
  --protocol tcp \
  --port 53 \
  --cidr 10.50.0.0/16

Resolver Rules for Controlled Forwarding

Resolver rules define which DNS queries get forwarded to which endpoints. Forwarding rules should be scoped precisely to only the domains that need cross-network resolution. Avoid creating catch-all forwarding rules that send all queries to on-premises resolvers, as this increases latency and creates a dependency on external infrastructure.

aws route53resolver create-resolver-rule \
  --creator-request-id "$(uuidgen)" \
  --rule-type FORWARD \
  --domain-name corp.example.com \
  --target-ips Ip=10.50.1.5,Port=53 Ip=10.50.2.5,Port=53 \
  --resolver-endpoint-id rslvr-out-0abc123def456 \
  --name forward-to-corp-dns

DNSSEC for Data Integrity

DNSSEC adds cryptographic signatures to your DNS records, allowing resolvers to verify that responses have not been tampered with in transit. Route 53 supports DNSSEC signing for hosted zones and DNSSEC validation for Resolver endpoints. Enabling DNSSEC signing involves creating a KMS key, establishing a key-signing key, and enabling signing on the zone.

# Create a customer-managed KMS key for DNSSEC
aws kms create-key \
  --key-usage SIGN_VERIFY \
  --key-spec ECC_NIST_P256 \
  --description "Route 53 DNSSEC signing key"

# Enable DNSSEC on the hosted zone
aws route53 enable-hosted-zone-dnssec \
  --hosted-zone-id Z1D633PEXAMPLE

After enabling signing, you must also publish the DS record from Route 53 to your parent domain registrar to complete the chain of trust. Without the DS record in the parent zone, resolvers cannot validate your zone's signatures.

VPC DNS Settings

Each VPC has DNS settings that affect security and resolution behavior. The two most important are enableDnsHostnames and enableDnsSupport. Both must be enabled for private hosted zones to function. Disabling enableDnsSupport prevents instances from using the VPC-provided DNS server at 169.254.169.253, which can break private hosted zone resolution.

aws ec2 modify-vpc-attribute \
  --vpc-id vpc-0abc123def456 \
  --enable-dns-support

aws ec2 modify-vpc-attribute \
  --vpc-id vpc-0abc123def456 \
  --enable-dns-hostnames

Network Firewall and DNS Filtering

AWS Network Firewall can inspect and filter DNS traffic leaving your VPC. By creating stateless rules that match on DNS query domains, you can block queries to known-malicious domains or prevent data exfiltration over DNS tunnels. This complements Route 53 Resolver DNS Firewall, which operates at the VPC DNS layer.

Route 53 Resolver DNS Firewall lets you create domain lists and associate them with VPCs to allow or block specific domains. This is particularly useful for preventing instances from communicating with command-and-control infrastructure over DNS.

# Create a firewall domain list
aws route53resolver create-firewall-domain-list \
  --creator-request-id "$(uuidgen)" \
  --name blocked-malware-domains

# Add domains to the list
aws route53resolver update-firewall-domains \
  --firewall-domain-id rslvr-fdl-0abc123def456 \
  --domains "malware-bad-site.com" "c2-example.net" "dns-tunnel-evil.org"

# Create a firewall rule that blocks queries to those domains
aws route53resolver create-firewall-rule \
  --creator-request-id "$(uuidgen)" \
  --firewall-rule-group-id rslvr-frg-0abc123def456 \
  --firewall-domain-list-id rslvr-fdl-0abc123def456 \
  --action BLOCK \
  --block-response NXDOMAIN \
  --name block-malware-queries

Best Practices

Apply Least Privilege Consistently

Never grant route53:* or broad route53:Change* permissions to roles that do not explicitly need them. Scope write permissions to specific hosted zone ARNs and use condition keys to restrict record types and names where possible. Review IAM policies regularly using IAM Access Analyzer to identify over-permissive statements.

Use Separate Accounts for DNS Management

In multi-account environments, centralize DNS management in a dedicated account. Other accounts can assume a cross-account role with scoped permissions to modify only their specific records. This separation reduces the blast radius of a compromised application account.

Enable CloudTrail Logging and Alarms

Route 53 API calls are logged by AWS CloudTrail. Monitor for suspicious activity such as unexpected ChangeResourceRecordSets calls, hosted zone deletions, or DNSSEC key deletions. Create CloudWatch Alarms or EventBridge rules that trigger on these events:

aws events put-rule \
  --name "route53-dns-change-alert" \
  --event-pattern '{
    "source": ["aws.route53"],
    "detail-type": ["AWS API Call via CloudTrail"],
    "detail": {
      "eventName": ["ChangeResourceRecordSets", "DeleteHostedZone"]
    }
  }'

Require MFA for DNS Changes

For highly sensitive zones, require multi-factor authentication for DNS record changes. This can be enforced through IAM condition keys that check for MFA presence. While this adds friction to automation, it significantly reduces the risk of unauthorized changes from compromised credentials.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RequireMFAForDNSChanges",
      "Effect": "Deny",
      "Action": "route53:ChangeResourceRecordSets",
      "Resource": "*",
      "Condition": {
        "BoolIfExists": {
          "aws:MultiFactorAuthPresent": "false"
        }
      }
    }
  ]
}

Implement Change Management with Approval Workflows

For production DNS, route changes through an approval workflow rather than allowing direct API calls. Tools like AWS Service Catalog, Terraform with PR-based reviews, or custom Lambda functions that validate change requests before applying them add an important layer of governance.

Monitor for Dangling DNS Records

Dangling DNS records that point to deleted or unclaimed resources create subdomain takeover risks. Regularly audit your hosted zones for CNAME and alias records pointing to resources that no longer exist. Automated scripts using the Route 53 API combined with resource existence checks can identify these vulnerabilities.

Use DNSSEC Validation on Resolver

Enable DNSSEC validation on Route 53 Resolver endpoints to protect VPC resources from DNS spoofing attacks. This ensures that DNS responses for DNSSEC-signed domains are cryptographically verified before being returned to instances.

aws route53resolver update-resolver-dnssec-config \
  --resource-id vpc-0abc123def456 \
  --validation ENABLE

Tag Hosted Zones for Governance

Apply consistent tags to hosted zones indicating ownership, environment, and sensitivity level. Tags enable better cost allocation, access control via ABAC (attribute-based access), and easier auditing. Use the route53:ResourceTag condition key in IAM policies to enforce tag-based access control.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowAccessToTeamZones",
      "Effect": "Allow",
      "Action": "route53:ChangeResourceRecordSets",
      "Resource": "arn:aws:route53:::hostedzone/*",
      "Condition": {
        "StringEquals": {
          "route53:ResourceTag/Team": "platform"
        }
      }
    }
  ]
}

Conclusion

Securing Route 53 requires a defense-in-depth approach that combines precise IAM policies with network-level controls. By scoping write permissions to specific hosted zones, restricting record types and names through condition keys, leveraging private hosted zones for internal DNS, deploying resolver endpoints with tight security groups, enabling DNSSEC for integrity, and monitoring all changes through CloudTrail, you can significantly reduce the risk of DNS-based attacks. DNS is foundational to every application running in your AWS environment, and treating Route 53 configuration with the same security rigor as your compute and data layers is essential for maintaining availability, integrity, and confidentiality across your infrastructure.