Sunday, July 03, 2005

Domain Name System

Introduction
The DNS plays a critical role in supporting the Internet infrastructure by providing a distributed and fairly robust mechanism that resolves Internet host names into IP addresses and IP addresses back into host names. The DNS also supports other Internet directory-like lookup capabilities to retrieve information pertaining to DNS Name Servers, Canonical Names, Mail Exchangers, etc.

Overview of the DNS
To connect to a system that supports IP, the host initiating the connection must know in advance the IP address of the remote system. An IP address is a 32-bit number that represents the location of the system on a network. The 32-bit address is separated into four octets and each octet is typically represented by a decimal number. The four decimal numbers are separated from each other by a dot character ("."). Even though four decimal numbers may be easier to remember there is a practical limit as to how many IP addresses a person can remember without the need for some sort of directory assistance. The directory essentially assigns host names to IP addresses.

The Stanford Research Institute’s Network Information Center (SRI-NIC) became the responsible authority for maintaining unique host names for the Internet. The SRI-NIC maintained a single file, called hosts.txt, and sites would continuously update SRI-NIC with their host name to IP address mappings to add to, delete from, or change in the file. The problem was that as the Internet grew rapidly, so did the file causing it to become increasingly difficult to manage. Moreover, the host names needed to be unique throughout the worldwide Internet. With the growing size of the Internet it became more and more impractical to guarantee the uniqueness of a host name. The need for such things paved the way for the creation of a new system called the Domain Name System.

DNS Design Goals

There were some design goals that were set at the time of structuring the Domain Name System.They are as follows:
  • The primary goal is a consistent name space which will be used for referring to resources.
  • The sheer size of the database and frequency of updates suggest that it must be maintained in a distributed manner,with local caching to improve performance.
  • Where there tradeoffs between the cost of acquiring data, the speed of updates, and the accuracy of caches, the source of the data should control the tradeoff.
  • The costs of implementing such a facility dictate that it be generally useful, and not restricted to a single application.
  • The system should be useful across a wide spectrum of host capabilities. Both personal computers and large timeshared hosts should be able to use the system, though perhaps in different ways.
Elements of DNSThe DNS has three major components:
  • The Domain Name Space
  • Name Servers
  • Resolvers
The Domain Name Space
The DNS is a hierarchical tree structure whose root node is known as the root domain. A label in a DNS name directly corresponds with a node in the DNS tree structure. A label is an alphanumeric string that uniquely identifies that node from its brothers. Labels are connected together with a dot notation, ".", and a DNS name containing multiple labels represents its path along the tree to the root. Labels are written from left to right. Only one zero length label is allowed and is reserved for the root of the tree. This is commonly referred to as the root zone. Due to the root label being zero length, all FQDNs end in a dot.

Each node has a label, which is zero to 63 octets in length. Brother nodes may not have the same label, although the same label can be used for nodes which are not brothers.The domain name of a node is the list of the labels on the path from the node to the root of the tree.By convention, domain names can be stored with arbitrary case, but domain name comparisons for all present domain functions are done in a
case-insensitive manner.

When a user needs to type a domain name, the length of each label is omitted and the labels are separated by dots (".").Since a complete domain name ends with the root label, this leads to a printed form which
ends in a dot. We use this property to distinguish between:
  • a character string which represents a complete domain name (often called "absolute"). For example, "poneria.ISI.EDU."
  • a character string that represents the starting labels of a domain name which is incomplete, and should be completed by local software using knowledge of the local domain (often
    called "relative"). For example, "poneria" used in the ISI.EDU domain.
Example Name Space
The following figure shows a Domain Name Space.


Resource Records
A domain name identifies a node. Each node has a set of resource information, which may be empty. The set of resource information associated with a particular name is composed of separate resource
records (RRs).A DNS RR has 6 fields:
  • NAME
  • TYPE
  • CLASS
  • TTL
  • RD Length
  • RDATA.
The NAME field holds the DNS name, also referred to as the owner name, to which the RR belongs. The TYPE field is the TYPE of RR. This field is necessary because it is not uncommon for a DNS name to have more than one type of RR.The common RR types are listed in the following table.

RECORD TYPE

DESCRIPTION

USAGE

A

An address record

Maps FQDN into an IP address

PTR

A pointer record

Maps an IP address into FQDN

NS

A name server record

Denotes a name server for a zone

SOA

A Start of Authority record

Specifies many attributes concerning the zone, such as the name of the domain (forward or inverse), administrative contact, the serial number of the zone, refresh interval, retry interval, etc.

CNAME

A canonical name record

Defines an alias name and maps it to the absolute (canonical) name

MX

A Mail Exchanger record

Used to redirect email for a given domain or host to another host


The owner name is often implicit, rather than forming an integral part of the RR. For example, many name servers internally form tree or hash structures for the name space, and chain RRs off nodes. The remaining RR parts are the fixed header (type, class, TTL) which is consistent for all RRs, and a variable part (RDATA) that fits the needs of the resource being described.The meaning of the TTL field is a time limit on how long an RR can be kept in a cache. This limit does not apply to authoritative data in
zones.

Queries
Queries are messages which may be sent to a name server to provoke a response. In the Internet, queries are carried in UDP datagrams or over TCP connections. The response by the name server either answers the question posed in the query, refers the requester to another set of name servers, or signals some error condition.In general, the user does not generate queries directly, but instead makes a request to a resolver which in turn sends one or more queries to name servers and deals with the error conditions and referrals that may result.DNS queries and responses are carried in a standard message format. The message format has a header containing a number of fixed fields which are always present, and four sections which carry query parameters and RRs.
The most important field in the header is a four bit field called an opcode which separates different queries. Of the possible 16 values,one (standard query) is part of the official protocol, two (inverse
query and status query) are options, one (completion) is obsolete, and the rest are unassigned.

The four sections are:

Question Carries the query name and other query parameters.

Answer Carries RRs which directly answer the query.

Authority Carries RRs which describe other authoritative servers.
May optionally carry the SOA RR for the authoritative
data in the answer section.

Additional Carries RRs which may be helpful in using the RRs in the
other sections.

Standard Queries
A standard query specifies a target domain name (QNAME), query type (QTYPE), and query class (QCLASS) and asks for RRs which match. This type of query makes up such a vast majority of DNS queries that we use the term "query" to mean standard query unless otherwise specified. TheQTYPE and QCLASS fields are each 16 bits long, and are a superset of defined types and classes.

The QTYPE field may contain:

matches just that type. (e.g., A, PTR).

AXFR special zone transfer QTYPE.

MAILB matches all mail box related RRs (e.g. MB and MG).

* matches all RR types.

The QCLASS field may contain:

matches just that class (e.g., IN, CH).

* matches aLL RR classes.

Name Servers
Name servers are the repositories of information that make up the domain database. The database is divided up into sections called zones, which are distributed among the name servers. While name servers can have several optional functions and sources of data, the essential task of a name server is to answer queries using data in its zones.By design,name servers can answer queries in a simple manner; the response can always be generated using only local data, and either contains the answer to the question or a referral to other name servers "closer" to the desired information.A given zone will be available from several name servers to insure its availability in spite of host or communication link failure.
A given name server will typically support one or more zones, but this gives it authoritative information about only a small section of the domain tree. It may also have some cached non-authoritative data about
other parts of the tree. The name server marks its responses to queries so that the requester can tell whether the response comes from authoritative data or not.

Example:
Dig(Domain Information Groper) is a tool for interrogating with the DNS Server.It performs DNS lookups and displays the answers that are returned from the name server(s) that were queried.

Syntax:
dig @server name type
where:
Server
is the name or IP address of the name server to query. This can be an IPv4 address in dotted-decimal notation or an IPv6 address in colon-delimited notation.

Working of Dig
When the supplied server argument is a hostname, dig resolves that name before querying that name server. If no server argument is provided,dig consults /etc/resolv.conf and queries the name server listed there.

Working Snapshot of Dig

[balaji@localhost ~]$ dig kernel.org

; <<>> DiG 9.3.1 <<>> kernel.org
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4738
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 4

;; QUESTION SECTION:
;kernel.org. IN A

;; ANSWER SECTION:
kernel.org. 600 IN A 204.152.191.5
kernel.org. 600 IN A 204.152.191.37

;; AUTHORITY SECTION:
kernel.org. 2779 IN NS ns2.kernel.org.
kernel.org. 2779 IN NS ns3.kernel.org.
kernel.org. 2779 IN NS ns.vger.kernel.org.
kernel.org. 2779 IN NS ns1.q.port80.se.
kernel.org. 2779 IN NS ns1.kernel.org.
kernel.org. 2779 IN NS ns2.gimp.org.

;; ADDITIONAL SECTION:
ns1.q.port80.se. 520573 IN A 217.75.109.220
ns1.kernel.org. 2166 IN A 209.128.68.125
ns2.kernel.org. 2166 IN A 204.152.191.4
ns3.kernel.org. 2166 IN A 204.152.191.36

;; Query time: 319 msec
;; SERVER: 218.248.255.145#53(218.248.255.145)
;; WHEN: Sun Jul 17 16:30:10 2005
;; MSG SIZE rcvd: 252