DNS Check now supports monitoring HTTPS records and SVCB records, DNS record types 65 and 64, both standardized in RFC 9460. They tell a client how to connect to a service rather than only where it is: which HTTP versions the endpoint speaks, which port it listens on, which addresses it can start connecting to, and which keys it needs for Encrypted ClientHello, all before it opens a connection. SRV records have carried a target and a port since 2000, but they say nothing about the transport, and browsers never adopted them for HTTP. SVCB generalizes the idea and adds the transport parameters, and its HTTPS-specific form is the one browsers actually query.

You may already have these records without having added one yourself. Cloudflare answers HTTPS queries for the domains it proxies. AWS added HTTPS and SVCB records to Amazon Route 53 on October 30, 2024, and extended them to Amazon CloudFront in July 2025, where pointing a Route 53 alias record at a distribution leaves CloudFront to generate the record's contents for you. Other providers have followed. That means these records can change underneath you, and until today, DNS Check had no way to tell you when they did.

DNS Check now supports monitoring CAA records. A CAA (Certification Authority Authorization) record tells public certificate authorities (CAs) which of them, if any, are allowed to issue TLS/SSL certificates for your domain. Public CAs have been required to honor these records since 2017, so a CAA record is effectively an access control list for certificate issuance.

The failure modes are worth taking seriously. When a CAA record disappears, changes, or adds an entry for a CA you didn't authorize, the result can range from a renewal failing at the worst possible time to someone else obtaining a valid certificate for your domain.

DNS Check now has a dark mode. It took us a while to get here, but if you've ever been paged for a DNS problem at 2 a.m., you know why it's worth having: the alert fires, you open your laptop, and the monitoring dashboard hits you with a full screen of white.

DNS Check now supports two features for Enterprise accounts that make it easier to work as a team: Team Members and Additional Email Recipients. Team Members lets multiple people log in and work with your DNS records using their own credentials. Additional Email Recipients sends notification emails to people who need to stay informed but don't need to log in.

DNS Check's load balancer monitoring now supports CIDR notation, making it practical to monitor domains served by CDNs and cloud providers that use large IP pools. Instead of listing every possible IP address a provider might return, you can enter CIDR ranges like 104.16.0.0/13 and DNS Check will verify that responses fall within those ranges.

We're kicking off 2026 by shipping improvements that make DNS troubleshooting faster and more intuitive. When a DNS check fails, you'll now see exactly what needs to change to fix it, and you'll have complete visibility into your DNS record behavior over time.

Suggested Fix Report

When a DNS record check fails, the new Suggested fix report shows exactly what action you need to take. Instead of manually comparing "Expected" vs "Found" records character-by-character, DNS Check now performs that comparison for you and presents clear guidance.

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 name servers (amzndns.*) hosted by Vercara, LLC (UltraDNS)
• aws.com and aws.amazon.com use name servers (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 name servers, 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