On October 19-20, 2025, Amazon Web Services (AWS) experienced a significant outage (AWS status) affecting its US-EAST-1 region in northern Virginia. The root cause was DNS resolution failures for DynamoDB’s API endpoints, which cascaded across AWS’s interconnected services, disrupting major platforms including Snapchat, McDonald’s, Disney+, Roblox, Coinbas, Reddit, and Amazon’s own services.

While investigating the outage, I discovered that Amazon doesn’t use its own AWS Route 53 service for amazon.com’s DNS.

Eating Your Own Dog Food

“Eating your own dog food” (or “dogfooding”) is a practice where a company uses its own products or services internally. The phrase originated in the 1980s in the technology industry, and it serves several important purposes:

  1. Quality assurance: Internal usage exposes bugs and usability issues before customers encounter them
  2. Credibility: Demonstrating confidence in your own products builds customer trust
  3. Employee understanding: Teams gain firsthand experience with what they’re building and selling

Many major technology companies have embraced dogfooding as a core principle. Atlassian uses Jira for all internal development, recently detailing how they dogfood new features like their Rovo Dev coding agent across all internal Jira sites. Slack deploys every new feature to an internal “Dogfood” tier first, where all Slack employees use it before external customers see it, helping catch problems early.

These companies understand that if their products aren’t good enough for their own use, they shouldn’t be selling them to customers. A company that uses its own products creates a positive feedback loop, making the products even better.

DNS Check follows this same principle. We monitor our own critical DNS records using our service, including dnscheck.co’s authoritative nameservers, MX records, and TXT records. When we add new features or make infrastructure changes, we experience the same monitoring alerts, notification workflows, and diagnostic tools that our customers use. This internal usage helps us identify potential improvements and ensures we’re building features that genuinely matter for DNS monitoring.

Amazon’s DNS Infrastructure Choice

Given the importance of dogfooding, it’s notable that Amazon doesn’t use Route 53 for its flagship domain. Route 53 is AWS’s managed DNS service, marketed for its scalability, reliability, and global infrastructure. Yet amazon.com relies on third-party DNS infrastructure from Vercara (formerly Neustar’s UltraDNS).

The decision predates the launch of Route 53 in December 2010. Amazon was already using UltraDNS for amazon.com in 2009, when a DDoS attack on UltraDNS briefly took down amazon.com. Migrating a domain as critical as amazon.com to a new DNS provider carries significant risk, even when that provider is your own service. However, this choice means Amazon doesn’t directly experience Route 53’s operational characteristics for its most critical domain.

The October 19-20 outage adds an interesting dimension to this situation. AWS experienced a significant disruption due to DNS failures affecting its internal infrastructure, but its most public-facing domain operates on a different DNS provider’s infrastructure. Had Amazon been using Route 53 for amazon.com, it would have had more firsthand operational experience with Route 53’s behavior in similar public-facing scenarios.

Steps to Reproduce

To verify that Amazon uses third-party DNS infrastructure instead of its own Route 53 service, you can follow these steps using standard command-line tools.

Note for Windows users: The examples below use dig and whois (common on Linux/macOS). On Windows, you can use nslookup instead of dig (nslookup examples are provided alongside dig). Windows does not include whois by default. You can use an online tool like who.is or whois.com for IP address lookups.

1. Check amazon.com’s authoritative nameservers

First, query the authoritative nameservers for amazon.com:

$ dig amazon.com NS +short
ns2.amzndns.org.
ns1.amzndns.net.
ns2.amzndns.com.
ns2.amzndns.co.uk.
ns1.amzndns.co.uk.
ns1.amzndns.com.
ns1.amzndns.org.
ns2.amzndns.net.

Or on Windows using nslookup:

> nslookup -type=NS amazon.com

Notice the naming pattern: *.amzndns.* - these are not Route 53 nameservers.

2. Compare with Route 53 nameserver patterns

For comparison, check the nameservers for aws.com, which uses Route 53:

$ dig aws.com NS +short
ns-2028.awsdns-61.co.uk.
ns-1500.awsdns-59.org.
ns-164.awsdns-20.com.
ns-917.awsdns-50.net.

Or on Windows:

> nslookup -type=NS aws.com

Route 53 nameservers follow the pattern ns-[number].awsdns-[number].[tld] where the TLD is typically .com, .net, .org, or .co.uk. This is the standard naming convention for all Route 53 public hosted zones.

Note that aws.amazon.com uses a mix of nameservers, including some Route 53 servers alongside AWS-internal infrastructure:

$ dig aws.amazon.com NS +short
tp.8e49140c2-frontier.amazon.com.
dr49lng3n1n2s.cloudfront.net.
ns-1860.awsdns-40.co.uk.
ns-106.awsdns-13.com.
ns-905.awsdns-49.net.
ns-1402.awsdns-47.org.

Or on Windows:

> nslookup -type=NS aws.amazon.com

The presence of awsdns.* nameservers confirms that aws.amazon.com uses Route 53.

3. Identify who owns the amzndns nameservers

Look up the IP address of one of amazon.com’s nameservers:

$ dig ns1.amzndns.com A +short
156.154.64.10

Or on Windows:

> nslookup ns1.amzndns.com

Check the ownership of this IP address using whois:

$ whois 156.154.64.10 | grep -E "^(NetRange|OrgName|Organization):"
NetRange:       156.154.60.0 - 156.154.80.255
OrgName:        Vercara, LLC

The IP addresses for all amzndns nameservers fall within the 156.154.60.0 - 156.154.80.255 range owned by Vercara, LLC (formerly Neustar). Vercara operates the UltraDNS managed DNS service.

Note: The grep patterns shown are compatible with ARIN (American Registry for Internet Numbers) output format. WHOIS output may vary slightly between different regional registries, but the ownership information will be present.

You can verify additional nameservers follow the same pattern:

$ dig ns2.amzndns.net A +short
156.154.69.10

$ dig ns1.amzndns.org A +short
156.154.66.10

$ whois 156.154.69.10 | grep -E "^(NetRange|OrgName):"
NetRange:       156.154.60.0 - 156.154.80.255
OrgName:        Vercara, LLC

Or on Windows:

> nslookup ns2.amzndns.net
> nslookup ns1.amzndns.org

4. Confirm Route 53 nameserver ownership

For comparison, verify that Amazon owns the Route 53 nameservers:

$ dig ns-106.awsdns-13.com A +short
205.251.192.106

$ whois 205.251.192.106 | grep -E "^(NetRange|OrgName):"
NetRange:       205.251.192.0 - 205.251.255.255
OrgName:        Amazon.com, Inc.

Or on Windows:

> nslookup ns-106.awsdns-13.com

5. Verify nameserver software identification

As a final confirmation, you can query the nameservers directly to identify their DNS software using a CHAOS class query:

$ dig +short CHAOS TXT version.bind @156.154.64.10
"UltraDNS Nameserver"

Or on Windows:

> nslookup -class=CHAOS -type=TXT version.bind 156.154.64.10

The UltraDNS nameserver explicitly identifies itself as “UltraDNS Nameserver”. Route 53 nameservers typically don’t respond to these CHAOS queries (they time out), which is a security practice to avoid revealing implementation details.

Summary

The evidence shows that:

  • amazon.com uses nameservers (amzndns.*) hosted by Vercara, LLC (UltraDNS)
  • aws.com and aws.amazon.com use nameservers (awsdns.*) hosted by Amazon.com, Inc. (Route 53)

Why This Matters

Amazon’s choice to use UltraDNS instead of Route 53 for amazon.com doesn’t necessarily indicate a problem with Route 53. Large enterprises often maintain DNS infrastructure decisions made years before newer solutions existed, and the risk of migrating critical domains can outweigh potential benefits. UltraDNS is a well-regarded DNS provider with a strong track record.

However, the lack of dogfooding does mean Amazon misses opportunities that come from using its own service for its most critical domain:

  1. Operational experience: Running amazon.com on Route 53 would give Amazon direct insight into Route 53’s behavior under the same traffic patterns and reliability requirements it demands for its primary domain. This real-world testing would complement its existing internal usage and customer feedback.

  2. Incident response: During DNS-related outages like the October 19-20 incident, having its primary domain on the same DNS infrastructure would provide additional operational data and motivation to resolve issues quickly. Teams would experience the same pain points as customers.

  3. Customer confidence: When AWS sells Route 53 to enterprises for their mission-critical domains, those customers might reasonably wonder why Amazon doesn’t use it for amazon.com. Dogfooding sends a strong signal about a product’s readiness for production use.

  4. Feature validation: New Route 53 features and performance improvements would be validated against one of the world’s highest-traffic domains, ensuring they work at scale before customers deploy them.

The October 19-20 outage highlighted how DNS failures create cascading problems across dependent services. While that outage affected AWS’s internal DNS infrastructure rather than Route 53, it demonstrates why DNS reliability matters for Amazon’s business. Using Route 53 for amazon.com would align its most visible domain with the DNS service it recommends to customers.

The Importance of DNS Monitoring

Whether you’re using Route 53, UltraDNS, or any other DNS provider, proactive monitoring remains essential. The AWS outage demonstrated how DNS issues can rapidly cascade, impacting services that rely on DNS resolution. Without monitoring, DNS problems often go undetected until users report failures.

DNS Check provides continuous monitoring for your DNS records, alerting you immediately when issues occur. Our service monitors authoritative nameservers from multiple global locations, ensuring that they respond correctly and return the expected values. When DNS problems arise, let DNS Check notify you before your customers do.

We eat our own dog food by monitoring our own DNS infrastructure with DNS Check. This means we rely on the same monitoring, alerting, and diagnostic tools that we provide to customers. When we improve DNS Check, we directly benefit from those improvements ourselves.

Ready to add DNS monitoring to your infrastructure? Sign up for a free DNS Check account and start monitoring your critical DNS records today. Whether you’re running on AWS, managing your own infrastructure, or using any other provider, DNS Check helps you catch DNS issues before they cascade into larger problems.