Wildcard DNS Records

An asterisk (*) means "anything" in two independent places in DNS Check, and each one solves a different problem:

• In a record's Name - monitors a wildcard DNS record: a record published in your zone as *.example.com, which answers queries for names that don't otherwise exist.
• In a record's expected Value - means "any answer will do, as long as the record exists". This is a DNS Check matching option rather than something published in DNS.

The two are independent. Use either on its own, or both in the same monitor.

Wildcards are available on every plan, including the free plan.

Wildcard Names

What a Wildcard DNS Record Is

A wildcard DNS record serves requests for names that have no record of their own. Here's a zone file excerpt with two ordinary A records and one wildcard:

; Name             Type  IP address
example.com.       A     1.2.3.4
www.example.com.   A     1.2.3.4
*.example.com.     A     5.6.7.8

A query for www.example.com returns 1.2.3.4, because a name with its own record is answered by that record. A query for foo.example.com returns 5.6.7.8: nothing in the zone matches that name, so the wildcard answers instead. Wildcards are commonly used for catch-all subdomains, for per-customer hostnames on a multi-tenant application, and for domains where every name should land on the same server.

The rules a name server follows when it expands a wildcard are defined in RFC 4592.

Monitoring a Wildcard Name

To monitor a wildcard record, enter its Name exactly as it appears in your zone file, asterisk included:

; Name             Type  IP address
*.example.com.     A     5.6.7.8

The Value field behaves as it does for any other record. Entering 5.6.7.8 checks that the wildcard resolves to that address, while entering * checks only that it resolves to something. Every record type DNS Check supports can be monitored under a wildcard name.

How a Wildcard Name Is Checked

Each time the check runs, DNS Check generates a random 20-character label and queries that in place of the asterisk. A monitor for *.example.com might query jcjmwpdddykdmafpltbj.example.com on one check and vfsentzelcoebsorodlw.example.com on the next.

This tests the wildcard the way a real client sees it: the queried name has no record of its own, so the answer can only come from the wildcard. Generating a new label for every check keeps it that way. In the unlikely event that a generated label collides with a name that does have its own record, that one check is answered by that record instead, and the next check moves on to a different label.

Where the Asterisk Can Go

The asterisk must be a whole label, and it must be the leftmost label of the name. This matches what name servers themselves accept:

Name	Accepted	Why
*.example.com		The asterisk is a whole label, and it's the leftmost one.
*.foo.example.com		A wildcard can sit at any depth, as long as it's leftmost.
foo.*.example.com		The asterisk isn't the leftmost label. Name servers don't expand this as a wildcard either.
www*.example.com		The asterisk is part of a label rather than a label of its own. DNS has no partial-label wildcards.

Internationalized names are converted to punycode as usual, so a wildcard record for a Unicode domain is stored and queried in its encoded form.

Wildcard Values

A * in the expected Value means "any value, as long as the record exists". The check passes as soon as the name returns at least one record of the type being monitored, whatever it contains, and fails when the name returns nothing.

This is the option to reach for when a value legitimately changes on its own, and pinning the check to one answer would report a failure every time it does. A CDN that returns addresses from a large pool, a provider that rotates part of a record, and a zone whose serial number increments on every edit are all cases where the record's existence is what you want to monitor, not its exact contents.

Record Types That Accept a Wildcard Value

Record types whose value is a single field take * as the whole value. Types whose value is made up of several fields accept * in the individual fields listed below, and each field is matched independently, so any mix of wildcarded and exact fields works:

Record type	Fields that accept *	Example	Passes when
A and AAAA	IP address	*	The name returns any address of that type.
CNAME	Value	*	The name is a CNAME pointing anywhere.
NS	Value	*	The name is delegated to any name server.
PTR	Value	*	The address has reverse DNS pointing anywhere.
TXT and SPF	Value	*	The name returns any record of that type.
MX	Preference, Exchange	10 *	An MX record exists with Preference 10, whichever mail server it names.
SOA	Serial	* in the Serial field	The SOA record matches on the other six fields, whatever its serial number is.
SVCB and HTTPS	Priority, Target, Parameters	1 . *	A record exists with that Priority and Target, whatever parameters it carries, including none.

Wildcarding every field of a multi-field type is the equivalent of a bare *. An MX record of * * passes when the name has any MX record at all, and an HTTPS record of * * * passes when it has any HTTPS record at all.

The SOA serial number is the one SOA field that takes a wildcard, because it's the one that changes on its own: it increments on every zone edit. The remaining six fields must be exact, which is what makes the check worth having.

A wildcard on the SVCB or HTTPS Parameters field is the practical choice when part of a record rotates outside your control. Encrypted ClientHello is the usual case: providers republish their ech keys on their own schedule, and a check pinned to the exact parameters fails each time they do, even though nothing is wrong. Monitoring the Priority and Target exactly with * for the Parameters still catches the record being removed or repointed.

Where a Wildcard Value Isn't Accepted

• SRV, CAA, and ALIAS records take exact values in every field.
• Load balancer records hold a set of addresses or domain names rather than a wildcard. To accept any address from a large pool, either list the pool's CIDR ranges as a load balancer record, or monitor the name as an ordinary record with a value of *.
• A wildcard label in a value, such as a CNAME pointing at *.example.com, is rejected. Values are compared literally against what DNS returns, and a response never contains an asterisk, so such a value could never match. Use * on its own instead.

Wildcards and the Other Matching Options

A wildcard value changes what counts as a match, so it interacts with DNS Check's other matching options.

Exclusive

By default, a wildcard check passes as long as at least one returned record matches, even when the name returns other records of the same type too. With Exclusive enabled, the set of records returned must correspond one-to-one with the records you monitor.

That pairing makes Exclusive and wildcards useful together. A single A record with a value of * and Exclusive enabled passes only when the name returns exactly one address, whatever that address is. Adding a second identical record requires exactly two. To match a name that publishes several records exactly, monitor one record, wildcard or specific, for each one.

Invert check

A wildcard value paired with Invert check reverses the question, and asks that the record not exist. Monitoring example.com A * with Invert check enabled passes while example.com has no A record, and fails, notifying you, as soon as one appears. This is the standard way to watch for a record being created, whether that's a planned cutover you're waiting on or a record nobody should be publishing. Our blog post on detecting DNS record creation covers this in detail.

Invert check needs a paid account, and can't be combined with Exclusive or with load balancer records.

Wildcard names with wildcard values

Combining the two monitors that a wildcard record exists without pinning what it returns. A monitor with a Name of *.example.com and a Value of * passes as long as names under example.com that have no records of their own still resolve to something.

Wildcards in Zone Files

A wildcard name is standard zone file syntax, so it's imported and exported like any other record:

*.example.com. A 5.6.7.8

A wildcard value isn't valid zone file syntax, since no real zone contains one. Rather than dropping these records, DNS Check writes them at the end of the exported file as comments, along with its other non-standard record types:

; ===================================================================
; The records below can't be written in standard zone file syntax,
; so DNS Check exports them as comments. Standard DNS servers ignore
; them. Re-import this file into DNS Check to restore them.
; ===================================================================
; DNS Check wildcard-value records (matching any value): https://www.dnscheck.co/wildcard-dns-records#wildcard-values
; any.example.com. A *
; example.com. MX * *
; === End DNS Check wildcard-value records ===

Standard DNS servers ignore comments, so the exported file remains a valid zone file, and importing it back into DNS Check restores the wildcard-value records intact.

Example Uses

What you want to know	How to monitor it
Names without records of their own still resolve, and to the right server	Name *.example.com, type A, value 5.6.7.8
A CDN or server pool is still handing out addresses, whichever ones it picks	Name www.example.com, type A, value *
Mail is still routed somewhere, whatever the provider changes it to	Type MX, Preference *, Exchange *
The zone's SOA parameters are correct, without failing on every zone edit	Type SOA, Serial *, other six fields exact
An HTTPS record still points where it should, while its ECH keys rotate	Type HTTPS, Priority 1, Target ., Parameters *
Exactly one address is published, whatever it is	Type A, value *, Exclusive enabled
A record that shouldn't exist yet, or at all, hasn't appeared	Type A, value *, Invert check enabled

Additional Resources

• RFC 4592 - defines how name servers expand wildcard records, including the cases where a wildcard does not apply.
• Wildcard DNS Record Monitoring - the blog post introducing wildcard name monitoring, comparing it to the older practice of monitoring a couple of made-up hostnames.
• Monitoring DNS Records for Wildcard Values - the blog post introducing wildcard values, with worked examples.
• Monitor DNS Records - how to add and configure the records in a DNS record group.