DNS Checks

Every time someone types a domain name, the Internet faces a question: where does this name point? The Domain Name System answers that question, translating example.com into 93.184.216.34. DNS checks verify this translation works correctly.

Why does this matter so much? Because DNS is the first thing that happens. Before your server receives a request, before your code executes a single line, DNS must resolve. If it fails, everything fails. Your server can be running perfectly—green lights across every dashboard—and still be completely unreachable because DNS points to nowhere.

How DNS Checks Work

A DNS check performs the same lookup a user's browser would perform. The monitoring system sends a query asking "What is the IP address for example.com?" and validates the response.

Record Existence: Does the query return an answer at all? If DNS servers have no record for your domain, users see "This site can't be reached."

Correct Value: Does the record contain the expected value? If your website should resolve to 93.184.216.34 but resolves to 192.0.2.1, traffic goes somewhere else—possibly a competitor's server, possibly a black hole.

Response Time: How quickly does the DNS server respond? Every millisecond of DNS latency happens before users even connect to your service.

Authority: Which DNS server provided the answer? Understanding whether responses come from authoritative servers or caching resolvers helps troubleshoot when things go wrong.

Types of DNS Records

DNS isn't just one kind of lookup. Different record types serve different purposes:

A Records map domain names to IPv4 addresses. When someone visits www.example.com, an A record returns addresses like 93.184.216.34. Most DNS monitoring focuses here because A records control where web traffic goes.

AAAA Records map domain names to IPv6 addresses. As the Internet transitions to IPv6, both A and AAAA records need to exist and point to the right places.

CNAME Records create aliases. A CNAME for www.example.com might point to example.com, causing lookups for the www subdomain to follow the alias. If the alias target doesn't exist, neither does the alias.

MX Records specify mail servers. Incorrect MX records mean email vanishes into the void—sent but never received, with no error message to explain why.

TXT Records store text data, often for email validation (SPF, DKIM) or domain verification. A malformed TXT record can cause your emails to land in spam folders.

NS Records identify which name servers are authoritative for a domain. If these point to servers that don't exist, your entire domain goes dark.

PTR Records provide reverse DNS, mapping IP addresses back to domain names. Many email servers check PTR records before accepting mail—no PTR, no delivery.

Authoritative vs. Recursive Queries

DNS checks can query in two fundamentally different ways:

Recursive Queries ask a DNS resolver (like 8.8.8.8 or your ISP's resolver) to look up a record. The resolver checks its cache, and if necessary, queries authoritative servers to find the answer. This simulates what actual users experience.

Recursive checks reveal caching behavior. After updating DNS records, recursive queries might return old values for hours. This is exactly what happens to real users—not a bug, just how DNS works.

Authoritative Queries skip resolvers and query your authoritative name servers directly. These checks verify your DNS servers have the correct records without being affected by caching.

Authoritative checks immediately reflect changes. If you just updated a record and the authoritative check returns the new value, you know the update succeeded—even though cached values persist across the Internet.

Monitoring from Multiple Locations

DNS behavior varies by location:

Geographic Variance: Some DNS providers use geographic load balancing (GeoDNS), returning different IP addresses based on where queries originate. A check from New York might return your East Coast server; the same check from London returns your European server.

Resolver Differences: Different DNS resolvers cache records for different durations. Checking from multiple resolvers reveals inconsistencies before users report them.

Propagation Verification: After changing DNS records, monitoring from multiple locations verifies changes propagated worldwide. Some regions might receive updates quickly while others lag by hours.

Anycast Performance: DNS providers often use anycast routing, directing queries to the nearest server. Checking from multiple locations verifies this routing works correctly.

DNS Response Time

Query response time directly affects user experience:

Fast Responses (under 20ms) are typical for cached records. Users experience no perceptible delay.

Moderate Responses (20-100ms) are common when resolvers must query authoritative servers. Most users won't notice, but it adds to total page load time.

Slow Responses (100+ms) become noticeable, especially for sites requiring multiple DNS lookups. Each lookup adds delay before content begins loading.

Timeouts occur when DNS servers don't respond at all. Browsers typically wait several seconds before giving up—an eternity of loading indicator with no progress.

Monitoring response time helps identify degradation before it becomes severe enough to cause timeouts. Gradually increasing DNS response times often predict infrastructure problems.

TTL and Caching

Time To Live (TTL) values control how long DNS records stay cached:

Short TTLs (60-300 seconds) mean changes propagate quickly but increase query load on authoritative servers. If you frequently change records, short TTLs ensure updates take effect rapidly.

Long TTLs (hours or days) reduce query load and improve performance through caching but mean changes propagate slowly. If records rarely change, long TTLs make sense.

The Catch: You can't force resolvers to clear their caches. If you update a record with a 1-hour TTL, some resolvers will serve the old value for the full hour. Monitoring from recursive resolvers reveals how long stale values persist.

Validating DNS Changes

When updating DNS records, careful monitoring ensures changes work correctly:

Pre-Change Baseline: Record current DNS responses from multiple locations. This shows what should change and helps verify updates.

Authoritative Verification: Immediately after making changes, check authoritative servers to confirm they return new values. If they still show old values, the update hasn't taken effect.

Propagation Tracking: Monitor recursive resolvers from multiple locations. As caches expire, resolvers start returning new values. The propagation time depends on previous TTL values.

Fallback Planning: Before changing critical DNS records, ensure you can revert quickly. Reduce TTLs several hours before planned changes so updates and potential rollbacks propagate quickly.

This process—change, verify, wait, watch caches expire worldwide—is what DNS changes actually feel like. You can't rush propagation. You can only monitor it.

DNSSEC Monitoring

DNSSEC cryptographically signs DNS records to prevent tampering:

Validation Status: DNSSEC checks verify signatures are valid and the chain of trust remains intact. Invalid signatures indicate tampering or configuration problems.

Chain of Trust: DNSSEC relies on a hierarchy from root servers down to your domain. Breaks anywhere in this chain cause validation failures—but only for users whose resolvers validate DNSSEC.

Key Rotation: DNSSEC keys must be rotated periodically. Monitoring alerts you when keys approach expiration so you can rotate them before they break resolution.

DS Records: Delegation Signer records at your registrar link your domain's DNSSEC keys to the parent zone. If these don't match your current keys, DNSSEC validation fails.

Common DNS Problems

Different failure patterns indicate different issues:

NXDOMAIN: The domain doesn't exist. Either it was never registered, was deleted, or is completely misconfigured.

SERVFAIL: The DNS server encountered an error. This often indicates DNSSEC validation failures, server misconfigurations, or authoritative server unavailability.

Timeout: No response received. DNS servers might be down, firewalls might block queries, or network connectivity failed.

Wrong Values: Records exist but contain incorrect data. Someone misconfigured something, or your DNS provider is returning outdated cached values.

Missing Records: A query succeeds but returns no records of the requested type. Querying for AAAA records when only A records exist isn't an error, but it might indicate incomplete configuration.

Monitoring DNS Providers

If you use third-party DNS hosting:

Provider Availability: Monitor whether your DNS provider's servers respond to queries. If they go down, your domain becomes unreachable even though your web servers run perfectly.

Provider Performance: Track query response times from various locations. DNS provider performance varies by region.

Provider Accuracy: Verify the DNS provider serves the records you configured. Occasionally, provider APIs or control panels malfunction, causing records to not be published despite showing correctly in the interface.

Failover Testing: Some DNS providers offer automatic failover—if your primary IP stops responding, DNS switches to a backup. Monitoring verifies this actually works.

Split-Horizon DNS

Some organizations return different answers based on query source:

Internal vs. External: Internal users might receive private IP addresses (like 10.0.0.5) while external users receive public IPs. Monitoring must check both perspectives.

Geographic Responses: GeoDNS returns different IPs based on query location. Comprehensive monitoring checks from all relevant regions.

Network-Specific: Some carriers or ISPs use DNS to direct users to cache servers or content delivery networks. Monitoring from these networks reveals what their subscribers experience.