The Domain Name System (DNS) is the method by which Internet addresses in
mnemonic form such as sunc.scit.wlv.ac.uk. are converted into the
equivalent numeric IP address such as 134.220.4.1. To the user and
application process this translation is a service provided either by the local
host or from a remote host via the Internet. The DNS server (or resolver)
may communicate with other Internet DNS servers if it cannot translate the
address itself. These notes will discuss
DNS names are constructed hierarchichally. The highest level of the hierarchy being the last component or label of the DNS address. Labels can be up to 63 characters long and are case insensitive. A maximum length of 255 characters is allowed. Labels must start with a letter and can only consist of letters, digits and hyphens. [Unfortunately some administrators construct names that start with digits. This is wrong and can easily cause problems with software that simply inspects the first character of a host address to determine whether a DNS name or an IP address has been quoted.]
Note In the early days of the Internet users in at least one country
(the United Kingdom) adopted a similar scheme with the highest hierarchical
level appearing first rather than last. I.e. uk.ac.wlv.scit.sun
rather than sunc.scit.wlv.ac.uk. This practice is, fortunately,
obsolete.
DNS addresses can be relative or fully qualified. A fully qualified address
includes all the labels and is globally unique. A relative address can be
converted by appending the local domain information. For example
sunc.scit.wlv.ac.uk is a fully qualified name for the host
sunc in the domain scit.wlv.ac.uk. Strictly there
should be a stop at the end of a fully qualified name but this is often
overlooked.
The final most significant label of a fully qualified name can fall into one of three classes
This is a special facility used for reverse translation, i.e. going from IP
address to fully qualified domain address. If everything is properly
configured a suitably framed query for 1.4.220.134.in-addr.arpa
will return sunc.scit.wlv.ac.uk. Details of this will be described
later.
The DNS was orginally introduced in the United States of America and the final component of an address was intended to indicate the type of organisation hosting the computer. Some of the three letter final labels (edu, gov, mil) are still only used by organisations based in the USA, others can be used anywhere in the world.
The three letter codes are
| code | meaning |
|---|---|
| com | Commercial. Now international. |
| edu | Educational. |
| gov | Government. |
| int | International Organisiation. |
| mil | Military. |
| net | Network related. |
| org | Miscellaneous Organisation. |
The final two letter codes indicate the country of origin and are defined
in ISO
3166 with the minor exception that uk is used for the United
Kingdom rather than gb although there are some .gb
sites. [This apparently happened because the ISO committee was unaware that
Northern Ireland was part of the United Kingdom but not part of Great
Britain.]
The two letter code us is used by some sites in the United
States of America.
In some countries there are sub-domains indicating the type of organisation
such as ac.uk, co.uk, sch.uk in the
United Kingdom and edu.au and com.au in Australia.
Most European countries have not adopted this useful practice. A fuller
discussion of the United Kingdom DNS domains is provided by the UK Network Information Centre.
To obtain a domain address it is necessary to identify the administrator of
the required domain and then all that is basically necessary is to send the
administrator the required code and the associated IP address and they will, if
they accept the request, include the details in their databases. Conditions for
acceptance vary widely between administrators, the administrators for the
com and org being, apparently, quite happy to accept
anything from anywhere.
For any group of computers partaking of the DNS naming scheme there is likely to be a single definitive list of DNS names and associated IP addresses. The group of computers included in this list is called a zone. A zone could be a top level national domain or a university department. Within a zone DNS service for subsidiary zones may be delegated along with a subsidiary domain. The computer that maintains the master list for a zone is said to have authority for that zone and will be the primary name server for that zone, there will also be secondaries for that zone.
When any process needs to determine an IP address given a DNS address it calls upon the local host to resolve the address. This can be done in a variety of ways
/etc/hosts
named
on a Unix system. named initially obtains information from
/etc/hosts but also maintains a cache of recent requests.
/etc/resolv.conf.
If a named process cannot resolve an address locally it will
call upon higher authority. Ultimately it will attempt to contact the system
that is authoritative for the zone in question, however, unless the information
is cached or in the hosts local files then it will not know the address of the
authoritative server. This problem is resolved by recursive resolution of
requests, i.e. any DNS server will pass requests it cannot handle to a higher
level server and so on until either the request can be handled (either by
sending a message to the identified authoritative host) or until the root of the
DNS name space is reached.
There are eight servers that can serve requests at the root of the DNS name
space, all servers should know their IP addresses so that DNS service can be
offered even if there are no cached addresses and no local servers indicated by
the /etc/resolv.conf file. The root servers will know the IP
addresses of the servers for all the national DNS zones and the three letter
zones.
The message formats used for exchange of queries and responses between hosts and DNS servers is specified in RFC 1035. Queries and responses can be transferred either via TCP or via UDP. There are "well-known" port numbers for DNS service using either protocol.
The format of a DNS query and response is
| Bits 0-15 | Bits 16-31 |
|---|---|
| Identification | flags |
| number of questions | number of answer RRs |
| number of authority RRs | number of additional RRs |
| questions | |
| answers (RRs) | |
| authority (RRs) | |
| additional information | |
RRs are Resource Records
The 16 flag bits provide further information about the query
A single indicating a query (0) or a response (1)
4 bits whose value means
| Value | Meaning |
|---|---|
| 0 | Standard Query |
| 1 | Inverse Query |
| 2 | Server status request |
If set, this means that the server is authoritative for the domain in question.
If set this means that the reply size exceeded 512 bytes and only the first 512 bytes were actually returned. This will only be used if the response is being returend via UDP.
If this bit is not set then recursion is denied. This means that if the responding server cannot resolve the query itself rather than passing it on to "higher authority" and returning the result it eventually receives, it will simply return a list of other servers to try.
If this bit is set by a responding server then that server is indicating that it can handle queries recusively.
These must be zero.
This indicates the status
| Value | Meaning |
|---|---|
| 0 | No error |
| 1 | Malformed Query |
| 2 | Server Failed |
| 3 | Name Does not Exist |
| 4 | Query type unsupported by server |
| 5 | Server refused to answer |
After the 12 byte header the DNS query message consists of a block of questions which in turn consist of query name, query type and query class.
Typically the query name is the name of site, each component of the name is sent a sequence of characters preceded by a byte holding the binary count of the number of characters in the component. The name is terminated by a zero byte.
The query type indicates the type of information required encoded in a 16 bit field. Common values are
| Name | Value | Description |
|---|---|---|
| A | 1 | IPv4 Address (32 bits) |
| NS | 2 | Name Server |
| CNAME | 5 | Canonical Name |
| PTR | 12 | Pointer Record |
| HINFO | 13 | Host Information |
| MX | 15 | Mail Exchange Record |
| TXT | 16 | Text String |
| AAAA | 28 | IPv6 Address (128 bits) |
| AXFR | 252 | Request for Zone Transfer |
| ANY | 255 | Request for All Records |
Query class is usually 1 meaning an Internet domain query, other values could be used for different addressing domains.
Response Records known as RRs form the body of the reply to a DNS query. They are used for the answers, authority and additional information fields.
The form is
| Bits 0-15 | Bits 16-31 |
|---|---|
| Domain Name | |
| type | class |
| Time to live | |
| Resource Data length | Resource Data |
| Resource data (continued) | |
The domain name is the query name from the query. The type is the query type. The class is 1 for the Internet domain. The time to live is the time for which the information can be cached by the client, typically two days, expressed in seconds. The resource data length specifies the number of bytes of resource data.
It is important to note that queries can be made for information relating to both individual hosts and for zones/domains. Most of the query types are fairly obvious. The MX query is used specifically for mail handling and can return information about hosts not directly or regularly connected to the Internet. The result of an MX query for such a host is the address of an Internet host that will receive mail for such a host and make its own arrangements for forwarding the mail via non-Internet means or when the host does connect. An MX query response for a domain provides the address of the host that will handle mail for that domain allowing email addresses of the form User@domain_name. The NS query can be used to identify the name servers for a particular domain.
On Unix systems the normal user interface is the program /usr/sbin/nslookup.
[The actual path may be different on some hosts]. This can be used to
perform almost any DNS function and display the results to the user.
Here is an example of its use on scitsc.wlv.ac.uk. Note. This
example was prepared before the scit.wlv.ac.uk zone was delegated,
scitsc is now known as sunc although the old name still works.
bash$ /usr/etc/nslookup Default Server: scitsc.wlv.ac.uk Address: 134.220.4.1 > set q=A > ccub.wlv.ac.uk. Server: scitsc.wlv.ac.uk Address: 134.220.4.1 Name: ccub.wlv.ac.uk Address: 134.220.1.20 > set q=CNAME > www.wlv.ac.uk. Server: scitsc.wlv.ac.uk Address: 134.220.4.1 www.wlv.ac.uk canonical name = ccuf.wlv.ac.uk > set q=MX > wlv.ac.uk. Server: scitsc.wlv.ac.uk Address: 134.220.4.1 wlv.ac.uk preference = 1, mail exchanger = wlv.ac.uk wlv.ac.uk inet address = 134.220.1.12 > set q=HINFO > ccub.wlv.ac.uk. Server: scitsc.wlv.ac.uk Address: 134.220.4.1 ccub.wlv.ac.uk CPU=SUN 690MP OS=Solaris 2.4 > set q=PTR > 12.1.220.134.in-addr.arpa Server: scitsc.wlv.ac.uk Address: 134.220.4.1 12.1.220.134.in-addr.arpa host name = ccug.wlv.ac.uk
Here it shows that sunc was providing DNS service. A number of queries
were made. The query type was specified using nslookup's set
q= command.
A simple query for the IP address corresponding to
ccub.wlv.ac.uk.
A given host can have several DNS names. One of these is the canonical or
reference name. This query reveals that www.wlv.ac.uk is really
ccuf.wlv.ac.uk.
A mail exchanger query, this time for the domain wlv.ac.uk
which reveals that mail sent to user@wlv.ac.uk is actually sent
to 134.220.1.12 which is really ccug.wlv.ac.uk. (see
below).
An HINFO query. This is only useful if the DNS domain administrator has bothered to create the relevant records and keep them up to date.
A PTR query. This shows "inverse" or "reverse" resolution. Notice the very clumsy way the query has to be entered, this is partly because IP addresses have the most sigificant part first whereas DNS addresses have the most significant part last. There are plenty of pieces of software that do reverse resolution without this clumsy interface.
The commonest program interface to DNS uses the library functions
gethostbyname() and gethostbyaddr(). These are
discussed in more detail elsewhere.
The nslookup program can be used to obtain a listing of all the
hosts in a zone. To do this it is first necessary to identify the name server
for the zone. This is done using an NS query, setting the server
parameter to one or other of the identified name servers and then using
nslookup's ls command. Note that in this example the
user was careful to include the final dot on the domain name, this prevented
nslookup from trying to append the local default domain name
(scit.wlv.ac.uk.) to the required domain name. For large domains
the ls command has an option to write its results to a file.
bash$ /usr/sbin/nslookup Default Server: sunc.scit.wlv.ac.uk Address: 134.220.4.1 > set q=NS > bilston.ac.uk. Server: sunc.scit.wlv.ac.uk Address: 134.220.4.1 Non-authoritative answer: bilston.ac.uk nameserver = unad1.wlv.ac.uk bilston.ac.uk nameserver = ccua.wlv.ac.uk bilston.ac.uk nameserver = ccub.wlv.ac.uk Authoritative answers can be found from: unad1.wlv.ac.uk internet address = 134.220.192.26 ccua.wlv.ac.uk internet address = 134.220.1.39 ccub.wlv.ac.uk internet address = 134.220.1.20 > server ccub.wlv.ac.uk Default Server: ccub.wlv.ac.uk Address: 134.220.1.20 > ls bilston.ac.uk. [ccub.wlv.ac.uk] bilston.ac.uk. server = ccub.wlv.ac.uk bilston.ac.uk. server = unad1.wlv.ac.uk bilston.ac.uk. server = ccua.wlv.ac.uk gw 194.62.148.1 novix1 195.188.205.2 www 194.62.148.4 fc 194.62.148.5 student1 195.18.205.3
The session above was logged in March 1998. It reveals 5 hosts in the
bilston.ac.uk domain. Surprisingly three different class C IP
network addresses appear in the output. This was because the organisation was in
the process of changing its Internet Service Provider accounting for two of the
network addresses, the third (195.18.205) is, apparently, a typographical error
for 195.188.205.
Furthre information on identifying the ownership of an IP network and, implicitly, a DNS domain can be found in the notes on IP routing.
With the rapid commercialisation of the Internet in the late 1990's disputes over DNS names arose from time to time and suggestions have been made for the creation of extra top level domains. The root of the current DNS hierarchy is maintained by the Network Information Center on a contract from the government of the United States of America. There have been several attempts to set up alternative hierarchies. The most succesful (at the time of writing - April 1998) is probably Alternic.
To use the Alternic DNS service you need to know the address of their root
servers, one of these is mx.alternic.net. Here's an example showing
that it does work for DNS resolution of www.alternic.nic.
bash$ /usr/sbin/nslookup Default Server: sunc.scit.wlv.ac.uk Address: 134.220.4.1 > server mx.alternic.net Default Server: mx.alternic.net Address: 206.191.128.47 > www.alternic.nic. Server: mx.alternic.net Address: 206.191.128.47 Name: www.alternic.nic Address: 206.191.128.47
Alternic uses three letter top level domains for countries (such as
jpn and ger) and has a large number of commercially
oriented top level domains. At the time of writing the only domains with
significant populations are porno and xxx.
A normal name server can only resolve Alternic addresses if they're already in its cache. Most DNS implementations with a list of root servers consult them in random order or consistently consult the first one in the list. Including one of the Alternic servers in amongst the list of root servers will not provide consistent resolution of addresses in both hierarchies.
[Note: this particular aberration seems to have fizzled out (May 1999)]
It is tempting to think that an Internet host with a name ending in ".uk" is actually located in the United Kingdom. There is no requirement that this should be so. For example the well known host www.yahoo.co.uk is actually located in southern Germany. In the case of the United Kingdom it is simply necessary to present the organisation that runs the ".co.uk" domain with an IP address (and a suitable sum of money !) and the DNS address will be registered. The top-level administration of the ".uk" domain will only delegate to specifically UK based organisations.
Some administrations are distinctly less fussy and a number of "zones of convenience" along the same lines as "flags of convenience" have come into fairly common usage. These are mostly poor third world countries or tiny groups of islands desperate for some hard cash, they also tend to sell un-necessary sets of stamps and coins to guillible collectors.
The most common ones seem to be ".cc" (the Cocos-Keeling Islands), ".to" (Tonga) and ".nu" (Niue). At one time both ".is" (Iceland) and ".tm" (Turkmenistan) allowed their top level domains to be used in this fashion, but they now seem to adopt a more rational approach.
Some of the blame must attach to Internic who have created some pretty unlikely top-level domains. It is difficult to imagine anybody using ".bv", the allocated top-level domain for Bouvet Island, an uninhabited (an uninhabitable !) Norwegian Dependency about half-way between South Africa and Antarctica whose only claim to fame is that it is the most isolated piece of land in the world.