We're excited to announce one of our most frequently requested features: inverted DNS checks. This new capability allows you to detect when DNS records are created (whether they're planned infrastructure changes or rogue records) and prevent unwanted values from appearing in your DNS configuration.

Understanding Inverted Checks

Traditional DNS monitoring follows straightforward logic: the check passes when your DNS records match the expected configuration. An A record check for example.com pointing to 192.0.2.100 passes when DNS queries return that specific IP address and fails when the record is absent or returns a different value.

Inverted checks reverse this logic. When you enable the "Invert check" option, the check passes when the DNS record is not found or when it exists with a value that differs from the specified value. This inverted logic addresses common operational scenarios that traditional monitoring systems can't handle.

Updated October 24, 2025: Added TL;DR per reader feedback for clarity.

TL;DR

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)

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, Coinbase, 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.

Early on October 20, 2025, Amazon Web Services (AWS) experienced a significant outage 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. The incident disrupted major platforms including Signal, Snapchat, Fortnite, Reddit, Coinbase, Ring, Amazon's own Alexa and Prime Video services, and banking applications for institutions like Bank of Scotland, Halifax, and Lloyds.

This outage demonstrates a fundamental truth about modern cloud infrastructure: DNS failures create disproportionate impact. When DNS resolution fails, even perfectly healthy servers become unreachable, effectively taking services offline.

Timeline and Technical Details

AWS first reported elevated error rates across multiple services at approximately 3:11 AM ET. The company identified the root cause as DNS resolution issues affecting DynamoDB API endpoints in the US-EAST-1 region. DynamoDB serves as a foundational service for many AWS offerings, so DNS failures preventing applications from resolving DynamoDB endpoints created cascading failures across more than 70 AWS services.

By 6:35 AM ET, AWS reported that the DNS issue had been "fully mitigated" and service operations were returning to normal. However, some services experienced lingering effects as backlogs cleared and systems recovered. The total disruption lasted approximately 3-4 hours for most affected services.

The incident highlights how DNS is a critical dependency of distributed systems. When DNS resolution fails, services can't locate the API endpoints they depend on. This creates the same observable failure as if those endpoints were completely offline, even though the underlying infrastructure might be functioning normally.

Over the past few months, we've heard from DNS Check customers encountering increasingly complex DNS configurations. Modern domains often accumulate dozens of TXT records for email authentication, domain verification, and security tokens, creating responses that exceed traditional UDP limits and trigger complex fallback mechanisms. These scenarios were generating confusing error messages and, in some cases, false alerts when DNS servers didn't handle large responses correctly.

We're excited to announce significant performance and reliability enhancements that directly address these challenges. These improvements make DNS troubleshooting clearer, reduce false alerts, and ensure accurate monitoring of your critical DNS records, regardless of how complex your DNS configuration becomes.

Enhanced DNS Error Diagnostics

We're excited to announce two significant enhancements to DNS Check: DNS Record Flapping Detection and Extended Notification History. These features streamline the troubleshooting process for recurring DNS resolution errors and reduce repetitive notifications.

DNS Record Flapping Detection

DNS record flapping occurs when a record rapidly alternates between passing and failing states. With our new feature, DNS Check identifies records that change state six or more times within two hours as flapping. This proactive detection serves two primary purposes:

We will migrate DNS Check’s infrastructure to more powerful hardware on Saturday, July 24. The maintenance window will begin at 12 am UTC and end at 1 am UTC.

We anticipate that this migration will cause 10-15 minutes of downtime for our website and API endpoints. Monitoring of some DNS records will also be delayed by up to 15 minutes.

The upgrade will make DNS Check's website snappier and increase the number of DNS records we can monitor. We've grown steadily since our last major hardware upgrade in 2018. We still have spare capacity from the 2018 upgrade but are upgrading now to ensure that we stay well ahead of the growth curve.

Happy New Year! We want to kick off 2021 by announcing some improvements to DNS Check.

1. Extended the Notification History

When troubleshooting an intermittent problem or flapping record, it's useful to see what failures occurred in the past and look for patterns. DNS Check maintains a log of the notifications sent for each monitored DNS record to support that type of troubleshooting. Each record's log can be viewed by clicking its History button.

We're going to replace some of the hardware that runs DNS Check's website on Friday, May 8th, between 4:15 am and 12:15 pm UTC.

A few minutes of degraded performance is expected towards the beginning of this window.

Website downtime is possible, but not expected. If downtime does occur, then it's expected to last approximately 5 minutes.

We're going to perform software updates to DNS Check's website on Sunday, December 30th between 11:00 pm and 11:30 pm UTC. We anticipate that the updates will cause 5-10 minutes of downtime for our website.

If you're using our API for DNS record monitoring, then we recommend scheduling a maintenance window within your monitoring system which covers this window.

Back in 2016, we added support for monitoring wildcard DNS records. Wildcard DNS records are used to serve requests for otherwise non-existent domain names. For example, if you created a wildcard record for *.example.com, but not a foo.example.com record, queries for foo.example.com would receive the IP addresses specified for *.example.com in response.

Today we're pleased to announce that we've extended our support for using wildcards in DNS records monitoring. DNS Check now allows you to specify a wildcard (*) in place of some DNS record values, such as an A record's IP address to indicate that any value is acceptable, but the record must exist.

Wildcard values are supported in the following areas:

• A and AAAA records may have an IP address of * specified.
• CNAME records may have a value of * specified to indicate that they may point to any domain.
• MX records may have an exchange of * specified to indicate that any exchange is acceptable.
• NS records may have a value of * specified to indicate that any nameserver is acceptable.
• PTR records may have a value of * specified to indicate that any value is acceptable.