June 26, 2026 · Ironimo Security Team

DNS Security Testing: Rebinding, Hijacking, and Infrastructure Vulnerabilities

DNS is the phone book of the internet, and like every piece of infrastructure that was designed for availability first and security second, it has a long history of vulnerabilities. DNS-based attacks range from infrastructure-level (zone transfers, cache poisoning) to application-level (DNS rebinding bypassing the same-origin policy) to operational (dangling records enabling subdomain takeover).

A security assessment that ignores DNS is incomplete. The attack surface is real, the techniques are well-documented, and the remediation is achievable. This guide covers DNS security from a penetration testing perspective.

DNS Rebinding: Bypassing the Same-Origin Policy

DNS rebinding is one of the more elegant attack techniques in web security. It exploits the browser's trust model around DNS to make an attacker-controlled website appear to be the same origin as an internal service.

How It Works

1. The attacker registers a domain (say attacker.com) and controls its DNS server.
2. The victim visits attacker.com. The DNS server returns the attacker's real IP with a very low TTL (0 or 1 second).
3. The attacker's page loads and executes JavaScript in the victim's browser.
4. After the TTL expires, the attacker's DNS server changes the IP resolution for attacker.com to an internal IP — say 192.168.1.1 (the victim's router) or 127.0.0.1 (localhost).
5. The JavaScript on the attacker's page makes XHR requests to attacker.com. The browser's same-origin policy allows this (same domain). But DNS now resolves to the internal service, so the requests go there.
6. The attacker reads internal API responses, exfiltrates data, and issues commands to the internal service — all through the victim's browser.

Real-world targets include home routers (admin interfaces on 192.168.1.1), localhost development servers, IoT devices, and Kubernetes API servers accessible from within the cluster.

Testing for DNS Rebinding Vulnerability

An application is vulnerable to DNS rebinding if:

• It binds to 0.0.0.0 (all interfaces) instead of 127.0.0.1 or a specific internal interface
• It doesn't validate the Host header against a whitelist of expected hostnames
• CORS is configured to allow arbitrary origins or doesn't apply (e.g. non-browser API consumers)

Test Host header validation:

# Does the application accept arbitrary Host headers?
curl -H "Host: attacker.com" http://localhost:8080/api/admin
curl -H "Host: 127.0.0.1" http://localhost:8080/api/admin

# Expected: 400 Bad Request or redirect to correct hostname
# Vulnerable: 200 OK with application response

For a proper DNS rebinding test, use the tool singularity (nccgroup/singularity) which automates the attack setup.

DNS Zone Transfer (AXFR)

DNS zone transfers (AXFR queries) allow one DNS server to copy all records from another. This is legitimate for DNS replication, but misconfigured nameservers that allow transfers from any source reveal the complete DNS inventory: subdomains, internal hostnames, mail servers, and IPs.

# Test for zone transfer
dig AXFR example.com @ns1.example.com
dig AXFR example.com @ns2.example.com

# Using host
host -t AXFR example.com ns1.example.com

# Expected: Transfer failed (REFUSED or NOTAUTH)
# Vulnerable: Full zone dump returned

Zone transfers against the authoritative nameservers should be refused for all but legitimate secondary servers. If a zone transfer succeeds, you get a complete map of the infrastructure.

DNS Cache Poisoning

DNS cache poisoning injects fraudulent records into a resolver's cache. A successfully poisoned cache routes users querying for bank.example.com to an attacker-controlled server. The attack requires guessing the query ID and port (both 16-bit) in a race against the legitimate response.

Modern defenses:

• DNSSEC — cryptographically signs DNS records. The resolver can verify the signature and reject forged responses. Check if your zones are DNSSEC-signed.
• Source port randomization — makes the attack window much smaller. Resolvers that don't randomize source ports are easier to poison.
• 0x20 encoding — randomizing the case of queries adds another dimension of randomization.

Test for DNSSEC:

# Check if zone is DNSSEC-signed
dig example.com DNSKEY
dig example.com DS @8.8.8.8

# Check for DNSSEC validation
dig +dnssec example.com A

# An unsigned zone returns no RRSIG records
# A signed zone shows RRSIG in the additional section

DNS Hijacking and Dangling Records

Subdomain Takeover via DNS

A DNS record that points to a service that no longer exists (a "dangling record") can be claimed by an attacker. If staging.example.com CNAME points to an S3 bucket that has been deleted, anyone can create a bucket with the same name and serve content from staging.example.com.

# Find CNAMEs pointing to services
dig CNAME staging.example.com
# Returns: staging.example.com. CNAME myapp.s3.amazonaws.com.

# Check if the target resource exists
curl -I http://myapp.s3.amazonaws.com
# 404 NoSuchBucket -> takeover possible

Common dangling record targets: AWS S3, Azure Blob Storage, GitHub Pages, Heroku, Fastly, Netlify, Zendesk, Intercom. Each has its own takeover mechanics — most require creating a resource at the dangling target hostname.

DNS-Based Domain Takeover

If a domain's DNS is managed through a third-party (a registrar's nameserver, an NS record pointing to a cloud DNS service), and that third-party account is compromised or the domain lapses, DNS can be hijacked at the registrar level.

Test for:

• NS records pointing to nameservers that no longer exist
• Domain registrar accounts with weak passwords or no MFA
• Expired domains in the organization's portfolio that still have active DNS records pointing to them

DKIM, SPF, and DMARC — Email DNS Security

Email authentication relies on DNS records. Misconfigured or missing email security records allow attackers to spoof your domain in phishing campaigns:

SPF (Sender Policy Framework)

# Check SPF record
dig TXT example.com | grep "v=spf1"

# Common issues:
# Missing SPF record - any server can send as your domain
# Overly permissive: +all (allow all) instead of -all (deny all)
# Too many DNS lookups (SPF has a 10-lookup limit)
# Example vulnerable: "v=spf1 include:example.com +all"
# Example secure:    "v=spf1 include:_spf.google.com -all"

DKIM (DomainKeys Identified Mail)

# DKIM keys are in selector._domainkey.example.com TXT records
# Common selectors: default, google, mail, selector1
dig TXT default._domainkey.example.com
dig TXT google._domainkey.example.com

# Weak key sizes (< 2048 bits) are vulnerable to factoring
# An exposed private key allows signing malicious emails as your domain

DMARC

# Check DMARC policy
dig TXT _dmarc.example.com

# Example secure: "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
# Example weak:   "v=DMARC1; p=none"  (monitoring only, no enforcement)
# Missing DMARC:  SPF and DKIM can still be bypassed

A missing or permissive DMARC policy (p=none) means your domain can be spoofed in phishing emails even if SPF and DKIM are configured — DMARC is what actually enforces alignment.

DNSSEC Validation Testing

Even if you've signed your zone with DNSSEC, the signing is only effective if resolvers perform validation. Test that:

• Your zone is signed (RRSIG records present)
• The DS record is published in the parent zone (connecting the chain of trust)
• DNSSEC validation is enforced at your corporate resolvers

# Test DNSSEC chain of trust
dig +dnssec +multi example.com A
# Look for: "ad" flag in the header (Authenticated Data)

# Use dnsviz for visual chain of trust analysis
# dnsviz.net provides a free web interface

# Test that a DNSSEC-invalid domain is rejected
dig +dnssec dnssec-failed.org
# Should return SERVFAIL if validation is working

DNS over HTTPS / DNS over TLS

Standard DNS queries are cleartext and can be observed and manipulated by on-path attackers. DoH (DNS over HTTPS) and DoT (DNS over TLS) encrypt DNS queries.

For web applications, the relevant consideration is whether internal DNS resolution could be intercepted by an attacker with network access. Applications that make DNS queries in sensitive contexts (resolving user-supplied hostnames, webhook delivery) should use a resolver with DoT/DoH support.

Testing Checklist

• Test zone transfer (AXFR) against all authoritative nameservers
• Check DNSSEC signing status and chain of trust for all zones
• Enumerate CNAMEs and check for dangling records pointing to dead services
• Verify SPF record exists and uses -all (hard fail)
• Verify DKIM is configured with 2048-bit keys for all mail-sending selectors
• Verify DMARC policy is p=reject or p=quarantine, not p=none
• Check DNS CAA records that restrict certificate issuance to specific CAs
• Test Host header validation on internal services for DNS rebinding susceptibility
• Check NS records for pointers to non-existent nameservers
• Review all DNS records in scope for expired or unused entries

Tools

• dig / nslookup / host — standard DNS query tools for all record types
• dnsx — fast DNS toolkit for bulk resolution and record enumeration
• subjack / nuclei — automated subdomain takeover detection
• MXToolbox — web-based SPF/DKIM/DMARC analysis
• dnsviz.net — DNSSEC chain of trust visualization
• singularity (nccgroup) — DNS rebinding attack platform for testing
• Ironimo — automated scanning covers subdomain takeover, misconfigured security headers, and DNS-related web application exposures

Remediation

Validate Host headers. Internal services, APIs, and development servers should explicitly validate the Host header against a whitelist. Frameworks like Django, Rails, and Laravel have built-in ALLOWED_HOSTS settings. Use them.

Disable zone transfers. Configure authoritative nameservers to refuse AXFR queries from all IPs except the legitimate secondaries. In BIND: allow-transfer { secondary_ip; };

Implement DNSSEC. Sign all zones and ensure DS records are published. Use a DNS provider that supports DNSSEC if managing it manually is too complex — most modern providers handle signing automatically.

Audit DNS records regularly. Run a monthly scan of all DNS records to identify dangling CNAMEs. When decommissioning services (Heroku dynos, S3 buckets, GitHub Pages sites), remove DNS records first, then the service.

Enforce email authentication. If you haven't already, deploy SPF (-all), DKIM (2048-bit keys), and DMARC (p=reject). This prevents your domain from being used in phishing. DMARC with reporting also gives you visibility into what's sending email as your domain.