DNS Security & Discovery

Infracast automatically discovers and audits DNS infrastructure across AWS Route53, Azure DNS, and GCP Cloud DNS — surfacing misconfigurations, subdomain takeover risks, and zone hygiene issues in real time.

Overview

DNS is a critical but often overlooked attack surface. Misconfigured records can expose internal services, enable subdomain hijacking, or leak zone data. Infracast integrates DNS zone discovery directly into its unified asset graph, correlating DNS records with the cloud resources they point to.

Supported Providers

Provider	Auth Method	Capabilities
AWS Route53	IAM Role / Access Key	Zone discovery, record enumeration, health check correlation, DNSSEC status, query logging
Azure DNS	Service Principal	Public and private zone discovery, record enumeration, email security record detection (SPF, DMARC, DKIM)
GCP Cloud DNS	Service Account	Zone discovery, record enumeration, DNSSEC configuration and key specs

DNS Zone Discovery

Once connected, Infracast discovers:

• All hosted zones (public and private)
• All record sets (A, AAAA, CNAME, MX, TXT, NS, SOA, PTR, SRV)
• TTL values and routing policies
• Health check associations (Route53)
• DNSSEC signing status and key specs

Discovered zones and records appear as nodes in the Infracast asset graph, linked to the cloud accounts and resources they belong to.

How to Enable

1. Navigate to Settings → Discovery Sources
2. Click Add Source → select your DNS provider (Route53 / Azure DNS / GCP Cloud DNS)
3. Provide credentials (IAM role ARN, service principal, or service account)
4. Click Save & Discover — discovery runs immediately and on your configured schedule

DNS Security Rules

Infracast ships 10 DNS security rules (hot-reloadable YAML, part of the standard compliance pack):

Rule ID	Name	Severity
DNS-001	DNSSEC Not Enabled on Public Zone	HIGH
DNS-002	DNS Query Logging Disabled	MEDIUM
DNS-003	Dangling CNAME — Potential Subdomain Takeover	CRITICAL
DNS-004	Missing CAA Record	MEDIUM
DNS-005	Missing SPF Record	HIGH
DNS-006	Missing DMARC Record	HIGH
DNS-007	Wildcard DNS Record in Production Zone	MEDIUM
DNS-008	Stale DNS Record — Target Not Found	HIGH
DNS-009	DNS Zone Missing DKIM Records	MEDIUM
DNS-010	Long TTL on Critical Records	LOW

All rules appear in the Findings view with remediation steps, framework mappings (NIST 800-53 SC-20, SC-21, SC-22), and direct links to the affected records.

Subdomain Takeover Analyzer

The Subdomain Takeover Analyzer checks every CNAME record against a database of known takeover-vulnerable services and flags records pointing to unclaimed endpoints.

Checked services include:

• AWS S3, CloudFront, Elastic Beanstalk
• Azure App Service, Azure Blob Storage, Azure Cloud App, Azure Traffic Manager
• Heroku, GitHub Pages
• Shopify, Zendesk, Ghost, Pantheon

How it works:

1. Infracast enumerates all CNAME records in discovered zones
2. Each target is checked against the known-vulnerable service database
3. Records pointing to unclaimed or deleted resources are flagged as Critical findings
4. Affected records appear in the graph with a takeover-risk indicator

Common Takeover Scenarios

• CNAME pointing to an S3 bucket that no longer exists
• Subdomain pointing to a decommissioned Heroku app
• Internal service CNAME pointing to a deleted Azure App Service
• GitHub Pages CNAME where the repository was deleted or made private

Asset Graph Integration

DNS records are first-class nodes in the Infracast asset graph, linked to cloud accounts and the resources they reference:

[Route53 Zone: example.com]
  ├── [A Record: api.example.com → 54.1.2.3]
  │     └── [EC2 Instance: i-abc123]
  ├── [CNAME: blog.example.com → acme.github.io] ⚠ TAKEOVER RISK
  └── [MX Record: example.com → mail.example.com]
        └── [A Record: mail.example.com → 54.4.5.6]

This enables cross-domain attack path analysis — for example, a subdomain takeover can chain into phishing campaigns or cookie theft against the parent domain.

UI — DNS Security Page

Three tabs are available:

Zones — table with provider badge, zone type (public/private), record count, DNSSEC status, query logging, SPF, DMARC indicator badges. Click to expand zone records inline.

Subdomain Takeover Risks — severity-sorted list of dangling CNAMEs. Each entry shows the zone, record name, CNAME target, matched vulnerable service, risk level, and a one-click remediation guide.

DNSSEC Status — coverage percentage (zones with DNSSEC enabled / total), per-zone DNSSEC detail table.

Summary stat cards at the top: Total Zones · Total Records · Takeover Risks · Zones Without DNSSEC.

Compliance Mapping

DNS security rules map to the following framework controls:

Framework	Control	Mapped Rules
NIST 800-53	SC-20, SC-21, SC-22	DNS-001 through DNS-010
CIS Controls	9.2, 12.1	DNS-001, DNS-003, DNS-004
FedRAMP	SC-20, SC-21	DNS-001, DNS-003
CMMC	SC.L2-3.13.8	DNS-003, DNS-004
PCI-DSS	6.4.3, 11.3	DNS-001, DNS-002

Permissions Required

AWS Route53

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "route53:ListHostedZones",
        "route53:ListResourceRecordSets",
        "route53:GetHealthCheck",
        "route53:ListHealthChecks"
      ],
      "Resource": "*"
    }
  ]
}

Azure DNS

Required role: DNS Zone Contributor (read-only operations only; Infracast does not modify records)

GCP Cloud DNS

Required role: roles/dns.reader

API Reference

# List all discovered DNS zones
GET /api/v1/tenants/{tenantID}/dns/zones

# Get a specific zone
GET /api/v1/tenants/{tenantID}/dns/zones/{zoneID}

# List DNS records across all zones
GET /api/v1/tenants/{tenantID}/dns/records

# List subdomain takeover risks
GET /api/v1/tenants/{tenantID}/dns/takeover-risks

# Check DNSSEC status
GET /api/v1/tenants/{tenantID}/dns/dnssec-status

# Get DNS-related findings
GET /api/v1/tenants/{tenantID}/findings?category=dns

API paths corrected 2026-09-14

DNS endpoints are tenant-scoped. The previously documented global DNS paths and a per-zone takeover-scan POST do not exist. Takeover risks are returned by /api/v1/tenants/{tenantID}/dns/takeover-risks.

Troubleshooting

No zones discovered

• Verify credentials have the required read permissions
• Check that the DNS provider is listed under Settings → Discovery Sources
• Review discovery logs under Settings → Discovery → History

Takeover scan shows false positives

Some CNAME targets that appear unclaimed may belong to private services not visible from the scanner's vantage point. Use the Mark as Accepted Risk action on the finding to suppress with justification.