Wildcard Records


DNS has the concept of wildcard records. They are most often used for MX records. On first sight they seem useful enough, but they are counter intuitive and often used incorrectly.

In the penguin.bv zone mail could have been set up like this:

 @               MX      10 mail                 MX      20 mail.herring.bv. *               MX      10 mail                 MX      20 mail.herring.bv. mail            MX      10 mail                 MX      20 mail.herring.bv. rms             A       192.168.55.130 

Which, by the way, is not the same as used to be in the penguin zone, and probably not what you, or I, want.

The proper name for the wildcard record is "*.penguin.bv". Thus it will not match a query for a MX record for "penguin.bv." A query for that will instead match the "@" record. A query for "mail.penguin.bv" will match the explicit record for mail, any record occurring in the zone overrides the wildcard. But, almost any other query will match the wildcard record. In practice, the wildcard record will make names that are not in the zone appear to be defined. For example a query for "foobar.penguin.bv" will be answered with an answer for "foobar.penguin.bv," not "*.penguin.bv." This is known as synthesizing resource records records are created on demand, from thin air. It is impossible to determine if a name in an answer is caused by a wildcard record or not.

Restrictions on Wildcards

In addition to not matching penguin.bv the wildcard record also does not match the name rms.penguin.bv. Wildcards does not match any name for which there is any data in the zone, even if the data present is not the kind the query requires. Explicit MX records must be set up for each name that occurs in the zone that is meant to have a MX record associated with it. This is a bit of a bummer as it restricts the usefulness of wildcards severely.

Wildcard RRs do not cross zone boundaries. The wildcard above does not affect the emperor.penguin.bv zone. The emperor.penguin.bv zone is searched for matches for queries within its scope. In the same manner wildcard records does not apply to subdomains within the same zone such as this setup:

 *               MX      10 mail                 MX      20 mail.herring.bv. sigurd.king     A       192.168.56.3 eirik.king      A       192.168.56.4 

A query for a MX for sigurd.king.penguin.bv will not match the wildcard record. The wildcard "*.king.penguin.bv" must be added to take care of this. "*.*.penguin.bv" is not allowed, nor is "foobar.*.penguin.bv." Only one wildcard, and only at the left end of the domain name is allowed.

In addition to all this, you should be sure that the mail server on the receiving end of wildcard MX records is able to handle the rather unpredictable names it might be handed. Consider "i.hate.penguin.bv," and whatever else Internet users will be able to think of.

The Problem with Wildcards

If you consider all these restrictions, you will find that wildcard records only match names for which there are no other DNS entries. This is probably the opposite of what you wanted. You wanted MX records for all the names in DNS, not all the names not in DNS. This is counter intuitive enough that many people make errors when using wildcards and the resulting problems are enough that wildcards are considered harmful by quite a few people.



The Concise Guide to DNS and BIND
The Concise Guide to DNS and BIND
ISBN: 0789722739
EAN: 2147483647
Year: 1999
Pages: 183

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net