Domain Name System (DNS)
This is a directory service that is a distributed database of labels forming a Name Space
across the Internet in a hierarchical structure. Domain names are resolved to IP addresses.
If you take the domain name www.cisco.com, and ping it from your workstation you might get the
Reply from 22.214.171.124. A DNS server has 'resolved' the name www.cisco.com' to the IP address 126.96.36.199,
either by a direct query on an authoritative server, or more likely from a local DNS server that has
cached this popular name already. DNS is also used for distributing mail routing information.
Structure of the DNS Directory
The DNS database namespace (directory) is split into Zones and Sub-zones. A zone is a point of delegation
within the DNS tree so that a name server is authoritative for the domains that are grouped within the
zone and any sub-zones below it.
A Zone MUST be known by at least two Name Servers. A Primary name server is where the zone's domain names
and host Resource Records are loaded manually into the configuration database.
The secondary name servers populate their databases from the primary. Both the Primary and Secondary name servers
can be Authoritative for the domains. This is because both types learn about their hosts
from an internally configured database rather than a cached result from a previous query.
A Caching Name Server is not authoritative for any zones or domains it merely learns the name
resolutions by recursively querying auhoritative name servers. All name servers cache, caching
is not limited to the Caching name server.
A server that is Authoritative, answers DNS queries regarding their particular Zones
and they are not reliant upon lower level name servers for the answer to a request.
Name servers that query the Authoritative servers, cache the responses so that DNS traffic is kept to a minimum.
The big DNS servers at the top of the DNS tree are authoritative for many thousands of Zones.
All zones are expressed in the form of Resource Records (RR). These records can be transferred incrementally
between Name Servers, or the whole zone can transferred as a large text file. This is known as Zone Transfer.
The DNS Tree
The structure of the domain name is important. The Root is located at the top and is represented
by a . dot or " " quotes.
The .com refers to the Top Level Domain (TLD) assigned by
InterNIC. There have been traditionally seven top level domains .org
(non-profit organisations), .net (ISPs), .edu (education), .gov (government), .com
(company), .arpa (ARPA) and .mil (military). These were set up in the 1980s and
originally applied to the US, however worldwide organisations use these TLDs now. In 2003 these were
increased to 14 Top Level Domains.
The additional TLDs are .aero, .biz, .coop, .info, .museum, .name and .pro
As well as these generic TLDs (gTLD)
there are county-code Top Level Domains (ccTLD) such as .uk for UK or .de for Germany.
The curent list of gTLDs can be found at this link
and a list of all the ccTLDs can be found at this link
The DNS Name Space tree has the following tree-like structure:
The Top Level Domains are closest to the Root and are the least specific. The node Labels
used can be up to 63 octets in length each, although all the labels in total must not exceed 255 octets.
The Fully Qualified Domain Name (FQDN) is a list of these labels with the labels nearest the root listed
on the right of the full name. The Root has the reserved 'Zero Length' label.
The Root Zero Length label is represented by a '.', however in practice this is often omitted from the far right of the domain name.
The labels are case-sensitive and you cannot have
the same label name as another branch at the same level (brothers), although you can use the same label on a different branch of the tree.
A Sub-Domain is where a domain's name ends in another domain's name and is therefore part
of that larger domain. For instance, 'rhyshaden.com' is a second level domain of 'com'. if you see 'www'
or 'ftp' then you are looking at a third level domain which could be a hostname or service, in that domain e.g.
'www.rhyshaden.com' is a host device providing a web service in the domain 'rhyshaden.com'. As well as Sub-Domains
you can delegate responsibility for Zones within a domain and a zone could have the same
name as the domain e.g. the zones 'first.rhyshaden.com', 'second.rhyshaden.com' and 'rhyshaden.com'
each look after a subset of nodes belonging to the domain 'rhyshaden.com'.
There have been requirements to set up domains for testing purposes or for internal use therefore a number of reserved
TLDs have been created. These are as follows:
- .test - is recommended for use in testing of current or new DNS related code.
- .example - is recommended for use in documentation or as examples.
- .invalid - is intended for use in online construction of domain names that are sure to be invalid and
which it is obvious at a glance are invalid.
- .localhost - This TLD has been statically defined in host DNS implementations as having an
'A' record pointing to the loopback IP address (127.0.0.1) and is reserved for this purpose. Any other use
would conflict with widely deployed code which assumes this use.
To complete the picture the second level domain names example.com, example.net and example.org
have been reserved also for use in examples.
Root Name Servers
Root Name Servers
sit at the top of the directory tree and contain pointers to Master Name Servers
There are currently 13 Root Servers and they were originally managed by the Internet Corporation for Assigned Names
and Numbers (ICANN) http://www.internic.net
These master name servers look after the top level domains .com
etc. plus the country domains. They contain the addresses
of the Domain Name Servers
for their particular top level domain. For instance, the master name server
for www.cisco.com would be looking after the top level domain .com
. In addition, this master name
server would have the address of the domain name server looking after the domain cisco.com
. The Domain Name server
looks after the Hostnames
etc. The hostname and the domain name together form
the Fully Qualified Domain Name (FQDN)
Below is a list of the 13 root name servers and locations:
|New name based on letter
||Dulles, Virginia, U.S.
||Marina Del Rey, California, U.S.
||distributed using anycast
||University of Maryland
||College Park, Maryland, U.S.
||Mountain View, California, U.S.
||distributed using anycast
||Defense Information Systems Agency
||Columbus, Ohio, U.S.
||U.S. Army Research Lab
||Aberdeen Proving Ground, Maryland, U.S.
||distributed using anycast
||distributed using anycast
||distributed using anycast
||distributed using anycast
||distributed using anycast
For Mail boxes the mail address local-host@mail-domain is mapped to a domain name by first taking the local-host name
and converting it into one single label. Then the mail-domain name is mapped directly to the domain name e.g.
email@example.com is mapped to rhaden.rhyshaden.com.
Operation of DNS
The domain name server has specific host addresses that reside in this particular domain. Any host (DNS Client)
can ask this domain name server for the IP address of a device in that domain e.g. the web server with the hostname www, provided that the hosts
have at least one DNS server IP address configured on the TCP/IP stack. If you are managing a DNS server,
the InterNIC will require you to maintain at least 2 DNS servers in case one should fail and 'disconnect'
users from the Internet.
The DNS server runs software such as Berkeley Internet Name Domain (BIND) (on Unix machines
the current version is 9.x) that basically performs
- The first task is that of the Name Server that details the tree-structured Domain Name Space and
carries out the mapping between names and IP addresses (Domain
Name Manager) by way of Resource Records.
- The second task is that of the Resolver, which asks another name server for the answer if the local one cannot
find the mapping asked for by the DNS client. If that name server cannot find the answer it asks another name server further up the tree
until a name server is found that has the answer in its cache or it is an authoritative name server that
looks after this zone and does not need to ask another name server. This can take a number of seconds sometimes,
such that the DNS client application times out. A retry normally resolves this.
Assuming a blank sheet where no names have been cached, the DNS conversation will look something like
- The client sends a DNS query for the IP address of 'www.example.com' to its configured local DNS server.
- If the local name server has the IP address then it sends this back in a reply to the client. If
the name server checks its database and realises that it has not yet resolved this name, so it breaks the
domain name into portions to
see if it knows any of the portions or whether it can forward on the query to a name server that does know
e.g. it starts with 'www.example.com', then 'example.com', then
just '.com' each time forwarding queries onwards i.e. it performs recursive lookups.
- Then the local DNS sends a query to one of the root name servers e.g. a.root-servers.net.
All DNS servers are pre-configured with the root name servers that can be amended over time as the need arises.
- The root name server knows all the '.com' name servers and so sends a Referral to one of them
e.g. b.gtld-servers.net i.e. the root name server tells the local name server to try the .com server.
- The local name server repeats the request but directs it at the '.com' server.
- The '.com' server searches its database and finds that it knows an authoritative domain name server
for the domain example.com e.g. 'authority.example.com'. This server tells the local DNS to try 'authority.example.com'.
- The local name server repeats the request again but directs it at the 'authority.example.com' server.
- The authoritative name server has an entry for 'www.example.com' in its database and therefore
sends a DNS response with the IP address of 'www.example.com' back to the originating local name server.
The Response will have the Authoritative Bit set.
- The local DNS then forwards this response to the client that originated the query in the first place
and also caches the IP address for future requests. The length of time that the answer remains cached is dependent
on the Time to Live (TTL) which is set on a server-by server basis.
A request to find out which IP address is associated with a particular hostname is a Forward DNS Lookup and
is sometimes called an 'A' Record Lookup, as this
type of record is called an 'A' Record (see later). You can have more than one 'A' record for one hostname and the resolver
will randomly pick one in its response thereby giving a bit of crude load-balancing. A request to find which name is
associated with a particular IP address is a Reverse DNS Lookup. The Pointer (PTR) record is used to aid this.
There are also other records stored within the DNS database.
One way to ease pressure on local DNSs is to designate a name server as a Forwarder. The Forwarder is used
to resolve external domain names that the internal name servers do not have in their databases. The internal name servers
are configured with the IP address of the Forwarder(s) and send queries to it when they need to. The internal name
servers wait a short while for a response before querying the root name servers held in their root hints list.
You can configure the internal name servers to send certain domain queries to the Forwarder thereby making the Forwarder
a Conditional Forwarder. The Forwarder builds a cache of external names and over time this eases the
pressure on WAN usage.
The DNS Protocol
DNS uses IP port number 53 and can either use UDP or TCP for transport. Generally, UDP (limited to 512 bytes) is used for queries and responses
i.e. Lookups but, TCP (virtual circuit) has to be used for Zone Transfers as the data shared between authoritative
servers handling particular zones needs to be reliable.
The DNS packet format is as follows:
- ID - The Identifier is created by the program to represent the query. Replies use this identifier
so that requests and replies can be matched.
- QR - This bit is 0 for a query, or 1 for a response.
- OPcode - This has a value of 0 for a standard query, 1 for an inverse query and
2 for a status request.
- AA - if a response has this bit set to 1, then the response comes from an Authoritative server.
- TC - Truncated means that the message was longer than the bandwidth would allow.
- RD - Recursive Desired means that the query wants the server to pursue the request recursively.
- RA - The response has this bit set to 1 if recursive querying is available on the server.
- Z - This is unused and is zero for all queries and responses.
- Rcode - The Response Code has the following values:
- 0 - No error
- 1 - Format error, the server did not understand the query
- 2 - Server failure, either the server is not functioning correctly or has failed to obtain a
response after forwarding on the request.
- 3 - Name error, only the authoritative server would set this value
- 4 - Not implemented, the server does not carry out this function
- 5 - Refused
- QDcount - The number of queries in the question part of the packet
- ANcount - The number of Resource Records in the answer part
- NScount - The number of Name Server resource records in the Authority Records part
- ARcount - The number of resource records in the Additional Records part
Resource Record (RR)
- Qname - The target domain-name is presented as a sequence of labels, each label consisting of a length
octet followed by that number of octets. The domain name ends with the zero length octet for the null
label of the root as described earlier. This DNS server looks for RRs that match the specified Qtype and Qclass.
If it does not have a match, this server can point to a DNS server that may have a match instead.
- Qtype - Specifies the type of query e.g. A, PTR, AXFR, MAILB etc.
- Qclass - Specifies the class of query, e.g. IN for Internet, CH for Chaos.
- Name - or 'Owner', the Domain name where the resource resides
- Type - A type code indicating the type of data in Rdata, this is a 16 bit field that defines the type of RR:
- A - Host address i.e. an 'A' record, or 'Answer' record. This is a successful resolution response.
- CNAME - Canonical name of the Alias. This is used if you want to do a hostname to hostname association
rather than a hostname to IP address association. This is useful if you have a number of hostnames associated with one IP address
i.e. one computer has a number of names associated with it such as www.example.com and ftp.example.com.
- HINFO - CPU type and OS used by the host
- MX - Domain Mail Exchange
- NS - Authoritative Name Server for the Domain, used in DNS Referrals.
- PTR - a pointer to another part of the Domain space by host name, used with inarpa.addr
when performing reverse DNS lookups.
- SOA - Start of a Zone of Authority
- Class - The class of data in Rdata, this is a 16 bit field identifying a protocol family, IN for Internet and CH for Chaos system
- TTL - Identifies in seconds, how long the Resource Record (RR) should be kept in the DNS cache of non-authoritative servers.
The lower this value, the greater the bandwidth used for zone information. Normally a few hours is short enough.
- RDlength - Length of Rdata in octets
- Rdata - Variable length description of the resource which contains the data for whatever Type (see above) the RR contains i.e.
- A - for IN, a 32 bit IP address, for CH, a 16 bit octal address
- CNAME - a domain name alias
- MX - a 16 bit preference value and host address of a Mail Exchange; the lower the number, the more preferred the Exchange is.
This MX record handles mail requests from the Mail server. You can have a number of MX records, hence the preference value. If a mail
server sends a request and no MX record exists, then the resolver performs an A record lookup and a connection to that IP address
is made on port 25 (SMTP) anyway.
- NS - Authoritative Name Server for the Domain
- PTR - a pointer to another part of the Domain space, this is a domain name or host name
- SOA - Start of a Zone of Authority information
- Pointer - For compression purposes, a pointer is used to point to multiple occurrences of a domain
name within the data. The pointer occurs at the end of the list of labels. Labels are identified by
00 whilst a pointer is identified by 11 followed by an offset value.
When using UDP for transport the message can not be longer than 512 bytes, so longer messages are truncated. The application
should take care of retransmissions since UDP does not do this itself.
When using TCP for the transport of DNS packets, the message begins with a two-octet length field which details the length
of the message to ready the application software for parsing of the message.
Reverse DNS Lookups (Inverse queries where you perform a lookup for the hostname belonging to an IP address)
are optional elements of a DNS server, however if a DNS server is unable to
process inverse queries it still must be able to return an error message. A Standard Query matches
a domain name to an SOA RR, whereas an Inverse Query matches an SOA RR to a domain name.
In order to do this you need to search the entire namespace. In order to help with this there is
a special domain namespace that uses addresses as names. This domain is called in-addr.arpa
and sits in a Reverse Zone. This Reverse Zone contains subdomains based on the IP address.
Because the domains are written in a 'leaf-to-root' order, to maintain consistency in naming, the
IP address names are also written in reverse e.g. the IP address 188.8.131.52 would have its
name in the reverse zone written as 184.108.40.206.
When making a reverse lookup, the resolver performs a PTR (Pointer)
lookup for a specific hostname within the in-addr.arpa domain. If you are in the network 192.168.4.0/24, then
requests for names for IP addresses in the subnet 192.168.4.0/24 will examine
PTR records within the domain 4.168.192.in-addr.arpa, only the octets defined by the mask determine the IP name.
On Unix boxes the command dig can be used to find out zone record information for a FQDN, e.g. dig www.rhyshaden.com a
returns the A record for www.rhyshaden.com.
Traditional DNS management required manual editing of text files called Zone files
that form the configuration database. This was prone to errors.
Nowadays, the Domain Name manager creates the zone files automatically checking for syntax and duplicate IP addresses.
Pointer (PTR) records are also automatically generated to provide the ability for Reverse DNS Lookup i.e. looking up
a name from an IP address query.
If you are hosting a zone i.e. setting up an Authoritative name server, then you need to register the domain with the
Registrar. Then you need to create a Zone file that contains all the DNS records for your zone. This zone file
begins with the Start of Authority (SOA) section which stores the zone information.
Authoritative Name Servers are responsible for maintaining their zone information. When changes occur, as new nodes
are added or taken away, these changes must be propagated to all the Name Servers.
In a particular zone, one of the Name Servers is designated as Master or Primary, and this coordinates the changes
by editing a Master file. The other secondary name servers can be set to periodically check for changes in the zone by
looking at the SERIAL field of the SOA, which increments when new zone versions are created.
Periodic polling of the secondary name servers can be set in the SOA RR by setting parameters. These parameters include REFRESH,
RETRY, and EXPIRE. When a new zone is loaded in a secondary, the secondary
waits REFRESH seconds before checking with the primary for a new serial number.
If this check cannot be completed, new checks are started every RETRY
seconds. The check is a simple query to the primary for the SOA RR of the zone.
After the secondary name server has polled and detected a zone change, it sends a AXFR, which is a request for a Zone Transfer.
The primary name server responds with a stream of RRs listing the names servers, authoritative or otherwise.
The first and last RR contain data for the top authoritative node of the zone. The Zone Transfer
uses TCP for transport of this data since this data is critical for proper functioning of DNS.
Rather than send RRs, the primary name server can send the Master file as a text file.
Start of Authority (SOA)
In Unix, the SOA looks something like the following example:
@ IN SOA ns hostmaster (
- @ - hostname of the master name server, this gets swapped with the domain name (e.g. rhyshaden.com)
when BIND loads the zone file.
- ns - name server, this is the name of the name server holding the zone information (authoritative Master server)
and is automatically completed and advertised as a FQDN e.g. ns.rhyshaden.com. The Slave servers query the master server i.e.
this name, for the zone. The master server does not need to query anyone for the zone.
- hostmaster - this is the e-mail address for the individual that controls the zone e.g. firstname.lastname@example.org.
Rather than just enter 'hostmaster' here, you could enter a FQDN in order to use an e-mail address outside of the e.g.
for 'email@example.com' you would use 'rhyshaden.somecompany.co.uk'.
- 2001112301 - is a serial number indicating to the slaves the version number of the zone information. The format is
yyyymmddxx i.e. in date form with the last two digits being the version for that day. The slave servers check the SOA
first when looking to update the zone information, if this number is newer than their copy, they will download the new
zone file information.
- 4H - 4 hours has been set for the Refresh time which is the length of time the zone is stored in the slave
servers before they check the master for an updated copy.
- 1H - 1 hour has been set for the Retry time. When a slave first comes on line it immediately tries to
download a copy of the zone from the master. If this fails, then the slave will retry every so often according to this retry time.
- 5D - 5 days has been set for the Expire time. If the master becomes unavailable for a period of
time, the slave servers will keep the zone alive for this period.
- 24H - 24 hours has been set as the Minimum time that the zones can live on in the slave servers.
Other record examples
After the SOA comes the A, NS and MX values for the particular zone for instance for the
IN NS ns
IN A 10.1.1.1
IN MX 10 mail
where 'ns' is the name of the authoritative name server for the zone.
and then there follows all the A and MX records e.g.
ns A 10.2.2.2
www CNAME @
Here ns is mapped to IP address 10.2.2.2 and the FQDN 'www.rhyshaden.com' (as the example in our case) has the alias
More detail on DNS can be found at RFC 1034
the concepts and RFC 1035
, which discusses the implementation of DNS.
Another RFC RFC 1591
works through through the domain name
structure and delegation.
The RFC RFC 2606
describes the reserved top level and second level domain names.