DNS Is Your Site's Phone Book. Here Is What Happens When the IPv6 Entry Goes Stale.
Picture a phone book where your business has two listings: one for your landline, one for your mobile. Customers who look up the landline number get through fine. But the mobile number in the book is three years old, from a phone you cancelled when you moved offices. Anyone who dials it hears a dead tone. You have no idea this is happening because your landline works perfectly and nobody calls to complain. They just stop calling.
That is exactly how DNS works for your website when it comes to IPv4 and IPv6. Your domain name has two types of "phone number" entries. One sends visitors to your site over IPv4. The other sends them over IPv6. If the IPv6 entry is missing, outdated, or pointing to a server that no longer exists, a growing segment of your audience quietly cannot reach you. Your monitoring tool checks the IPv4 path, sees a healthy response, and reports 100% uptime. Meanwhile, mobile users in Tokyo, Sao Paulo, and Mumbai see nothing but error screens.
This guide explains DNS in plain, business-friendly language. You will learn what A records and AAAA records actually do, why they go wrong more often than anyone admits, and what you should be monitoring to prevent the kind of invisible outage that drains revenue without triggering a single alert.
DNS in 60 Seconds: The Phone Book Analogy
DNS stands for Domain Name System. Its job is simple: when someone types "yourcompany.com" into a browser, DNS translates that human-readable name into a numeric address that computers use to find your server. Without DNS, your visitors would need to memorize long strings of numbers to reach your website.
Think of DNS as a phone book. Your domain name is your business name. The numeric addresses are your phone numbers. And just like a phone book can have multiple listings for the same business (main office, mobile, fax), DNS can have multiple entries for the same domain. The two entries that matter most for this conversation are:
- A record = your "landline number" = the IPv4 address (looks like
203.0.113.5) - AAAA record = your "mobile number" = the IPv6 address (looks like
2001:db8::5)
When a visitor's device wants to reach your site, it looks up your domain in DNS. If the device prefers IPv4, it grabs the A record. If it prefers IPv6, it grabs the AAAA record. Modern devices often look up both and try whichever connects faster. If only one record exists, the device uses that one. If the record it tries points to a dead server, the visitor gets an error.
Why Two Records Exist (and Why Both Matter)
IPv4 has been the standard internet protocol for decades. Every website, server, and device has an IPv4 address. The problem is that IPv4 addresses are running out. There are only about 4.3 billion of them, and the internet has grown far beyond that. IPv6 was created to solve this shortage. It provides an almost unlimited supply of addresses.
Today, both protocols run side by side. Many internet service providers, especially mobile carriers, have shifted heavily toward IPv6. In countries like India, over 70% of Google traffic comes over IPv6. In the United States, major carriers like T-Mobile and Verizon route most mobile traffic over IPv6.
For your business, this means a meaningful percentage of your audience may be connecting over IPv6 right now. If your AAAA record is missing or broken, those connections fail. The visitor's browser may eventually fall back to IPv4 (if available), but that fallback adds delay. Sometimes it fails entirely, especially on IPv6-only mobile networks that do not have a fallback path.
The bottom line: your A record handles one set of customers, your AAAA record handles another. Both records need to be accurate, current, and pointing to a server that actually responds. Neglecting either one is the equivalent of publishing a disconnected phone number in the yellow pages.
The Five Most Common DNS Mistakes That Break IPv6
Here is the frustrating truth about IPv6 outages: the majority of them are not caused by server crashes or network failures. They are caused by simple DNS errors. Someone forgot to update a record. Someone did not know a record existed. Someone changed hosting providers and only updated half of their DNS configuration. These mistakes are easy to make and hard to detect without the right monitoring in place.
1. The forgotten AAAA record after a server migration
This is the single most common DNS-related IPv6 outage. Your company moves to a new hosting provider or a new server. Your developer updates the A record to point to the new server's IPv4 address. Everything works. The old server gets decommissioned. Nobody remembers that the AAAA record still points to the old server's IPv6 address.
The result: IPv4 users happily reach the new server. IPv6 users try to connect to a server that no longer exists. They get timeouts, connection refused errors, or simply a blank page. This situation can persist for weeks or months because the team's own testing (typically from office networks over IPv4) works perfectly.
2. DNS TTL set too high during a transition
TTL stands for Time To Live. It tells DNS resolvers around the world how long they can cache your record before checking for updates. If your AAAA record has a TTL of 86400 (24 hours), and you change the record, some resolvers will keep serving the old address for up to a full day.
This is a problem during migrations. You update the AAAA record, but visitors keep reaching the old server because their ISP's resolver cached the old address. The fix is simple: lower your TTL to 300 seconds (5 minutes) before any planned migration, wait for the old TTL to expire, then make the change. But teams forget this step constantly.
3. The CDN that dropped IPv6 support
You move your site behind a CDN (content delivery network) for performance and security. The CDN handles IPv4 perfectly, but their IPv6 support is incomplete, disabled on your plan, or simply broken. Your AAAA record now points to a CDN edge that does not respond over IPv6. Or worse, the CDN removes your AAAA record entirely without telling you.
IPv4 users get the fast, cached CDN response. IPv6 users either get errors or have their connections silently dropped. For more on this specific problem, see why your site can be up on IPv4 but down on IPv6 through your CDN.
4. The zombie AAAA record
Your company set up IPv6 years ago. The person who configured it has since left. The IPv6 infrastructure was quietly retired because nobody was maintaining it, but the AAAA record in DNS was never removed. It still points to an IP address that no longer belongs to your organization. At best, that address leads nowhere. At worst, someone else now owns that address and your AAAA record sends your IPv6 visitors to a stranger's server.
5. Inconsistent records across DNS providers
Some organizations use multiple DNS providers for redundancy. If the providers are not synchronized, one might serve the correct AAAA record while the other serves an outdated or missing one. The result is intermittent IPv6 failures: some visitors reach your site, others do not, depending on which DNS provider their resolver queried. These failures are maddening to debug because they seem random.
How Browsers Choose Between IPv4 and IPv6
When a visitor types your domain into a browser, the browser does not just pick IPv4 or IPv6 at random. Modern browsers use an algorithm called "Happy Eyeballs" (yes, that is its real name). Here is how it works in simple terms:
- The browser looks up both the A record (IPv4) and the AAAA record (IPv6) simultaneously.
- It starts a connection attempt over IPv6 first (because IPv6 is preferred on modern systems).
- If the IPv6 connection does not succeed within about 250 milliseconds, it starts a parallel connection attempt over IPv4.
- Whichever connection succeeds first wins. The browser uses that one and drops the other.
This sounds like a safety net, and it partially is. But here is what it means in practice:
- Broken IPv6 adds latency even when IPv4 works. The browser spends 250 ms trying IPv6, fails, then falls back to IPv4. Your page load is a quarter of a second slower for every affected visitor. That adds up.
- Some networks are IPv6-only. On these networks, there is no IPv4 fallback. If your AAAA record is broken, these visitors simply cannot reach you. Mobile carriers increasingly use this configuration.
- The delay is per connection, not per page. A single web page often opens multiple connections (for images, scripts, fonts, API calls). If each one pays the 250 ms penalty, the cumulative slowdown is severe.
The takeaway: even if IPv4 "catches" the failure, broken IPv6 hurts your site's performance and user experience. It is not a harmless background issue.
What You Should Be Monitoring
Knowing the risks is one thing. Detecting them before they cost you money is another. Here is what a proper DNS and dual-stack monitoring setup looks like:
Monitor both protocols independently
A single uptime monitor that does not specify a protocol will almost always connect over IPv4. It will show 100% uptime even while your IPv6 endpoint is completely broken. You need separate monitors: one that forces IPv4, one that forces IPv6. UptyBots lets you set the network type on each monitor, so each check resolves and connects using only the protocol you specify.
For step-by-step instructions, see our guide on setting up separate IPv4 and IPv6 uptime checks.
Monitor from multiple geographic locations
DNS answers can differ depending on where in the world the query comes from. A resolver in Frankfurt might return the correct AAAA record while a resolver in Singapore returns an outdated one. UptyBots's multi-location monitoring catches these inconsistencies because probes in different regions resolve DNS independently.
Watch for diverging uptime between protocols
The most valuable signal from dual-stack monitoring is when one protocol's uptime diverges from the other. If your IPv4 monitor shows 99.99% and your IPv6 monitor shows 98.5%, you have a recurring IPv6 problem. The gap between the two numbers is the exact amount of hidden downtime you were previously unaware of. Track this gap over time to measure whether your infrastructure improvements are working.
Pay attention to response time differences
Even when both protocols show high uptime, significant response time differences can indicate problems. If your IPv4 checks average 50 ms and your IPv6 checks average 250 ms, your IPv6 traffic is taking a much longer network path. This might mean your CDN is not properly configured for IPv6, or your hosting provider's IPv6 routing is suboptimal.
How to Test Your DNS Setup Right Now
You do not need to be a networking expert to verify your DNS configuration. Here are four approaches, from the simplest to the most thorough:
Option 1: Ask your developer (30 seconds)
Send this message to whoever manages your hosting: "Does our domain have both an A record and an AAAA record? Are both pointing to active servers?" A competent developer or hosting provider will answer this in under a minute.
Option 2: Use an online tool (2 minutes)
Go to a DNS checker website like dnschecker.org. Type in your domain. Look for both A and AAAA results. The tool will show you what different resolvers around the world see when they look up your domain. If you see an A record everywhere but AAAA results are missing or inconsistent, you have a problem.
Option 3: Run a command (2 minutes)
If you have access to a terminal, these commands show your current DNS state:
# Look up your IPv4 address dig A yourcompany.com +short # Look up your IPv6 address dig AAAA yourcompany.com +short
Both should return an address. If the second command returns nothing, you have no AAAA record and IPv6 users cannot resolve your domain.
Option 4: Check from multiple resolvers (5 minutes)
DNS propagation issues mean different resolvers might return different answers. Query a few of the big public resolvers to check consistency:
# Google Public DNS dig AAAA yourcompany.com @8.8.8.8 +short # Cloudflare DNS dig AAAA yourcompany.com @1.1.1.1 +short # Quad9 dig AAAA yourcompany.com @9.9.9.9 +short # Your ISP's default resolver dig AAAA yourcompany.com +short
All four should return the same IPv6 address. If they differ, your DNS change has not fully propagated, or your DNS providers are not synchronized.
Real-World DNS Disasters (and What They Cost)
These are not hypothetical scenarios. They are patterns that UptyBots users discover regularly when they first set up dual-stack monitoring.
The e-commerce site that lost 15% of mobile traffic for three weeks
A mid-size online retailer migrated to a new cloud provider. Their ops team updated the A record the same day. The AAAA record was forgotten because their migration checklist only mentioned "update DNS" without specifying both record types. For three weeks, mobile users on IPv6-only carriers in India and Brazil could not reach the checkout page. The company noticed a dip in mobile conversion rates but attributed it to a "seasonal trend." Only after setting up separate IPv4 and IPv6 monitors did they discover the AAAA record was pointing to a decommissioned server.
The SaaS company with a zombie AAAA record
A B2B SaaS platform had set up IPv6 two years earlier as a proof of concept. The engineer who did the work left the company. The IPv6 infrastructure was quietly shut down during a cost-cutting round, but the AAAA record was never removed. For over a year, any IPv6-capable client that preferred IPv6 would attempt to connect, fail, and then fall back to IPv4 after a noticeable delay. The SaaS company's own testing never caught it because their office network used IPv4.
The media site that published conflicting DNS records
A news website used two DNS providers for redundancy. After a server move, one provider was updated with the new AAAA record. The other provider was not. Roughly half of all IPv6 queries returned the correct address. The other half returned the old, dead address. The result was intermittent IPv6 failures that seemed completely random. User reports ranged from "site is fine" to "site is completely down." Debugging took days until someone thought to query both DNS providers separately.
A Simple DNS Health Checklist for Business Owners
You do not need to understand the technical details to keep your DNS healthy. Just make sure these items are covered:
- Both records exist. Your domain should have an A record (IPv4) and an AAAA record (IPv6) if you serve any IPv6-capable audience.
- Both records point to live servers. Every address listed in DNS should respond to web traffic. Do not leave records pointing to decommissioned infrastructure.
- Both records are updated together. Any time you change your A record (server migration, CDN change, IP update), update the AAAA record at the same time. Add this to your migration checklists.
- TTL is reasonable. A TTL of 300 to 3600 seconds (5 to 60 minutes) works for most sites. Lower it before planned changes, then raise it back afterward.
- DNS providers are synchronized. If you use multiple DNS providers, verify they serve identical records. Automate this if possible.
- Monitoring covers both protocols. Set up separate IPv4 and IPv6 monitors so you are alerted the moment one protocol diverges from the other.
Frequently Asked Questions
Do I really need both A and AAAA records?
If you serve a global audience, yes. IPv6 adoption is over 40% worldwide and climbing. Mobile networks in India, Brazil, the United States, and across Asia route significant traffic over IPv6. Even in markets where IPv6 adoption is lower, having a working AAAA record avoids the latency penalty from failed IPv6 connection attempts.
What if we have not set up IPv6 at all?
That is a valid choice, but make sure you do not have a stale AAAA record sitting in your DNS. If there is no AAAA record, browsers will not attempt IPv6 connections and there is no penalty. The danger is having an AAAA record that points to nothing: that forces browsers to try IPv6, fail, wait, and fall back, making your site slower for every IPv6-capable visitor.
How long does DNS propagation take?
It depends on the TTL of the old record. If the old TTL was 3600 seconds (1 hour), most resolvers will update within an hour. If it was 86400 (24 hours), it can take a full day. Some ISP resolvers ignore TTL and cache longer. In practice, most changes propagate globally within a few hours.
How does UptyBots help with DNS monitoring?
UptyBots resolves both A and AAAA records, tests reachability over each protocol independently, and alerts you when either one becomes unavailable. Because checks run from multiple global locations, you also catch regional DNS inconsistencies that would be invisible from a single testing point.
Should I use the same DNS provider for both record types?
Yes, unless you have a specific technical reason to split them. Using a single provider for both A and AAAA records keeps them synchronized and eliminates the risk of inconsistent records across providers. If you do use multiple providers, automate record synchronization and monitor both providers independently.
Can a CDN handle my AAAA records automatically?
Some CDNs manage DNS records for you when you point your domain to them, including creating AAAA records for IPv6 support. But not all CDN plans include IPv6, and some CDNs handle IPv6 inconsistently across their edge network. Verify that your CDN actually serves IPv6 traffic by testing with curl -6 https://yourdomain.com or by checking with your CDN provider directly.
The Cost of Getting This Wrong
DNS mistakes are uniquely dangerous because they are silent. A server crash shows up in every monitoring tool. A DNS misconfiguration affecting only IPv6 slips through the cracks of any monitoring system that does not specifically test both protocols.
The financial impact scales with your traffic. If 20% of your visitors arrive over IPv6 and your AAAA record has been broken for a month, you have lost roughly 20% of potential conversions for that entire period. For a site generating $50,000 per month, that is $10,000 in invisible lost revenue. For larger sites, the numbers multiply accordingly.
The fix is not expensive or complicated. It takes about ten minutes to set up separate IPv4 and IPv6 monitors, and the ongoing cost is minimal. The alternative is flying blind and hoping your DNS is correct, which is not a strategy anyone would recommend for any other part of their business infrastructure.
Start monitoring both protocols today: see our tutorials or choose a plan.