A wildcard DNS record is a record in a DNS zone that will match requests for non-existent domain names. A wildcard DNS record is specified by using a * as the leftmost label (part) of a domain name, e.g. *.example.com. The exact rules for when a wildcard will match are specified in RFC 1034, but the rules are neither intuitive nor clearly specified. This has resulted in incompatible implementations and unexpected results when they are used.
A wildcard DNS record in a zone file looks similar to this example:
*.example.com. 3600 IN MX 10 host1.example.com.
This wildcard DNS record will cause DNS lookups on domain names ending in example.com that do not exist to have MX records synthesized for them. So, a lookup for the MX record for somerandomname.example.com would return an MX record pointing to host1.example.com.
Wildcards in the DNS are much more limited than other wildcard characters used in other computer systems. Wildcard DNS records have a single * (asterisk) as the leftmost DNS label, such as *.example.com. Asterisks at other places in the domain will not work as a wildcard, so neither *abc.example.com nor abc.*.example.com work as wildcard DNS records. Moreover, the wildcard is matched only when a domain does not exist, not just when there are no matching records of the type that has been queried for. Even the definition of "does not exist" as defined in the search algorithm of RFC 1034 section 4.3.3 can result in the wildcard not matching cases that one might expect with other types of wildcards.
The original definition of how a DNS wildcard behaves is specified in RFC 1034 sections 4.3.2 and 4.3.3, but only indirectly by certain steps in a search algorithm and as a result, the rules are neither intuitive nor clearly specified. As a result, 20 years later, RFC 4592, "The Role of Wildcards in the Domain Name System" was written to help clarify the rules.
To quote RFC 1912, "A common mistake is thinking that a wildcard MX for a zone will apply to all hosts in the zone. A wildcard MX will apply only to names in the zone which aren't listed in the DNS at all." That is, if there is a wildcard MX for *.example.com, and an A record (but no MX record) for www.example.com, the correct response (as per RFC 1034) to an MX request for www.example.com is "no error, but no data"; this is in contrast to the possibly expected response of the MX record attached to *.example.com.
Example usages
The following example is from RFC 4592 section 2.2.1 and is useful in clarifying how wildcards work.
Say there is a DNS zone with the following resource records:
$ORIGIN example. example. 3600 IN SOA <SOA RDATA> example. 3600 NS ns.example.com. example. 3600 NS ns.example.net. *.example. 3600 TXT "this is a wildcard" *.example. 3600 MX 10 host1.example. sub.*.example. 3600 TXT "this is not a wildcard" host1.example. 3600 A 192.0.2.1 _ssh._tcp.host1.example. 3600 SRV <SRV RDATA> _ssh._tcp.host2.example. 3600 SRV <SRV RDATA> subdel.example. 3600 NS ns.example.com. subdel.example. 3600 NS ns.example.net.
A look at the domain names in a tree structure is helpful:
The following responses would be synthesized from one of the wildcards in the zone:
Queried domain
Queried RR type
Results
host3.example.
MX
The answer will be a "host3.example. IN MX ..."
host3.example.
A
The answer will reflect "no error, but no data" because there is no "A" resource record (RR) set at *.example.
foo.bar.example.
TXT
The answer will be "foo.bar.example. IN TXT ..." because bar.example. does not exist, but the wildcard does.
The following responses would not be synthesized from any of the wildcards in the zone:
Queried domain
Queried RR type
Results
host1.example.
MX
No wildcard will match because host1.example. exists. Instead you will get an answer of "no error, but no data". The wildcard MX record does not provide MX records for domains that otherwise exist.
sub.*.example.
MX
No wildcard will match because sub.*.example. exists. The domain sub.*.example. will never act as a wildcard, even though it has an asterisk in it.
_telnet._tcp.host1.example.
SRV
No wildcard will match because _tcp.host1.example. exists (without data).
host.subdel.example.
A
No wildcard will match because subdel.example. exists and is a zone cut, putting host.subdel.example. into a different DNS zone. Even if host.subdel.example. does not exist in the other zone, a wildcard will not be used from the parent zone.
ghost.*.example.
MX
No wildcard will match because *.example. exists, it is a wildcard domain, but it still exists.
The final example highlights one common misconception about wildcards. A wildcard "blocks itself" in the sense that a wildcard does not match its own subdomains. That is, *.example. does not match all names in the example. zone; it fails to match the names below *.example.. To cover names under *.example., another wildcard domain name is needed—*.*.example.—which covers all but its own subdomains.
In practice
To quote from RFC 4592, many DNS implementations diverge, in different ways, from the original definition of wildcards. Some of the variations include:
With djbdns, in addition to checking for wildcards at the current level, the server checks for wildcards in all enclosing superdomains, all of the way up to the root.[citation needed] In the examples listed above, the query for _telnet._tcp.host1.example for an MX record would match a wildcard despite the domain _tcp.host1.example existing.
Microsoft's DNS server (if configured to do so[1]) and MaraDNS (by default) have wildcards also match all requests for empty resource record sets; i.e., domain names for which there are no records of the desired type. In the examples listed above, the query for sub.*.example for an MX record would match *.example, despite sub.*.example explicitly existing with only a TXT Record.
Registrants
Wildcard domains are widely used by blogging websites that allow users to create sub-domains upon demand; e.g., sites such as WordPress or Blogspot. Another popular use is by Free Dynamic DNS websites that allow users to create a DNS name that changes to match their host IP as the IP address is changed periodically by their ISP's DHCP server.
New TLDs
New gTLDs are prohibited from publishing wildcards (or using equivalent name server mechanisms) by specification 6 of the ICANN New gTLD Base Registry agreement. However, ICANN's Name Collision Occurrence Management Framework (PDF), explicitly requires new gTLDs to publish (for at least 90 days) special MX, SRV, TXT, and 127.0.53.53 A record wildcards that warn of potential name collisions due to use of relative domain names with domain search paths.
Registries/ISPs
Several domain name registrars have, at various times, deployed wildcard records for the top-level domains to provide a platform for advertising, most notably VeriSign for .com and .net with its (now removed) Site Finder system. The .museum TLD also had a wildcard record which has now been removed. As of March 2018[update], top-level domains using a wildcard A record (other than 127.0.53.53) are .fm, .la, .ph, .pw, .vg and .ws. The internationalized TLDs .中国 (.xn--fiqs8s or .xn--fiqz9s for "China") and .გე (.xn--node for the Georgian letters for the Georgian country code "GE") also have wildcard A records. The *.中国 wildcard resolves to ibaidu.com (flagged by Chrome as unsafe), and the *.გე wildcard resolves to a website of the .ge TLD.
It has also become common for ISPs to synthesize address records for typos, for the same person, a practice called "catchall" typosquatting, but these aren't true wildcards, but rather modified caching name servers.[2]
Ignoring wildcards from others
The Internet Software Consortium produced a version of the BIND DNS software that can be configured to filter out wildcard DNS records from specific domains. Various developers have produced software patches for BIND and for djbdns.
Other DNS server programs have followed suit, providing the ability to ignore wildcard DNS records as configured.
IAB Commentary: Architectural Concerns on the use of DNS Wildcards
February 07, 2023
wildcard, record, wildcard, record, record, zone, that, will, match, requests, existent, domain, names, wildcard, record, specified, using, leftmost, label, part, domain, name, example, exact, rules, when, wildcard, will, match, specified, 1034, rules, neither. A wildcard DNS record is a record in a DNS zone that will match requests for non existent domain names A wildcard DNS record is specified by using a as the leftmost label part of a domain name e g example com The exact rules for when a wildcard will match are specified in RFC 1034 but the rules are neither intuitive nor clearly specified This has resulted in incompatible implementations and unexpected results when they are used Contents 1 Definitions of DNS wildcards 2 Example usages 3 In practice 3 1 Registrants 3 2 New TLDs 3 3 Registries ISPs 3 4 Ignoring wildcards from others 4 References 5 External linksDefinitions of DNS wildcards EditA wildcard DNS record in a zone file looks similar to this example example com 3600 IN MX 10 host1 example com This wildcard DNS record will cause DNS lookups on domain names ending in example com that do not exist to have MX records synthesized for them So a lookup for the MX record for somerandomname example com would return an MX record pointing to host1 example com Wildcards in the DNS are much more limited than other wildcard characters used in other computer systems Wildcard DNS records have a single asterisk as the leftmost DNS label such as example com Asterisks at other places in the domain will not work as a wildcard so neither abc example com nor abc example com work as wildcard DNS records Moreover the wildcard is matched only when a domain does not exist not just when there are no matching records of the type that has been queried for Even the definition of does not exist as defined in the search algorithm of RFC 1034 section 4 3 3 can result in the wildcard not matching cases that one might expect with other types of wildcards The original definition of how a DNS wildcard behaves is specified in RFC 1034 sections 4 3 2 and 4 3 3 but only indirectly by certain steps in a search algorithm and as a result the rules are neither intuitive nor clearly specified As a result 20 years later RFC 4592 The Role of Wildcards in the Domain Name System was written to help clarify the rules To quote RFC 1912 A common mistake is thinking that a wildcard MX for a zone will apply to all hosts in the zone A wildcard MX will apply only to names in the zone which aren t listed in the DNS at all That is if there is a wildcard MX for example com and an A record but no MX record for www example com the correct response as per RFC 1034 to an MX request for www example com is no error but no data this is in contrast to the possibly expected response of the MX record attached to example com Example usages EditThe following example is from RFC 4592 section 2 2 1 and is useful in clarifying how wildcards work Say there is a DNS zone with the following resource records ORIGIN example example 3600 IN SOA lt SOA RDATA gt example 3600 NS ns example com example 3600 NS ns example net example 3600 TXT this is a wildcard example 3600 MX 10 host1 example sub example 3600 TXT this is not a wildcard host1 example 3600 A 192 0 2 1 ssh tcp host1 example 3600 SRV lt SRV RDATA gt ssh tcp host2 example 3600 SRV lt SRV RDATA gt subdel example 3600 NS ns example com subdel example 3600 NS ns example net A look at the domain names in a tree structure is helpful example sub host1 tcp ssh host2 tcp ssh subdel The following responses would be synthesized from one of the wildcards in the zone Queried domain Queried RR type Resultshost3 example MX The answer will be a host3 example IN MX host3 example A The answer will reflect no error but no data because there is no A resource record RR set at example foo bar example TXT The answer will be foo bar example IN TXT because bar example does not exist but the wildcard does The following responses would not be synthesized from any of the wildcards in the zone Queried domain Queried RR type Resultshost1 example MX No wildcard will match because host1 example exists Instead you will get an answer of no error but no data The wildcard MX record does not provide MX records for domains that otherwise exist sub example MX No wildcard will match because sub example exists The domain sub example will never act as a wildcard even though it has an asterisk in it telnet tcp host1 example SRV No wildcard will match because tcp host1 example exists without data host subdel example A No wildcard will match because subdel example exists and is a zone cut putting host subdel example into a different DNS zone Even if host subdel example does not exist in the other zone a wildcard will not be used from the parent zone ghost example MX No wildcard will match because example exists it is a wildcard domain but it still exists The final example highlights one common misconception about wildcards A wildcard blocks itself in the sense that a wildcard does not match its own subdomains That is example does not match all names in the example zone it fails to match the names below example To cover names under example another wildcard domain name is needed example which covers all but its own subdomains In practice EditTo quote from RFC 4592 many DNS implementations diverge in different ways from the original definition of wildcards Some of the variations include With djbdns in addition to checking for wildcards at the current level the server checks for wildcards in all enclosing superdomains all of the way up to the root citation needed In the examples listed above the query for telnet tcp host1 example for an MX record would match a wildcard despite the domain tcp host1 example existing Microsoft s DNS server if configured to do so 1 and MaraDNS by default have wildcards also match all requests for empty resource record sets i e domain names for which there are no records of the desired type In the examples listed above the query for sub example for an MX record would match example despite sub example explicitly existing with only a TXT Record Registrants Edit Wildcard domains are widely used by blogging websites that allow users to create sub domains upon demand e g sites such as WordPress or Blogspot Another popular use is by Free Dynamic DNS websites that allow users to create a DNS name that changes to match their host IP as the IP address is changed periodically by their ISP s DHCP server New TLDs Edit New gTLDs are prohibited from publishing wildcards or using equivalent name server mechanisms by specification 6 of the ICANN New gTLD Base Registry agreement However ICANN s Name Collision Occurrence Management Framework PDF explicitly requires new gTLDs to publish for at least 90 days special MX SRV TXT and 127 0 53 53 A record wildcards that warn of potential name collisions due to use of relative domain names with domain search paths Registries ISPs Edit Several domain name registrars have at various times deployed wildcard records for the top level domains to provide a platform for advertising most notably VeriSign for com and net with its now removed Site Finder system The museum TLD also had a wildcard record which has now been removed As of March 2018 update top level domains using a wildcard A record other than 127 0 53 53 are fm la ph pw vg and ws The internationalized TLDs 中国 xn fiqs8s or xn fiqz9s for China and გე xn node for the Georgian letters for the Georgian country code GE also have wildcard A records The 中国 wildcard resolves to ibaidu com flagged by Chrome as unsafe and the გე wildcard resolves to a website of the ge TLD It has also become common for ISPs to synthesize address records for typos for the same person a practice called catchall typosquatting but these aren t true wildcards but rather modified caching name servers 2 Ignoring wildcards from others Edit The Internet Software Consortium produced a version of the BIND DNS software that can be configured to filter out wildcard DNS records from specific domains Various developers have produced software patches for BIND and for djbdns Other DNS server programs have followed suit providing the ability to ignore wildcard DNS records as configured References Edit Microsoft Corporation When Monetizing ISP Traffic Goes Horribly Wrong Security Fix From wayback machineExternal links EditIAB Commentary Architectural Concerns on the use of DNS Wildcards Retrieved from https en wikipedia org w index php title Wildcard DNS record amp oldid 1135089471, wikipedia, wiki, book, books, library,
