DNS Check Blog

New Features: Team Members and Additional Email Recipients

Mon, 06 Apr 2026 04:00:00 -0400

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.

Team Members

The Team Members feature lets you invite other people to log in and work with your DNS Check account. Each team member gets their own email and password, so there's no need to share a single set of credentials. This is useful when multiple people on your team need to view, create, or manage DNS records.

Roles

Each team member has one of three roles to control what they can access:

Role	DNS Records	Account Settings
Admin	View, create, edit, delete	Full access
Manager	View, create, edit, delete	No access
Viewer	View only	No access

Admin team members see the same interface as the account owner and can access all account-level settings, including billing, notification configuration, integrations, and API keys. Manager team members can manage DNS records, but can't access account settings. Viewer team members can only view DNS records and their status, which is useful for stakeholders who need visibility without the ability to make changes.

Adding Team Members

To add a team member, click the user icon in the top navigation bar and select Team Members. From there, click Add team member, enter their email address, and select a role.

The team member receives an email invitation with a link to set their password. Once they set their password, they can log in and start working with your DNS records. You can change a team member's role or remove them from the Team Members page.

The number of team members you can add depends on your Enterprise plan tier.

Additional Email Recipients

The Additional Email Recipients feature lets you send DNS Check notification emails to additional email addresses beyond your primary account email. This is designed for people or services that need to receive alerts about DNS record changes but don't need to log in to DNS Check.

Setting Up Recipients

To add a recipient, go to the Email tab on your Notification Settings page, find the Additional Email Recipients section, and click the Add email recipient button.

The recipient receives a confirmation email and must click the confirmation link before they start receiving notifications. This confirmation step prevents unwanted emails from being sent to addresses that didn't opt in.

Managing Recipients

Once added, you can manage recipients from the Notification Settings page:

For each recipient, you can:

Resend confirmation if the recipient didn't receive the confirmation email
Enable/Disable to temporarily pause notifications without removing the recipient
Delete the recipient

Recipients can also unsubscribe themselves using the unsubscribe link included in every notification email.

You can turn notifications to your primary account email address on and off by toggling the Send notifications to control on the Email tab of your Notification Settings.

When to Use Each Feature

These two features serve different needs:

Team Members is for people who need to log in to DNS Check, whether to view DNS record status, create new records, or manage account settings. Each team member has their own credentials and a defined level of access.
Additional Email Recipients is for people who need to receive notification emails, such as an on-call distribution list, a manager who wants to stay informed, or a ticketing system that ingests emails.

You can use both features together. For example, you might add your software developers and sysadmins as team members with the Manager role so they can create and edit records, add cyber security team members with the Viewer role so they can check status without making changes, and add an ops mailing list as an additional email recipient so the broader team gets notified about DNS issues.

Get Started

Team Members and Additional Email Recipients are available now for all Enterprise accounts. To start using them, log in and visit the Team Members page and your Notification Settings.

If you're not yet using DNS Check, create a free account to start monitoring your DNS records. Free accounts can monitor up to 10 DNS records with email notifications. To unlock Team Members, Additional Email Recipients, and other Enterprise features, visit our Features page to find the right plan for your team.

Monitor Load Balanced DNS Records with CIDR Ranges

Sat, 07 Feb 2026 10:00:00 -0500

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.

How Load Balancer Monitoring Works

Before diving into the CIDR improvements, here's a quick overview of how DNS Check monitors load-balanced records.

Many DNS configurations return multiple IP addresses for a single domain name. This is DNS-based load balancing: traffic is distributed across servers for performance, redundancy, or geographic routing. When you query a load-balanced domain, you might get back one, some, or all of its configured addresses, often in a different order each time.

DNS Check handles this by letting you enter the full set of valid IP addresses or hostnames for a load-balanced record. Each time the record is checked, DNS Check compares the response to your list. If every returned address appears in your list, the check passes. If any returned address isn't in the list, the check fails. The order doesn't matter, and partial responses (a subset of your list) are fine.

This approach works well for load balancers with a small, fixed set of IPs. But some providers rotate responses across hundreds or thousands of addresses, which is where CIDR support comes in.

CIDR Range Monitoring

Providers like Cloudflare, Fastly, and other CDNs serve content from large IP pools. A Cloudflare-proxied domain might resolve to any address within several /13 or /20 ranges. Listing individual IPs would be impractical and fragile, as providers regularly add and rotate addresses within their published ranges.

With CIDR support, you can enter ranges like 104.16.0.0/13 directly in the "IP addresses" field. DNS Check then verifies that each IP returned in a DNS response falls within one of the specified CIDR ranges. This works for both IPv4 (A record) and IPv6 (AAAA record) load balancers.

For example, Cloudflare publishes its IP ranges. You can enter these ranges as load balancer addresses in DNS Check to monitor any Cloudflare-proxied domain. If a DNS query returns 104.21.35.12, DNS Check confirms that the address falls within 104.16.0.0/13 and the check passes. If a query returns an IP outside all specified ranges, the check fails and you're notified, which could indicate a DNS hijack, misconfiguration, or an unexpected provider change.

You can also mix individual IP addresses and CIDR ranges in the same load balancer. Each entry, whether a single IP or a CIDR range, counts as one of the 30 allowed entries per load balancer.

Paste IP Lists Directly

To make setup even faster, the "IP addresses" field now accepts newline-delimited input in addition to comma-separated values. This means you can copy a list of IP ranges from a provider's website and paste it directly into DNS Check without reformatting.

For example, visiting cloudflare.com/ips and copying the IPv4 ranges gives you a newline-separated list. Paste it into the "IP addresses" field as-is, and DNS Check converts the newlines to commas when the record is saved. The field is now a multi-line text area to support this workflow.

Getting Started

Load balancer monitoring with CIDR support is available now for all paid DNS Check accounts. To set up a CIDR-based load balancer check:

Navigate to your DNS record group and click "Add DNS record"
Select a load balancer type from the dropdown (e.g., "A record balancer" or "AAAA record balancer")
Enter the domain name you want to monitor in the "Name" field
Enter your CIDR ranges in the "IP addresses" field, separated by commas or newlines
Save the record

The screenshot at the top of this post shows an example of this form with Cloudflare's IPv4 CIDR ranges entered as addresses.

DNS Check immediately begins monitoring. If any DNS response returns an address outside your specified ranges, you'll be notified through your configured notification channels: email, Slack, PagerDuty, webhooks, and more.

For complete documentation on load balancer monitoring, visit our Monitoring Load Balancer DNS Records page.

Guided DNS Troubleshooting, Full History, and UI Improvements

Sat, 03 Jan 2026 14:22:00 -0500

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.

Create this record: When an expected DNS record is completely missing from your DNS configuration, the report displays the full record you need to create, highlighted in green. This makes it immediately clear that the record doesn't exist and needs to be added.

Update this record: When a DNS record exists but contains a typo or hasn't yet incorporated a minor update, the report highlights the exact characters that are incorrect. Incorrect characters are highlighted in red strikethrough, while the correct replacement characters are highlighted green. A match percentage helps confirm when a difference is likely a typo rather than a completely wrong value.

Delete this record: For exclusive DNS checks where extra unwanted records exist alongside the correct one, the report shows which records to delete, highlighted in red.

This improvement is particularly valuable for long SPF or TXT records where a single typo can be buried in a string of dozens of characters. What previously required careful manual comparison now takes a glance.

Complete DNS Record History

Previously, the "Notification History" report only showed state changes that triggered email notifications. This created gaps in your visibility when notifications were disabled, when "suppress notification of pass" was enabled, or during initial record setup.

DNS Check now records all state changes, regardless of whether a notification was sent. The report was renamed to "History" to reflect this broader scope. You can now see:

Initial check results when a new DNS record is first added
ServFail errors (even when the delay slider, described below, prevents email notifications)
All transitions, not just those that triggered emails or other notices

This complete history makes troubleshooting easier because you can see exactly what happened to a DNS record over time, independent of your notification preferences.

Redesigned Notification Settings

The notification settings interface was redesigned for better usability on both desktop and mobile devices.

Improved navigation: Desktop displays a sidebar for quick access to each notification type. Mobile uses a drill-down navigation pattern that makes better use of limited screen space.

ServFail delay slider: The ServFail delay setting is now an interactive slider with a value bubble and contextual description, replacing the previous text input. This makes it easier to understand and adjust the amount of time DNS Check waits before alerting on ServFail errors.

Better mobile experience: Dropdown menus auto-scroll into view, action buttons stack vertically for easier tapping, and touch targets on buttons and toggle switches are larger.

Additional Improvements

Pass/fail feedback when adding DNS records: You now see diagnostic notifications when creating DNS records, confirming whether the newly added record passes or fails its initial check.
Responsive DNS Record History view: The history view adapts better to mobile screens, matching the responsive design already used for viewing DNS record groups.
Visual feedback on rechecks: A subtle fade effect now highlights when DNS record status updates after a recheck, making it clear that a refresh occurred.

These updates are available now for all DNS Check accounts. For questions about these features, visit our FAQ or contact us.

Detect DNS Record Creation: Planned or Rogue

Mon, 03 Nov 2025 11:53:00 -0500

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.

Use Case 1: Monitoring for Record Creation

The most common use case for inverted checks is monitoring for DNS record creation. You need to know when a DNS record that doesn't currently exist gets added to your zone, but traditional DNS monitoring can only alert you when existing records disappear or change values.

Scenario: You're planning to create a new subdomain for a staging environment at staging.example.com. The DNS record doesn't exist yet, but you want to be notified immediately when your team adds it to DNS so you can verify the configuration is correct.

Configuration:

Name: staging.example.com
Type: A
Value: * (wildcard match)
Invert check: Enabled

Behavior:

Passing state: DNS queries return NXDomain (the record doesn't exist)
Failing state: Any A record for staging.example.com is found, triggering a notification

The wildcard value (*) matches any IP address. With invert enabled, the check passes while no record exists and fails once any A record appears, regardless of its value. This gives you immediate visibility when the record gets created.

For DevOps and security teams, this enables:

Monitoring planned infrastructure additions
Catching rogue DNS record creation
Tracking when external parties add DNS records to delegated zones
Detecting when deprecated subdomains get recreated

Monitoring Domain Registration

A specialized application of record creation monitoring is tracking when unregistered domains get registered. This helps organizations monitor domains they plan to acquire or detect when competitors or malicious actors register similar domains.

Scenario: You're planning to acquire example-startup.com, but it's currently unregistered. You want to be notified immediately if someone else registers it before you complete your acquisition.

Configuration:

Name: example-startup.com
Type: NS
Value: * (wildcard match)
Invert check: Enabled

Behavior:

Passing state: DNS queries return NXDomain (domain not registered)
Failing state: NS records appear, indicating the domain was registered and name servers configured

When a domain is unregistered, queries for its NS records return NXDomain. Once someone registers the domain and configures authoritative name servers, NS records appear in DNS. An inverted NS check with a wildcard value detects this transition, alerting you to the registration.

This monitoring approach works because domain registrations typically include name server configuration. While some registrars and TLDs technically allow registration without immediate name server configuration, most domains have NS records configured shortly after registration to make the domain functional. While the domain owner might delay adding A, MX, or other records, NS records typically appear soon after registration completes.

Use Case 2: Detecting Unwanted Values

The second major use case is detecting when specific problematic values appear in your DNS configuration. This addresses security concerns, helps prevent misconfigurations, and helps maintain DNS hygiene.

Scenario: Your organization uses 192.0.2.50 for internal development environments, and this IP address should never appear in public DNS records. You want to be alerted immediately if this internal IP leaks into your production DNS configuration.

Configuration:

Name: example.com
Type: A
Value: 192.0.2.50 (the unwanted IP)
Invert check: Enabled

Behavior:

Passing state: DNS returns A records, but 192.0.2.50 is not among them
Failing state: 192.0.2.50 appears in the DNS results, triggering an alert

Unlike the wildcard approach, this configuration specifies an exact value to avoid. The check passes as long as that specific value doesn't appear in DNS, even if the record has other values. This gives you precise control over what triggers alerts.

This pattern helps with:

Catching internal IP addresses appearing in public DNS
Alerting when DNS records revert to old, deprecated values
Finding blacklisted IP addresses in your DNS configuration
Monitoring for specific problematic CNAME targets or MX servers

How Inverted Checks Work

The inverted check logic applies to all DNS record types that DNS Check supports: A, AAAA, CNAME, MX, NS, TXT, SOA, SPF, SRV, and ALIAS records. There's one exception: load balancer records (records with multiple expected values) cannot use inverted checks.

Scenario	Normal Check	Inverted Check
Record doesn't exist (NXDomain)	Fails - record not found	Passes - record absent as desired
Record exists with expected value	Passes - correct value found	Fails - unwanted value detected
Record exists with different value	Fails - wrong value	Passes - unwanted value absent
DNS server error (ServFail, timeout)	Fails - cannot determine state	Fails - cannot determine state

Note that DNS server errors remain failures for both normal and inverted checks. When DNS Check can't query your name servers due to errors or timeouts, it cannot reliably determine whether the record exists or what values it contains. These ambiguous states generate alerts, ensuring you're notified of DNS infrastructure problems.

Special Behavior with ALIAS Records

ALIAS record monitoring in DNS Check differs from other record types. Instead of checking a single DNS record, ALIAS checks perform two independent DNS queries and compare the results: one lookup for the ALIAS record name and another for the expected target.

For regular ALIAS checks, the monitoring passes when both lookups return identical results, confirming the ALIAS mapping works correctly. This ensures the ALIAS record resolves to the expected IP addresses.

When you enable inverted checks on ALIAS records, the comparison logic reverses. The check passes when the two lookups return different results, indicating the two records point to different locations. This behavior helps detect scenarios like:

CDN or load balancer configurations change without coordination
DNS failover or traffic management policies activate unintentionally
ALIAS records break due to misconfigured target records

Setting Up Inverted Checks

Creating an inverted check requires a paid DNS Check account (Professional or Enterprise). The feature is available when adding or editing a DNS record.

Steps to create an inverted check:

Navigate to your DNS record group and click "Add DNS record" or edit an existing record
Fill in the DNS record name, type, and value fields as usual
Enable the "Invert check" toggle
Save the record

DNS Check immediately begins monitoring with the inverted logic. The record appears in your DNS record group with an INVERTED badge for easy identification.

Important Restrictions

Inverted checks work independently from other DNS Check features, but a few intentional restrictions prevent confusing or overly complex monitoring configurations:

Cannot combine with Exclusive mode: The "Exclusive" option and "Invert check" option are mutually exclusive. You cannot enable both on the same DNS record. When you enable one option, DNS Check automatically disables the other in the user interface. This restriction prevents ambiguous monitoring logic that would be difficult to reason about and troubleshoot.

Not available for load balancer records: DNS records configured as load balancers (with multiple expected values) cannot use inverted checks. Load balancer monitoring already implements specialized logic for handling sets of IP addresses or hostnames. Adding inverted logic would overcomplicate the feature without clear use cases. If you need to monitor load balancer absence, create a non-load-balancer wildcard check with invert enabled instead.

Requires paid account: Inverted checks are available on paid accounts (Professional and Enterprise plans).

Zone File Export Handling

When you export your monitored DNS records to zone file format using the "Export to zone file" button, DNS Check includes inverted records as comments rather than standard zone file entries. This design decision reflects the nature of inverted monitoring: zone files define what DNS records should exist in your zone, while inverted checks monitor what should not exist or what should be absent.

Inverted records appear in the exported zone file with a clear comment prefix:

; INVERTED CHECK: staging.example.com. A * (passes when absent)
; INVERTED CHECK: example.com. A 192.0.2.50 (passes when value doesn't match)

This format provides documentation of your inverted monitoring configuration without affecting the zone file's functionality. You can import the zone file into your DNS server or use it as configuration documentation, and the commented inverted checks serve as useful notes about monitoring expectations.

Using Inverted Checks at Scale

Inverted checks integrate seamlessly with DNS Check's existing notification and monitoring features. State changes for inverted records trigger the same notification channels as traditional checks: email, webhooks, Slack, PagerDuty, Opsgenie, and other configured integrations.

When an inverted check fails (meaning an unwanted record was detected or a monitored record was created), DNS Check's error messages clearly communicate what was found. The notification includes the inverted record's configuration and the actual DNS query results.

The state change history for inverted records tracks transitions just like normal records, providing a complete audit trail of when monitored records appeared, disappeared, or changed values. This historical data helps with troubleshooting recurring issues and understanding DNS configuration changes over time.

Get Started with Inverted Checks

Inverted checks address DNS monitoring scenarios that traditional monitoring can't handle, from detecting rogue record creation to detecting internal IP addresses appearing in public DNS. The inverted logic provides visibility into DNS record creation and unwanted value detection without requiring complex workarounds or external scripting.

Ready to start using inverted checks? Sign up for a DNS Check account and upgrade to a Professional (starting at $8/month) or Enterprise plan to enable inverted checks. Existing paid customers can start using inverted checks immediately by either editing an existing DNS record or creating a new one and turning on the "Invert check" option.

For detailed documentation on the "Invert check" feature, including usage with ALIAS records and examples for each DNS record type, visit our Monitor DNS Records page.

Amazon Isn't Eating Its Own DNS Dog Food

Tue, 21 Oct 2025 09:50:00 -0400

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:

Quality assurance: Internal usage exposes bugs and usability issues before customers encounter them
Credibility: Demonstrating confidence in your own products builds customer trust
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.

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 name servers

First, query the authoritative name servers 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 name servers.

2. Compare with Route 53 name server patterns

For comparison, check the name servers 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 name servers 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 name servers, 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.* name servers confirms that aws.amazon.com uses Route 53.

3. Identify who owns the amzndns name servers

Look up the IP address of one of amazon.com's name servers:

$ 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 name servers 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 name servers 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 name server ownership

For comparison, verify that Amazon owns the Route 53 name servers:

$ 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 name server software identification

As a final confirmation, you can query the name servers 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 name server explicitly identifies itself as "UltraDNS Nameserver". Route 53 name servers typically don't respond to these CHAOS queries (they time out), which is a security practice to avoid revealing implementation details.

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:

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.
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.
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.
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 name servers 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.

Lessons from the October 2025 AWS DNS Outage

Mon, 20 Oct 2025 12:02:00 -0400

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.

Why DNS Failures Have Outsized Impact

DNS resolution is typically one of the first steps in any network communication. When an application needs to communicate with a service like DynamoDB, it must first resolve the service's hostname to an IP address. If this resolution fails or returns incorrect information, the entire communication chain breaks down.

In AWS's case, internal DNS resolution problems meant that services couldn't locate DynamoDB endpoints. Because many AWS services use DynamoDB for state management, session storage, and data persistence, this single DNS issue propagated across a large portion of AWS's infrastructure.

This cascading effect demonstrates why DNS monitoring deserves special attention in your infrastructure reliability strategy. Unlike many other failure modes that might affect individual services or components, DNS failures can simultaneously impact everything that depends on the affected domain.

The Case for DNS Monitoring

While AWS's internal DNS infrastructure isn't directly accessible to external monitoring, organizations running on AWS can monitor their own DNS configurations to catch issues before they affect users. DNS Check provides monitoring for several scenarios that could prevent or mitigate outage impacts:

Name server availability monitoring: Track whether your authoritative name servers are responding to queries. If a name server becomes unreachable, DNS Check detects this immediately and sends alerts, giving you time to investigate before users are affected.
Resolution correctness: Verify that DNS queries return the expected values. Incorrect DNS responses can route traffic to the wrong endpoints or create partial outages that are difficult to diagnose.
Geographic consistency: DNS Check queries from multiple global locations, helping you detect geolocation-based routing issues or inconsistent responses from different name servers.

For organizations depending on cloud infrastructure, DNS monitoring provides an early warning system. While you can't control AWS's internal DNS infrastructure, you can monitor your own DNS records and receive immediate notification when issues occur. This visibility helps you respond quickly, whether that means communicating with customers, activating failover systems, or contacting your service provider.

Building DNS Resilience

The AWS outage reinforces several architectural principles for DNS resilience:

Use multiple authoritative name servers: Most domains configure multiple authoritative name servers, providing redundancy if one name server fails.
Monitor DNS responses continuously: Automated monitoring detects DNS issues faster than manual checks or user reports. DNS Check monitors your records at regular intervals and alerts you immediately when problems occur, helping you maintain awareness of your DNS infrastructure's health.
Understand your DNS dependencies: Map out which systems depend on DNS resolution for critical services. This understanding helps you assess the potential impact of DNS failures and prioritize monitoring for your most important records.
Implement appropriate timeout and retry logic: Applications should handle DNS resolution failures gracefully. Configure reasonable timeout values and implement retry logic that accounts for temporary DNS issues without creating excessive load on DNS infrastructure.
Consider multi-region and multi-cloud strategies: While complex to implement, distributing your infrastructure across multiple regions or cloud providers can reduce the impact of regional outages. This typically requires careful DNS configuration to route traffic appropriately and failover mechanisms to handle regional failures.

Looking Forward

Large-scale outages like this AWS incident serve as valuable reminders that no infrastructure is immune to failures. DNS's role as a foundational Internet protocol means that DNS issues often create widespread impact. By implementing proactive DNS monitoring, organizations gain visibility into this critical infrastructure layer and can respond quickly when problems occur.

DNS Check monitors your DNS records and sends notifications when problems are detected, helping you maintain reliable DNS infrastructure. Whether you're running a small application or managing DNS for a large organization, monitoring provides the visibility needed to catch issues early and respond effectively.

Ready to add DNS monitoring to your infrastructure? Sign up for a free DNS Check account and start monitoring your critical DNS records today.

Performance and Reliability Enhancements

Sat, 13 Sep 2025 12:15:00 -0400

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

When DNS queries fail, the difference between a server error, a network timeout, and a connection refusal can determine whether you're looking at a name server misconfiguration or a network connectivity issue. Previously, DNS Check grouped all DNS server communication errors under a single "ServFail" category, forcing you to investigate further to understand the root cause.

DNS Check now distinguishes between three distinct types of communication failures:

General ServFail errors: Issues with the name server itself, such as internal server errors or misconfigurations. You'll see these when the name server receives your query but can't process it due to zone file errors or server-side issues.
Query timeouts: When DNS Check's connection to your chosen name server times out. This typically indicates network connectivity problems or an overloaded name server that can't respond within the timeout window.
Connection refused: When the name server actively refuses the connection request. This often means the name server isn't accepting queries from DNS Check's monitoring locations or isn't running on the expected port.

This enhanced error categorization immediately points you toward the right troubleshooting approach. Instead of generic ServFail messages requiring additional investigation, you get specific diagnostic information that saves time and reduces confusion during DNS incidents.

Improved Support for Large TXT Records

Here's a real-world example that illustrates why large TXT record support matters. When you query a domain with extensive verification and email authentication records, you might see something like this:

$ dig txt example.com
;; Truncated, retrying in TCP mode.

; <<>> DiG 9.10.6 <<>> txt example.com
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12832
;; flags: qr rd ra; QUERY: 1, ANSWER: 23, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;example.com.			IN	TXT

;; ANSWER SECTION:
example.com.		300	IN	TXT	"MS=ms70274184"
example.com.		300	IN	TXT	"google-site-verification=C7thfNeXVahkVhniiqTI1iSVnElKR_kBBtnEHkeGDlo"
example.com.		300	IN	TXT	"apple-domain-verification=DNnWJoArJobFJKhJ"
example.com.		300	IN	TXT	"facebook-domain-verification=h9mm6zopj6p2po54woa16m5bskm6oo"
example.com.		300	IN	TXT	"stripe-verification=5096d01ff2cf194285dd51cae18f24fa9c26dc928cebac3636d462b4c6925623"
[... 18 more verification records ...]
example.com.		300	IN	TXT	"v=spf1 ip4:199.15.212.0/22 include:_spf.google.com include:spf1.mcsv.net include:spf.mandrillapp.com -all"

;; Query time: 10 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; MSG SIZE  rcvd: 1954

Notice two critical details: the "Truncated, retrying in TCP mode" message and the final response size of 1954 bytes. This response exceeds the DNS Flag Day recommended UDP buffer size of 1232 bytes, forcing the query to fall back from UDP to TCP - exactly the scenario illustrated in the diagram above.

DNS Check now handles these large TXT record scenarios more reliably through several key improvements:

Enhanced EDNS handling: We've improved compatibility with name servers that have incomplete implementations of RFC 6891 Extension Mechanisms for DNS (EDNS). Some DNS providers implement EDNS incompletely, causing issues when responses approach or exceed the advertised buffer size. DNS Check now adapts to these implementation quirks automatically.
Improved TCP connection management: When UDP responses are truncated (as shown in the dig output above), DNS Check establishes a TCP connection to retrieve the complete response. We've enhanced our TCP connection handling to prevent premature disconnects that some name servers exhibit, ensuring reliable retrieval of large responses.
DNS Flag Day compliance: DNS Check now uses 1232-byte UDP buffers by default, following DNS Flag Day recommendations. This prevents IP fragmentation issues that can cause packet loss and monitoring failures.

This enhancement is particularly valuable for monitoring email authentication records like SPF records with multiple include statements, large DKIM public keys, and domains with extensive third-party service integrations that require domain verification records.

Optimized Query Reliability

Reliability improvements often happen behind the scenes, but their impact on your monitoring experience is significant. We've fine-tuned timeout values and retry logic to strike a better balance between rapid issue detection and false positive prevention.

Smarter timeout management: Different types of DNS queries require different timeout strategies. Large TXT record queries over TCP naturally take longer than simple A record lookups over UDP. DNS Check now adjusts timeout values based on query type and transport protocol, reducing false timeouts for legitimate slow responses while maintaining rapid detection of actual failures.
Connection pooling enhancements: For users monitoring hundreds or thousands of DNS records, efficient connection management makes a substantial difference in query performance. We've optimized connection pooling to reuse TCP connections when appropriate, reducing the overhead of establishing new connections for each large record query.
Intelligent retry strategies: When a query fails, the retry approach depends on the failure type. Network timeouts warrant different retry timing than server errors. DNS Check now implements failure-specific retry logic that improves success rates while avoiding unnecessary load on DNS servers.

These optimizations are particularly beneficial if you're monitoring large numbers of DNS records or require frequent check intervals, but all users benefit from more reliable monitoring and fewer false alerts.

Streamlined Integrations

Reliable notifications depend on reliable integration partners. We've updated our integration offerings to focus on actively maintained, dependable notification channels:

Removed discontinued services: Following Flowdock's service discontinuation, we've removed this integration to prevent configuration confusion. If you were using Flowdock notifications, you'll need to migrate to an alternative integration.
Enhanced Basecamp support: The Basecamp integration now supports both Basecamp 3 and Basecamp 4. Existing Basecamp integrations continue working without modification.

All remaining integrations received strengthened error handling and more robust delivery mechanisms. These improvements reduce the likelihood of missed notifications during DNS incidents, when reliable alerting matters most.

API Performance Improvements

The DNS Check API has received significant architectural improvements that benefit both our web application and API users. We've streamlined the internal codebase, removing legacy dependencies while maintaining full backward compatibility.

Faster response times: Database query optimizations and improved caching reduce API response latency, particularly for accounts monitoring large numbers of DNS records.
Enhanced reliability: Better error handling and connection management improve API availability.
Future-ready architecture: These changes establish a foundation for upcoming API enhancements, including expanded query capabilities and additional DNS record types.

If you're building applications on DNS Check's API, you'll experience more consistent performance. The improved architecture also supports our roadmap for additional API features.

Looking Forward

These enhancements reflect our commitment to evolving DNS Check alongside the changing DNS landscape. As organizations adopt more cloud services, improve email security, and integrate additional third-party tools, DNS configurations grow increasingly complex. DNS Check's improvements ensure reliable monitoring regardless of this complexity.

The enhanced error diagnostics provide clearer troubleshooting guidance when issues occur. The improved large TXT record support handles modern DNS configurations that previous generations of DNS monitoring tools struggle with. The optimized query reliability reduces false alerts that can desensitize teams to real DNS problems.

Whether you're monitoring a handful of critical records for a small business or managing DNS infrastructure for a large enterprise, these improvements ensure you receive accurate, actionable alerts when DNS issues arise and clear information to resolve them efficiently.

Ready to experience these improvements? Sign up for a free DNS Check account and start monitoring your DNS records today. Existing customers immediately benefit from these enhancements: no configuration changes required.

Two New DNS Record Monitoring Features

Sat, 29 Mar 2025 11:42:15 -0400

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:

Notification of Flapping Issues: DNS Check will alert you when flapping is detected, enabling you to investigate and address potential problems rapidly.
Aggregated Notifications: DNS Check consolidates flapping alerts into a single email per hour for users with immediate email notifications enabled. This approach prevents an overwhelming number of emails during periods of instability. There are a few caveats to this behavior. See our FAQ entry for details.

Common causes of DNS record flapping include:

Inconsistent Responses from Authoritative Name Servers: Different name servers may return varying results for the same query, often due to misconfigurations.
Geolocation-based Routing: DNS Check queries from multiple global locations, which can trigger discrepancies in DNS responses from CDNs and load balancers. To address this:
- If monitoring a CDN or load balancer record, configure it as a load balancer record and specify all potential IPs or hostnames that your CDN or load balancer could return. DNS Check will consider the record passing if any subset of the expected results are returned.
- Alternatively, set a specific name server for DNS Check to query to ensure consistent results from a deterministic IP address.
Connectivity Issues: These can cause a record to alternate between passing and failing with ServFail errors.

By detecting and alerting you to flapping records, DNS Check empowers you to maintain the stability and reliability of your DNS configurations.

Extended Notification History

Understanding the history of your DNS records is crucial for effective troubleshooting and analysis. We’ve expanded our notification history retention for Enterprise accounts to 365 days, allowing for a full year of state change tracking. Professional accounts retain 90 days of history, while Basic accounts maintain a 7-day history. This extended access enables you to observe long-term patterns, investigate past incidents, and maintain comprehensive records for auditing purposes.

These enhancements reflect our commitment to providing robust and user-friendly DNS monitoring. We aim to empower you with the tools to maintain an optimal DNS configuration by offering detailed insights into DNS record behavior and extending historical data access.

For more information on these features and how they can benefit your organization, visit our Features page.

Capacity Expansion

Sun, 18 Jul 2021 05:48:14 -0400

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.

If you're using our API for DNS record monitoring, then we recommend scheduling a maintenance window within your monitoring system that runs from 12 to 1 am UTC on Saturday, July 24.

Feel free to contact us if you have any questions.

DNS Monitoring Improvements

Sat, 02 Jan 2021 05:24:00 -0500

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.

Here's an example report:

The log used to be maintained for 30 days for paid accounts, but we recently increased the retention period to 90 days.

Free accounts can also view this log, but only for the past 7 days.

The Troubleshoot DNS Records page has more details on this feature.

2. Added Support for Monitoring More DNS Records

We added four new subscription options to the checkout page to monitor up to 3,000 DNS records. Previously, the largest available package on that page had a 1,0000 DNS record limit.

We're also able to create custom packages for monitoring more than 3,000 DNS records. Get in touch with us if you'd like a custom quote.

3. Made the Zone File Importer More Robust

DNS Check offers the option of importing entire zone files for monitoring. This system worked for properly formed zone files, but some DNS hosting providers produce malformed zone files that can cause issues, like making individual records unreadable. Another common problem is omitting the zone file's $ORIGIN, making relative references like @ meaningless.

We've enhanced the zone file importer's "Autocorrect syntax errors" option to fix more types of zone file issues. The enhancement was significant enough to warrant turning the option on by default. It was off by default before.

The Monitor DNS Records page shows how to access the zone file importer.

4. Made the Check Frequency Configurable

We added the ability to customize how often DNS records are checked. Each DNS record group now has "Check frequency" settings that can be set to any of the following:

Every 5 minutes (the default)
Every hour
Paused

Previously, all DNS records were checked every 5 minutes, and there wasn't any way to pause checks.

5. Added a Status Page

Finally, we've created a status page at status.dnscheck.co. Moving forward, we'll post notices about upcoming maintenance there. If any services experience downtime, we'll also document them on the status page. Feel free to subscribe for status updates.

That's it for now. More improvements are coming in 2021, and we're looking forward to sharing them with you.