The Microsoft DNS Server is currently beta software. ------- Release ------- The MS NT DNS server will ship as part of NT Server 4.0. (The latest public version is the NT4.0 beta 2 release.) There will no official NT3.51 release of the MS DNS server and no support for the MS DNS on NT 3.51. The dnsbeta and dnsbug aliases are no longer monitored. As this is now an official release, all support issues should be addressed through the standard NT4.0 beta channels: For support and bug reports regarding NT 4.0 DNS beta, use the WINNT40 beta forum on Compuserve, and post in the Networking/Protocols section. For Microsoft Developer Network (MSDN) customers that receive NT 4.0 Server, use the MSDNLIB forum, section Winnt40. ------------ Installation ------------ For WindowsNT 4.0 (SUR) Beta, the DNS server is part of the normal setup process and may be installed, during network services installation. If not installed during setup, DNS may be installed using the network control panel applet. After services control panel applet may be used to set the startup mode of the DNS service. I recommend using manual startup. If you have previously installed the MS DNS service, and are simply updating to a later release: 1. Stop the DNS service. Type "net stop DNS" on the command line, or use the services manager in the control panel. 2. Copy all DNS binaries to the system32 directory. 3. Run dnssetup.exe. This configures your registry to properly start the DNS service. 4. Copy any database files to system32\dns directory. If using DNS manager to configure your site, copy cache.dns to system32\dns. A valid cache file is the minimum requirement to boot the server and be able to configure it with the DnsAdmin. 5. "net start dns" will restart your DNS service. ------------- Configuration ------------- You must have a set of database files in place in order for the DNS service to start. All database files MUST be in %SystemRoot%\system32\dns. Required: - A cache file (named cache.dns) OR - A boot file and the database files specified by in the boot file. You are encouraged to use the DnsAdmin tool to configure the DNS database files for your site. If you have existing database files, the DnsAdmin can have the DNS server read those files in. OR if you have an existing BIND installation at your site, you can simply use your existing BOOT file and database files, place them in the system32\dns directory and be ready to run. NOTE: sample files are included if you wish to edit files manually, but you are encouraged to use the DNS admin tool. --------------- WINS Resolution --------------- The MS DNS server now contains fast, asynchronous resolution through WINS lookup. In some settings, particularly installations with DHCP enabled WindowsNT, Windows95 or WFW3.11 clients, it will be advantageous to enable the DNS service to lookup unresolved names through WINS. First you must decide which DNS zones have WINS clients. Then on the DNS server for that zone, enable WINS resolution, pointing the DNS server at the appropriate WINS server(s) that serves the hosts in that zone. For example, you might have DHCP configured WINS clients in the domain "place.dom." Then with WINS lookup if a query for "testhost.place.dom." that was NOT found in the place.dom database file, WINS servers would be queried for "TESTHOST" resolving the host's address. - Setup: For each forward lookup domain in which you wish to attempt WINS resolution of hostnames, add the "WINS" resource record. See the example in place.dom sample file. For each reverse lookup domain in which you wish to attempt reverse WINS resolution, use the "WINS-R" RR. WINS resolution is setup for a zone through the zone properties dialog in the DNS manager. (Right click on the zone you wish to configure for WINS or WINS Reverse resolution.) - How WINS lookup works: When the DNS server gets an address query for a name in an authoritative zone configured for WINS lookup, and there is NO A record for the queried name, then the DNS server queries the WINS server. The query is done for the workstation name so for a machine to be found by DNS through WINS, it MUST have the workstation service running (it is on by default) and be using one of the WINS servers used by the DNS server. When the WINS server responds the name and address(es) is cached for 10 minutes. The short caching time allows the DNS to respond rapidly when machines change there IP address through DHCP. Note that these cached A records from WINS lookup are NOT transfered during a zone transfer. They are not permanent and are not complete. The correct "transfer" is to have the secondary DNS servers also running WINS lookup. The WINS record itself may be configured to be included in the zone transfer. - How WINS-R (reverse WINS) lookup works: When the DNS server gets a PTR query for a name in an authoritative reverse lookup zone configured for NBSTAT lookup, and there is NO PTR record for the queried name, then the DNS server does a netBIOS node status query on the IP address through NBT. When netBIOS returns, DNS checks through the registered names and picks the "best" one. Priority is given to the workstation name, then the server name, then any unique name. The resulting name is appended with the NBSTAT result domain name and a PTR record with the IP to name mapping is cached for 10 minutes. Note that as in the case of WINS, the cached PTR records themselves are not sent in a zone transfer. The NBSTAT record itself will be sent in the zone transfer unless the "LOCAL" flag is set. - Zone transfer of WINS / WINS-R There is an additional flag for the WINS and WINS-R directives in the zone transfer file to allow better interoperability with UNIX during a corporate rollout and handle remote sites more efficiently. In the DNS Manager under zone properties WINS / WINS-R dialog check the box "Settings only affect local server", to avoid sending these records in a zone transfer. To set this flag can be set in the database files, specify the LOCAL flag immediately after the WINS or WINS-R record type. For example: @ WINS LOCAL 1.1.1.1 1.1.1.2 On the primary DNS server, this directive keeps the record from being sent in a zone transfer. On the secondary DNS server, it keeps the record around even after a zone transfer is sent. This allows you to be a secondary to a UNIX DNS, or to specify different WINS servers for a secondary which may be at a remote site away from the primary. -------------------- Problems + Reminders -------------------- -> Consult the eventlog. The DNS server logs numerous errors, warnings and useful information to the event log. If a problem is encountered be sure to check the eventlog. -> Error 13: The data is invalid. The DNS service will return this error when it is unable to load the database. 1) The location for the DNS database files is now hardcoded to the %SystemRoot%\system32\dns directory. DNS configuration and zone files will not be read from the %system32%\drivers\etc directory or from a directory indicated by the $DIRECTORY directive. 2) Consult the event log. Most error conditions are reported in the eventlog. Those involving problems loading the files usually include file and line number. -> Doubled domain names. A common DNS error is double domain names caused by failing to place trailing periods (".") at the end of fully qualified DNS names. If the error goes away when you ping the IP address (e.g., pinging foobar's IP address gives the correct name), then the problem must involve either a CNAME or A record (or both) for foobar with a fully-qualified (totally spelled out) domain name on the right hand side, that does not end in 'dot'. Otherwise, the problem is two-fold: 1) The reverse-lookup file for the in-addr.arpa domain has the wrong domain name in the SOA record, in this case, "dc-tbc.microsoft.com." instead of "xxx.in-addr.arpa." 2) The PTR record for that IP number has an FQDN on the right-hand-side (as it generally must) and does not end in 'dot'. Generally, If you type the trailing dot on the command line and the lookup fails, but it succeeds with a short name, your database files have missing dots at the end of FQDNs. - Nslookup Incompatibilities Some versions of nslookup require server support of the IQUERY opcode, which is a deprecated method of looking up an IP number. An example session with such an nslookup follows: machine# nslookup *** Can't find server name for address 1.2.3.4: Not implemented *** Can't find initialize address for server : Timed out Default Server: localhost Bus error (core dumped) machine# The solution to this problem is to upgrade to a newer version of nslookup, which is publicly available on the internet. A work-around to this problem is to point nslookup to a BIND name server at startup and then issue the "lserver" command to change servers. Most nslookup versions support the syntax: "nslookup - initial_server". Be sure to specify the initial server as an IP number. ----- Notes ----- - Auto-created reverse lookup zones: The DNS server will automatically create the 0.in-addr.arpa, 127.in-addr.arpa and 255.in-addr.arpa zones if your database setup does not include them. These zones answer bogus queries for 0.0.0.0, 127.0.0.1 and 255.255.255.255 IP addresses, keeping these queries from being recursed to the root name servers. You are encouraged to simple allow the DNS to create these zones and not bother creating themselves. - Statistics The DNS server provides some statistics on server behavior. The DNS manager exposes a very limited subset of these. For viewing and clearing the full set of statistics use the DnsCmd.exe tool. - Address sorting No attempt is made to sort addresses of multi-homed hosts (hosts with multiple addresses). The DNS server round robins the address list of all multi-homed hosts. This is the simplest solution for handling load balancing to a multi-homed server. If this solution is insufficient for or causes problems at your site, please send a bug report explaining the issue. Optionally providing alternatives to round robinning is under consideration. - SNMP + Perfmon The DNS does not currently export its counters through SNMP or Perfmon. This support will be added after the NT4.0 release. - Unsupported directives: * directory directive (all database files must be in system32\dns) * sortlist directive * $INCLUDE directive - Supported resource records: A, PTR, NS, SOA, CNAME, MX, MB, MR, MG, HINFO, TXT, MINFO, RT, RP, X25, ISDN, WKS, AFSDB, AAAA are fully supported. Note the AAAA is only supported as record data. It is NOT SUPPORTED as a DNS host address, i.e. it is NOT returned as additional record data during a query for NS or other record types. The MD and MF resource types are not supported in database files. These record types are obsolete, and references to them should be change to the MX type. Occurences of these types in database files are logged to the EventLog. - Learning about DNS: I recommend reading "DNS and BIND" by Paul Albitz and Cricket Liu (publisher: O'Reilly and Associates). This book is a great introduction to the Domain Name System, and to configuring BIND database files. ------ Thanks ------ Thank you for participating in the DNS Server beta program, your bug reports and suggestions have been most helpful. jim