Microsoft DNS

Microsoft DNS is the name given to the implementation of domain name system services provided in Microsoft Windows operating systems.

Overview
The Domain Name System support in Microsoft Windows NT, and thus its derivatives Windows 2000, Windows XP, and 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 client, to perform Dynamic DNS Update transactions, registering the machines' names and IP addresses. 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 Windows.

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 if 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 preferred DNS server until it fails to answer, whereupon communication switches to one of several alternative DNS servers.

The effects of running the DNS Client service
There are several minor differences in system behavior depending on whether the DNS Client service is started:


 * Parsing of the "hosts" file: The lookup functions read only 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 lookup.


 * 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 preferred to alternative DNS servers: The fallback from the preferred 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 preferred 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 preferred DNS server and some talking to alternative DNS servers.

Differences from other systems
Linux distributions and various versions of Unix have a generalized name resolver layer. The resolver can be controlled to use a hosts file or Network Information Service (NIS), by configuring the Name Service Switch.

Dynamic DNS Update client
Whilst DNS lookups read DNS data, DNS updates write them. Both workstations and servers running Windows attempt to send Dynamic DNS update requests to DNS servers.

Workstations running Windows attempt to register their names and their IP addresses with DNS servers, so that other machines may locate them by name. Prior to Windows Vista (and Windows Server 2008) this registration is performed by the DHCP Client service. It is thus necessary to run the DHCP Client service on pre-Vista machines, 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). In Microsoft Vista (and Windows Server 2008) Microsoft moved the registration functionallity from the DHCP Client service to the DNS Client service.

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.

DNS server
Microsoft Windows server operating systems can run the DNS Server service. This is a monolithic DNS server that provides many types of DNS service, including caching, Dynamic DNS update, zone transfer, and DNS notification. DNS notification implements a push mechanism for notifying a select set of secondary servers for a zone when it is updated.

Microsoft's "DNS Server" service was first introduced in Windows NT 3.51 as an add-on with Microsoft's collection of BackOffice services (at the time was marked to be used for testing proposes only). Its code is a fork of ISC's BIND, version 4.3, and remains largely compatible with it including the format of all master files.

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.

Like various other DNS servers, 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.

Common issues
Prior to 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, the mechanism was turned off by default.

A longstanding well-known issue is incompatibility with BIND configuration files, in particular, the lack of support for DNS wildcards. This can be partially attributed to the fact that Microsoft's DNS server is based on BIND 4.3, before BIND added the support for DNS wildcards. Loose Wildcarding can be enabled. To create a wildcard character record, the Dnscmd command-line tool can be used. Also the support of IPv6 is implemented using a different technique from that of BIND 9, further driving even more incompatibilities between the two products.

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