Wildcard DNS record

Last updated

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

Definitions of DNS wildcards

A wildcard DNS record in a zone file looks similar to this example:

*.example.com.3600INMX10host1.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:

$ORIGINexample.example.3600INSOA<SOARDATA>example.3600NSns.example.com.example.3600NSns.example.net.*.example.3600TXT"this is a wildcard"*.example.3600MX10host1.example.sub.*.example.3600TXT"this is not a wildcard"host1.example.3600A192.0.2.1_ssh._tcp.host1.example.3600SRV<SRVRDATA>_ssh._tcp.host2.example.3600SRV<SRVRDATA>subdel.example.3600NSns.example.com.subdel.example.3600NSns.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 domainQueried RR typeResults
host3.example.MXThe answer will be a "host3.example. IN MX ..."
host3.example.AThe answer will reflect "no error, but no data" because there is no "A" resource record (RR) set at *.example.
foo.bar.example.TXTThe 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 domainQueried RR typeResults
host1.example.MXNo 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.MXNo 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.SRVNo wildcard will match because _tcp.host1.example. exists (without data).
host.subdel.example.ANo 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.MXNo 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:

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, 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.

Related Research Articles

The Domain Name System (DNS) is a hierarchical and distributed naming system for computers, services, and other resources in the Internet or other Internet Protocol (IP) networks. It associates various information with domain names assigned to each of the associated entities. Most prominently, it translates readily memorized domain names to the numerical IP addresses needed for locating and identifying computer services and devices with the underlying network protocols. The Domain Name System has been an essential component of the functionality of the Internet since 1985.

A top-level domain (TLD) is one of the domains at the highest level in the hierarchical Domain Name System of the Internet after the root domain. The top-level domain names are installed in the root zone of the name space. For all domains in lower levels, it is the last part of the domain name, that is, the last non empty label of a fully qualified domain name. For example, in the domain name www.example.com, the top-level domain is .com. Responsibility for management of most top-level domains is delegated to specific organizations by the ICANN, an Internet multi-stakeholder community, which operates the Internet Assigned Numbers Authority (IANA), and is in charge of maintaining the DNS root zone.

A name server is a computer application that implements a network service for providing responses to queries against a directory service. It translates an often humanly meaningful, text-based identifier to a system-internal, often numeric identification or addressing component. This service is performed by the server in response to a service protocol request.

In the Internet, a domain name is a string that identifies a realm of administrative autonomy, authority or control. Domain names are often used to identify services provided through the Internet, such as websites, email services and more. As of 2017, 330.6 million domain names had been registered. Domain names are used in various networking contexts and for application-specific naming and addressing purposes. In general, a domain name identifies a network domain or an Internet Protocol (IP) resource, such as a personal computer used to access the Internet, or a server computer.

A mail exchanger record specifies the mail server responsible for accepting email messages on behalf of a domain name. It is a resource record in the Domain Name System (DNS). It is possible to configure several MX records, typically pointing to an array of mail servers for load balancing and redundancy.

Zero-configuration networking (zeroconf) is a set of technologies that automatically creates a usable computer network based on the Internet Protocol Suite (TCP/IP) when computers or network peripherals are interconnected. It does not require manual operator intervention or special configuration servers. Without zeroconf, a network administrator must set up network services, such as Dynamic Host Configuration Protocol (DHCP) and Domain Name System (DNS), or configure each computer's network settings manually.

The Domain Name System Security Extensions (DNSSEC) are a suite of extension specifications by the Internet Engineering Task Force (IETF) for securing data exchanged in the Domain Name System (DNS) in Internet Protocol (IP) networks. The protocol provides cryptographic authentication of data, authenticated denial of existence, and data integrity, but not availability or confidentiality.

A Service record is a specification of data in the Domain Name System defining the location, i.e., the hostname and port number, of servers for specified services. It is defined in RFC 2782, and its type code is 33. Some Internet protocols such as the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP) often require SRV support by network elements.

Sender Policy Framework (SPF) is an email authentication method which ensures the sending mail server is authorized to originate mail from the email sender's domain. This authentication only applies to the email sender listed in the "envelope from" field during the initial SMTP connection. If the email is bounced, a message is sent to this address, and for downstream transmission it typically appears in the "Return-Path" header. To authenticate the email address which is actually visible to recipients on the "To:" line, other technologies such as DMARC must be used. Forgery of this address is known as email spoofing, and is often used in phishing and email spam.

A Canonical Name (CNAME) record is a type of resource record in the Domain Name System (DNS) that maps one domain name to another.

The Extensible Provisioning Protocol (EPP) is a flexible protocol designed for allocating objects within registries over the Internet. The motivation for the creation of EPP was to create a robust and flexible protocol that could provide communication between domain name registries and domain name registrars. These transactions are required whenever a domain name is registered or renewed, thereby also preventing domain hijacking. Prior to its introduction, registries had no uniform approach, and many different proprietary interfaces existed. While its use for domain names was the initial driver, the protocol is designed to be usable for any kind of ordering and fulfilment system.

In the Domain Name System (DNS) hierarchy, a subdomain is a domain that is a part of another (main) domain. For example, if a domain offered an online store as part of their website example.com, it might use the subdomain shop.example.com.

DNS zone transfer, also sometimes known by the inducing DNS query type AXFR, is a type of DNS transaction. It is one of the many mechanisms available for administrators to replicate DNS databases across a set of DNS servers.

DNS spoofing, also referred to as DNS cache poisoning, is a form of computer security hacking in which corrupt Domain Name System data is introduced into the DNS resolver's cache, causing the name server to return an incorrect result record, e.g. an IP address. This results in traffic being diverted to any computer that the attacker chooses.

A Domain Name System (DNS) zone file is a text file that describes a DNS zone. A DNS zone is a subset, often a single domain, of the hierarchical domain name structure of the DNS. The zone file contains mappings between domain names and IP addresses and other resources, organized in the form of text representations of resource records (RR). A zone file may be either a DNS master file, authoritatively describing a zone, or it may be used to list the contents of a DNS cache.

dig (command) Network administration command-line tool

dig is a network administration command-line tool for querying the Domain Name System (DNS).

DNS hijacking, DNS poisoning, or DNS redirection is the practice of subverting the resolution of Domain Name System (DNS) queries. This can be achieved by malware that overrides a computer's TCP/IP configuration to point at a rogue DNS server under the control of an attacker, or through modifying the behaviour of a trusted DNS server so that it does not comply with internet standards.

Amazon Route 53 is a scalable and highly available Domain Name System (DNS) service. Released on December 5, 2010, it is part of Amazon.com's cloud computing platform, Amazon Web Services (AWS). The name is a possible reference to U.S. Routes, and "53" is a reference to the TCP/UDP port 53, where DNS server requests are addressed. In addition to being able to route users to various AWS services, including EC2 instances, Route 53 also enables AWS customers to route users to non-AWS infrastructure and to monitor the health of their application and its endpoints. Route 53's servers are distributed throughout the world. Amazon Route 53 supports full, end-to-end DNS resolution over IPv6. Recursive DNS resolvers on IPv6 networks can use either IPv4 or IPv6 transport to send DNS queries to Amazon Route 53.

DNS-based Authentication of Named Entities (DANE) is an Internet security protocol to allow X.509 digital certificates, commonly used for Transport Layer Security (TLS), to be bound to domain names using Domain Name System Security Extensions (DNSSEC).

A TXT record is a type of resource record in the Domain name system (DNS) used to provide the ability to associate arbitrary text with a host or other name, such as human readable information about a server, network, data center, or other accounting information.

References

This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.