.

[an error occurred while processing this directive]

 

Features - February 1999 - Everything you wanted to know about DNS but were too afraid to ask
Richard Adams takes an in-depth look at the intricate workings of DNS
.

Implementing a DNS service in an NT network isn’t always necessary. NT makes use of LAN Manager-based NetBIOS names to provide essential domain services such as authentication, domain synchronisation and browsing. So, when do you need DNS and what does it do? The purpose of DNS (Domain Name Space, Service or Server – it depends on the context and the speaker) is, of course, to provide hostname resolution. This is the process of taking a user-friendly name for a computer (known as a host in the world of TCP/IP) and finding out or resolving its IP address in order to be able to address packets of data to it over the network. Without the IP address, we would not be able to send or receive messages over TCP/IP and although in most cases it is possible for the user to specify the IP address directly to the application, who knows or cares to remember the IP addresses of all resource servers on an intranet or, worse still, the Internet?

The Domain Name Space

Let’s start by taking a look at the Domain Name Space. This refers to the hierarchical organisation of domains and hosts on the Internet or an intranet. In this case, the term domain does not refer to Microsoft’s logical organisation of servers and workstations in Windows NT, but rather to the worldwide, open standard, naming convention on TCP/IP networks. Let’s take a look at the logical arrangement of the Internet through DNS to see how domains and hosts are organised. When the Internet was first developed, no-one thought that it would ever need to support anything like as many hosts as it does today. Each host had a unique IP address and a unique hostname and these were mapped onto a simple, flat-file database and stored on a server that everyone could access. If a user on HOSTA wanted to use resources on HOSTB, all he had to do was query this database file, asking for the IP address that corresponded to the entry for the name HOSTB. Once the IP address for HOSTB had been resolved, HOSTA could start addressing data packets to HOSTB. Flat file database storage is no longer practical as there are tens of thousands of hosts on the Internet and even an intranet can run into several hundred, so the Domain Name Space was developed to take its place.

DNS structure

Unlike the hosts system, Domain Name Space has a hierarchical, tree-like structure. Within this structure are tiers known as domains and subdomains and hosts can reside within each domain. Each subdomain in turn can contain further subdomains or hosts. Within this domain/subdomain structure, the total number of hosts throughout the Internet is divided up and arranged into logical groupings. At the top of DNS lies the root. The root is represented by a full-stop (.) although this is usually left out when one types an address – including it would be a bit like posting a letter to somebody and including ‘Earth’ as the final line of the address. The root exists for two purposes. Firstly, it is there as a master container from which domains and subdomains can be created, and secondly, it contains a set of DNS servers, which are used to assist in the process of hostname to IP address resolution. More about that later, but for now let’s look at the first tier down within the Domain Name Space.

This tier contains the basic domains that exist on the Internet. Examples include com, gov, mil, edu and country-specific domains such as nz, uk, etc.. These are referred to as Top Level domains. In a similar way to the root, top level domains exist firstly as a container in which to create domains and subdomains and secondly as a container for DNS servers. These DNS servers are registered as records in the DNS servers at the root level. We will see why later.

Both the root and top level of DNS are not owned or governed by any one company or organisation, but instead are maintained for and on behalf of the entire Internet community by a body known as InterNIC which comprises engineers, scientists, strategists and decision-makers loaned by various companies and organisations on a voluntary basis. Most (if not all) of these companies derive very large business benefits from ensuring the ongoing growth and usability of the Internet. It is InterNIC that looks after the DNS system and provides the central stability and resources that allow the Internet to be useful and organised.

Second level domains

Underneath the top-level domains come Second Level domains. These domains are not owned and maintained by InterNIC, but by separate companies, organisations or even an individual person if that’s what turns them on. Second level domains are applied for through InterNIC or one of its local (as in local to your own country) subsidiaries. To obtain a second level domain, you must first of all choose a name that is unique to the top-level domain in which you wish to create your domain.

For example, a company called Top Banana (UK) Ltd may decide it wants to apply for the domain topbanana.co.uk. As long as topbanana.co.uk has not already been registered then they will be able to proceed, even if there is a topbanana.nz already in existence elsewhere. The second requirement for obtaining a second level domain is to provide the IP addresses of two DNS servers (a primary and a fault-tolerant backup) on which zone information for the domain and any subdomains will be stored. These IP addresses are again registered, but this time with the top-level domain rather than the root. The third requirement for obtaining a second level domain is to hand over a registration fee (currently £75) on an annual basis. Once a second level domain has been obtained, it is entirely up to the body in whose name it is registered to use it and maintain it. The second level domain becomes the root level domain for that company, who can then create subdomains, sub-subdomains and so on for as many levels as they wish. For example, Top Banana (UK) Ltd might decide to create the subdomains london.topbanana.co.uk and edinburgh.topbanana.co.uk and perhaps even sales.london.topbanana.co.uk and research.london.topbanana.co.uk if it chooses.

Adding the hosts

Once the domain name structure has been established, hosts (computers) can be organised into this structure. For example, all hosts could be placed directly into the root of that company’s domain or into the hierarchical subdomain structure as required. In this way we end up with an FQDN, or Fully Qualified Domain Name. An FQDN defines the name of a host and the domain in which it resides, thus making it unique throughout the entire Internet. FQDNs take the format of hostname.subdomain.domain. For example, our fictitious company might have a host called print12. Its FQDN might look like print12.topbanana.co.uk, or possibly print12.london.topbanana.co.uk. It would be entirely up to the IT department whether they want to logically place the host in a subdomain or the root. In this case as the host is a print server it makes a lot of sense to specify whether it is located physically in either the London office or the Edinburgh office to prevent confusion for users trying to choose which printers to attach to. The IT team may well decide therefore to place print12 in the london.topbanana.co.uk domain rather than the root. On the other hand, an application server containing the accounts database that is needed by staff in both London and Edinburgh might be better off being left in the root.

For external (or internal for that matter) users, our company might provide a web server and perhaps an ftp server. The standard for naming these hosts is to place them in the root domain and to give them host names that match the protocol that they are supporting – www.topbanana.co.uk and ftp.topbanana.co.uk. This is not a requirement, but it is a naming convention that Internet users are familiar with and as such makes it easier for those users to find these resources. So now we have a way of organising the Internet into main areas (com, edu, co.uk,), into companies (microsoft.com, whitehouse.gov, lloyds.co.uk) and finally into subdomains (seattle.microsoft.com, finance.lloyds.co.uk). We can then precisely locate any host on the Internet by using its FQDN – a combination of hostname and domain name (www.microsoft.com, print12.topbanana.co.uk). This, however, is only half the battle. Now we have to find a way to hold this information alongside an IP address for each host and to arrange things so that any host connected via the Internet (or intranet) can retrieve that IP address. To do this we need to take a look at DNS Server functionality, as this is the key to how address resolution is achieved.

DNS Server functionality

As previously mentioned, the Domain Name Space is divided into root, top and second level, a second level domain can be further subdivided into root and subdomains. At each level there are DNS servers whose responsibility it is to contain information that allows for a hostname to be resolved into an IP address. Brief mention has also been made of how that information is organised on a DNS server by use of zones. A zone is an area of administrative jurisdiction for name resolution. Each zone will contain all hostnames and IP addresses for hosts in a domain, plus it may contain hostnames and IP addresses for hosts in subdomains of the domain as an option. Alternatively, some or all subdomains may have their hosts’ addressing information managed by a separate zone. Within the zone lies one or more DNS server and each DNS server in that zone will contain a database file (called zonename.dns) which will store the IP address and hostname mappings for hosts in that zone. The use of several DNS servers for one zone is purely for fault tolerance and load balancing, as each server will contain an exact duplicate of the data in its copy of the zone file. A DNS server may in turn contain multiple zones, for example, an ISP may host many different zones on its DNS server as it hosts many companies’ web sites.

Each zone will have a Primary DNS Server. The primary DNS server is the server that contains the read-write version of the zone file. An administrator would go to this server in order to create a new record for a host or to edit or delete existing records. Other servers that also maintain information for this zone can only contain read-only copies of the zone file and they are known as Secondary DNS Servers. A secondary DNS server must obtain updated information from a Master DNS Server. The master DNS server simply refers to a DNS server that supplies a copy of the zone file to another DNS server. This could be the primary DNS server but it doesn’t necessarily have to be. For example, we could have a zone whose file is maintained by four servers – one primary and three secondary. The first secondary will use the primary as its master, but then the other two secondaries could in turn use the first secondary as their master.

Once the zone file has been created, the administrator adds a record for each host in the domain and subdomains that this zone manages. These host records will contain the hostname and the IP address for a host so that the IP address can be looked up and resolved if the hostname is known. There may also be other types of records stored in a zone file. The most common are NS – the IP address of each DNS server that maintains the zone file for this domain, WINS – the IP address of a WINS server that DNS servers are configured to use in order to assist them with name resolution queries and MX – the hostnames and priority orders of servers running SMTP mail services for that domain.

Resolving hostnames

Any host on the Internet can now use the DNS server to look up a hostname and resolve it into an IP address by querying the DNS server. Of course before they can do that, they need to know which DNS server to go to and that is the clever part about the whole DNS system. Each DNS client (known as a resolver) is configured to query a particular DNS server – usually the one that is most local to them, for example, the company’s DNS server within an organisation, or the ISP’s DNS server when dialling up to the Internet from home. This DNS server may be storing data in one or more zone files and the query may be for a host in a domain serviced by one of these zones. In this case, the DNS server can simply look up the relevant record in its zone file and return the appropriate IP address to the resolver. But what happens if that particular DNS server does not contain a zone file that manages the domain that the host (the host that the resolver wants the IP address of) resides in?

Each DNS server is configured with a special zone which contains the Cache File. Do not confuse this with cached information stored in RAM. The cache file contains the IP addresses of the DNS servers in the root (of the Internet usually, but on an intranet it could be the second level domain for that company). If the DNS server cannot resolve the query directly itself through information stored in its zone files, it uses the cache file to obtain the IP address of a DNS server in the root and forwards the resolution query on to that root level DNS server. When the root level DNS server receives the request it too will check to see if it contains the relevant zone file. If not, it will respond with the IP addresses of top level DNS servers that are relevant to the request.

For example, if the request is to resolve www.microsoft.com then the root DNS server would return IP addresses of DNS servers in the com top level domain, which are registered as records in the DNS servers at the root. The original DNS server now queries a top level DNS server. Again, this DNS server will search to see if it contains a relevant zone file. If not, it simply returns the IP addresses of the DNS servers that are registered for the relevant second level domain. In our example, the com DNS servers would return IP addresses for DNS servers of microsoft.com. Now of course the original DNS server can query a second level DNS server that will contain the correct zone file. This DNS server will return the correct IP address to the original DNS server, which will in turn pass it back to the resolver. This process is known as iterative querying and is the method used by all DNS servers throughout either the Internet or an intranet to keep in touch with each other and resolve all hostnames whilst only having to maintain a relatively tiny amount of information locally in the zone files.

Cached information

It would of course be a slow and painful wait if we had to go through this entire iterative querying process every time we wanted to look up an IP address, so the final part to the picture is cached information. When a DNS server learns an IP address it caches it in RAM, initially for two minutes and then if it is required again within those two minutes, for up to a further eight minutes. This means that cached information stays in a DNS server for up to ten minutes before it is flushed. If another DNS performs an iterative query that can be resolved by information in the cache, the information is returned along with the remaining time to live for the data. The new DNS server will only keep the information in its cache for this time, rather than the whole ten minutes. The reason for this behaviour is very simple. If every DNS server that learned from another DNS server, that learned from another DNS server, etc., kept the information for a further ten minutes then in fact the data would never get flushed and it wouldn’t be long before cached information got very large and very out-of-date! In this article we have taken an in-depth look at the intricate workings of DNS. We have looked at what it is, what it does and how it works. We have looked at some of the component parts of it, the hierarchical structure, the role of InterNIC and the functions of DNS servers and resolvers. What we haven’t touched upon is how to implement it, but that’s another article.