315 lines
11 KiB
Plaintext
315 lines
11 KiB
Plaintext
|
|
||
|
|
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
|