Unix for Advanced Users

13. Unix Networking

13.1. How Hosts Connect

Humans like working with recognizable names. So, when connecting to a remote machine, we prefer typing something like telnet lnxed1.ucs.indiana.edu instead of telnet 129.79.28.88. The problem is that the underlying networking protocol in Unix (namely TCP/IP) knows nothing about names. In order to connect, the first piece of information it must have is the remote machine's IP number. You probably guessed it; some sort of table which maps the hostnames to their IP numbers is needed. This process is called name resolution.

Fully Qualified Domain Name (FQDN): Each networked site is allocated a unique domain name. For us at IU-Bloomington, the domain name is indiana.edu. Most sites subdivide the domain further into subdomains. Each department (or institutional unit) usually gets its own subdomain name (such as math.indiana.edu for the math department here at IUB). Finally, hostnames are tacked on to the subdomain name to yield what is known as the fully qualified domain name (FQDN) (e.g. alpha.math.indiana.edu). If the subdomain is not tacked on, you have an unqualified hostname.

The /etc/hosts file: In the old days, when the number of hosts on the internet was small, the hostname to IP number mapping was done by a local file, namely /etc/hosts. As the internet grew to thousands (now millions) of hosts, it became impossible to keep all the information in a local file (not to mention the problems of distributing an authoritative version of the file). Security also became an issue - you could download a rogue version of the hosts file and connect to a hacker's machine instead of the real one.

Domain Name Service (DNS): To address these problems, DNS, a better name resolution solution was proposed. The idea behind DNS is to distribute the task of name space management to each individual site. Each site runs its own, authoritative name server, and a central dispatch mechanism is provided so that each site can resolve hostnames at remote (non-local) sites.

How remote hostnames are resolved: Let's say that you want to contact a remote host (such as linux.microsoft.com!). Here is how it works:

• The resolver library (against which all networking binaries are linked) on your system sends a request to a local nameserver (configured via the /etc/resolv.conf file, to be described below).
• The local nameserver contacts one of the central (also called root) nameservers which keeps a list of a redundant top level nameservers for resolving top level domains, i.e. .edu, .com, etc. The local nameserver is given the IP number of one of these top level nameservers.
• The local nameserver now contacts the .com top level domain server to obtain the address of Microsoft's nameserver.
• The local nameserver finally contacts the name server at Microsoft to resolve the hostname (i.e. get its IP number).
• Your local nameserer returns the information to your resolver.

How DNS is Configured: Most Unix workstations are configured in a resolver-only mode. The file /etc/resolv.conf configures the resolver by pointing it to the name servers for your domain. For example, here is a typical /etc/resolv.conf for a Unix workstation at IU-Bloomington:

search math.indiana.edu ucs.indiana.edu indiana.edu
nameserver 129.79.1.1
nameserver 129.79.5.100

Why doesn't the /etc/resolv.conf specify the nameservers by name?

So, the answer to the question "Is the remote hostname all I need to connect?" is a resounding no. Either the hostname to IP number mapping must exist in /etc/hosts, or the DNS must be queried to obtain the IP number corresponding to a hostname.