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 name server is acceptable.
• PTR records may have a value of * specified to indicate that any value is acceptable.

We've moved the Sunday, February 25th maintenance window that was announced in the previous post to take place on Monday, February 26th between 16:00 and 17:00 UTC.

The maintenance window was rescheduled so that mitigations for the Spectre and Meltdown vulnerabilities can be put in place at the same time as the hardware upgrade.

We anticipate that this maintenance will cause 5-15 minutes of downtime for our website.

We're going to migrate DNS Check's website to new and more powerful hardware on Sunday, February 25th starting at 1:00 am UTC. We anticipate that this migration 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.