We heard yesterday that the Internet started as the ARPAnet network, developed by the Department of Defence in the US. Then one file was sufficient to hold all the information necessary to allow communication between hosts. This has evolved into the DNS of today which is a distributed database with each data segment being available across the entire network through a client-server scheme. The structure of this database is very similar to an inverted tree and has a hierarchial structure. Charles has already mentioned that each node in the tree corresponds to a domain of the Domain Name system. The root of this tree is written as a single dot. Under the root are the first level domains such as .COM, .ORG and country names like .MT. I have shown here the emerging subdomains of mt.
The UK namespace, which I deal with every day, started out with only two subdomains - ac.uk for academic sites and co.uk for businesses. Now there are many more and new subdomains are being added at the present time.
Every domain has a domain name which identifies its position in the database. Each domain may be administered by a different organisation and broken down into subdomains and responsibility for those subdomains given to other organisations. This process is called delegation.
Every host on the Internet has a domain name which points to information about that host. Records such as IP addresses, MX records, holding mail routing information. The programs which hold this information are called name servers and they make the data available to client programs called resolvers. The name servers usually hold all the data for some part of the domain name space, called a zone. The name server is then said to be authoritive for that zone. The difference between a zone and domain is that a zone contains the domain names and data of a domain except for domain names and the associated data which are delegated elsewhere.
All this information stuck on nameservers, how is it used to enable communication over wide area networks? When any program running a machine wants to make a connection with a remote host for some reason its IP address is required.
Queries are sent to nameservers requesting information about domain names. These queries may be recursive or non-recursive.
Recursive queries must return an answer or an error message saying that the domain in question does not exist. Recursive queries put most of the burden on one particular nameserver. Non-recursive queries return the best answer the nameserver has. If the nameserver is not authoritive for that domain then the reply can be thought of as hints as to where to find the information required. These are likely to include the names of nameservers and their addresses closer to the domain in question.
UNIX hosts will use a library program called libresolv to contact the local DNS server. libresolv will ask the server to find out and return the IP address of the remote host. In a Sun network the request goes through NIS (Network Information Services) first and NIS then uses libresolv to send a request to the DNS server on the LAN. If the local nameserver on your INTRA-net is authoritive for that domain then either this, local, DNS server or the NIS will know the answer and can immediately return the answer to the program. If the nameserver is NOT authoritive for the domain then it must make further queries out to the Internet. This process of finding out information on domains a nameserver is NOT authoritive for is called resolution.
Libresolv must be very simple as it is linked into every program run on a machine at compile time. This resolver takes up as little memory as possible. Because it is simple it only sends out single recursive queries. This can be thought of as a security feature, not allowing machines on a secure sub-net direct access to the Internet. This system also allows caching of the answers received on the local DNS server. All the information it receives can be stored in memory. So at some point in the future, if the same or a related query is made the server may have the answer in its cache. Or at least it may know the names and addresses of the authoritive nameservers for that zone and can go to them first rather than start at the root nameservers each time. This speeds up the resolution process.
Cached data is not held forever. Alongside the other records domain name data also contains a Time-To-Live, a TTL. This is the maximum length of time a nameserver is allowed to cache the data. After this time the nameserver must request the information again or discard it. A compromise is necessary between a short and a long TTL. Having a short TTL will make sure your visible DNS records are up-to-date and consistent across the Internet. However, having a long TTL will reduce the load on your local namserver(s) but may lead to inconsistent data across the Internet when you change your DNS records for any reason. This happened at ExNet recently when we added a third nameserver and changed the IP address of your primary (main) nameserver. This was an occasion when we wanted a short TTL to make sure remote nameservers queried our authoritive nameservers and didn't cache out-of-date and incorrect data for too long.
Resolution process - In the slides we go through the resolution of a pointer query for domain 7.34.207.194.in-addr.arpa. As has been mentioned, a pointer record maps an IP address back to its domain name.
To achieve this inverse IP mapping as it is called , part of the domain space was set up with addresses as names. This is the arpa domain. Nodes in this domain are named after the dotted octet representation of IP addresses eg 192.135.233.213.in-addr.arpa. This dotted octet representation is the expression of 32 bit IP addresses as four numbers in the range 0 to 255, separated by dots. So there could be 256 subdomains of the root in-addr.arpa domain and 156 subdomains of one of those domains etc. This domain is very large and must be enough for all the hosts in the Internet. (Addresses are likely to run out in the next few years if the Internet carries on growing the way it has recently)
Looking at an arpa domain it gets less specific from left to right whereas the corresponding domain name would become more specific from right to left. So the numbers in the arpa domain reads in the IP address backwards. This convention gives administrators the ability to delegate authority for these domains to particular networks.
In the query shown, first one of the root nameservers for the in-addr.arpa domain is sent a non-recursive query for the 7.34.207.194.in-addr.arpa domain. Since it is NOT authoritive for the domain it returns an empty answers section and 'hints' - the names and addresses of nameservers closer to the domain in the query. In this case the name and address records for the 192.in-addr.arpa domain is returned. Now the local DNS server can sent out the query again to this nameserver as it has its address. Similar to before the nameserver authoritive for 194.in-addr.arpa is NOT authoritive for the 7.34.207.194.in-addr.arpa domain. This time the names and addresses of nameservers even closer to the domain are returned. When one of these nameservers are queried they return the data we are looking for and the local DNS server on your INTRA-net can return it to the program which requires it.
User Command queries slide
Firstly -- address query. This is how a sysadmin would send the query using the dig command. Here I am requesting the nameservers authoritive for exnet.com
The inverse query here is asking for the pointer records for this particular arpa domain. I can ask this in two different ways. One with the proper representation and one with the IP address format which is automatically reversed for me when the query is made. This domain just happens to be one of the computer science machines at Queen Mary and Westfield College, part of the University of London.
As more and more hosts connect to the Internet it becomes more important to keep to this "ideal" hierarchial structure to prevent overloading of any one nameserver. The issue is one of bandwidth rather than CPU performance. Important nameservers must be able to deal with a large number of queries and it is much better to spread the load over a number of nameservers.
The process of registering a domain name in the UK namespace has two main sub-processes. When a customer asks an ISP to register a domain name for them a request will be sent to the UK Naming Committee, This will time-out after three days if there are no objections to the name. Then the ISP can send a delegation request to the appropriate body.
In an effort to subdomain where possible, and thus distribute the DNS database even further, the UK has tried to encourge the use of third level domains as a starting point for registration of company domain names. The aim was to put companies under subdomains such as music.co.uk (for organisations in the music industry), radio.co.uk (radio stations), etc. This would improve the efficiency of resolution process. However people were reluctant to register these names as they were long and cumbersome. No matter how technically elegant this solution was it clashed with the new commercial feel of the Internet where snappy domain names are hot property. Even legal matters have to be considered. Legal matters also have to be considered. As an Internet Service Provider, if a customer comes to ExNet wanting to register microsoft.co.uk - should we go ahead? They may be masquerading as the real microsoft known as "passing-off". This is illegal. The Naming Committee expects ISPs to have made reasonable checks that a company is trading under the name they say are trading under. We are expected to ask for letterheads and company registration numbers for Ltd companies. If legal problems arise who is responsible? The customer, the ISP for not checking properly, the Naming Committee for approving the name (although microsoft.co.uk is well known what about not so well known names?), the organisation who delegated the domain? Currently a company is being set up to run a Naming Service which is hoped to address these problems.
Malta has a good range of subdomains which will be a good framework for placing all the domain names which will be registered in the future.
To recap this talk covered the heirarchial structure of the DNS, briefly mentioned the types of records held for each domain name. The process of resolution was explained. Finally the commercial and legal issues of registering domain names cannot be ignored.