DNS FROM DUMMIES

DNS by Javi & Leo

INDEX
1. GENERAL INFORMATION 4
1.1 - Introduction
1.1.1 - The DNS protocol role
1.1.2 - Logical names vs. numerical identifier
1.1.3 - OSI stack & packet shape
1.1.4 - DNS and revDNS
1.1.5 - Official documentation: the RFC's for DNS
Eliminated, directly in documentation chap 4

[note:1034-1035 & more]

1.2 - General structure ...9

1.2.1 - RIPE IP European registry
1.2.2 - Official registries & references
1.2.3 - National registries
1.2.4 - Registrars
1.2.5 - DNS tree, TLD, subTLD
1.2.6 - Hierarchical structure & recursive resolution: how to reach the right IP
1.2.7 - Authoritative servers, zone transfers
1.2.8 - Registrar vs. maintainer: who do what?
1.2.9 - How to read and interpreter fields in a query (example)

2. SERVER SIDE SW ....

2.1 - Bind & Microsoft DNS Server
2.2 - Zone Files; record, entries, fields - TTL
2.3 - RR types: SOA,A,MX,PTR,CNAME,TXT, SPF, NS & others
2.4 - Examples:
- use of A
- use of PTR
- MX record
- use of CNAME
- use of TXT and SPF
- Domain zone for MBE Colt

3. CLIENT SIDE SW 25
3.1 Nslookup
3.1.1 - Flags and their use
3.1.2 - examples
3.2 Dig
3.2.1 - flags & use
3.2.2 - examples (exaustive)
3.3 - Online tools: Ping, lookup, trace, whois, dns records, dig, MX Lookup, SPF check

DNS from Dummies by Javi & Leo

4. DOCUMENTATION
4.1 - Useful books
4.2 - Online & free documentation

[& link to official RFC's]

4.3 - Common terms

DNS from Dummies by Javi & Leo

1. GENERAL INFORMATION
1.1 Introduction
1.1.1 The DNS protocol role

The Domain Name System (DNS) is a hierarchical naming system for computers, services, or
any resource connected to the Internet or a private network. It associates various information
with domain names assigned to each of the participants. Most importantly, it translates
domain names meaningful to humans into the numerical (binary) identifiers associated with
networking equipment for the purpose of locating and addressing these devices worldwide.
An often used analogy to explain the Domain Name System is that it serves as the "phone
book" for the Internet by translating human-friendly computer hostnames into IP addresses.
For example, www.example.com translates to 208.77.188.166.
The Domain Name System makes it possible to assign domain names to groups of Internet
users in a meaningful way, independent of each user's physical location. Because of this,
World-Wide Web (WWW) hyperlinks and Internet contact information can remain consistent
and constant even if the current Internet routing arrangements change or the participant uses
a mobile device. Internet domain names are easier to remember than IP addresses such as
208.77.188.166 (IPv4) or 2001:db8:1f70::999:de8:7648:6e8 (IPv6). People take advantage of
this when they recite meaningful URLs and e-mail addresses without having to know how the
machine will actually locate them.
The Domain Name System distributes the responsibility of assigning domain names and
mapping those names to IP addresses by designating authoritative name servers for each
domain. Authoritative name servers are assigned to be responsible for their particular
domains, and in turn can assign other authoritative name servers for their sub-domains. This
mechanism has made the DNS distributed, fault tolerant, and helped avoid the need for a
single central register to be continually consulted and updated.
In general, the Domain Name System also stores other types of information, such as the list
of mail servers that accept email for a given Internet domain. By providing a worldwide,
distributed keyword-based redirection service, the Domain Name System is an essential
component of the functionality of the Internet.
Other identifiers such as RFID tags, UPC codes, International characters in email addresses
and host names, and a variety of other identifiers could all potentially utilize DNS.
The Domain Name System also defines the technical underpinnings of the functionality of this
database service. For this purpose it defines the DNS protocol, a detailed specification of the
data structures and communication exchanges used in DNS, as part of the Internet Protocol
Suite (TCP/IP). The DNS protocol was developed and defined in the early 1980s and
published by the Internet Engineering Task Force

DNS from Dummies by Javi & Leo

1.1.2 - Logical names vs. numerical identifier

As we have seen, in the internet working structure, the DNS protocol has the fundamental
task to dynamically mapping the correspondence between logical names of internet
resources, normally well managed by humans, and their relative numerical address
expressed in a 4-byte dotted notation, well managed by binary machines.
Whenever a user or a program makes the request of any resource, by simply clicking an
hyperlink in a webpage, by sending a message via email or an appliance that need the exact
time from an NTP server, the DNS system allow them to reach the needed resource in
internet.
Hereby we can also see the particularity of DNS protocol: even if its an Application Layer
protocol, as WWW,SMTP or NTP, it works under and supporting all the other Application
protocols, obviously excepted those that requires a normal binary interaction, for example a
VPN tunnel.

This fundamental role of DNS protocol, is the main reason because is frequently involved in a
lot of issues, normally masking an unreachable resource (for some name resolution
problems), with his physical unavailability.
One of the most important side effects of DNS system, is that it separate the name of a
resource from his physical location, maintaining consistency of all internets information stored
into the servers.
For example a link to an external webpage, will always works if referred by his logical name
(i.e. www.multisite.com/site1/home3/page5/image4.jpg ), also if the server location (and so his
IP address) changes, because the DNS system has in charge to retrieve the up-to-date IP
address of the resource we need.
This is possible because the information pairs between logical names and their relative IP
addresses are stored in a centralized manner in a distributed database, and more important,
in a logical hierarchical structure that allows an intrinsically recursive and very faster
resolution of names.
Normally after a couple of DNS queries, the IP address of a resource is available to the
requester.

DNS from Dummies by Javi & Leo

Well see the logical details of the distributed hierarchical database of DNS system and how a
resolution is made in chapter 1.2
We finally would like to notice that the paradigm of layering of addresses that DNS system
follow, its extensively used in internet technology.
One layer below the same role is taken by ARP, that allow the pairing and resolution between
an IP address and the hardware physical address associated with it.

1.1.3 - OSI stack & packet shape

As we noticed in the previous paragraphs, DNS its an Application layer protocol, but is
special, because normally used by other protocols of the same layer in order to reach the
correct destination.

As his most important function is to map logical names and address, we can also see some
diagrams in which DNS protocol stands between transport layer and the other Application
layers protocols.
This support function of DNS protocol not appear in this picture, but we can imagine a
graphical situation similar to ARP protocol, as we can see above and as noticed at the end of
previous chapter.

We can take a quick view to the DNS header and packet shape.

DNS from Dummies by Javi & Leo

The below image begin from layer three (IP) and you have obviously imagine that all this
packet will be inserted into a layer-2 packet, i.e. its the variable - from 46 to 1500 bytes data field of a canonical layer-2 packet

On the upper headers the only thing to be noticed from our point of view its that in case of a
query, the Destination port is normally the standard 53. For an answer its obviously the
Source port that take the 53 value.
The interesting fields in the header of the DNS Data section are:
-

Query ID: unique identifier for a query, permit association between question and
answer;
QR: this bit take the value 0 if its a query, 1 for an answer from DNS server
Opcode:4 bits field, normally take the value 0000 that stands for query;
AA: take the value 1 if its an Authoritative Answer;
TC: take the value 1 if the answer is truncated
RD: Recursion Desired, set to 1 if client wish that server perform the recursion of the
lookup
RA: recursion Allowed, set to 1 if the server can recurse the lookup for the client
Z: must be all 0
Rcode: response code from the server;

DNS from Dummies by Javi & Leo

Question count/Answer count/Authority Count/Additional record Count: indicate the

number of the relative fields filled in the DNS question or answer data. We will see
in details how this field are filled in a question/answer example.

You can found a complete reference of the DNS parameters for example at:
http://www.iana.org/assignments/dns-parameters

1.1.4 DNS and revDNS

Reverse DNS lookup or reverse DNS resolution (rDNS) is the determination of a domain
name that is associated with a given IP address using the Domain Name System (DNS) of the
Internet.
Computer networks use the Domain Name System to determine the IP address that is
associated with a given domain name. This process is also known as forward DNS resolution.
Reverse DNS lookup is the inverse process of this, the resolution of an IP address into its
designated domain name.
The reverse DNS database of the Internet is rooted in the Address and Routing Parameter
Area (arpa) top-level domain of the Internet. IPv4 uses the in-addr.arpa domain and the
ip6.arpa domain is delegated for IPv6.
The process of reverse resolving an IP address is facilitated with the pointer DNS record type
(PTR record).
Internet standards documents (RFC 1033, RFC 1912 Section 2.1) specify that "Every
Internet-reachable host should have a name" and that such names are matched with a
reverse pointer record.

[Some more? Leo have to fill!]

DNS from Dummies by Javi & Leo

1.2 - General structure

1.2.1 - RIPE IP European registry

RIPE IP European registry

The RIPE NCC is an independent, not-for-profit membership organisation that supports the
infrastructure of the Internet through technical co-ordination in its service region. The most
prominent activity of the RIPE NCC is to act as the Regional Internet Registry (RIR) providing
global Internet resources and related services (IPv4, IPv6 and AS Number resources) to
members in the RIPE NCC service region. The membership consists mainly of Internet
Service Providers (ISPs), telecommunication organisations and large corporations located in
Europe, the Middle East and parts of Central Asia.
The RIPE NCC also provides services for the benefit of the Internet community at large.
These services include:
* Development and maintenance of the RIPE Database
* Administrative support for the RIPE community.
Other activities include:
* Outreach activities with governments and industry-related organisations,
* Management of one of the 13 root name servers (K-root),
* Deployment of a routing database
* Co-ordination support for ENUM delegations
* Neutral measuring network that provides publicly accessible and authoritative statistics on
the operation of the Internet.
All RIPE NCC's activities and services are listed in the annual RIPE NCC Activity Plan.

1.2.2 - Official registries and references

A domain name registry, is a database of all domain names registered in a top-level domain. A
registry operator, also called a Network Information Center (NIC), is the part of the Domain
Name System (DNS) of the Internet that keeps the database of domain names, and
generates the zone files which convert domain names to IP addresses. Each NIC is an
organisation that manages the registration of Domain names within the top-level domains for
which it is responsible, controls the policies of domain name allocation, and technically
operates its top-level domain. It is potentially distinct from a domain name registrar.
Domain names are managed under a hierarchy headed by the Internet Assigned Numbers
Authority (IANA), which manages the top of the DNS tree by administrating the data in the
root nameservers.
IANA also operates the .int registry for intergovernmental organisations, the .arpa zone for
protocol administration purposes, and other critical zones such as root-servers.net.

DNS from Dummies by Javi & Leo

IANA delegates all other domain name authority to other domain name registries such as
VeriSign.
Country code top-level domains (ccTLD) are delegated by IANA to national registries such as
DENIC in Germany, or Nominet in the United Kingdom.
Some name registries are government departments (e.g., the registry for Sri Lanka nic.lk).
Some are co-operatives of internet service providers (such as DENIC) or not-for profit
companies (such as Nominet UK). Others operate as commercial organizations, such as the
US registry (nic.us).
The allocated and assigned domain names are made available by registries by use of the
WHOIS system and via their Domain name servers.
Some registries sell the names directly (like SWITCH in Switzerland) and others rely on
separate entities to sell them. For example, names in the .com TLD are in some sense sold
"wholesale" at a regulated price by VeriSign, and individual domain name registrar sell names
"retail" to businesses and consumers.

1.2.3 National registries

A country code top-level domain (ccTLD) is an Internet top-level domain generally used or
reserved for a country (a sovereign state or a dependent territory).
All ccTLD identifiers are two letters long, and all two-letter top-level domains are ccTLDs.
Creation and delegation of ccTLDs is performed by the Internet Assigned Numbers Authority
(IANA) as described in RFC 1591, corresponding to ISO 3166-1 alpha-2 country codes with
few exceptions explained below.
The IANA (currently contracted to ICANN) is responsible for determining an appropriate
trustee for each ccTLD. Administration and control is then delegated to that trustee, which is
responsible for the policies and operation of the domain. The current delegation can be
determined from IANA's list of ccTLDs. Individual ccTLDs may have varying requirements and
fees for registering subdomains. There may be a local presence requirement (for instance,
citizenship or other connection to the ccTLD), as for example the Canadian (ca) and German
(de) domains, or registration may be open.
Lenient registration restrictions on certain ccTLDs have resulted in domain names like I.am,
tip.it, start.at and go.to. Other variations of ccTLD usage have been called domain hacks,
where the Second-level domain and ccTLD are used together to form one word or one title.
This has resulted in domains like blo.gs of South Georgia and the South Sandwich Islands
(gs), del.icio.us of United States of America (us), and cr.yp.to of Tonga (to). (Non country code
TLDs have also been used, like inter.net which uses the .net gTLD, probably the first domain
hack ever.)
Another form of hacks on ccTLDs results from speculation over typographical errors. The .co
domain of Colombia has generated interest ever since it was realized that people might miss
typing the "m" for sites in the .com domain, or similarly reach the domain .cm for Cameroon
due to a missed "o".
A number of the world's smallest countries have licensed their TLDs for worldwide commercial
use. For example, Tuvalu and the Federated States of Micronesia, small island-states in the
Pacific, have partnered with VeriSign and FSM Telecommunications respectively, to sell
domain names using the .tv and .fm TLDs to television and radio stations.

DNS from Dummies by Javi & Leo

10

1.2.4 Registrars

A domain name registrar is an organization or commercial entity, accredited by the Internet

Corporation for Assigned Names and Numbers (ICANN) or by a national country code toplevel domain (ccTLD) authority, to manage the reservation of Internet domain names in
accordance with the guidelines of the designated domain name registries and offer such
services to the public.
An end-user cannot directly register a domain and manage their domain information with
ICANN. A designated registrar must be chosen. Prior to 1999, the only com registrar was NSI,
but the approval of the SRS opened up the opportunity for other companies to be designated
as registrars.
Each ICANN-accredited registrar must pay a fixed fee of US$4,000 plus a variable fee. The
sum of variable registrar fees are designed to total US$3.8 million.
Only the designated registrar may modify or delete information about a domain name. The
competition that the SRS created enables end users to choose from many registrars offering
different services at varying prices. It is not unusual for an end user to switch registrars which
invokes a domain transfer process governed by specific domain name transfer policies.
When a registrar registers a com domain name for an end-user, it must pay a maximum
annual fee of US$6.86 to VeriSign, the registry operator for com, and a US$0.20
administration fee to ICANN. Most domain registrars price their services and products to
address both the annual fees and the administration fees that must be paid to ICANN.
Barriers to entry into the bulk registrar industry are high for new companies without an existing
customer base.
Many registrars also offer registration through reseller affiliates. An end-user registers either
directly with a registrar, or indirectly through one or more layers of resellers. As of 2008, the
cost generally ranges from a low of about $7.50 per year to about $35 per year. The
maximum period of registration of a domain name is generally 10 years.
Some registrars are offering longer periods of up to one hundred years, but such offers
involve the registrar renewing the registration for their customer. The one hundred year
domain name registration would not be in the official registration database. Some packages of
Internet services, such as web hosting, include the domain registration in the total package
pricing.

DNS from Dummies by Javi & Leo

11

1.2.5 DNS tree, TLD, subTLD

The domain name space consists of a tree of domain names. Each node or leaf in the tree
has zero or more resource records, which hold information associated with the domain name.
The tree sub-divides into zones beginning at the root zone. A DNS zone consists of a
collection of connected nodes authoritatively served by an authoritative nameserver. (Note
that a single nameserver can host several zones.)
Administrative responsibility over any zone may be divided, thereby creating additional zones.
Authority is said to be delegated for a portion of the old space, usually in form of subdomains, to another nameserver and administrative entity. The old zone ceases to be
authoritative for the new zone.

A domain name usually consists of two or more parts (technically labels), which are
conventionally written separated by dots, such as example.com.
* The rightmost label conveys the top-level domain (for example, the address
www.example.com has the top-level domain com).
* Each label to the left specifies a subdivision, or subdomain of the domain above it. Note:
subdomain expresses relative dependence, not absolute dependence. For example:
example.com is a subdomain of the com domain, and www.example.com is a subdomain of
the domain example.com. In theory, this subdivision can go down 127 levels. Each label can
contain up to 63 octets. The whole domain name may not exceed a total length of 253 octets.
In practice, some domain registries may have shorter limits.
* A hostname refers to a domain name that has one or more associated IP addresses (e.g.,
the 'www.example.com' and 'example.com' domains are both hostnames, whereas the 'com'
domain is not).

DNS from Dummies by Javi & Leo

12

The Domain Name System is maintained by a distributed database system, which uses the
client-server model. The nodes of this database are the name servers. Each domain or
subdomain has one or more authoritative DNS servers that publish information about that
domain and the name servers of any domains subordinate to it. The top of the hierarchy is
served by the root nameservers: the servers to query when looking up (resolving) a top-level
domain name (TLD).
The client-side of the DNS is called a DNS resolver. It is responsible for initiating and
sequencing the queries that ultimately lead to a full resolution (translation) of the resource
sought, e.g., translation of a domain name into an IP address.
A DNS query may be either a non-recursive query or a recursive query:
* A non-recursive query is one in which the DNS server provides a record for a domain for
which it is authoritative itself, or it provides a partial result without querying other servers.
* A recursive query is one for which the DNS server will fully answer the query (or give an
error) by querying other name servers as needed. DNS servers are not required to support
recursive queries.
A top-level domain or domain name (TLD) is the highest level of domain names in the root
zone of the Domain Name System of the Internet. For all domains in lower levels, it is the last
part of the domain name, that is, the label that follows the last dot of a fully qualified domain
name. For example, in the domain name www.example.com, the top-level domain is com, or
COM, as domain names are not case-sensitive. Management of most top-level domains is
delegated to responsible organizations by the Internet Corporation for Assigned Names and
Numbers (ICANN), which operates the Internet Assigned Numbers Authority (IANA) and is in
charge of maintaining the DNS root zone.
Originally, the top-level domain space was organized into three main groups, Countries,
Categories, and Multiorganizations. An additional temporary group consisted only of the initial
DNS domain, arpa, intended for transitional purposes toward the stabilization of the domain
name system.
Countries are designated in the domain name system by their English two-letter ISO country
code. This group of domains is therefore commonly known as country-code top-level domains
(ccTLD).
The Categories group has become known as the generic top-level domains. Initially this group
consisted of GOV, EDU, COM, MIL, ORG, and NET.
In the growth of the Internet, it became desirable to create additional generic top-level
domains. Some of the initial domains' purposes were also generalized, modified, or assigned
for maintanance to special organizations affiliated with the intended purpose.
As a result, IANA today distinguishes the following groups of top-level domains:
* country-code top-level domains (ccTLD): Two letter domains established for countries or
territories. With some historical exceptions, the code for any territory is the same as its twoletter ISO 3166 code.
* generic top-level domains (gTLD): Top-level domains with three or more characters
o unsponsored top-level domains: domains that operate directly under policies
established by ICANN processes for the global Internet community.
o sponsored top-level domains (sTLD): These domains are proposed and sponsored by
private agencies or organizations that establish and enforce rules restricting the eligibility to
use the TLD. Use is based on community theme concepts.
o infrastructure top-level domain: This group consists of one domain, the Address and
Routing Parameter Area (ARPA). It is managed by IANA on behalf of the Internet Engineering
Task Force for various purposes specified in Request for Comments.

DNS from Dummies by Javi & Leo

13

In addition, a group of internationalized domain name (IDN) top-level domains has been
installed under test for testing purposes.
The authoritative list of currently existing TLDs in the root zone is published at the IANA
website at http://www.iana.org/domains/root/db/
In the Domain Name System (DNS) hierarchy, a subdomain is a domain that is part of a larger
domain.
The Domain Name System (DNS) has a tree structure or hierarchy, with each node on the
tree being a domain name. A subdomain is a domain that is part of a larger domain, the only
domain that isn't also a subdomain is the root domain. For example, "mail.example.com" and
"calendar.example.com" are subdomains of the "example.com" domain, which in turn is a
subdomain of the "com" top-level domain (TLD).
A "subdomain" expresses relative dependence, not absolute dependence: for example,
wikipedia.org comprises a subdomain of the org domain, and en.wikipedia.org comprises a
subdomain of the domain wikipedia.org. In theory, this subdivision can go down to 127 levels
deep, and each DNS label can contain up to 63 characters, as long as the whole domain
name does not exceed a total length of 255 characters. But in practice some domain
registries have shorter limits than that.
Subdomains are commonly used by organizations that wish to assign a unique name to a
particular department, function, or service related to the organization. For example, a
university might assign "cs" to the computer science department, such that a number of hosts
could be used inside that subdomain, such as mail.cs.example.edu or www.cs.example.edu.
A subdomain is sometimes termed a vanity domain, can be a subdomain of an ISP's own
domain aliased to an individual user account or expresses the individuality of the person on
whose behalf it is registered.
Depending on application, a record inside a domain, or subdomain might refer to a hostname,
or a service provided by a number of machines in a cluster. Some websites use different
subdomains to point to different server clusters. For example, www.example.com points to
Server Cluster 1 or Data centre 1, and www2.example.com points to Server Cluster 2 or Data
centre 2, etc.

1.2.6 - Hierarchical structure & recursive resolution: how to reach the right IP?

The resolver, or another DNS server acting recursively on behalf of the resolver, negotiates
use of recursive service using bits in the query headers.
Resolving usually entails iterating through several name servers to find the needed
information. However, some resolvers function simplistically and can communicate only with a
single name server. These simple resolvers (called "stub resolvers") rely on a recursive name
server to perform the work of finding information for them.
A
domain
name
may
have
several
name
components
(e.g.,
ahost.ofasubnet.ofabiggernet.inadomain.example). In practice, full host names will frequently
consist of just three segments: ahost.inadomain.example, and most often
www.inadomain.example. For querying purposes, software interprets the name segment by

DNS from Dummies by Javi & Leo

14

segment, from right to left. At each step along the way, the program queries a corresponding
DNS server to provide a pointer to the next server which it should consult.
A DNS recursor consults three nameservers to resolve the address www.wikipedia.org.
As originally envisaged, the process was as simple as:
1. the local system is pre-configured with the known addresses of the root servers in a file of
root hints, which need to be updated periodically by the local administrator from a reliable
source to be kept up to date with the changes which occur over time.
2. query one of the root servers to find the server authoritative for the next level down (so in
the case of our simple hostname, a root server would be asked for the address of a server
with detailed knowledge of the example top level domain).
3. querying this second server for the address of a DNS server with detailed knowledge of
the second-level domain (inadomain.example in our example).
4. repeating the previous step to progress down the name, until the final step which would,
rather than generating the address of the next DNS server, return the final address sought.
The diagram illustrates this process for the real host www.wikipedia.org.
The mechanism in this simple form has a difficulty: it places a huge operating burden on the
root servers, with every search for an address starting by querying one of them. Being as
critical as they are to the overall function of the system, such heavy use would create an
insurmountable bottleneck for trillions of queries placed every day. In practice caching is used
to overcome this problem, and, in fact, root nameservers deal with very little of the total traffic.

Name servers in delegations appear listed by name, rather than by IP address. This means
that a resolving name server must issue another DNS request to find out the IP address of the
server to which it has been referred. Since this can introduce a circular dependency if the
nameserver referred to is under the domain that it is authoritative of, it is occasionally
necessary for the nameserver providing the delegation to also provide the IP address of the
next nameserver. This record is called a glue record.
For example, assume that the sub-domain en.wikipedia.org contains further sub-domains
(such as something.en.wikipedia.org) and that the authoritative name server for these lives at
ns1.something.en.wikipedia.org. A computer trying to resolve something.en.wikipedia.org will
thus first have to resolve ns1.something.en.wikipedia.org. Since ns1 is also under the
something.en.wikipedia.org subdomain, resolving ns1.something.en.wikipedia.org requires
resolving something.en.wikipedia.org which is exactly the circular dependency mentioned
above. The dependency is broken by the glue record in the nameserver of en.wikipedia.org
that provides the IP address of ns1.something.en.wikipedia.org directly to the requestor,
enabling it to bootstrap the process by figuring out where ns1.something.en.wikipedia.org is
located.

DNS from Dummies by Javi & Leo

15

1.2.7 - Authoritative servers, zone transfers

In computing, a name server (also spelled nameserver) consists of a program or computer

server that implements a name-service protocol. It maps a human-recognizable identifier to a
system-internal, often numeric, identification or addressing component.
For example, on the Internet, a special case of name servers, so called Domain Name
System (DNS) servers, are used to translate a hostname or a domain name (for example,
'en.wikipedia.org') to its corresponding binary identifier (the IP address 145.97.39.155), or vice
versa.
The Internet maintains two principal namespaces, the domain name hierarchy and the
Internet Protocol (IP) address system. The Domain Name System maintains the domain
namespace and provides translation services between these two namespaces. Internet name
servers implement the Domain Name System. A DNS name server is a server that stores the
DNS records, such as address (A) records, name server (NS) records, and mail exchanger
(MX) records for a domain name (see also List of DNS record types) and responds with
answers to queries against its database.
The top hierarchy of the Internet Domain Name System is served by the root name servers
maintained by delegation by the Internet Corporation for Assigned Names and Numbers
(ICANN).
An authoritative name server is a name server that gives original, first-hand, definitive
answers (authoritative answers) to DNS queries and not just cached answers that were
obtained from another name server. Therefore it only returns answers to queries about
domain names that are installed in its configuration system.
An authoritative name server can either be a master server or a slave server. A master server
is a server that stores the original (master) copies of all zone records. A slave server uses an
automatic updating mechanism of the DNS protocol in communication with its master to
maintain an identical copy of the master records.
Every domain name must be assigned a set of authoritative name servers that are installed in
NS records in the parent domain.
When domain names are registered with a domain name registrar their installation at the
domain registry of a top level domain requires the assignment of a primary name server and
at least one secondary name server. The requirement of multiple name servers aims to make

DNS from Dummies by Javi & Leo

16

the domain still functional even if one name server becomes inaccessible or inoperable. The
designation of a primary name server is solely determined by the priority given to the domain
name registrar. For this purpose generally only the fully qualified domain name of the name
server is required, unless the servers are contained in the registered domain, in which case
the corresponding IP address is needed as well.
Primary name servers are often master name servers, while secondary name server may be
implemented as slave servers.
An authoritative server indicates its status of supplying definitive answers, deemed
authoritative, by setting a software flag (a protocol structure bit), called the Authoritative
Answer (AA) bit in its responses. This flag is usually reproduced prominently in the output of
DNS administration query tools (such as dig) to indicate that the responding name server is
an authority for the domain name in question.
In principle, authoritative name servers are sufficient for the operation of the Internet.
However, with only authoritative name servers operating, every DNS query must start with
recursive queries at the root zone of the Domain Name System and each user system must
implement resolver software capable of recursive operation.
To improve efficiency, reduce DNS traffic across the Internet, and increase performance in
end-user applications, the Domain Name System supports DNS cache servers which store
DNS query results for a period of time determined in the configuration (time-to-live) of the
domain name record in question. Typically, such caching DNS servers, also called DNS
caches, also implement the recursive algorithm necessary to resolve a given name starting
with the DNS root through to the authoritative name servers of the queried domain. With this
function implemented in the name server, user applications gain efficiency in design and
operation.
The combination of DNS caching and recursive functions in a name server is not mandatory,
the functions can be implemented independently in servers for special purposes.
Internet service providers typically provide recursive and caching name servers for their
customers. In addition, many home networking routers implement DNS caches and recursors
to improve efficiency in the local network.

1.2.8 - Registrar vs. maintainer: who do what?

1.2.9 - How to read and interpreter fields in a query

[PENDING]

DNS from Dummies by Javi & Leo

17

2. SERVER SIDE SOFTWARE

2.1 - Bind & Microsoft DNS Server

BIND, for Berkeley Internet Name Domain, is the most commonly used Domain Name
System (DNS) server on the Internet. On Unix-like systems it is the de facto standard.
BIND was originally created by four graduate students at the Computer Systems Research
Group at the University of California, Berkeley, and was first released with 4.3BSD. Paul Vixie
started maintaining it in 1988 while working for DEC. Today, BIND is maintained by the
Internet Systems Consortium.
A new version of BIND (BIND 9) was written from scratch in part to address the architectural
difficulties with auditing the earlier BIND code bases, and also to support DNSSEC (DNS
Security Extensions). Other important features of BIND 9 include: TSIG, DNS notify,
nsupdate, IPv6, rndc flush (remote name daemon control), views, multiprocessor support, and
an improved portability architecture. rndc uses a shared secret to provide encryption for local
and remote terminals during each session.
Earlier versions of BIND offered no mechanism to store and retrieve zone data in anything
other than flat text files. Since BIND 9.4 DLZ has been available as a compile time option
allowing for zone storage in a variety of database formats including LDAP, Berkeley DB,
PostgreSQL, MySQL, and ODBC.
Like Sendmail, WU-FTPD and other systems dating back to the earlier days of the Internet
(when security was not such an issue as it has since become) BIND 4 and BIND 8 have had a
large number of serious security vulnerabilities over the years and as such their use is now
strongly discouraged. While BIND 9 was a complete rewrite, it has still experienced numerous
vulnerabilities.
The configuration files are not checked automatically for errors at runtime, but a configuration
syntax verification tool is included in the distribution.
Microsoft DNS is the name given to the implementation of domain name system services
provided in Microsoft Windows operating systems.
The Domain Name System support in Microsoft Windows NT, and thus its derivatives
Windows 2000, Windows XP, and Windows Server 2003, comprises two clients and a server.
Every Microsoft Windows machine has a DNS lookup client, to perform ordinary DNS
lookups. Some machines have a Dynamic DNS client, to perform Dynamic DNS Update
transactions, registering the machines' names and IP addresses. Some machines run a DNS
server, to publish DNS data, to service DNS lookup requests from DNS lookup clients, and to
service DNS update requests from DNS update clients.
The server software is only supplied with the server versions of Windows.
Applications perform DNS lookups with the aid of a DLL. They call library functions in the DLL,
which in turn handle all communications with DNS servers (over UDP or TCP) and return the
final results of the lookup back to the applications.
Microsoft's DNS client also has optional support for local caching, in the form of a DNS Client
service (also known as DNSCACHE). Before they attempt to directly communicate with DNS
servers, the library routines first attempt to make a local IPC connection to the DNS Client
service on the machine. If there is one, and if such a connection can be made, they hand the

DNS from Dummies by Javi & Leo

18

actual work of dealing with the lookup over to the DNS Client service. The DNS Client service
itself communicates with DNS servers, and caches the results that it receives.
Microsoft's DNS client is capable of talking to multiple DNS servers. The exact algorithm
varies according to the version, and service pack level, of the operating system; but in general
all communication is with a preferred DNS server until it fails to answer, whereupon
communication switches to one of several alternative DNS servers.
There are several minor differences in system behavior depending on whether the DNS Client
service is started:
* Parsing of the "hosts" file: The lookup functions read only the hosts file if they cannot offload their task onto the DNS Client service and have to fall back to communicating with DNS
servers themselves. In turn, the DNS Client service reads the "hosts" file once, at startup, and
only re-reads it if it notices that the last modification timestamp of the file has changed since it
last read it. Thus:
o With the DNS Client service running: The "hosts" file is read and parsed only a few
times, once at service startup, and thereafter whenever the DNS Client service notices that it
has been modified.
o Without the DNS Client service running: The "hosts" file is read and parsed
repeatedly, by each individual application program as it makes a DNS lookup.
* The effect of multiple answers in the "hosts" file: The DNS Client service does not use the
"hosts" file directly when performing lookups. Instead, it (initially) populates its cache from it,
and then performs lookups using the data in its cache. When the lookup functions fall back to
doing the work themselves, however, they scan the "hosts" file directly and sequentially,
stopping when the first answer is found. Thus:
o With the DNS Client service running: If the "hosts" file contains multiple lines denoting
multiple answers for a given lookup, all of the answers in the cache will be returned.
o Without the DNS Client service running: If the "hosts" file contains multiple lines
denoting multiple answers for a given lookup, only the first answer found will be returned.
* Fallback from preferred to alternative DNS servers: The fallback from the preferred DNS
server to the alternative DNS servers is done by whatever entity, the DNS Client service or
the library functions themselves, is actually performing the communication with them. Thus:
o With the DNS Client service running: Fallback to the alternative DNS servers happens
globally. If the preferred DNS server fails to answer, all subsequent communication is with the
alternative DNS servers.
o Without the DNS Client service running: Any fallback to the alternative DNS servers
happen locally, within each individual process that is making DNS queries. Different
processes may be in different states, some talking to the preferred DNS server and some
talking to alternative DNS servers.
Linux distributions and various versions of Unix have a generalized name resolver layer. The
resolver can be controlled to use a hosts file or Network Information Service (NIS), by
configuring the Name Service Switch.
Whilst DNS lookups read DNS data, DNS updates write them. Both workstations and servers
running Windows attempt to send Dynamic DNS update requests to DNS servers.
Workstations running Windows attempt to register their names and their IP addresses with
DNS servers, so that other machines may locate them by name. This is done not by the DNS
Client service, but by the DHCP Client service. It is thus necessary to run the DHCP Client
service, even if DHCP isn't being used to configure the machine, in order to dynamically
register a machine's name and address for DNS lookup. The DHCP Client service registers
name and address data whenever they are changed (either manually by an administrator or
automatically by the granting or revocation of a DHCP lease).

DNS from Dummies by Javi & Leo

19

Servers running Microsoft Windows also attempt to register other information, in addition to
their names and IP addresses, such as the locations of the LDAP and Kerberos services that
they provide.
Microsoft Windows server operating systems can run the DNS Server service. This is a
monolithic DNS server that provides many types of DNS service, including caching, Dynamic
DNS update, zone transfer, and DNS notification. DNS notification implements a push
mechanism for notifying a select set of secondary servers for a zone when it is updated.
Microsoft's "DNS Server" service was first introduced in Windows NT 3.51 as an add-on with
Microsoft's collection of BackOffice services (at the time was marked to be used for testing
proposes only). Its code is a fork of ISC's BIND, version 4.3, and remains largely compatible
with it including the format of all master files.
As of 2004, it was the fourth most popular DNS server (counting BIND version 9 separately
from versions 8 and 4) for the publication of DNS data.
Like various other DNS servers, Microsoft's DNS server supports different database back
ends. Microsoft's DNS server supports two such back ends. DNS data can be stored either in
master files (also known as zone files) or in the Active Directory database itself. In the latter
case, since Active Directory (rather than the DNS server) handles the actual replication of the
database across multiple machines, the database can be modified on any server ("multiplemaster replication"), and the addition or removal of a zone will be immediately propagated to
all other DNS servers within the appropriate Active Directory "replication scope". (Contrast this
with BIND, where when such changes are made, the list of zones, in the /etc/named.conf file,
has to be explicitly updated on each individual server.)
Microsoft's DNS server can be administered using either a graphical user interface, the "DNS
Management Console", or a command line interface, the dnscmd utility.
Prior to Windows Server 2003 and Microsoft Windows 2000 Service Pack 3, the most
common problem encountered with Microsoft's DNS server was cache pollution. Although
Microsoft's DNS Server had a mechanism for properly dealing with cache pollution, the
mechanism was turned off by default.
A long-known issue are the incompatibilities with BIND configuration files: in particular, the
lack of support for DNS wildcards. This can be partially attributed to the fact that Microsoft's
DNS server is based on BIND 4.3, before BIND added the support for DNS wildcards. Loose
Wildcarding can be enabled as described here. To create a wildcard character record, the
Dnscmd command-line tool can be used. Also the support of IPv6 is implemented using a
different technique from that of BIND 9, further driving even more incompatibles between the
two products.
In 2004, a common problem involved the feature of the Windows Server 2003 version of
Microsoft's DNS server to use EDNS0, which a large number of firewalls could not cope with.

DNS from Dummies by Javi & Leo

20

2.2 - Zone Files; record, entries, fields TTL

A zone file is a text file that describes a portion of the domain name system (DNS) called a
DNS zone. A zone contains information that defines mappings between domain names and IP
addresses and other resources, organized in form of resource records (RR).
The format a zone file is defined in RFC 1035 section 5 and RFC 1034 section 3.6.1. This
format was originally used by the Berkeley Internet Name Domain (BIND) software package,
but has been widely adopted by other DNS server software. Each line typically defines a
single resource record. A line begins with a domain name, but if left blank, defaults to the
previously defined domain name. Following the domain name is the TTL, the class (which is
almost always "IN" for "internet" and rarely included), the type of resource record (A, MX,
SOA, etc.), followed by type-specific data such as the IPv4 address for A records. Comments
can be included by using a semi-colon and lines can be continued by using parenthesis.
There are also file directives that are marked with a keyword starting with a dollar-sign.
A simple example of a zone file:
$ORIGINexample.com.;designatesthestartofthiszonefileinthenamespace
$TTL1h;ThedefaultexpirationtimeofaresourcerecordwithoutitsownTTLvalue
example.com.INSOAns.example.com.username.example.com.(
2007120710;serialnumberofthiszonefile
1d;slaverefresh(1day)
1d;slaveretrytimeincaseofaproblem(1day)
4w;slaveexpirationtime(4weeks)
1h;minimumcachingtimeincaseoffailedlookups(1hour)
)
example.com.NSns;ns.example.comisthenameserverforexample.com
example.com.NS ns.somewhere.com. ;ns.somewhere.comisabackupnameserverfor
example.com
example.com. MX 10 mail.example.com.; mail.example.com is the mailserver for
example.com
@MX20mail2.example.com.;Similartoaboveline,butusing"@"tosay"use$ORIGIN"
@MX50mail3
;Similartoaboveline,butusingahostwithinthisdomain
example.com.A10.0.0.1;ipaddressfor"example.com"
nsA10.0.0.2;ipaddressfor"ns.example.com"
wwwCNAMEns;"www.example.com"isanaliasfor"ns.example.com"
wwwtestCNAMEwww;"wwwtest.example.com"isanotheraliasfor"www.example.com"
mailA10.0.0.3;ipaddressfor"mail.example.com",anyMXrecordhostmustbe
;anAorAAAArecord,itshouldneverbeaCNAMErecord

;asexplainedinRFC2181(section10.3)

As a minimum, the zone file should specify the default "time to live" (TTL) for a record in a
client's cache after which it should repeat the lookup, and the 'Start of Authority' (SOA) record
with the name of the primary authoritative nameserver for the zone, the email address of
someone responsible for management of the nameserver and the zone, and some
information for backup nameservers, that is, other servers that keep a backup copy of the
zone information in case the main nameserver is not reachable. The email address has the @
symbol replaced by a period (.). In the zone file, host names that do not end in a period are
assumed to be relative to the zone origin. For example, in the example above, "www" refers to
"www.example.com", but "example.com." does not refer to "example.com.example.com", but
rather to "example.com". Names ending with a period are said to be 'fully qualified' domain
names.
A zone file is referenced by the configuration file of the nameserver software such as bind,
typically by a statement such as:
zone"example.com"{typemaster;file"/var/named/db.example.com";};

DNS from Dummies by Javi & Leo

21

TTL
Time to live (sometimes abbreviated TTL) is a limit on the period of time or number of
iterations or transmissions in computer and computer network technology that a unit of data
(e.g. a packet) can experience before it should be discarded.
In IPv4, time to live (TTL) is an 8-bit field in the Internet Protocol (IP) header. It is the 9th octet
of 20. The time to live value can be thought of as an upper bound on the time that an IP
datagram can exist in an internet system. The TTL field is set by the sender of the datagram,
and reduced by every host on the route to its destination. If the TTL field reaches zero before
the datagram arrives at its destination, then the datagram is discarded and an ICMP error
datagram (11 - Time Exceeded) is sent back to the sender. The purpose of the TTL field is to
avoid a situation in which an undeliverable datagram keeps circulating on an internet system,
and such a system eventually becoming swamped by such immortal datagrams.
In theory, time to live is measured in seconds, although every host that passes the datagram
must reduce the TTL by at least one unit. In practice, the TTL field is reduced by one on every
hop. To reflect this practice, the field is named hop limit in IPv6.
TTLs also occur in the Domain Name System (DNS), where they are set by an authoritative
nameserver for a particular resource record. When a caching (recursive) nameserver queries
the authoritative nameserver for a resource record, it will cache that record for the time (in
seconds) specified by the TTL. If a stub resolver queries the caching nameserver for the
same record before the TTL has expired, the caching server will simply reply with the already
cached resource record rather than retrieve it from the authoritative nameserver again.
Nameservers may also have a TTL set for NXDOMAIN (acknowledgment that a domain does
not exist); but they are generally short in duration (3 hours at most).
Shorter TTLs can cause heavier loads on an authoritative nameserver, but can be useful
when changing the address of critical services like web servers or MX records, and therefore
are often lowered by the DNS administrator prior to a service being moved, in order to
minimize disruptions.
The units used are seconds. A common TTL value for DNS is 86400 seconds, which is 24
hours. A TTL value of 86400 would mean that if a DNS record was changed, DNS servers
around the world could still be showing the old value from their cache for up to 24 hours after
the change.

DNS from Dummies by Javi & Leo

22

2.3 - RR types: SOA,A,MX,PTR,CNAME,TXT, SPF, NS & others

SOA, start of authority record. Specifies authoritative information about a DNS zone, including
the primary name server, the email of the domain administrator, the domain serial number,
and several timers relating to refreshing the zone.
A, address record. Returns a 32-bit IPv4 address, most commonly used to map hostnames to
an IP address of the host, but also used for DNSBLs, storing subnet masks in RFC 1101, etc.
MX, mail exchange record. Maps a domain name to a list of mail exchange servers for that
domain.
PTR, pointer record. Pointer to a canonical name. Unlike a CNAME, DNS processing does
NOT proceed, just the name is returned. The most common use is for implementing reverse
DNS lookups, but other uses include such things as DNS-SD.
CNAME, canonical name record. Alias of one name to another: the DNS lookup will continue
by retrying the lookup with the new name.
TXT, text record. Originally for arbitrary human-readable text in a DNS record. Since the early
1990s, however, this record more often carries machine-readable data, such as specified by
RFC 1464, opportunistic encryption, Sender Policy Framework (deprecated), DomainKeys,
DNS-SD, etc.
NS, name server record. Delegates a DNS zone to use the given authoritative name servers.
SPF, spf record. Specified as part of the SPF protocol, as an alternative to storing SPF data in
TXT records. Uses the same format as the TXT record.
Other records are AAAA, AFSDB, CERT, DHCID, DLV, DNAME, DNSKEY, DS, HIP,
IPSECKEY, KEY, LOC, NAPTR, NSEC, NSEC3, NSEC3PARAM, RRSIG, SIG, SRV, SSHFP
and TA.

DNS from Dummies by Javi & Leo

23

2.4 - Examples
- use of A
- use of PTR
- MX record
- use of CNAME
- use of TXT and SPF
- Domain zone for MBE Colt

DNS from Dummies by Javi & Leo

24

3. CLIENT SIDE SW

3.1 - nslookup

A simple command line tool that we can use to check DNS fields and internet resources is
nslookup, normally provided with both Windows and Unix OS.
Nslookup can be a useful tool for a first step troubleshooting, but we will see in the other
sections some more sophisticated tools to make more accurate queries to name servers.
Please finally notice that we will see the Windows version but the flags and examples are also
valid in a Unix environment, and normally integrated into the TCP/IP stack of all the modern
OS.
We will also see in the appropriate section, that the same tool is provided by a lot of website,
but for most of them user cant set all parameters that will be available using the command
line tool.
We can start an interactive nslookup session by typing nslookup at the command line
prompt:

As we can see above, we obtain as answer, the default server that will try to resolve our query
(normally the primary DNS server set in our network connections).
We can obviously change this default server, so we can try resolve our query using, for
instance, a particular name server we wants to check (for example the DNS server used by a
particular customer, to see if he could correctly resolve a domain name)
Will be also provided to the user an interactive prompt where he can set some details for the
query parameter and other useful things, that we now will see.

DNS from Dummies by Javi & Leo

25

3.1.1 - Flags and their use

Typing ? or help at the nslookup internal shell we can obtain the list of all parameters that
we can use to retrieve some canonical name information we need.

Here some basic notes on the options, leaving an exhaustive explanation in the examples of
the next paragraph.
As a basic task we can simply insert the name of the resource we need to resolve, introducing
a NAME at the nslookup prompt.
When we use the notation
> NAME1 NAME2
we ask to the program to check the canonical name NAME1 using the NAME2 DNS server
instead of the default server indicated at the beginning of the nslookup session.
Using the keyword set we can set some details to resolve our canonical name, adding some
optional keywords. For example typing
> set all
> set type=MX

we can see all the parameters set for our session

all the next queries will be on MX record

You can also find an exhaustive explanation man page of nslookup at:
http://www.kloth.net/services/nslookup-man.php

DNS from Dummies by Javi & Leo

26

3.1.2 - Examples

Typing the comman set all, we can see here the default settings of nslookup.
In this example we can see among the other information that:
-

the answering server will not be provide us debug informations (nodebug,nod2);

we will ask for a recursive resolution;
to use canonical 53 servers port;
the default request will be an A field;
the default root server;

If we now type the domain microsoft.com we obtain the answer:

that reports for this domain the two A field, which is the default type query as we have seen
in the previous picture.
If we want to know the mail servers for the domain microsoft.com, we have to first change the
type of query, and after ask again for the microsoft domain:

Note that after have setting the type of record we obtain again the prompt of the interactive
nslookup session.
To end the entire session you must type x or exit or control-C.

DNS from Dummies by Javi & Leo

27

As final thing we can see the answer, changing the type of record and setting it to ANY:

For space problem we avoid to provide the output of debug information.

You can try yourself to see what is the nslookup output, setting the two debugs options:
> set debug
> microsoft.com
or
> set d2 (more exhaustive)
> microsoft.com

3.2 - Dig

Dig its a very powerful program for check and troubleshoot DNS issues.
Like NSLookup has a lot of features, but permit a more accuracy in your searches.
You can find it in a lot of websites. For example you can download it from:
http://members.shaw.ca/nicholas.fong/dig/
or on more other web pages, as the window porting doesnt have a dedicated website.
There isnt need to install it. You have only to unzip it in a folder and run it via CLI.
For a better work environment you have only to edit your system PATH variable and to edit
and put into %systemroot%\system32\drivers\etc\ the resolv.conf file.
Normally youll find detailed instruction on how to setup dig on the same page where you
have downloaded the dig zip file.

DNS from Dummies by Javi & Leo

28

3.2.1 - Flags and use

3.2.2 Examples

3.3 - Online tools - Ping, lookup, trace, whois, dns records, dig, MX Lookup, SPF check

4. DOCUMENTATION
- useful books
- online & free documentation
- link to official RFC's

DNS from Dummies by Javi & Leo

29

DNS from Dummies by Javi & Leo

30