Wildcard DNS record
From Wikipedia, the free encyclopedia
A wildcard DNS record is a record in a DNS zone file that will match all requests for non-existent domain names, i.e. domain names for which there are no records at all.
Contents |
[edit] Wildcards in practice
Whilst the aforegiven definition is in accordance with RFC 1034 § 4.3.2, it is not actually the case in practice. No DNS server software implements wildcards as per RFC 1034. This is in part because, as defined in RFC 1034, wildcard behaviour is not what people generally expect, particularly the interactions between wildcards and MX records. All DNS servers implement wildcards differently, both from RFC 1034 and from one another.
- 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.
- If configured to do so, both Microsoft's DNS server 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. This has the behaviour in conjunction with MX records that, in the main, people actually desire. In other words, if there is a MX record for "*.example.com", and an A record (but no MX record) for "www.example.com", the "correct" response to a MX request for "www.example.com" is "that doesn't exist"; the actual response with Microsoft's DNS server and MaraDNS is the MX record attached to "*.example.com".
- With BIND, the server follows CNAME chains that are synthesised from wildcards.
- If configured to do so DNS Redirector with an "*" in the SimpleDNS file can be used to resolve each and every lookup to a single IP, including fictional domain-names that end in non-existent extensions such as .comm or .blue, you could also use keyword files to redirect matching domain-names to a single IP.
[edit] Registries that employ wildcards
Between 15 September 2003 and 4 October 2003, VeriSign operated a wildcard DNS entry for all non-existent .com and .net domain names on its root server which redirected users to a VeriSign "web portal" with information about VeriSign products and purchase links to "partner" sites. This had the advantage of VeriSign receiving greater revenue from users wishing to register these domain names, however this action was heavily criticized within the internet technology community. For more coverage of the commercial, ethical, and technical issues relating to this, see the Site Finder article.
The .museum top-level domain operated by MuseDoma has always used a wildcard DNS record to resolve unregistered domains. Attempting to access such a domain leads to a web page informing the user that the domain is not in use, and providing links for further information about .museum. Other top-level domains using a wildcard DNS record (as of August 2006) include .cm, .mp, .nu, .ph, .pw, .tk and .ws.
[edit] 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.
[edit] External links
- IAB Commentary: Architectural Concerns on the use of DNS Wildcards
- MuseDoma statement concerning wildcard A records in TLDs
- Internet Software Consortium announcement of "delegation-only" feature that can be used to filter out wildcards
- "All your *.COM/*.NET are belong to us." — an explanation of VeriSign's wildcards and their effects, and critique of the various attempts to work around such wildcards in software, including
delegation-only
, showing how they are each flawed