Here is some material from my archives. Some of the specific site info
(and email addresses are dated). Nevertheless the basics remain ...
C&IS LAN Administrator Tutorial
What is the DNS and how do you use it?
An Introduction to the Domain Name System
by
[log in to unmask]
10/30/92
<draft 1>
The basic purpose of the Domain Name System is to allow character-based
host names (Fully Qualified Host Names (FQDN)) to be translated to their
IP Address (dotted quad notation).
IP addresses (and not FQDNs) are the basis of all TCP/IP packet
transport.
The DNS is NOT a single or flat file situated on some computer
somewhere; instead it is a distributed hierachical database, using a
client/server model of access. The client is usually called the
resolver and it makes a request (lookup) to the server.
Interestingly enough, not all FQDNs are on the Internet. In particular,
there is a feature of the DNS that allows one to e-mail (SMTP) to
machines NOT on the Internet, but gatewayed through machines on the
Internet. In this case, the gateway machine is called a Mail eXchanger
and DNS constructs that map the FQDN of the non-Internet machine to the
gateway are called MX records.
The DNS is also used to do reverse (or in DNS parlance "pointer")
lookups. That is, given an IP address, what is the FQDN. Certain SMTP
and anonymous FTP servers will do this and if the customer-provided and
system-provided information does not coincide, then no service will be
provided, or perhaps a warning message will be issued.
<dns1>
Network Working Group E. Krol
Request for Comments: 1118 University of Illinois Urbana
September 1989
The Hitchhikers Guide to the Internet
Names
All routing across the network is done by means of the IP address
associated with a packet. Since humans find it difficult to remember
addresses like 128.174.5.50, a symbolic name register was set up at
the NIC where people would say, "I would like my host to be named
uiucuxc". Machines connected to the Internet across the nation would
connect to the NIC in the middle of the night, check modification
dates on the hosts file, and if modified, move it to their local
machine. With the advent of workstations and micros, changes to the
host file would have to be made nightly. It would also be very labor
intensive and consume a lot of network bandwidth. RFC-1034 and a
number of others describe Domain Name Service (DNS), a distributed
data base system for mapping names into addresses.
We must look a little more closely into what's in a name. First,
note that an address specifies a particular connection on a specific
network. If the machine moves, the address changes. Second, a
machine can have one or more names and one or more network addresses
(connections) to different networks. Names point to a something
which does useful work (i.e., the machine) and IP addresses point to
an interface on that provider. A name is a purely symbolic
representation of a list of addresses on the network. If a machine
moves to a different network, the addresses will change but the name
could remain the same.
Domain names are tree structured names with the root of the tree at
the right. For example:
uxc.cso.uiuc.edu
is a machine called "uxc" (purely arbitrary), within the subdomains
of the U of I, and "uiuc" (the University of Illinois at Urbana),
registered with "edu" (the set of educational institutions).
A simplified model of how a name is resolved is that on the user's
machine there is a resolver. The resolver knows how to contact
across the network a root name server. Root servers are the base of
the tree structured data retrieval system. They know who is
responsible for handling first level domains (e.g., 'edu'). What
root servers to use is an installation parameter. From the root
server the resolver finds out who provides 'edu' service. It
contacts the 'edu' name server which supplies it with a list of
addresses of servers for the subdomains (like 'uiuc'). This action
is repeated with the sub-domain servers until the final subdomain
returns a list of addresses of interfaces on the host in question.
The user's machine then has its choice of which of these addresses to
use for communication.
A group may apply for its own domain name (like 'uiuc' above). This
is done in a manner similar to the IP address allocation. The only
requirements are that the requestor have two machines reachable from
the Internet, which will act as name servers for that domain. Those
servers could also act as servers for subdomains or other servers
could be designated as such. Note that the servers need not be
located in any particular place, as long as they are reachable for
name resolution. (U of I could ask Michigan State to act on its
behalf and that would be fine.) The biggest problem is that someone
must do maintenance on the database. If the machine is not
convenient, that might not be done in a timely fashion. The other
thing to note is that once the domain is allocated to an
administrative entity, that entity can freely allocate subdomains
using what ever manner it sees fit.
The Berkeley Internet Name Domain (BIND) Server implements the
Internet name server for UNIX systems. The name server is a
distributed data base system that allows clients to name resources
and to share that information with other network hosts. BIND is
integrated with 4.3BSD and is used to lookup and store host names,
addresses, mail agents, host information, and more. It replaces the
/etc/hosts file or host name lookup. BIND is still an evolving
program. To keep up with reports on operational problems, future
design decisions, etc., join the BIND mailing list by sending a
request to [log in to unmask] BIND can also be
obtained via anonymous FTP from ucbarpa.berkeley.edu.
There are several advantages in using BIND. One of the most
important is that it frees a host from relying on /etc/hosts being up
to date and complete. Within the .uiuc.edu domain, only a few hosts
are included in the host table distributed by SRI. The remainder are
listed locally within the BIND tables on uxc.cso.uiuc.edu (the server
machine for most of the .uiuc.edu domain). All are equally reachable
from any other Internet host running BIND, or any DNS resolver.
BIND can also provide mail forwarding information for interior hosts
not directly reachable from the Internet. These hosts an either be
on non-advertised networks, or not connected to an IP network at all,
as in the case of UUCP-reachable hosts (see RFC-974). More
information on BIND is available in the "Name Server Operations Guide
for BIND" in UNIX System Manager's Manual, 4.3BSD release.
There are a few special domains on the network, like NIC.DDN.MIL.
The hosts database at the NIC. There are others of the form
NNSC.NSF.NET. These special domains are used sparingly, and require
ample justification. They refer to servers under the administrative
control of the network rather than any single organization. This
allows for the actual server to be moved around the net while the
user interface to that machine remains constant. That is, should BBN
relinquish control of the NNSC, the new provider would be pointed to
by that name.
In actuality, the domain system is a much more general and complex
system than has been described. Resolvers and some servers cache
information to allow steps in the resolution to be skipped.
Information provided by the servers can be arbitrary, not merely IP
addresses. This allows the system to be used both by non-IP networks
and for mail, where it may be necessary to give information on
intermediate mail bridges.
The following list is not necessary for connection to the Internet,
but is useful in understanding the domain system, mail system, and
gateways:
RFC-974 Mail Routing and the Domain System
RFC-1009 Requirements for Internet Gateways
RFC-1034 Domain Names - Concepts and Facilities
RFC-1035 Domain Names - Implementation and Specification
RFC-1101 DNS Encoding of Network Names and Other Types
<dns0>
As to HOW mail routing is performed ... from Frey & Adams,
Appendix E: How Internet Addresses are Handled by UUCP Sites:
---- start of quoted text ----
For hosts running IP on the real, physical Internet (as distinct from
the pseudo-, nonphysical internet of hosts capable of using this kind
of addressing), routing to reach a domain address is done in what can
be called {real time}. For example, the mailer sees that you have
written mail to [log in to unmask] and so it queries a program
called nameserver running on the system.
The nameserver asks the authoritative root servers who handles mail
for some.where.edu. The root servers return, not the actual address,
but pointers to other servers that really know all the details of
hosts inside the organizational entitiy where.edu. These pointers
are ns (NameServer) records, and they point to servers that perform
lower-level nameservice.
The mailer now queries those servers, asking which host handles mail
for some.where.edu, and (one presumes) and address is returned by
these servers. Then the mailer, knowing where to deliver mail an
dhow to do so, connects with the remote mailer and delivers the mail
via a protocol called SMTP (Simple Mail Transport Protocol).
If a host is not physically connected to Internet (and thus is not
directly reachable), a mailer gets back, not addresses, but rather
another type of pointer called an MX (Mail eXchanger) record. MX
records indicate the hosts that have advertised a willingness to be
the mail exchanger for the indicated destination. For instance, if
there were a site zebra in Denver registered as zebra.den.co.us and
you sent mail to it, the approximate sequence of events would be:
1 The mailer accepts the mail message from the user agent.
2 The mailer asks the local nameserver, "How do I get mail to
zebra.den.co.us?"
3 The nameserver doesn't know, so it asks the root servers,
"Who's in charge of Colorado?" Of course, this assumes that
the person sending e-mail is in the United States. -- rlm
4 Root servers, via NS records, return the information,
"venera.isi.edu is the host in charge of Colorado."
5 The nameserver then asks venera, "How do I push mail in the
direction of zebra.den.co.us?"
6 venera opens, "Mail addressed to zebra.den.co.us should be
handed to boulder.colorado.edu.*"
7 The nameserver returns this answer to the mailer and caches a
copy of the answer in case it's asked again in the near
future.
8 The mailer opens an smtp connection to boulder.colorado.edu
and sends the mail. It assumes that the mail exchanging
hosts knows how to detect the destination hosts for which it
serves as MX (usually syntactically) and that it will then
convert the mail to some other transport (probably UUCP in
this case).
* boulder.colorado.edu is used as an example only.
---- end quoted text ----
<dns3>
4.1.1 IP Connectivity
Correct attachment to the Data Backbone and correct implementation
of TCP/IP protocols allow the local user access to a wide range of
available Penn State computing resources.
4.1.1.1 IP Addresses
TCP/IP networks and hosts are accessed by reference to an IP
address. IP addresses are defined as a dotted set of 4 decimal
numbers, each in the range 0 to 255 (example: 128.118.25.2). The
address gives the user some information about the location of the
referenced system by being arranged in a defined hierarchical
order. For example, 128.118 is a network number assigned by the
Internet control authority to Penn State University. Penn State
then uses the next number of the dotted set to represent campus
subnetworks, so that 128.118.25 is the address of the OTC Ethernet
in the Telecommunications Building. Penn State subnet numbers are
assigned to the different departments requesting them by OTC. The
last number in the dotted address set is a host number on the local
subnetwork. 128.118.25.2 thus is the address of the TN terminal
server on the OTC Ethernet on the Penn State University network.
The local subnet host numbers are assigned by the departmental
subnet administrators.
4.1.1.2 Internet Host and Domain Names
Since the user normally wishes to refer to systems by name rather
than by IP address, there is also a TCP/IP naming structure for
system addresses. The name is given as a dotted set of subnames
such as PSUVM.PSU.EDU or SHIRE.CS.PSU.EDU. These subnames are also
arranged in a hierarchical order. Each of these subnames represents
a separate Internet "domain" (or finally, a hostname). EDU, for
example, represents the "top-level" domain of educational
institutions. PSU.EDU is a centrally assigned name designating the
Penn State University (PSU) domain. CS.PSU.EDU designates the
Computer Science Department subdomain at Penn State and PSUVM and
SHIRE represent host names.
Domain and subdomain names do not map 1 to 1 to network and
subnetwork addresses. For example, one administrative subdomain
might include more than one subnetwork. TCP/IP networks then make
use of "nameservers", which are host computers that translate
Internet names into correct IP addresses. This eliminates the need
for the user to maintain local IP-address-to-host-name tables.
Most TCP/IP networks also make use of "domain nameservers" which
translate names specific to a given domain and thus allow the use
of shortened Internet names such as PSUVM for PSUVM.PSU.EDU for any
user within the PSU.EDU domain.
4.1.3 Additional Network Services
OTC now operates two services which are automatically available to
all TCP/IP Data Backbone users: Internet Domain Name Service and
NTP (Network Time Protocol) Service. The following sections
outline basic considerations for use of these services. Specific
user questions should be directed via electronic mail to
[log in to unmask]
4.1.3.1 Domain Name Service
OTC now operates the Domain Name Server for Penn State (that is,
for the PSU.EDU domain). End users connecting to the Data Backbone
have automatic access to Domain Name Service, but must implement a
Name Resolver on their local system to use the name service. The
particular resolver implementation will depend on the type of local
system. Users of PC/TCP Software, for example, enter the name
server address in a simple configuration command. Users of Unix
systems must enter the name server host name and IP address in the
/etc/resolv.conf file. The official Penn State name servers are:
OTC2.PSU.EDU 128.118.25.3
ISENGARD.CS.PSU.EDU 130.203.1.4 and 130.203.3.2
Penn State Data Backbone users should register their host names in
the PSU.EDU Domain. To do so they must first have a valid IP
address assigned to the host system (by the local subnet
administrator). They must then submit a request through the local
subnet administrative or technical contact person (see Section 5.2)
to OTC stating the target IP address and requested host name. These
requests should be sent via electronic mail to:
[log in to unmask] Names are assigned on a first-come first-
served basis so that if the requested name is already in use in the
PSU.EDU domain, the user will be asked to choose a different name.
Departments may wish to establish separate official subdomains
within the PSU.EDU domain for the sake of management efficiency
etc. OTC's current policy is to leave the choice up to the
individal department, college or administrative unit as to whether
they wish to register their host systems in the PSU.EDU domain or
within a designated subdomain. Examples of official PSU.EDU
subdomains are CS.PSU.EDU (Computer Science), MATH.PSU.EDU
(Mathematics), HMC.PSU.EDU (Hershey Medical Center). If a
department wishes to establish a separate subdomain within the
PSU.EDU domain, a request to this effect should be sent by the
subnet administrative or technical contact person via electronic
mail to [log in to unmask] The request should include the
desired subdomain name and a list of the hosts which are to be
included in the subdomain. Once again the names are assigned on a
first-come first-served basis.
OTC maintains the name server host tables for all official PSU.EDU
subdomains as well as for the main PSU.EDU domain, but subdomains
may choose to maintain their own subdomain name servers. The
Computer Science, Math and Physics departments at Penn State,
amoung others, maintain their own name servers. If a given
subdomain wishes to assume local operation of their own name
server, they must coordinate this effort with OTC by the same
contact process as mentioned above.
Glossary
Domain A naming category in the domain naming system.
For instance, a host named silk.ftp.com has two
levels of domain name. It has a hostname of
silk, and is part of the ftp domain within the
com domain.
Domain Naming System A hierarchial system of host naming. It allows
for grouping hosts into categories. For
instance, in the ARPANET naming scheme, hosts
with extensions of .COM are commercial hosts, and
names with extensions of .EDU are educational
hosts.
Host name Resolution A mechanism which provides static and dynamic
mechanisms for resolving host names into numeric
addresses. The Internet Name Server Protocol
accesses an Internet Name Server which provides
dynamic name-to-number translation (this process
is specified in IEN 116). The Domain Name
Protocol accesses a Domain Name Server which
provides dynamic name-to-number translation
(this process is specified in RFCs 882 and 883).
A static local host table can also be accessed
for name-to-number translations.
<end>
|
