Microsoft DNS

From Wikipedia, the free encyclopedia

The DNS support in Microsoft Windows NT (and thus its derivatives Microsoft Windows 2000, Microsoft Windows XP, and Microsoft Windows Server 2003) comprises two clients and a server. Every Microsoft Windows machine has a DNS lookup client, to perform ordinary DNS lookups. Some machines have a Dynamic DNS Update client, to perform Dynamic DNS Update transactions, registering the machine's name(s) and IP address(es). Some machines run a DNS server, to publish DNS data, to service DNS lookup requests from DNS lookup clients, and to service DNS update requests from DNS update clients.

The server software is only supplied with the "server" versions of the operating system, such as Microsoft Windows Server 2003.

1 DNS lookup client
- 1.1 The effects of running the DNS Client service
- 1.2 Differences from other systems
2 Dynamic DNS Update client
3 DNS server
- 3.1 Common issues
4 References
5 See also
6 External links

[edit] DNS lookup client

Applications perform DNS lookups with the aid of a DLL. They call library functions in the DLL, which in turn handle all communications with DNS servers (over UDP or TCP) and return the final results of the lookup back to the applications.

Microsoft's DNS client also has optional support for local caching, in the form of a DNS Client service (also known as DNSCACHE). Before they attempt to directly communicate with DNS servers, the library routines first attempt to make a local IPC connection to the DNS Client service on the machine. If there is one, and such a connection can be made, they hand the actual work of dealing with the lookup over to the DNS Client service. The DNS Client service itself communicates with DNS servers, and caches the results that it receives.

Microsoft's DNS client is capable of talking to multiple DNS servers. The exact algorithm varies according to the version, and service pack level, of the operating system; but in general all communication is with a primary DNS server until it fails to answer, whereupon communication switches to one of several alternative DNS servers.

[edit] The effects of running the DNS Client service

There are several minor differences in system behaviour according to whether the DNS Client service is started:

Parsing of the "hosts" file: The lookup functions only read the hosts file if they cannot off-load their task onto the DNS Client service and have to fall back to communicating with DNS servers themselves. In turn, the DNS Client service reads the "hosts" file once, at startup, and only re-reads it if it notices that the last modification timestamp of the file has changed since it last read it. Thus:
- With the DNS Client service running: The "hosts" file is read and parsed only a few times, once at service startup, and thereafter whenever the DNS Client service notices that it has been modified.
- Without the DNS Client service running: The "hosts" file is read and parsed repeatedly, by each individual application program as it makes a DNS lookups.

The effect of multiple answers in the "hosts" file: The DNS Client service does not use the "hosts" file directly when performing lookups. Instead, it (initially) populates its cache from it, and then performs lookups using the data in its cache. When the lookup functions fall back to doing the work themselves, however, they scan the "hosts" file directly and sequentially, stopping when the first answer is found. Thus:
- With the DNS Client service running: If the "hosts" file contains multiple lines denoting multiple answers for a given lookup, all of the answers in the cache will be returned.
- Without the DNS Client service running: If the "hosts" file contains multiple lines denoting multiple answers for a given lookup, only the first answer found will be returned.

Fallback from primary to alternative DNS servers: The fallback from the primary DNS server to the alternative DNS servers is done by whatever entity, the DNS Client service or the library functions themselves, is actually performing the communication with them. Thus:
- With the DNS Client service running: Fallback to the alternative DNS servers happens globally. If the primary DNS server fails to answer, all subsequent communication is with the alternative DNS servers.
- Without the DNS Client service running: Any fallback to the alternative DNS servers happen locally, within each individual process that is making DNS queries. Different processes may be in different states, some talking to the primary DNS server and some talking to alternative DNS servers.

[edit] Differences from other systems

Unices and Linux distributions have a similar local caching scheme, namely the nscd daemon, which the DNS lookup library functions attempt to communicate with before falling back on communicating directly with DNS servers. The two systems are comparable. However, there is an important difference between them. The Microsoft DNS Client service operates at the level of actual DNS lookups, and properly respects the TTL values of all results received. In contrast, nscd caches the results of other types of lookup mechanisms, in addition to the DNS, and operates at a more abstract level, where TTL values have no meaning. nscd will cache DNS lookup results beyond their assigned TTL values in certain circumstances, whereas the Microsoft DNS Client service will not.

[edit] Dynamic DNS Update client

Whilst DNS lookups read DNS data, DNS updates write them. Both workstations and servers running Microsoft Windows attempt to write DNS data, by sending Dynamic DNS Update requests to DNS servers.

Workstations running Microsoft Windows attempt to register their names and their IP addresses with DNS servers, so that other machines may locate them by name and map their IP addresses to their names. This is done not by the DNS Client service, but by the DHCP Client service. (It is thus necessary to run the DHCP Client service, even if DHCP isn't being used to configure the machine, in order to dynamically register a machine's name and address for DNS lookup.) The DHCP Client service registers name and address data whenever they are changed (either manually by an administrator or automatically by the granting or revocation of a DHCP lease).

Servers running Microsoft Windows also attempt to register other information, in addition to their names and IP addresses, such as the locations of the LDAP and Kerberos services that they provide.

[edit] DNS server

Microsoft Windows Domain Controllers can run a DNS Server service. This is a fully fledged, monolithic (i.e. BIND-style rather than djbdns-style), DNS server that provides all types of DNS service, including caching, Dynamic DNS Update, zone transfer, and notification. As of 2004, it was the fourth most popular DNS server (counting BIND version 9 separately from versions 8 and 4) for the publication of DNS data.^[1]

Like PowerDNS, Microsoft's DNS server supports different database back ends. Microsoft's DNS server supports two such back-ends. DNS data can be stored either in master files (also known as zone files) or in the Active Directory database itself. In the latter case, since Active Directory (rather than the DNS server) handles the actual replication of the database across multiple machines, the database can be modified on any server ("multiple-master replication"), and the addition or removal of a zone will be immediately propagated to all other DNS servers within the appropriate Active Directory "replication scope". (Contrast this with BIND, where when such changes are made the list of zones, in the /etc/named.conf file, has to be explicitly updated on each individual server.)

Microsoft's DNS server can be administered using either a graphical user interface, the "DNS Management Console", or a command line interface, the dnscmd utility.

[edit] Common issues

Prior to Microsoft Windows Server 2003 and Microsoft Windows 2000 Service Pack 3, the most common problem encountered with Microsoft's DNS server was cache pollution. Although Microsoft's DNS Server had a mechanism for properly dealing with cache pollution, until those releases that mechanism was turned off by default.

In 2004, the most common problem involved the ability of the Microsoft Windows Server 2003 version of Microsoft's DNS server to use EDNS0, which a large number of firewalls could not cope with. ^[2]