Detect DNS Record Creation: Planned or Rogue

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 nameservers configured

When a domain is unregistered, queries for its NS records return NXDomain. Once someone registers the domain and configures authoritative nameservers, 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 nameserver configuration. While some registrars and TLDs technically allow registration without immediate nameserver 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.

Note that DNS server errors remain failures for both normal and inverted checks. When DNS Check can't query your nameservers 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:

1. Navigate to your DNS record group and click "Add DNS record" or edit an existing record
2. Fill in the DNS record name, type, and value fields as usual
3. Enable the "Invert check" toggle
4. 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.