IP addresses and names
No Comments
Written by Robert on April 13, 2008 – 5:08 am
IP addresses have to be used in packets that are transmitted. But even when converted to dotted decimal form, IP addresses are unsuitable for human consumption. There have to be mechanisms for mapping between IP addresses and memorable names.
ARPANET started with a simple table – after all it had a maximum of some two hundred machines. The table contained entries listing the names and the one byte numbers then used as machine addresses. A program that needed the address of a named server would open the file to read and search the table. The simple table approach was carried forward as ARPANET began its evolution into the Internet, and is still used for some limited purposes. Most computers will have something equivalent to an /etc/hosts file (this is a Unix/Linux file;Windows has a similar file). This will contain the IP addresses and names of the main server machines in a local network; these machines will appear with official names and, possibly, nicknames. An example of a modern version of such a hosts file is:
127.0.0.1 localhost loghost
130.130.68.33 aten.its.uow.edu.au aten
#
130.130.68.4 draci.its.uow.edu.au draci
130.130.68.17 kudan.its.uow.edu.au kudan
130.130.68.29 naga.its.uow.edu.au naga
130.130.64.1 wraith.cs.uow.edu.au wraith
130.130.68.64 helios.its.uow.edu.au helios
(The modern versions of the file use the DNS name as the official name.) These files still have a role in the name-to-IP mapping process. Most communications are amongst machines on the same local network; a quick search through such a file will resolve a large proportion of lookup requests.
The initial mechanism for handling name/IP mappings for the whole Internet was based on a similar hosts file. The Internet-wide name/IP mappings were held in a HOSTS.TXT file that was maintained by Stanford Research Institute’s Network Information Center (SRINIC). SRI-NIC had to be informed whenever an organization added a new machine or removed an existing machine, or in any other way changed IP addresses used within the address space that it had been allocated. SRI-NIC would check for consistencies (all machines in the hosts file had to be given unique names – there weren’t any domains back then to help split up the namespace). If the submitted data appeared valid, SRI-NIC would update the main hosts file. Systems administrators for Internetted machines would regularly download the latest hosts file. Resolving the name-to-IP mapping for an Internet host involved a search through a local copy of this reference file.
This scheme proved impractical for the growing Internet. There were several problems. First, the HOSTS.TXT file ceased to be small. Reading and searching through an unordered text file became something of a performance bottleneck as its size grew into the thousands of entries. The size of the file even had direct impact on network performance – there was constant traffic as Internet machines downloaded the latest version from SRI-NIC. There were also problems with validity. Most copies of the file would be out of date. Some entries might refer to IP addresses that had been reallocated; there would be no entries for newer servers in the local copy of the HOSTS.TXT file. Finally, the network traffic load and administrative load on SRI-NIC was becoming too large.
These problems were solved by reflecting them back onto those who were their sources. The problems were all due to organizations increasing the number of machines that they had, changing the names of machines, and changing IP addresses of machines in those parts of the address space that they controlled. The solution was to make each organization look after the name/IP mappings for their own machines (machines in their ‘domain’ of responsibility).
A machine’s name became a composite of a hostname (individual machine name), and a domain name. The domain name was essentially an agreed, standardized name that identifies the organization responsible for inventing the hostname and assigning an IP address to the machine. Name to IP mappings were to be handled by using the domain name to identify the responsible organization and then forwarding a name resolution request to that organization.
Each organization had to run a ‘name server’ that would handle name lookup requests submitted using a defined protocol. (At least one backup name server was also required in order to keep things running even when a name server machine went down.)Most requests sent to name servers would ask for the IP address of a named hostmachine that supposedly existed within that organization’s ‘domain’, but some requests would be for the hostname that should be used for a given IP address. The name servers used data files created by the systems administrator for a domain; these files were just slightly more sophisticated versions of a hosts file containing name, IP address and a little additional data for each machine in the domain.
Of course, you have to know the IP address of an organization’s name server machine before you can send requests to a name server program running on that machine. This was handled by grouping name servers into a hierarchy. At the very top of the hierarchy, the root, there was to be a name server that had tables that identified the IP addresses for the name servers for each of a small number of ‘top-level’ groupings or ‘domains’. Actually, 13 name server machines shared the task of handling this root table. The IP addresses for these root servers were held in a small, rarely changed data file that could easily be distributed to all sites using the Internet.
Popularity: 39% [?]
