Simple Example: Local Network Priority
A
multihomed computer, server1.lucernepublishing.com, has three A
resource records for each of its three IP addresses in the
lucernepublishing.com zone. These three records appear in the following
order in the zone, either in the zone file or in Active Directory:
server1 IN A 192.168.1.27
server1 IN A 10.0.0.14
server1 IN A 172.16.20.4
When a DNS client resolver
at IP address 10.4.3.2 queries the server for the IP addresses of the
host server1.lucernepublishing.com, the DNS Server service notes that
the originating IP network address (10.0.0.0) of the client matches the
network (class A) ID of the 10.0.0.14 address in the answer list of
resource records. The DNS Server service then reorders the addresses in
the response list, as follows:
server1 IN A 10.0.0.14
server1 IN A 192.168.1.27
server1 IN A 172.16.20.4
If the IP address of the
requesting client has no local network match with any of the resource
records in the answer list, the list is not prioritized in this manner.
Complex Example: Local Subnet Priority
In
a network that uses IP subnetting (nondefault subnet masks), a DNS
server first returns any IP addresses that match both the client’s
network ID and subnet ID before returning any IP addresses that match
only the client’s network ID.
For
example, a multihomed computer, server1.lucernepublishing.com, has four
A resource records corresponding to each of its four IP addresses in
the lucernepublishing.com zone. Two of these IP addresses are for
distinct and separate networks. The other two IP addresses share a
common IP network address, but because custom netmasks of 255.255.248.0
are used, the IP addresses are located in different subnets. These
example resource records appear in the following order in the zone,
either in the zone file or in Active Directory:
server1 IN A 192.168.1.27
server1 IN A 172.16.22.4
server1 IN A 10.0.0.14
server1 IN A 172.16.31.5
If the IP address of the
requesting client is 172.16.22.8, both IP addresses that match the same
IP network as the client, the 172.16.0.0 network, are returned at the
top of the response list to the client. However, in this example, the
172.16.22.4 address is placed ahead of the 172.16.31.5 address because
it matches the client IP address down through the 172.16.20.0 subnet
address.
The reordered answer list returned by the DNS service follows:
server1 IN A 172.16.22.4
server1 IN A 172.16.31.5
server1 IN A 192.168.1.27
server1 IN A 10.0.0.14
Enable Round Robin
The
Enable Round Robin option is selected by default. This setting ensures
that, in response to a request to resolve the name of a multihomed
computer, DNS servers in Windows Server 2003 rotate the order of
matching A resource records in the response list returned to subsequent
clients. This feature provides a simple way to balance the network load
for frequently queried multihomed computers among all the computer’s
network adapters. This feature is also commonly used to balance
requests between multiple servers that offer identical network
services, such as an array of Web servers providing content for a
single Web site.
Note
Local
subnet priority supersedes the use of round robin rotation for
multihomed computers. When enabled, however, round robin is used as a
secondary method to sort multiple records returned in a response list. |
Round Robin Example
The
Web server named server1.lucernepublishing.com has three network
adapters and three distinct IP addresses. In the stored zone (either in
a database file or in Active Directory), the three A resource records
mapping the host name to each of its IP addresses appear in this fixed
order:
server1 IN A 10.0.0.1
server1 IN A 10.0.0.2
server1 IN A 10.0.0.3
The first DNS
client—Client1—that queries the server to resolve this host’s name
receives the list in this default order. However, when a second
client—Client2—sends a subsequent query to resolve this name, the list
is rotated as follows:
server1 IN A 10.0.0.2
server1 IN A 10.0.0.3
server1 IN A 10.0.0.1
Disabling Round Robin
When
you clear the Enable Round Robin check box, round robin is disabled for
the DNS server. In this case, when clients query the DNS server to
resolve the host name of a multihomed computer, the server always
returns the matching A resource records in the order in which those
records appear in the zone.
Secure Cache Against Pollution
By
default, the Secure Cache Against Pollution option is enabled. This
setting allows the DNS server to protect its cache against referrals
that are potentially polluting or nonsecure. When the setting is
enabled, the server caches only those records with a name that
corresponds to the domain for which the original queried name was made.
Any referrals received from another DNS server along with a query
response are simply discarded.
For
example, if a query is originally made for example.microsoft.com, and a
referral answer provides a record for a name outside the microsoft.com
domain name tree (such as msn.com), that name is discarded if the
Secure Cache Against Pollution option is enabled. This setting helps
prevent unauthorized computers from impersonating another network
server.
When this option is disabled,
however, the server caches all the records received in response to DNS
queries—even when the records do not correspond to the queried-for
domain name.
Name Checking
By
default, the Name Checking drop-down list box on the Advanced tab of
the DNS server properties dialog box is set to Multibyte (UTF8). Thus,
the DNS service by default verifies that all domain names handled by
the DNS service conform to the Unicode Transformation Format (UTF). Unicode
is a 2-byte encoding scheme, compatible with the traditional 1-byte
US-ASCII format, that allows for binary representation of most
languages. Each name-checking method is described in Table 2.
Table 2. Name-Checking Methods
| Method | Description |
|---|
| Strict RFC (ANSI) | Uses
strict checking of names. These restrictions, set in Request for
Comments (RFC) 1123, include limiting names to uppercase and lowercase
letters (A–Z, a–z), numbers (0–9), and hyphens (-). The first character
of the DNS name can be a number. |
| 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 UTF-8 support, which is
provided with Windows Server 2003. Names encoded in UTF-8 format
must not exceed the size limits clarified in RFC 2181, which specifies
a maximum of 63 octets per label and 255 octets per name. Character
count is insufficient to determine size because some UTF-8 characters
exceed one octet in length. This option allows for domain names using
non-English alphabets. |
| All Names | Permits any naming conventions. |
Despite
the flexibility of the UTF-8 name-checking method, you should consider
changing the Name Checking option to Strict RFC when your DNS servers
perform zone transfers to non-Windows servers that are not UTF-8–aware.
Although DNS server implementations that are not UTF-8–aware might be
able to accept the transfer of a zone containing UTF-8 encoded names,
these servers might not be able to write back those names to a zone
file or reload those names from a zone file.
You should use the other two Name Checking options, Non RFC and All Names, only when a specific application requires them.
Load Zone Data On Startup
By
default, the Load Zone Data On Startup drop-down list box is set to the
From Active Directory And Registry option. Thus, by default DNS servers
in Windows Server 2003 initialize with the settings specified in the
Active Directory database and the server Registry. However, this
setting includes two other options, From Registry and From File.
When
you configure the Load Zone Data On Startup setting to the From
Registry option, the DNS server is initialized by reading parameters
stored in the Windows Registry. When you configure this setting to the
From File option, the DNS server is initialized by reading parameters
stored in a boot file, such as those used by BIND servers.
To
use such a file, you should supply a copy of a boot file from a
BIND-based DNS server. On BIND-based DNS servers, this file is
typically called the Named.boot file. The format of this file must be
the older BIND 4 format, not the more recent BIND 8 boot file format.
When a boot file is used, settings in the file are applied to the
server, overriding the settings stored in the Registry on the DNS
server. However, for any parameters not configurable using boot file
directives, Registry defaults (or stored reconfigured server settings)
are applied by the DNS Server service.
Enable Automatic Scavenging Of Stale Records
By
default, the Enable Automatic Scavenging Of Stale Records option is
cleared on the Advanced tab. According to this setting, DNS servers in
Windows Server 2003 by default do not automatically delete stale or
outdated resource records from a zone for which Aging has been enabled.
When
this setting is enabled, scavenging of stale resource records is
performed automatically at the interval configured in the Scavenging
Period.
