1.0 Configuration

You must have a set of configuration files in place in order for the
DNS service to start.  These files are:

  - A file named "boot" in the %SystemRoot%\system32\drivers\etc directory.

  - Database files specified by the boot file.

You can use files from a BIND installation at your site, or you can use
the included files, which contain comments to help explain their format.

The included files are:
  boot
  cache
  arpa-127.rev
  arpa-257.rev
  place.dom  

The purpose of these files is as follows:

boot    - This file controls the startup behavior of the DNS server.
          The syntax of Windows NT DNS boot files is compatible with
          BIND boot files.  Briefly, the syntax of this file is as
          follows:

          Commands must begin at the beginning of a line.  No spaces
          may precede commands.  Recognized commands are: "directory,
          cache, primary, and secondary."  The syntax of these commands
          is:

          "directory <pathname>"  - Causes the server to read database
          files from the directory given by <pathname> instead of from
          the %SystemRoot%\system32\drivers\etc directory.

          "cache     .    <filename>" - Specifies a file used to help
          the DNS service contact name servers for the root domain.
          This command and the file it refers to MUST be present.  
          A cache file suitable for use on the Internet is provided.

          "primary    <domain> <filename>" - Specifies a domain for
          which this name server is authoritative and a database file
          which contains the name information for that domain.

          "seconday   <domain> <hostlist> [<filename>]" - Specifies
          a domain for which this name server is authoritative, and
          a list of host's IP addresses from which to attempt downloading
          the zone information, rather than reading it from a file.
          The optional filename instructs the DNS service to maintain
          a backup copy of the downloaded information, in the specified
          file.

cache   - This file contains host information that is needed to 
          achieve usable DNS connectivity.  For users on the Internet,
          the provided file should suffice.     
          
arpa-127.rev  - A database file for the 127.in-addr.arpa. domain. 
                This domain is used for reverse-lookups of IP numbers
                in the 127 network, such as "localhost."  This file 
                should be usable as provided.

arpa-257.rev  - A fictitious database file for reverse lookups in 
                the fictitious "257" network.  This file must be edited 
                and renamed before use on a production DNS servers.

place.dom     - A fictitious database file for looking up host names
                in the "place.dom" domain.  This file must be edited
                and renamed before use on a production DNS server.

To use these files, you must change the database information to match
your companies info.  Note that information in arpa-257.rev and place.dom 
is fictitious.

1.1 Setting up WINS name resolution

In some settings, it well be advantageous to use the DNS service as 
a "provider" of WINS names.  For example, you may want to be able
to use a UNIX machine to connect to a machine with a WINS name and 
no fixed IP address.  In this case, point the UNIX machine's resolver
at the NT machine running DNS service, and make sure that the DNS
service's machine has a properly configured WINS server.  Then, decide
which domain WINS names will belong in.  For example, you might 
decide that the domain "nt.place.dom." is the name space in which 
all WINS machines will be named.  You would then expect queries for
"testmachine.nt.place.dom." to be handled via WINS lookup, looking
for the machine "TestMachine".

To do this:

- For each domain in which you wish to attempt WINS resolution of
  hostnames, add the "$WINS" directive.  Note that this directive 
  must be on a line by itself, and start in column 1.  Note also,
  that the quote are NOT to be typed. 

  The "$WINS" should immediatly follow the SOA resource record.

For an example, see the place.dom file.

NB: Do not put the "$WINS" in reverse-lookup ( in-addr.arpa. ) 
    domains.

1.5 Learning about DNS

I heartily 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.

2.0 Installation

To instal the Domain Name Server Service, follow these instructions:

  1. Read through this entire file.  Be sure that the boot file and
     the database files are in the proper directories.

  2. You must install the TCP/IP protocol software on your machine.  

  3. Run the "install" batch file from the directory which contains
     the DNS service files.  This batch file will:

     - Copy the DNS service executable file to your system directory.

     - Configure the registry entries that control the DNS server.

     - Start the DNS server.

  4. Open the Control Panel applet, and choose the serices Control
     Panel.  

  5. In the services control panel, look for the name "Dns,"  and select
     it.

  6. Press the "Startup..." button.

  7. Choose Automatic Startup, and press the "Ok" button.



3.0 Contacts for Bug Reports:

If you would like to report a bug or a suggestion, or if you have
a quesition, please email:

  t-heathh@microsoft.com.

    - and -

  davidtr@microsoft.com.


Thanks for participating in this Beta program!

4.0 Release notes

Particulars:

- 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 under the "System" category.

Limitations:

- The NULL resource type may not appear in any database file read at
  boot-time by the DNS server.  This will be corrected in a later
  revision of the server.

- If the "responsible party" entry in a database file's SOA record
  matches identically with a hostname in the DNS, data for that host
  may contain one extra mailbox record.  For example:

    @ IN SOA microsoft.com. joe.microsoft.com. (....)

    joe.microsoft.com. IN A 1.2.3.4

  Would cause the machine joe.microsoft.com to contain two records,
  an A record for 1.2.3.4, and an MB record for microsoft.com.

  This will be corrected or clarified in a later revision of the 
  server.

- Data in the cache file which does not pertain to the root domain
  name servers is not ignored properly.  If you use a cache file 
  from a system running BIND, you may end up with extra entries in
  your database that you do not see with BIND.  The solution is to
  edit your cache file to contain only entries relevant to lookups
  against the root domain.

- The current DNS server must not be authoritative for the root 
  domain.  In more detail, the cache file must contain at least
  one NS record for the root domain, and that NS record must have
  at least one A record specified in the cache file.  This prevents
  the DNS server from being authoritative for the root domain.  
  This will be corrected in a revision.

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.

Warnings:

- This DNS server is "Beta" software provided for testing purposes.
  Because of this software's interaction with the FTP Server, DHCP
  client services, and the LPD TCP/IP printing service, it is not
  recommended that this software be run on a production server for
  any of the affected services.





