Ref: 21770010
Title: Undocumented Requirement for Domain Name Resolution on the NCS/AT
Date: 4/3/91

Copyright 3Com Corporation, 1991.  All rights reserved.

Domain name resolution starts at the root domain name server and works
down a hierarchical tree to sub-domain name servers at the ends ("leaves")
of the tree structure.  When a client queries the domain name server, the
server checks to see if the name exists within the subdomain for which the
server is an authority.  If the name exists in the server's database, the
server returns the IP address for the name queried.  If the name does not
exist, the server checks to see whether or not recursive resolution has been
requested by the client.  When recursive resolution has been requested, the
server is responsible for contacting a domain name server that can resolve
the name and return the answer to the requesting client.

The NCS/AT Domain Name Service does not implement recursive resolution.
Clients can send only non-recursive resolution requests.  If the NCS/AT
cannot resolve the name from within its own database, it replies with
information about the name server the client should contact next to
resolve the name.

For a client within the domain to find the name server at which to begin,
the client must first set the name service address to the IP address of
the NCS/AT.  On 3Com's Comm Servers, this is done with the
SETD PrimaryNameService = <IP address> command.

If the NCS/AT cannot reply with a resolution to the name request, it
must, in the domain names (dnnames) database, supply information about
other name servers who can resolve the name; otherwise an error will occur.
NS records are used to indicate the names of the domain name servers that are
authorities for other domain name zones.

Note:  Domain name zones and the name servers that are authorities for
those zones are created arbitrarily by the designer.  The designer usually
follows administrative groups unrelated to the physical layout of network
connections.

In setting up the domain name structure, the designer should implement
the distributed dnnames database such that local clients can resolve domain
names by querying the domain name server within the same namespace, without
having to query the root or parent domain name server immediately above
it.  This prevents inefficient queries that start at the root of the
domain and work down the tree to the local domain name server.  It also
lessens the chance of name resolution failure when, for example, a
higher-level name server across a router is down, or the router is down, or
the link itself is down, even if the local name server could resolve the
name.


** IMPORTANT, UNDOCUMENTED FEATURE FOR DOMAIN NAMES ON THE NCS/AT **

In order for the name resolution to use the local server before searching
for name servers at the domain immediately above it, the administrator for
the dnnames database must include an SOA-type record which specifies the
"start of a zone of authority."  Without an SOA record present in the
NCS/AT's dnnames file, the client will first query the PrimaryNameServer,
which will reply with information about the parent name server the client
should contact next, instead of resolving locally--even if the name is
present in the database.  The parent domain name server will then reply
with information about the domain name server to contact next--which happens
to be the name server that was previously queried by the client within the
same namespace.

SOA record types are not currently documented in the NCS/AT Operations
Guide.  (Only NS, A, and CNAME records are defined.)  Please refer to RFCs
1034 and 1035 for an explanation of SOA record types.

