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>