DNS is one of the oldest and most fundamental internet technologies. Every domain name lookup, every website visit, every email delivery depends on DNS working correctly. When DNS has problems, things break in ways that aren't always obvious.
Understanding DNS lookups—what they check, what they reveal, and how to interpret results—makes debugging network and email issues dramatically faster. A simple DNS query can reveal problems that would otherwise take hours of investigation to uncover.
How DNS Works
The Domain Name System translates human-readable domain names into IP addresses that computers use to communicate. When you type example.com into a browser, DNS resolves that name to an IP address like 93.184.216.34.
This resolution happens through a hierarchy of servers:
Your local DNS resolver - Usually provided by your ISP or configured manually (like Google's 8.8.8.8 or Cloudflare's 1.1.1.1). This resolver caches responses and queries other servers when needed.
Root nameservers - The top of the DNS hierarchy. They know where to find information about top-level domains (.com, .org, .net, etc.).
TLD nameservers - Servers responsible for specific top-level domains. The .com nameservers know which nameservers are authoritative for individual .com domains.
Authoritative nameservers - The servers that actually hold the DNS records for a specific domain. They provide definitive answers about that domain's configuration.
When you look up a domain, your resolver queries through this hierarchy to find the authoritative answer, then caches the result according to TTL (Time To Live) values.
Types of DNS Records
Different DNS record types serve different purposes. Understanding what each type does helps you know which records to check for different problems.
A Records map domain names to IPv4 addresses. This is the most basic record type—"this domain points to this IP." Most web hosting relies on A records.
AAAA Records map domain names to IPv6 addresses. The same concept as A records, but for the newer IP address format.
CNAME Records create aliases. A CNAME says "this domain is actually that other domain." When you look up a CNAME, you follow the chain until you reach an A record. CDNs and load balancers commonly use CNAMEs.
MX Records specify mail servers. When someone sends email to user@example.com, MX records tell the sending server which mail servers handle email for example.com. MX records include priority values—lower numbers are tried first.
TXT Records store arbitrary text. They're used for domain verification, SPF email authentication, DKIM signatures, and various other purposes where domains need to publish text data.
NS Records identify authoritative nameservers. These records tell the DNS system which servers are authoritative for a domain.
SOA Records contain administrative information about the DNS zone—serial numbers, refresh intervals, and responsible party contact information.
A DNS lookup API returns structured data that's easier to work with than parsing command-line output:
const response = await fetch(
'https://api.apiverve.com/v1/dnslookup?domain=example.com',
{ headers: { 'x-api-key': 'YOUR_API_KEY' } }
);
const { data } = await response.json();
// Check if domain can receive email
if (!data.records.MX || data.records.MX.length === 0) {
console.log('No MX records - domain cannot receive email');
}
// Get the IP address the domain points to
const ipAddress = data.records.A?.[0];
This structured response makes it easy to check specific record types and integrate DNS verification into automated workflows.
Debugging Connection Problems
When an application can't connect to a service, DNS is a common culprit. Connection errors that say "host not found" or "DNS resolution failed" point directly to DNS. But DNS problems can also cause timeouts and connection refused errors when the domain resolves to the wrong IP.
Check if the domain resolves at all. A domain that doesn't resolve in DNS simply doesn't exist from the internet's perspective. This could mean the domain registration expired, DNS isn't configured, or there's a problem with the authoritative nameservers.
Check if it resolves to the expected IP. A domain might resolve successfully but to an old IP address. After infrastructure changes, DNS might still point to decommissioned servers. Comparing the resolved IP to expected values catches this quickly.
Check if nameservers are responding. If a domain's authoritative nameservers are down, DNS resolution fails. The NS records tell you which nameservers should be responding.
Check multiple DNS resolvers. Different resolvers may have different cached data. If your local resolver has stale cache while others work fine, you've identified the problem.
DNS Propagation
DNS changes don't take effect instantly. When you update DNS records, those changes need to propagate through the caching hierarchy. This propagation can take minutes to hours, sometimes up to 48 hours for full global propagation.
TTL determines cache duration. Each DNS record has a Time To Live value that tells resolvers how long to cache the result. A TTL of 3600 seconds means resolvers can cache the record for one hour before re-querying.
Different resolvers update at different times. A resolver that queried your domain 5 minutes before you made a change will serve the old record for almost the full TTL. A resolver that queries after your change gets the new record immediately.
This causes "works for some users" problems. During propagation, some users see old records, others see new records. Traffic splits between old and new destinations until propagation completes.
DNS propagation checkers query multiple resolvers around the world and show whether they're returning consistent results. During propagation, you'll see mixed results. Once propagation completes, all resolvers return the same data.
Email Delivery Issues
Email delivery depends heavily on DNS. When email isn't arriving, DNS is often involved.
MX records must exist and be correct. A domain without MX records can't receive email. MX records must point to mail servers that actually accept mail for that domain.
MX records have priorities. Multiple MX records with different priority values provide failover. The lowest priority number is tried first. If that server is unavailable, senders try higher-numbered priorities.
Mail servers must be reachable. MX records pointing to non-existent or unreachable servers cause email delivery failures. Checking whether MX servers respond on port 25 confirms they're actually operating.
SPF, DKIM, and DMARC use DNS. Email authentication mechanisms publish their configuration in TXT records. Misconfigured authentication records cause email to be rejected or marked as spam.
When debugging email issues, checking MX records reveals whether email configuration exists. Checking TXT records shows whether email authentication is properly configured.
TTL Strategy
TTL values balance freshness against efficiency. Lower TTLs mean faster propagation but more DNS queries. Higher TTLs reduce query load but make changes slow to take effect.
Long TTLs (hours to days) work well for stable records that rarely change. Your main website IP that hasn't changed in years doesn't need a 5-minute TTL.
Short TTLs (minutes) make sense when you're planning changes or need quick failover. Before a migration, reducing TTL ensures the old value ages out of caches quickly.
Very short TTLs are sometimes used for dynamic DNS or rapid failover systems. TTLs under a minute are possible but increase DNS query volume significantly.
A common mistake is making changes with long TTLs still in effect. If your TTL is 24 hours, propagation takes up to 24 hours. Lower the TTL in advance, wait for the old TTL to expire, then make changes.
Multiple A Records and Load Balancing
DNS can return multiple A records for a single domain. Clients typically pick one, often in round-robin fashion. This provides basic load balancing and redundancy.
All returned IPs should be healthy. If DNS returns three IPs and one is unhealthy, roughly one-third of clients connect to the unhealthy server. This causes intermittent failures that can be difficult to diagnose.
DNS doesn't check health. DNS servers don't verify that the IPs they return are actually working. They just return configured records. Sophisticated setups use health-checking DNS services that automatically remove unhealthy IPs.
When debugging intermittent connectivity issues, checking whether the domain returns multiple IPs and whether all are healthy reveals this class of problem quickly.
CNAME Chains
CNAME records create aliases that point to other domains. Sometimes these chain—domain A is a CNAME to domain B, which is a CNAME to domain C, which finally has an A record.
Long CNAME chains add latency. Each step requires additional resolution. Most DNS clients limit chain length to prevent infinite loops.
CNAME chains complicate troubleshooting. When something goes wrong, you need to trace the entire chain to find the problem. The domain you're looking up might work fine, but something it points to might not.
SSL certificates must cover the original domain. If you access api.example.com and it's a CNAME to cdn.provider.net, the SSL certificate must include api.example.com, not just the CNAME target.
Tracing CNAME chains reveals the actual endpoints your domain points to and helps identify where in the chain problems occur.
DNS as a Monitoring Target
Given how critical DNS is, monitoring it makes sense:
Availability monitoring - Alert when authoritative nameservers stop responding.
Record change monitoring - Alert when DNS records change unexpectedly. This can indicate configuration errors, expired domains, or malicious changes.
Propagation monitoring - After intentional changes, confirm propagation completes as expected.
Response time monitoring - DNS should respond within milliseconds. Slow DNS resolution affects all dependent services.
DNS monitoring catches infrastructure problems that would otherwise manifest as mysterious application failures.
Common DNS Problems
Domain expired - Domain registrations must be renewed. An expired domain may stop resolving entirely or be taken over by someone else.
Nameserver misconfiguration - The domain's nameservers must actually be authoritative for it. Misconfigured nameservers cause resolution failures.
Missing records - A domain might exist but lack specific records. Missing MX records prevent email; missing A records prevent web access.
Wrong records - Records pointing to old IPs, decommissioned servers, or incorrect values cause traffic to go to wrong destinations.
TTL misconfiguration - Extremely long TTLs make recovery from problems slow. Extremely short TTLs increase load and can cause issues with rate-limited DNS services.
Delegation problems - The parent zone (like .com) must properly delegate to your nameservers. Delegation issues cause resolution failures even when your nameservers are correctly configured.
DNS and Security
DNS plays a role in several security considerations:
Domain hijacking - If attackers gain control of DNS, they can redirect traffic to malicious servers. Monitoring for unexpected record changes helps detect this.
DNS poisoning - Attacks that insert false data into DNS caches. DNSSEC helps prevent this by cryptographically signing DNS records.
Domain takeover - When a CNAME points to a service (like a cloud bucket) that no longer exists, attackers can sometimes claim that service and receive traffic intended for your domain.
Email spoofing - Without proper SPF, DKIM, and DMARC records, attackers can send email appearing to come from your domain.
DNS security starts with visibility—knowing what your records are and being alerted when they change unexpectedly.
Practical DNS Debugging
When troubleshooting, a systematic approach helps:
Start with basic resolution. Does the domain resolve at all? What does it resolve to?
Check record types relevant to the problem. Web issues need A/AAAA records. Email issues need MX records. Specific features might need TXT records.
Compare against expectations. Is the resolved IP what you expect? Are MX records pointing to your mail servers?
Check propagation if changes were made recently. Are all resolvers returning the same data, or is propagation still in progress?
Check the entire chain. If CNAMEs are involved, trace to the final destination.
Check nameserver health. Are the authoritative nameservers responding properly?
This systematic approach finds most DNS problems quickly. The specific query that reveals the issue depends on the symptoms, but following this progression covers the common cases.
The Debugging Checklist
For quick reference when troubleshooting:
- Does the domain resolve? (Check A/AAAA records)
- Does it resolve to the expected IP?
- Are nameservers responding? (Check NS records)
- Is DNS consistent globally? (Check propagation)
- What's the TTL? (How stale might caches be?)
- For email: Do MX records exist and point to working servers?
- For CNAMEs: What does the chain look like?
Most debugging workflows skip DNS entirely, checking application code, server configuration, and network routes while ignoring the name resolution that happens before any of that matters.
Adding DNS to your debugging checklist catches a category of problems that would otherwise require extensive investigation to identify.
Perform DNS lookups programmatically with the DNS Lookup API. Check global propagation with the DNS Propagation Checker API. Verify mail server configuration with the MX Lookup API. Debug DNS issues faster.
Originally published at APIVerve Blog
Top comments (0)