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
Azure DNS	Service Principal	Zone discovery, record enumeration, VNET-linked zone detection
GCP Cloud DNS	Service Account	Zone discovery, record enumeration, DNSSEC status

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

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	Subdomain Takeover Risk	Critical
dns-002	Dangling CNAME — Resource Deleted	High
dns-003	DNSSEC Not Enabled	Medium
dns-004	Zone Transfer Exposed (AXFR)	High
dns-005	Wildcard Record Detected	Medium
dns-006	MX Points to Non-Existent Host	High
dns-007	Stale A Record — No Matching Asset	Medium
dns-008	SPF Record Missing or Permissive	Medium
dns-009	DMARC Record Absent	Medium
dns-010	NS Delegation Mismatch	Low

All rules appear in the Findings view with remediation steps, framework mappings, 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 (e.g., GitHub Pages, Heroku, S3, Fastly, Shopify) and flags records pointing to unclaimed endpoints.

How it works:

1. Infracast enumerates all CNAME records in discovered zones
2. Each target is resolved and checked against cloud provider APIs to verify ownership
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 graph:

[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.

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/dns/zones

# List records for a zone
GET /api/v1/dns/zones/{zoneId}/records

# Run subdomain takeover scan
POST /api/v1/dns/zones/{zoneId}/takeover-scan

# Get DNS-related findings
GET /api/v1/findings?category=dns

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.