Describe the name resolution process

In DNS we have a hierarchical model it's fairly critical that it doesn't fail because the entire Internet is based on DNS.

In order that this model does not fail there should be a hierarchy of master and slave DNS servers. DNS offers choices that would cause this hierarchy to form, but just to let you know that there is almost invariably more than one server in DNS.

Every ISP is required to register for any new domain they create.

In Linux we're going to need to understand where to set our names to be looked up because in fact there are at least three different places where names can be looked up on the operating system: DNS is a hierarchical system, domains are organized in a tree structure, much like that of the Linux File System. The root of the tree is represented by a full stop (.) under that the top-level domains like .com, .edu, .net, .org etcetera are ordered. Included in the list of top-level domains are the country domains, like .uk, .za, .us, .ca etcetera.

DNS uses a distributed database to resolve the IP addresses of websites. For instance the root servers can resolve the IP addresses of the top-level domains, each of the top-level domains are able to resolve the IP addresses of the DNS servers that are delegated to those domains. This delegation continues to the DNS server of the ISP or Hosting companies of particular websites.

.   Root
    |----- .org
    |----- .com
    |----- .edu
    |----- .za -- ------| ----- org ----- eg.   tsf.org.za
    |----- .us		| ----- co  ----- eg.   ananzi.co.za
    |----- .uk		| ----- ac  ----- eg.   uct.ac.za  
    |----- .ca
            

The top-level domain addresses may not be purchased. Second level domains like www.google.com can be purchased.

Earlier I said that DNS is a distributed database. To understand what this means and why DNS works so well imagine a situation where one organization was responsible for all the IP addresses available on the Internet. Each time somebody purchases a domain name some person in that organization would need to add the new website's IP address and Fully Qualified Domain Name (see below) to the database. As you can imagine it would be impossible for one organization to do this seemlessly and at a low cost.

DNS works, because it is distributed. When I register a domain (www.riaan.music.choice.myisp.co.za) the company I host the website on registers the the IP address of my webserver against that domain name. If someone in Guatamala wanted to visit my website their ISP would not have my webserver's IP address, but they would have the IP address of the rootservers. These are the servers that are responsible for resolving the IP addresses of the top-level domains. So, the guy in Guatamala is trying to visit my website. His browser would send a request to his ISP, his ISP would not necessarily be able to resolve my IP address directly from my Domain name. What it would do then, is to contact the rootserver and ask it to resolve the IP address of .za domain.

When it has the IP address of the .za domain, it would ask the DNS server's of the .za domain to resolve the IP address of .co.za domain. The DNS server of the .co.za domain would be able to resolve the IP address of my.isp.co.za, which would give it the IP address of the ISP who is hosting my website. Finally it will ask my ISP to resolve the IP address of the www.riaan.music.choice.myisp.co.za which would allow the person in Guatamala to visit my site as soon as my ISP has registered the domain and the IP address of the host.

The host file

The first and certainly the oldest is our host file and that lives in /etc/hosts, and this is a very primitive name to IP address look-up mechanism.

A host file would look similar to:

riaan@debian:~> cat /etc/hosts
#
# hosts         This file describes a number of hostname-to-address
#               mappings for the TCP/IP subsystem.  It is mostly
#               used at boot time, when no name servers are running.
#               On small systems, this file can be used instead of a
#               "named" name server.
# Syntax:
#
# IP-Address  Full-Qualified-Hostname  Short-Hostname
#

127.0.0.1       localhost

# special IPv6 addresses
::1             localhost ipv6-localhost ipv6-loopback

fe00::0         ipv6-localnet

ff00::0         ipv6-mcastprefix
ff02::1         ipv6-allnodes
ff02::2         ipv6-allrouters
ff02::3         ipv6-allhosts

168.210.56.151   linux.local     debian

                

A little word of warning, if you don't put the fully qualified domain name as the first entry in the file, then when you try and access a host name on your machine, you will not get a fully qualified domain.

The first thing in your host file should be your fully qualified domain name and every other entry in your host file can be an alien. If I want my machine to also be called Hamish or Linux1, I can add it to my host file and in fact you can add any number of entries to your host file.

You are not restricted to just a single entry.

DNS Name Server

Names can also be looked up in the DNS name servers.

NIS

Host names can also be look up by using the NIS service (Network Information Service).

NIS's job is to have a central repository of network services. The host's file is a network service so NIS can distribute the host's file to a whole bunch of different machines on the network.

We'll talk about NIS later.

So where to look up the host name?

The danger of having so many places of looking hosts up is which one does it use?

Well, for that you have a file called /etc/nsswitch.conf and this file dictates how a name is looked up.

It's the Name Service Switch file and if you edit that file you'll see entries that are enabled as follows: the password for example comes from file or it might be 'compat' which means that it's compatible and it comes from file.

There are hosts, which come from file but it can also come from DNS. Networks for example, might come first from file and then from NIS and then from DNS and then from NIS+.

debian:/etc# cat nsswitch.conf
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd:         compat
group:          compat
shadow:         compat

hosts:          dns files
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis
                

This file defines the order in which hosts will be looked up, they are firstly looked up in file, in other words, in /etc/host and only after that, they will be looked up in DNS.

In fact in the example above the hosts will never be looked up because DNS would be used before the /etc/hosts file

Now if we wanted our host to first be looked up in DNS we could obviously switch the entries around.