windows-xp/Source/XPSP1/NT/ds/dns/server/samples/dnsread.txt

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