 |
del.icio.us |
 |
Digg |
 |
Furl |
 |
|
 |
Rojo |
| Add to OnlyWire |
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 left most label (part) of a domain name, e.g. *.example.com. The exact rules about when a wild card will match is 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 |
Definitions for DNS wildcards
Wild card DNS record in a zone file looks similar to this example:
*.example.com. 3600 MX 10 host1.example.com.
This wild card 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 left most 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. More over, the wild card 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.2 can result in the wild card not matching cases that you 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 wild card 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"; the expected response is the MX record attached to *.example.com.
Example wildcard 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:
|
-------------example------------
/ / \ \
/ / \ \
/ / \ \
* host1 host2 subdel
| | |
| | |
sub _tcp _tcp
| |
| |
_ssh _ssh
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 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 wild card 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 wild card will match because sub.*.example. exists. The domain sub.*.example. will never act as a wild card, even though it has an asterisk in it. |
| _telnet._tcp.host1.example. | SRV | no wild card will match because _tcp.host1.example. exists (without data). |
| host.subdel.example. | A | no wild card 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 wild card will not be used from the parent zone. |
| ghost.*.example. | MX | no wild card will match because *.example. exists, It is a wild card 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.
Wildcards 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 wild card 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, despite sub.*.example. explicitly existing with only an A record.
- With BIND, the server follows CNAME chains that are synthesised from wildcards.[citation needed]
Registries/ISPs that employ wildcards
Several domain name registrars have, at various times, deployed wild cards for the top-level domains that they serve, most notably VeriSign for the .com and .net with its (now removed) Site Finder system. The .museum TLD also had a wild card which has now been removed. Top-level domains using a wildcard DNS record, as of July 2008, include .cg, .cm, .kr, .mp, .nu, .ph, .rw, .st, .tk, .vg, and .ws.
It has also become common for ISPs to synthesize A records to redirect typos to their advertising sites. so called "Catchall" typosquatting, but these aren't true wild cards, but rather modified caching name servers.[2]
Ignoring wildcards employed by others
The Internet Software Consortium produced a version of the BIND DNS software that can be configured by system administrators to filter out wildcard DNS from certain domains. Various others produced a wide range of software patches for BIND and for djbdns.
|
|||||||||||
