Checking names and zone data

  • Article

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Checking names and zone data

The following name-checking methods can be used with the DNS Server service and managed using the DNS console.

Method Description

Strict RFC (ANSI)

Uses strict checking of names according to RFC 1123 Internet host naming specifications.

Non RFC (ANSI)

Permits names that are nonstandard and that do not follow RFC 1123 Internet host naming specifications.

Multibyte (UTF8)

Permits recognition of characters other than ASCII, including Unicode, which is normally encoded as more than one octet (8 bits) in length.

With this option, multibyte characters can be transformed and represented using Unicode Transformation Format (UTF-8) support.

All names

Permits any naming conventions.

Notes

  • For more information on when to use nondefault settings for name checking with the DNS Server service, see Unicode character support.

  • For more information about RFCs, see DNS RFCs.

Checking for bad zone data

You can configure the DNS Server service to check for bad or unrecognized zone data when the service is started. To enable this option, see Prevent loading of a zone when bad data is found.

DNS wildcarding

The DNS Server service can use wildcards to associate multiple possible DNS name destinations with a single computer acting as a gateway for all names based on a wildcarded name. The most common use of wildcards in DNS records is with the mail exchanger (MX) resource record; for example, to configure DNS for an Internet mail gateway host routing mail between your private network and the Internet.

Basics of using DNS wildcards

When you are trying to determine where to use a wildcard in DNS, such as an MX resource record used to route and forward mail, note these guidelines:

  • The asterisk (*) is the character reserved to indicate the wildcarded name.

  • The asterisk is only used once as the leading (leftmost) character in a DNS name. For example, *.example.microsoft.com.

  • If used, an asterisk must always match at least one or more whole labels of a name that precede any non-wildcarded (exact) characters in the remaining part of the name. For example, the wildcard name *.example.microsoft.com may apply to one or more descendents of a domain, such as haifa.example.microsoft.com or seattle.us.example.microsoft.com, but it will not apply to the domain name itself, which is example.microsoft.com.

  • Wildcards are not used when a query for an exact name produces an exact match.

  • The contents of wildcarded resource records conform to normal DNS formats and rules for resource records.

Typically, wildcards are only used when the DNS name queried is an indeterminate name subordinate to a known name. In this case, the closest match to the wildcarded name is used. For example, if the following MX resource record is used in the example.microsoft.com zone:

*.example.microsoft.com.   IN  MX  10   mailserver1.example.microsoft.com.

This record would allow mail destined for the following possible DNS domain names to be routed to the mail routing host (mailserver1.example.microsoft.com.) specified in the MX resource record:

haifa.example.microsoft.com.

seattle.us.example.microsoft.com.

santiago.sa.example.microsoft.com.

When wildcarding is used, the asterisk (*) wildcard symbol must match at least one whole label beyond the specified part of the DNS name in which the wildcard is used.

For example, an e-mail message destined to user@example.microsoft.com could not use the previous example MX resource record to be forwarded to its destination. For the e-mail to be forwarded correctly, an additional explicit MX resource record needs to be added in the same zone, such as:

example.microsoft.com.   IN  MX  10   mailserver1.example.microsoft.com.

Loose RFC wildcarding

For Windows NT Server 4.0 (prior to Service Pack 4), the DNS Server service was not strictly compliant with the method for using wildcards in a DNS name lookup described in RFC 1034. It only stopped a wildcard lookup when it reached a node in the DNS domain namespace tree that had resource records of the type specified in a query.

For example, if in the example.microsoft.com. zone the following records were used:

      *.example.microsoft.com.             IN  MX  10   mailserver1.example.microsoft.com.
      example.microsoft.com.               IN  MX  10   mailserver2.example.microsoft.com.
      host-a.example.microsoft.com.        IN  A        10.0.0.1
      mailserver1.example.microsoft.com.   IN  A        10.0.0.2
      mailserver2.example.microsoft.com.   IN  A        10.0.0.3

and a DNS query was made by a computer, Host B, as follows:

Queried name:  host-a.example.microsoft.com.

Queried type:    MX

with loose wildcarding in effect, the following sequence occurs between the DNS Server service and Host B:

  1. Host B sends the example query to a DNS server configured to use loose RFC wildcarding, such as a DNS server running under Windows NT Server 4.0 prior to Service Pack 4.

  2. No MX resource records match the specified name (host-a.example.microsoft.com.).

  3. An MX resource record -- the type specified in the query -- is included in the zone and uses a wildcarded name that is the parent of the queried name (*.example.microsoft.com.).

  4. The DNS Server service checks the wildcarded MX resource record name (*.example.microsoft.com.) for its mapped host names, finds a matching A resource record for the specified name (mailserver1.example.microsoft.com.) and uses this information to answer Host B.

  5. The mail program on Host B can then send mail to mailserver1.example.microsoft.com. by using its IP address.

The loose RFC approach allows you to set up only two MX records and cover queries to the entire zone. However, the two MX resource records need to be added for both the zone root (the explicit name of the zone) and a wildcard node (*) directly below the zone root. However, if you have individual mail hosts that should receive their own mail directly, then add MX resource records for each of those hosts that refer directly to their own host name, as stated in their registered A resource record.

Strict RFC wildcarding

With the strict wildcarding approach as described in RFC 1034, a revised sequence of events occurs when reviewing the previous example. Based on the same specified zone and query information provided, the revised sequence of steps would be used between the DNS Server service and Host B:

  1. Host B sends the example query to a DNS server configured to use strict RFC wildcarding.

  2. No MX resource records match the specified name (host-a.example.microsoft.com.), but an A resource record of that name is found in the zone.

    Because the queried name was found, no wildcarding is done.

  3. The DNS Server service responds to the query with an authoritative negative response that includes no errors or resource records in the answer section of the response.

  4. The mail program on Host B then sends a new query for the same name, specifying that A resource records be used for the query type.

  5. The DNS Server service answers the A query with an authoritative positive response, which includes the A resource record in the answer section of the response.

  6. The mail program on Host B can then send mail to mailserver1.example.microsoft.com. by using its IP address.

The strict RFC approach to wildcarding is easier if your mail hosts are capable of receiving mail directly. The disadvantage to this approach is that you typically need to add more MX resource records to the zone. This can happen if you have mail hosts not capable of receiving mail directly, or if you need to advertise any mail hosts that are not mail servers.