DNS for Testers

How DNS Works #

The Domain Name System (DNS) is the internet’s phone book — it translates human-readable domain names (like api.example.com) into IP addresses (like 93.184.216.34) that computers use to communicate. Every network request your application makes starts with a DNS lookup, making DNS the foundation of all networked communication.

The Resolution Process #

When your browser or test tool needs to resolve a domain name, a cascade of lookups occurs:

1. Browser cache: The browser checks its own DNS cache first (typically 60 seconds)
2. OS cache: The operating system’s DNS resolver cache is checked next
3. Recursive resolver: Your ISP’s or configured DNS server (like Google’s 8.8.8.8 or Cloudflare’s 1.1.1.1) is queried
4. Root nameserver: If the resolver does not have a cached answer, it asks a root nameserver which directs to the TLD server
5. TLD nameserver: The .com, .org, or .io server directs to the domain’s authoritative nameserver
6. Authoritative nameserver: Returns the actual DNS record with the IP address

This entire process typically takes 20-100ms but can be cached at each level, reducing subsequent lookups to near-zero.

DNS Record Types #

DNS Diagnostic Tools #

dig — The QA Engineer’s DNS Swiss Army Knife #

# Basic lookup
dig example.com

# Short output — just the answer
dig +short example.com

# Query specific record type
dig example.com AAAA
dig example.com MX
dig example.com TXT

# Trace the full resolution path
dig +trace example.com

# Query a specific DNS server
dig @8.8.8.8 example.com

# Show TTL values
dig example.com | grep -A1 "ANSWER SECTION"

nslookup — Quick and Cross-Platform #

# Basic lookup
nslookup example.com

# Query specific server
nslookup example.com 8.8.8.8

# Query specific record type
nslookup -type=MX example.com

Checking Propagation Across Resolvers #

# Compare results across multiple public DNS servers
dig @8.8.8.8 example.com +short      # Google
dig @1.1.1.1 example.com +short      # Cloudflare
dig @9.9.9.9 example.com +short      # Quad9
dig @208.67.222.222 example.com +short  # OpenDNS

If different resolvers return different IP addresses, DNS propagation is still in progress.

DNS Testing Scenarios #

Environment Routing with Hosts File #

The /etc/hosts file (or C:\Windows\System32\drivers\etc\hosts on Windows) overrides DNS resolution locally. This is the most common DNS technique QA engineers use:

# Route production domain to staging server
# Add to /etc/hosts:
10.0.1.50  api.example.com
10.0.1.50  www.example.com

This allows testing production-domain behavior against a staging server without any DNS infrastructure changes. The browser and all tools will connect to the IP you specified.

TTL-Related Testing #

Before any DNS migration or deployment that changes DNS records:

1. Check current TTL: dig example.com | grep TTL — a TTL of 86400 (24 hours) means old records persist for a full day
2. Lower TTL before migration: Reduce TTL to 300 (5 minutes) at least 24 hours before the change
3. Monitor propagation: After the change, verify from multiple resolvers that new records are live

DNS Failover Testing #

Many applications use DNS-based failover — when a primary server fails, DNS routes traffic to a backup. Test this by:

1. Verifying failover records exist (multiple A records or health-check-based DNS)
2. Simulating primary server failure and confirming DNS switches to the backup
3. Measuring failover time (depends on TTL and health check intervals)

Advanced DNS Testing #

DNS-Based Service Discovery #

In microservice architectures, services find each other through DNS (especially SRV records in Kubernetes). Testing includes:

• Verifying SRV records return correct host:port combinations
• Testing service registration/deregistration timing
• Checking that clients handle DNS record changes gracefully

GeoDNS Testing #

GeoDNS routes users to the nearest server based on their geographic location. To test from different locations:

# Use DNS servers in different regions
dig @dns-server-in-europe.example.com api.example.com +short
dig @dns-server-in-asia.example.com api.example.com +short

# Or use online tools like DNS Checker, whatsmydns.net

DNSSEC Validation #

DNSSEC adds cryptographic signatures to DNS records, preventing tampering. Verify DNSSEC is configured:

# Check DNSSEC status
dig example.com +dnssec

# Verify the full DNSSEC chain
dig +sigchase +trusted-key=. example.com

DNS over HTTPS (DoH) #

Modern browsers use DNS over HTTPS, encrypting DNS queries. This can affect test behavior:

• DoH bypasses local DNS settings and hosts file in some configurations
• Corporate proxies may not see DNS queries, affecting monitoring
• Test with DoH enabled and disabled to verify consistent behavior

Subdomain Takeover Testing #

When a CNAME points to a service that no longer exists (e.g., a deleted S3 bucket or Heroku app), an attacker can claim that service and serve malicious content:

# Check for dangling CNAMEs
dig subdomain.example.com CNAME +short
# If the target service returns NXDOMAIN, it may be vulnerable

Hands-On Exercise #

Investigate the DNS configuration for a website of your choice:

1. Query all record types (A, AAAA, CNAME, MX, TXT, NS)
2. Trace the full resolution path with dig +trace
3. Modify your hosts file to redirect the domain to 127.0.0.1 and verify it works
4. Check the TTL value and calculate how long a DNS change would take to propagate
5. Compare resolution results across three different DNS resolvers

# 1. Query all record types
DOMAIN="example.com"
for TYPE in A AAAA CNAME MX TXT NS; do
  echo "=== $TYPE ==="
  dig +short $DOMAIN $TYPE
done

# 2. Full trace
dig +trace $DOMAIN

# 3. Hosts file redirect (requires sudo)
echo "127.0.0.1  $DOMAIN" | sudo tee -a /etc/hosts
curl $DOMAIN  # Should fail or connect to localhost
# Remember to remove the entry after testing!

# 4. Check TTL
dig $DOMAIN | grep -A5 "ANSWER SECTION"

# 5. Compare resolvers
for DNS in 8.8.8.8 1.1.1.1 9.9.9.9; do
  echo "=== $DNS ==="
  dig @$DNS +short $DOMAIN
done

Pro Tips #

• Use /etc/hosts to redirect domains to test environments without DNS changes — it is the safest and fastest approach for QA
• Check DNS TTL before deployments — a high TTL means slow cutover and potential testing inconsistencies
• Test from multiple DNS resolvers to detect propagation inconsistencies — different users may resolve to different servers during transitions
• DNS caching can make tests pass locally but fail in CI — flush DNS caches when debugging (sudo dscacheutil -flushcache on macOS)
• Monitor DNS resolution time — slow DNS adds latency to every single request your application makes

Key Takeaways #

1. DNS is the first step in every network request — DNS failures affect everything downstream
2. The hosts file is QA’s best friend for routing test traffic without infrastructure changes
3. TTL awareness is critical during deployments and environment migrations
4. DNS diagnostic tools (dig, nslookup) should be in every tester’s toolkit