DNS - Domain Name System (2006-0411)
1 of 23
DNS - Domain Name System
Personal Manual by Edgar Rothermich
<[email protected]>
2006-0411
The Problem
IP Address............................................................................................................................................................ 2
Domain Name.......................................................................................................................................................2
The Domain Name System
Name Creation...................................................................................................................................................... 3
Tree.............................................................................................................................................................. 4
Node............................................................................................................................................................. 4
Label............................................................................................................................................................. 4
Domain Name...............................................................................................................................................4
Domain Name Space................................................................................................................................... 4
Domain......................................................................................................................................................... 4
Sub-Domain.................................................................................................................................................. 4
Database Creation................................................................................................................................................ 5
Distributed Database.................................................................................................................................... 5
Authority over a Domain............................................................................................................................... 5
Delegation of a Domain................................................................................................................................ 6
Zone............................................................................................................................................................. 7
Hostname..................................................................................................................................................... 7
Address-to-Name Mapping........................................................................................................................... 8
Hardware.............................................................................................................................................................10
Zone Data File............................................................................................................................................ 10
Name Server............................................................................................................................................... 10
Delegation thru referral............................................................................................................................... 11
Registration................................................................................................................................................. 12
Name Server (DNS Server)
Name Server tasks............................................................................................................................................. 13
1) Store Zone Files..................................................................................................................................... 13
2) Resolves Queries................................................................................................................................... 13
Type of name server........................................................................................................................................... 14
Master - Slave............................................................................................................................................. 14
Setting up a Slave Name Server for a zone:.............................................................................................. 14
Resolver.............................................................................................................................................................. 15
Stub Resolver............................................................................................................................................. 15
Smart Resolver........................................................................................................................................... 15
Resolution
Who to ask? Name Server.................................................................................................................................. 16
Query Types........................................................................................................................................................16
Recursive Query......................................................................................................................................... 16
Iterative Query............................................................................................................................................ 16
Forwarder............................................................................................................................................................17
Forward Server........................................................................................................................................... 17
Forward Zone..............................................................................................................................................17
Cache................................................................................................................................................................. 18
Time-To-Live............................................................................................................................................... 18
Setup
Config File: “named.conf”.................................................................................................................................... 20
Zone types.................................................................................................................................................. 20
Zone File............................................................................................................................................................. 21
Rules - Syntax............................................................................................................................................ 21
Resource Records...................................................................................................................................... 21
Abbreviations.............................................................................................................................................. 22
OS X ServerAdmin
BIND - ServerAdmin........................................................................................................................................... 23
DNS - Domain Name System (2006-0411)
2 of 23
The Problem
Every Computer on the Internet has a unique IP Address. When a Client (Web Browser) requests a service from a Server (Web Server), it
sends that request over the internet with an IP Address attached to that request. It is similar to a regular postal letter that has the address of
its destination printed on the letter.
The Problem is that the address of a computer, the "IP Address", a string of numbers (134.56.72.112) is not easy to remember.
IP Address
This is a 32bit word made of 4 sets of numbers, each between 0 and 255 divided by a dot.
192.65.1.25
If you want to access a website from your browser, your browser (the Client) has to send a message using the http protocol to the webserver
(the Server) to request the webpage. Your client uses the Internet's routing system to find the webserver. The Routing System can only find
the webserver however by its IP Address.
Web Server
Web Browser
http://123.234.34.4
request sent to 123.234.34.4
Client
123.234.34.4
Server
Domain Name
The problem is that human beings can remember long numbers not as easy as names. That's why the internet uses a Domain Name System,
which is a database that can assign a Domain Name to every IP Address.
However if you type in your web browser the Domain Name instead the IP Address and try to send it to the webserver with that address, the
response wouldn't come back because the Internet Routing system still needs the IP Address. The Webbrowser has to ask a little program on
your computer the "Resolver" to go and find the IP Address for the Domain Name.
The Resolver (acting as client) sends out a request to a Name Server (server) to find the IP Address for the given Domain Name. The Name
Server can search the Domain Name System, finds the answer and returns it to the Resolver.
The Resolver hands the IP Address to the browser which uses it to send its request for the webpage over the internet using the IP Address
that the Routing System can use.
Web Browser
http://apple.com
Web Server
request sent to 123.234.34.4
apple.com = 123.234.34.4
Server
The IP Address for apple.com is 123.234.34.4
Resolver
Name Server
What is the IP Address for apple.com
Client
Server
DNS - Domain Name System (2006-0411)
3 of 23
The Domain Name System
The Domain Name System is an architecture of clever rules that allows to use Names instead of Number when contacting computers on the
Internet. It was invented 1983 by Paul Mockapetris. To better understand the way it works, you can look at 3 components:
Name Creation: how to come up with unique names
Database Creation: how to manage those names and their information in a database
Hardware: how to use servers to make that information available on the internet
Keep in mind that the Domain Name System has nothing to do with the actual location of any computer on the internet.
Name Creation
The objective is to pick names and assign them to the IP Address of computers. The only rule would be to make sure that the names are
unique, like Amazon, Apple or Google. The "forefathers" of the internet however came up with a little more complex but clever idea how to
create names.
They used the model of an inverted tree:
You can't just pick any name for a Domain Name. The actual Domain Name is a combination of names called "labels", represented by nodes of
the tree. The way how to combine those labels together follows the structure of the inverted tree:
• Label
• You start with the first node and give it a label: a
• Then you branch out and give the next node a label: b
• From that node you branch out to the next node and give that a label: c
• Domain Name
• The final Domain Name is constructed in the following way:
"Read all the labels from the current node up to the root, put them into sequence, separated by a dot: c.b.a. "
• Therefore each node has a text label and the actual Domain Name
Node
Level
node
Label
Domain Name
(null label)
node
Label
Domain Name
.
(null label)
.
com
com.
org
org.
apple
apple.com.
tea
tea.org
www
www.apple.com.
green
green.tea.org.
Root Level
Top Level
Secondary
Level
Third Level
The complete tree with all the nodes representing all Domain Names on the Internet is called the Domain Name Space
The model of the inverted tree visualizes how Domain Names are created. The tree model ensures that all the Domain Names are unique with
two simple rules:
• You can choose any label for any node inside the Domain Name Space with one exception:
• The sibling nodes (the one with the same parent node) have to be unique
Note:
Each node represents a Domain Name which is assigned to an IP address of a host computer. BUT the location of the nodes on the tree have
no direct relationship with the actual location of the computer (host) they representing. The tree is just a model that helps to create the
Domain Names
DNS - Domain Name System (2006-0411)
4 of 23
Domain Name Space
Domain Name System:
node
Label: .
Domain Name: (Root)
Domain: (Root)
Doma
in
Doma
in
Do
m
ai
n
node
node
Doma
in
Label: apple
Domain Name: apple.com.
Domain: apple.com
(Secondary Level Domain)
Do
ma
in
ain
m
Do
Label: com
Domain Name: com.
Domain: .com
(Top Level Domain)
Tree
The creation of the Domain Names follow he model of an inverted tree
Node
Each node of the tree can be given a label: max 63 characters, allowed are 26 letters, 10 numbers and the hyphen (not starting with!)
Each node carries the actual Domain Name (max total length of 255 characters)
Each node itself is the beginning of a sub-tree (it could go down 127 levels deep)
Label
The label given to each node is a building block of the Domain Name. Putting all the labels from any given node up to the root node in
sequence will make up the actual Domain Name (labels are separated by dots). The top label of the tree is the Root or "null label" which is
normally not used
Domain Name
The actual Domain Name, used in applications like a webbrowser. The Domain Name of any given node is the combination of all the node
labels from that node up to the root node with dots separating the labels.
Domain Name Space
The Domain Name Space is the sum of all Domain Names represented by the whole tree.
Domain
A Domain is that part of the tree starting with the node that has the same Domain Name.
• the whole tree starting at the top with the root node is called the "root Domain"
• the sub-tree starting with the node "com" is called the ".com Domain" also known as a Top Level Domain
• the sub-tree starting with the node "apple.com" is called the "apple.com Domain"
• the sub-tree starting with the node "math.ucla.edu" is called the "math.ucla.edu Domain"
• etc ….
Sub-Domain
A Sub-Domain is the next sub-tree, branching out from the node of the current Domain
DNS - Domain Name System (2006-0411)
5 of 23
Database Creation
The previous chapter explained the set of rules on how you create the Domain Names. Now lets look at how and where you store them
Distributed Database
A simple way to store (any) data is to create one big database. Make a record for each Domain Name that stores the assigned IP Address and
any data related for that Domain Name.
Domain Name
IP Address
store.apple.com
55.215.22.6
google.com
23.58.206.36
amazon.de
56.89.9.124
ftp.ucla.org
111.2.23.204
The drawbacks of such a database however would be:
• The database would grow fairly big: One record for each IP Address (400Mio computers on the internet)
• An update of the database would be needed whenever there is a change in any data for a Domain Name worldwide
• And there would be the question about who has the authority of maintaining the database
That's why the creator of the Domain Name System decided to use the architecture of a “Distributed Database” to store Domain Name data.
Two key elements of a distributed database are Authority and Delegation
Authority over a Domain
With a flat database you would have one organization who has the authority to store the data for all existing Domain Names in one place.
The distributed database model however allows to delegate portions of the database to different companies. How does that work:
• The delegation of authority process follows the same inverted tree model that it used to create the Domain Names in the first place.
• You start at the top with the root node and give one company the authority to manage all data inside that Root Domain
• That company with the authority over the Root Domain doesn't want to store and manage all the data. It uses its authority to delegate
(in this case) all of the child nodes (”sub-domains of the Root Domain’) to different companies. Therefor it has no authority over those
domains anymore.
• The company X that received the authority for one of those Domains (“.com”) is now in charge of creating new names in that
Domain. It also is in charge of storing and managing all the data of the “.com domain”
• The company X now also decides that it doesn’t want to have the authority for the whole “.com domain” and delegates the authority
of it’s child nodes (”Sub-domains of the .com domain) to other companies. Therefor it has no authority over those sub-domains
anymore.
• The company Apple for example receives the authority for one of the sub-domains from company X. It is the “apple.com domain” and
Apple is now in charge of creating new names in that Domain. It also is in charge of storing and managing all the data of the
“apple.com domain”
If you own the authority for a Domain you have the authority to ...
• ... choose the the label for any node (and therefore the Domain Names) in its Domain
(sub-tree)
• ... manage the Domain Names in its Domain (sub-tree)
• ... delegate the authority of any of its Sub-Domains starting from a node in its
Domain down the inverted tree.
DNS - Domain Name System (2006-0411)
6 of 23
Delegation of a Domain
The one company that has the authority over the Root Level (top node) of the Domain Name Space (top of the inverted tree) is the
Organization ICANN (Internet Corporation for Assigned Names and Numbers). Here is another example how the process of delegation work:
• Root Level Domain
• ICANN uses that authority to delegate its authority to nodes below its node
• ICANN "creates" new labels which are represented by new "child" nodes on the tree. It delegates their authority to other organizations
or companies. The authority of ICANN ends therefore with the Root Level. The Root Domain’s Sub-domains called Top Level Domains.
• Top Level Domain
• The authority for all the nodes on the Top Level (the one with the Root as their parent node) lies in different companies/organizations:
• gTLD: these are the "generic Top Level Domain Names" managed by NSI who got their authority from ICANN (com, net, org,
edu, ...)
• ccTLD: the "Country Code Top Level Domain Names" are managed by organizations assigned by each country they represent (de,
uk, jp, us, ...)
• Those organizations with the authority for the Top Level Domains can now create new labels which are represented by new "child"
nodes of their own node. The tree (Domain Name Space) is growing. The organizations now delegate their authority for the child
nodes to other organizations: Apple, Google, Universities, etc, or even individuals.
• Second Level Domain
• Companies like Apple or Universities like UCLA have now the authority for their own domain which they got from the TLD
organizations.
• apple.com, ucla.edu, amazon.com, google.com
• Those companies or organizations can create new labels which are represented by new "child" nodes of their own node. The tree
(Domain Name Space) is growing further. And of course they could again delegate the authority for their Sub-domains.
• Third Level Domain
• If a company or organization is really big then it could decide to have part of its subtree managed by a separate department. UCLA
could decide to create a child node with the label "math" and "art" and let the Math and Art department manage their part of the
node:
• math.ucla.edu, art.ucla.edu
Node
Level
node
Label
Domain Name
Authority
Delegated to
(null label)
.
ICANN
edu to NSI
edu
edu.
NSI
ucla to UCLA
ucla
ucla.edu.
UCLA
math to Math
Department
math
math.ucla.edu.
UCLA Math
Department
Root Level
Top Level
Secondary
Level
Third Level
The last node of a branch is called a hostname.
DNS - Domain Name System (2006-0411)
7 of 23
Delegating Domains in the Domain Name System
Domain Name Space
zone
➊
node
Domain
➋
Domain
zone
➌
node
zone
Domain
➍
node
Domain
zone
Do
zone
ma
in
in
ma
Do
➎
zone
Zone
The zone is the part of the tree that one company has the actual authority for. This is different from
the Domain. Technically ICANN has the authority over the Root Domain which is the whole tree below
the Root node. But it delegates the Authority for the nodes below to other companies. The place of
those nodes mark the end of its authority over the Root Domain.
The space including all the nodes from the start of its domain down to the next delegation is called a
Zone.
A company has only the authority over a zone in the Domain Name Space and not necessarily over its
whole domain. If a company doesn’t delegate any Sub-domains then the space of its Domain is the
same as the space of its zone. (No 5)
➊
➋
delegating the sub-domain
com
➌
Label: com
Domain Name: com.
Domain: .com
(Top Level Domain)
➍
delegating the sub-domain
apple.com
➎
Label: apple
Domain Name: apple.com.
Domain: apple.com
(Secondary Level Domain)
A zone is finally the actually record of the distributed database. The company that has the authority for
that zone stores that record and makes it available for everybody on the Internet. The sum of all zones
make up the distributed database of the Domain Name System
Hostname
Each node in the Domain Name Space has its Domain Name that can be assigned to an IP Address of
a computer. This is how the whole thing started in the first place.
• A Domain Name is considered a “Hostname” when its node marks the end of a branch of the tree
and is assigned one or more IP Addresses.
• Any node inside a branch has also a Domain Name that represents an IP Address of a host computer,
but that node has more data about that Domain Name than just a simple Name-Number mapping.
• A Domain Name that has one or more associated IP addresses is called a hostname.
Label: .
Domain Name: (Root)
Domain: (Root)
DNS - Domain Name System (2006-0411)
8 of 23
Address-to-Name Mapping
"(root)"
There is one special branch in the Domain Name Space. It's Domain is
"arpa"
in-addr.arpa
"in-addr"
That domain is used for the reverse lookup or address-to-name mapping.
At the beginning we were interested to assign a name to a hard to remember IP Address of a host computer. The DNS allowed an easy
solution how to find any IP Address of a computer with a specific name assigned to it.
For some procedures (security, verifications, etc) it is also necessary to do the reverse lookup: "what name was assigned to a given IP
Address of a host computer".
The creator of the Domain Name System didn't have to come up with another brilliant idea, they could use the existing "inverted tree" model
of the Domain Name Space that worked so great for creating Domain Names.
IP Address:
32bit IP Address
0 … 255
.
8bit
(octet)
0 … 255
.
8bit
(octet)
0 … 255
8bit
(octet)
.
0 … 255
8bit
(octet)
Each computer on the internet is given a unique 32bit address. The number is broken down in 4 groups of 8bit words (octet),
displayed as decimal values. The 4 numbers are separated by dots.
How do we apply the IP number to the inverted tree?
The subdomain "in-addr.arpa" will have three more subdivisions:
• The in-addre.arpa node will branch out to 256 possible nodes, each with the label name representing one of the 256 numbers of the first
octed (from the left)
• 1st octet level
Each of the 1st octet level nodes can branche out again to 256 nodes, each with the label name representing one of the 256 numbers of
the 2nd octet. Now we have 256x256=65,563 possible nodes. The arpa branch of the Domain Name Space is growing really big
• 2nd octet level
Each of the 2nd octet level nodes branches out again to 256 nodes, each with the label name representing one of the 256 numbers of the
3rd octet.
• 3rd octet level
Each of the 3rd octet level nodes branches out again to 256 nodes, each with the label name representing one of the 256 numbers of the
4th octet. But this time those new nodes are "leaves" of the branch which means they are end nodes that don't branch out again. Like with
Domain Names, end nodes represent host computers.
• 4th octet Level
With the fourth octet, the IP Address is completed
root
arpa
IP Address
14.32.114.10
in-addr
14
Domain Name
10.114.32.14.in-addr.arpa
32
114
10
1st octet
2nd octet
3rd octet
4th octet
DNS - Domain Name System (2006-0411)
9 of 23
Delegate arpa zones
The folding of the 32bit IP Address into the inverted tree model works nicely, but who has the authority over which part of the arpa branch?
The handling of authority also works in a hierarchical fashion like in the Domain Name System. The difference here is that you don't delegate
the authority of a Domain Name Space, but the authority over a physical network which makes up the internet from the backbone all the way
down to the LAN in your office.
When you purchase an internet connection (i.e. T1 line), you will be assigned some numbers of the 32bit IP Address in form of an IP range:
124.12.4.1 to 124.12.4.64 This is called a fixed IP range (dynamic IPs are a different story)
The IP range is given to you by the provider who gave up (delegation) a portion of his IP range which he himself purchased from a bigger
provider.
Owning the Name and Number
You own actually two things:
• The Domain Name that you registered and received the authority for
• The IP Address that you leased from your Internet Provider
Now you can do your setup:
• Your name server has to setup the zone files
You assign your Domain Names and Subdomain Names to the IP Address that you leased from your provider
• But your name server has to setup an additional "special" zone file.
The one that stores the address-to-name mapping. That zone file should have a list with all the IP numbers you own with one (!)
assigned Host Name. Although name-to-address mapping allows multiple records (multiple names pointing to the same IP address),
address-to-name mapping allows only one record: Looking up one IP address must bring up one unique name.
Subnet Delegation
Traditionally, subnet delegations were intended to fall along subnet classes defined by the number of octets shared in common. Under this
system the smallest subnet that could be created was the class c subnet with 256 IP addresses of which 254 are usable. However as time has
passed and the demand on IP addresses has grown dramatically, it is no longer practical for providers to devote 256 addresses to customers
only intending to use six or seven.
Classless subnets are delegated in the reverse zone of the parent that is delegating. The key tools for the delegation are PTR records, NS
records and CNAME records. The NS records declares the existence of the subnet’s domain name servers. The PTR records attach canonical
names to reverse lookup addresses. CNAME records can be used to create aliases for simplification. The ways that these record types can be
used to generate classless subnets varies from the crude:
The ISP delegates each IP address as a class D subnet with one or more NS records for each IP address, The customer must create a zone for
each IP address, complete with its own SOA record, duplicates the NS records and a PTR record.
To the elegant:
The ISP doesn’t delegate at all, instead using one CNAME record for each reverse IP address in its reverse zone. For example:
9.0.168.192.in-addr.arpa. CNAME 9.example.com.
The 9 attached to Example.com is an arbitrary label, chosen in this case to match the last digit of the reverse IP address. The customer will
simply need a PTR record to resolve 9.example.com to an IP address.
DNS - Domain Name System (2006-0411)
10 of 23
Hardware
The previous chapter revealed the Zone as the actual element of the distributed database that is managed by the company with the authority
for that zone. Where is that zone stored:
Zone Data File
The Zone Data File is just a text file, containing all the information for that zone. That is:
• The Domain Names of all the nodes inside the zone
• The IP-Address mapping for all the Domain Names
• The delegation data for any branch of its Domain
• other data necessary for managing the zone
• The DNS specs describe the exact format and syntax of the “zone data file” or just “zone file”
Name Server
A “Name Server” or “DNS Server” is a host computer with the following tasks:
• It creates, manages and stores the zone file(s) for which it has the authority for
• Runs an application that answers queries about the information in its zone file: “What is the IP Address for the Domain Name
“apple.com?”
• Helps to find other name servers that stores a specific zone file
zone files
name servers
Domain Name Space
Domain Name System
distributed database
(root)
com
org
de
yahoo
apple
ftp
mail
store
hosts
One name server can store many different zone files when a company running that server owns many Domains.
One Zone file can be stored on many name servers for redundancy and load balancing.
DNS - Domain Name System (2006-0411)
11 of 23
Delegation thru referral
So we established that the database of the Domain Name System is "distributed", which means that the database is not stored in one place
as a whole, but elements of the database are spread over many many computers. All those elements combined together make up the
Domain Name Space
The elements of the database are called Zones
The zone includes all the Domain Names on the tree from the starting node of the Domain to the end node of a branch, or the node which
starts the Authority of another zone.
The data for the zones are stored in plain text files called Zone Data Files (or zone files)
The Zone Files are stored on computers called Name Servers
A name server must have the Authority to store that "element of the database" and answer with the information of that zone file to any
queries.
A name server gets the authority through Delegation. The Authority can be delegated in a hierarchical way from the top node (Root) down
the inverted DNS tree:
The Authority is delegated when the company who has the authority for its Domain (i.e. zone = com) enters the Sub-Domain(i.e. zone =
apple.com) in the zone file linking it with an NS record to the IP Address of the name server that stores the zone file for that new domain.
• ICANN has the main Authority of the DNS system, the top of the inverted tree, called the Root Domain. This is the Domain Name
with the "null label".
• ICANN now, as the top authority, delegates the authority for the nodes below. These are called the Top Level Domains. Some of those
are: com. and org. and net.
• This is how it works:
ICANN runs a name server (the Root Name Server) that stores the zone file for the root domain.
• It has the authority for that root zone (root domain).
• Now it delegates the authority of com org net (and others) to the company NSI. The mechanism for that is very easy: The zone file on the
root domain name server has a entry (NS record) that tells the following information to anybody who asks for information about that
domain
"I have delegated the authority for the zone (Domain Name) ".com" . Any further information for that
Domain is found on the name server with the following IP Address …."
label
Domain Name
zone file
Server
name server 126.32.51.124
authoritative for zone: root
.
zone file : (root)
com NS 126.32.51.124
name server 126.32.51.124
authoritative for zone: com.
com
apple
www
.
. com .
. apple . com .
zone file : com.
apple.com NS 22.6.123.3
name server 22.6.123.3
authoritative for zone: apple.com
zone file : apple.com.
www.apple.com. A 224.3.25.4
web server 224.3.25.4
www.apple.com
DNS - Domain Name System (2006-0411)
12 of 23
Registration
Registry:
This is an organization, responsible for maintaining the zone file for a TLD. There is only one registry for any TLD. For the Domain
com, net and org this is NSI (Network Solutions Inc)
Registrar:
This is the middle man (i.e. GoDaddy) between the registry and the the customer. They provide the registration for the customer
and submit the data to the registry.
Registration:
This is the process of registering a Domain Name in the registry with the help of a registrar.
Domain Name Registration
Registry
query: store.apple.com?
zone file: com
referral: apple.com = 123.14.96.2
apple.com NS 123.14.96.2
registrar submits domain name
apple.com
Registrar
Domain Name: apple.com
Name Server: 123.14.96.2
Delegation:
apple.com
customer requests domain name
apple.com
Customer
zone file: apple.com
ns.apple.com A 123.14.96.2
store.apple.com A 123.14.96.4
query: store.apple.com?
response: store.apple.com = 123.14.96.4
• The company Apple wants to own the Domain "apple.com".
• It contacts a registrar, finds that the name is available and submits all the required information together with the submission fee to the
registrar. The main information is the IP Address of the Name Server(s) where the Customer will store the zone file of the new apple.com
domain.
• The registrar takes the customers information and submits it to the registry of the .com domain, in this case Network Solutions Inc (NSI)
that manages the zone file for the .com Domain.
• The registry now delegates the apple.com domain to the company Apple by adding the delegation information into the .com zone file
apple.com
NS 123.14.96.2
"Any request coming in, looking for information about the domain "apple.com", please go to the name server with the IP address
123.14.96.2 that manages the zone file for the domain apple.com and therefor might have the requested information."
From now on, any name server requesting host information about the domain "apple.com" will be referred to the Apple's name serve
DNS - Domain Name System (2006-0411)
13 of 23
Name Server (DNS Server)
A Name Server is a computer running a name server application (like BIND). It acts as a building block of the whole distributed database for
the DNS. It becomes a part of the the Domain Space.
The name server does 2 main things: Store Zone Files - Resolve Queries
Name Server tasks
1) Store Zone Files
A name server stores information for the zone it is authoritative for:
The BIND config file lists all zones (Domain Names) it is authoritative for. (/private/etc/namec.conf)
The detailed data for each zone is stored in individual "zone data files" or "zone files" (/private/var/named/)
The DNS specs define two main types of name servers:
• Master Name Server (type master): reads the data for its authoritative zone from the zone file which it stores in his "/
private/var/named" location
• Slave Name Server (type slave): retrieves the zone data from another name server that is authoritative for that zone (mostly
a master name server, but it could also be a slave name server). This procedure is called "zone transfer"
Both the master and slave name server are authoritative for their zone.
The Name Server can act as a "Master" or "Slave" for any zone it is authoritative for. Please note that this is a functionality for a
zone and not a functionality for the name server as a machine itself. That means that a name server can act as a "Master" name
server for one set of zones and as a "Slave" name server for another set of zones.
The term "Primary" or "Secondary" name server in the DNS specs is more used in the sense that you have to have more than one
name server setup for any given zone. It doesn't matter which one you call Primary or Secondary. All name server (type master or
type slave) are equally authoritative for a zone once they are assigned name server for a zone. There is no priority
2) Resolves Queries
A name server answer question about Domain Names it is authoritative and helps to find Domain Name that it is not authoritative.
Name servers in the whole Domain Name Space store zone files which are the actual segments of the DNS distributed database.
Those zone files represent the part of the database the name server is authoritative for.
Storing that information on name servers was the first part. The second part is finding the name server that stores the zone file
with the information for a specific <Domain Name - IP Address> answer.
The basic query architecture works like a "Client <> Server" model. A Client queries a Server which replies to the Client. There are
two basic scenarios:
• Resolver <> Name Server: This is the start of any query where a host computer tries to access a Server (web server, ftp server, afp
server, etc) using a domain name. The application (web browser, ftp client, etc) however needs the IP Address to send out the request
to find the machine that hosts the web server or ftp server. So the application has to ask the "Resolver", a set of Library routines
linked into the application, to resolve the Domain Name first. The resolver (acting as a client itslef) sends out a query to its name
server (acting as a server). The IP Address of the name server haas to be entered in the host computers Network settings. Note that
the entry for the Name Server has to be entered as an IP Address, so the Resolver can find the name server directly by its number.
Entering a Domain Name would require to resolve the name servers domain name in order to resolve another domain name.
• Name Server <> Name Server: A query for a name server can actually come from another name server. This is the case when a
name server can't find the answer for a resolver query. It has to go out and ask another "colleague" in the Domain Space.
DNS - Domain Name System (2006-0411)
14 of 23
Type of name server
Master - Slave
The terms "Primary Name Server" and "Secondary Name Server" are defined in the DNS specs, but the actual functionality depends on the
"type" settings in the BIND config file for
• Both name servers (master or slave) have equal authority for the the zone
BIND named.conf
• Querying one or the other should result in the same answer
• The idea behind it is load balancing and especially redundancy. Therefore both name servers
should not be on the same subnet (or physical location)
• Two name servers is the minimum requirement, but you can setup as many name servers as
you want.
• The term Primary and Secondary says nothing about the actual functionality of the server. This
is defined in the BIND "named.conf" file
• The "named.conf" file defines what type of name server it is for any given zone. This is
important!
• You can't setup a computer to be a Master Name Server or Slave Name Server. It can be either
or, or both at the same time. The named.conf file tells the name server wether it acts as a
master or a slave name server on a per-zone basis!
Retrieving the zone file
The main difference between a Master and a Slave name server is where it gets its zone data.
• The Master name server loads the zone data from the zone file, that it stored locally in the "/var/named/" directory
• The Slave name server loads the zone data over the network from another name server
• The Slave name server can load the zone data from a Master name server or another Slave name server
• The process of loading zone data from one name server into another is called Zone Transfer
Setting up a Slave Name Server for a zone:
• You define the type of the name server for a specific zone in the BIND config file.
• the entry in the config file makes the computer a Slave for that zone.
• The config file lists the IP Address of the Primary Name Server(s) from where it transfers the zone data
• The Slave Name Server reads the master zone file when it starts up ("transfers") the data from the master server
• It creates a backup file containing the Serial Number from the zone's SOA record
• Whenever the name server (containing "slave type" zone entries) gets
restarted, it will load the backup files first and checks only the serial number of
the master zone file on the Master Name Server to determine if the backup file
is still valid
OSX Server Admin - DNS
• Also, whenever the zone file on the master name server gets updated and the
serial number get changed, it informs the slave name server to update the
zone file (sends a NOTIFY message)
• You can deactivate the "Zone transfer" on the name server for security
reasons, so the name server will not answer to any transfer requests.
The actual NS record in the zone file lists all the name servers for that zone. That means:
• You can query any of those name servers to get the answer for that zone (Domain)
• Because these are the name servers who have the authority for that zone (Domain Name)
• To have authority means they store (or retrieve) the zone data file with all the records for that zone (host names, mail exchange info,
etc)
• All NS records in the zone file are therefore equal and there is no indication wether it is a master or slave name server, it doesn't
matter for the lookup process as long the master and slave name server are in sync.
$TTL 86400
epezote.com.
SOA
ns1.sonicimages.com. admin.epezote.com.
2006010810; serial
3h
; refresh
1h
; retry
1w
; expiry
1h
) ; minimum
epezote.com.
IN
NS
ns1.epezote.com.
epezote.com.
IN
NS
ns2.epezote.com.
epezote.com.
IN
NS
ns3.epezote.com.
epezote.com.
IN
A
65.19.33.15
www.epezote.com.
IN
A
65.19.33.14
(
DNS - Domain Name System (2006-0411)
15 of 23
Resolver
A Resolver is the client on the host machine that accesses the name server to ask for the IP address of a Domain Name.
A Resolver is a set of Library routines linked into the application that need its service, like web browser, ftp client, etc.
It handles the following commands:
• Querying a name server (the one entered in the Network setting in the "DNS Server")
• Interpreting responses (a returned resource record or an error)
• Return the information to the program that requested it. (web browser, ftp client, etc)
There are two kinds of Resolvers:
Stub Resolver
The DNS specs call a Stub Resolver one that can do only limited tasks like sending a query and receiving it. It can not do a follow-up of a
referral from a name server. The name server that the resolver queries has to do the whole "investigation" and come up with the final answer
before it returns the query to the resolver. This is called "recursive query" where the whole burden lies on the name server it queries.
Smart Resolver
A smarter Resolver can perform follow-ups if necessary and also can cache responses. If a previously requested query comes again from an
application, then the resolver can use the cache data and doesn't have to request the query again from the name server
The Resolver has its own config file "/private/var/run/resolv.conf' that stores the IP Address of the DSN Server entered into the "System
Preferences/Network/" settings.
Resolvers cache most recent lookups. To flush the cache use the Terminal command
lookupd -flushcache
Even application like webbrowser can cache lookups they received from the Resolver which could make troubleshooting DNS issues very
difficult.
DNS - Domain Name System (2006-0411)
16 of 23
Resolution
Resolution or "Name Resolution" is the process of searching the Domain Name Space and finding data for a given Domain Name, most likely
its IP Address.
Who to ask? Name Server
Name Servers store the bits of information of the Domain Name Space which makes up the distributed database for all existing Domain
Names. If a resolver queries a name server, it can provide the answer from three different sources.
• The name server has the authority for the domain name it was queried. Therefore it can pull the data from the zone file and sends
back the answer
• The name server doesn't have the authority for the domain it was queried but it has it looked up before and stored it in its cache. It
reads the answer from its cache and send it back to the resolver.
• The name server doesn't have the authority for the domain it was queried and no answers are in the cache. It starts a query of its
own. How it performs the search depends on the query type
Query Types
There are two types of queries how a client (resolver or name server) can query a server (name server)
Recursive Query
The Client asks the name server for the data of a zone and tells him:
"If you don't have the answer right away, go out and try to find a name server who can further assist me"
That starts the following sequence to resolve the Domain Name starting from right to left (down the inverse Domain Name tree). Lets use the
following Domain Name: web.google.co.uk
• The resolver asks his main name server for "web.google.co.uk", but it doesn't have the authority for
that zone nor does it have the answer stored in cache from a previous lookup.
• This will tell the name server to begin the recursive query process starting at the top of the
Domain Name Space, the Root Domain Name Server
(root)
uk NS = 53.3.56.2
• The main name server asks the root name server for a name
server that has the authority for the Top Level Domain uk
• The root name server reports back with a referral,
which is a list of all (!) name servers with the authority
for the Top Level Domain uk
uk.
Main Name Server
co.uk NS = 85.3.6.41
• The main name server picks one name server from the
list (based on an intelligent process) and sends the same
query to that name server.
• The name server for the uk zone report back with a list of all
name servers with the authority for the Second Level Domain
co.uk
• The main name server picks one name server from the list and
sends the same query to that name server.
• The name server for the co.uk zone report back with a list of all
name servers with the authority for the Third Level Domain
google.co.uk
co.uk.
Resolver
google.co.uk NS = 85.3.6.41
google.co.uk.
web.google.co.uk = 65.231.2.24
• The main name server picks one name server from the list and
sends the same query to that name server.
• The name server for the google.co.uk zone has finally the authority and reports back with the requested IP Address for the host
web.google.co.uk
This recursive query type puts the load on the client (in the previous example the main name server that got the query from the resolver)
who only gets one referral at a time and then has to go out and query the next name server and so on until he finds the name server who is
authoritative for the domain name and gets the data from it. This is the default query for name servers which do not only manage the data
for the zones they are authoritative but do the whole search procedure for queried domain names they are not authoritative for.
Iterative Query
The Client asks the name server for the data of a zone and tells him:
If you don't have the answer right away, go out and try to find it and don't report back until you found the answer"
This iterative query type puts the load on the server who has to do the whole investigation while the client sits and waits for the server to
come back with the final answer.
• This is the default query type of a stub resolver that doesn't have the intelligence to follow-up referrals
• You can also change the default recursive query type of a name server to iterative by using the "Forwarding" option
DNS - Domain Name System (2006-0411)
17 of 23
Forwarder
These techniques are especially used with firewall and other security measures.
Forward Server
By default, the name server uses the recursive query when it acts as a client and queries another name server. You can change this behavior
to iterative query with an option in the named.conf file.
options {
forwarders { 192.249.249.1;
192.249.249.3; } ;
};
Now all the queries made to that "forwarding name server" will be forwarded to the specified name servers, which will do the recursive query
and respond back to the "forwarder name server" which will then respond back to the resolver
recursive
Resolver
iterative
Name
Server
iterative
Forwarder
Name
Server
Name
Server
Name
Server
Name
Server
Here is the sequence of events:
• Any queries for cached or authoritative data on the forwarding name server are answered to the resolver right away
• If the requested data are not cached or authoritative then it makes a iterative query to the name server listed in the config file and
waits for a short period of time for the result. Repeating the IP Address in the config file initiates repeated requests.
• If the contacted name servers won't return an answer in some specified time, then the forwarding name server switches back to
recursive query and tries to resolve the name in the usual way by its own
• Adding the line "forward only" in the config file will prohibit the "recursive fall back query". This forces the forwarding name server to
contact only the servers listed in the config file.
Forward Zone
This feature enables you to apply the forwarding behavior not for the whole name server, but for individual zones. This is done by changing
the "zone type" for that specific zone to "forward". Note that the server has no authority for that zone (like for a type master or slave), it is
just an instruction if a request for that zone comes in.
With this tool you can setup a forwarding zone for a domain name that you want to resolved by a specific name server and not wait what
comes back from the usual "top to bottom" recursive query.
authoritative zone
authoritative zone
non-authoritative zone
zone "apple.com"
type master;
file "apple.com.zone";
zone "apple.com"
type slave;
masters {192.12.3.4);
zone "apple.com"
type forward;
forwarders { 138.52.3.20}
You can use a trick by assigning a forwarder on the server level and also for a specific zone without entering any IP Addresses inside the
brackets of that zone. This will enable the general forwarding for all incoming requests using the defined IP Addresses except for that specific
zone. The effect of not assigning any IP Addresses for that forward means is that it uses recursive query right away, circumventing the server
level forwarding.
DNS - Domain Name System (2006-0411)
18 of 23
Cache
The recursive query process creates a lot of traffic and and puts a lot of loads on all the name servers. One procedure called "caching" can
dramatically reduces that:
Whenever a name server A queries another name server B for a domain name and receives an answer, it will actually "learn" or "memorize"
that information by putting it into a so called "cache". The next time the name server A receives a query for that same information, it looks in
its cache first to see if the data is already there from a previous lookup. If that data is found in the cache, then the name server will respond
back to the querier with that data and it doesn't have to bother another name server again.
As you can see in the graphics before, the name server issuing a recursive query gets the information (referral) for all name servers in the
sequence of the labels of the domain name
website.google.co.uk
When the name server gets later a request for "store.apple.co.uk". it doesn't have to start the recursive query process from the top with the
root name server. It has the IP address of the authoritative name server for the zone "co.uk" still in the cache and can start the search from
there.
(root)
Main Name Server
uk NS = 53.3.56.2
cache:
uk NS = 53.3.56.2
co.uk NS = 85.3.6.41
google.co.uk NS = 85.3.6.41
Query:
store.apple.co.uk
uk.
not
needed
co.uk NS = 85.3.6.41
co.uk.
Resolver
apple.co.uk NS = 85.3.6.41
apple.co.uk.
store.apple.co.uk = 65.231.2.24
Time-To-Live
Every time a name server receives zone data from an authoritative name server, the data will come with a special note called "Time-To-Live"
or TTL. This information tells the querier:
"Here is the data you requested, but keep it in your cache not longer than the following
amount of time: nnn" (i.e. TTL=24h)
The note also includes the "negative caching" instruction:
"I'm sorry, the data you requested is not valid in my zone file. (Maybe you misspelled
it, or the data hasn't been setup yet. Please wait for the following amount of time
before you ask me again about the same data (i.e. TTL=1h). Maybe the IT guy will
update the zone file later and the requested data might be available then."
Everybody caches in:
Not only name servers can cache zone data. Resolvers also cache most recent lookups. Even application like webbrowser can cache lookups
they received from the Resolver which could make troubleshooting DNS issues very difficult.
To flush the resolver cache use the Terminal command
lookupd -flushcache
DNS - Domain Name System (2006-0411)
19 of 23
Setup
The following steps are involved to run a name server on a host machine
1.
Run a name server application like BIND (Berkeley Internet Name Daemon)
2.
Configure the named.con file to read the zone files
3.
Create the zone data files:
• One zone file for each domain name it has the authority for
• A zone file for the local host (Loopback) to direct traffic to themselves 127.0.01
• A reverse lookup zone file for the network
• A hint file (lookup for the root name server)
• One zone file for each forwarding zone (optional)
query
response
Name Server
BIND.app
named.conf
zone
data file
zone
data file
zone
data file
zone
data file
DNS - Domain Name System (2006-0411)
20 of 23
Config File: “named.conf”
• The BIND config file "named.conf" is stored in the "private/etc/" directory.
• It stores the instruction for the BIND application how to read the zone data files plus additional instructions how to function as a name
server
• There is only one option statement with all the options included under that statement (i.e. directory of the zone data files)
• Each zone data file has a one line statement
• semicolon (;) ends a configuration statement
• Round brackets {} allow single line statements to extend over multiple lines
• BIND allows three kinds of comments:
/* This is a C-style comment */
// This is C++-style comment
# This is a shell-style comment
The named.conf file lists all the zone files the name server has information about.
The zone statement includes:
• zone name
options {
directory "/var/named";
recursion true;
};
• zone type
• file name
• additional information
Zone types
There are different types of zone records, depending how they respond to DNS request
and how they acquire the zone data:
Authoritative Zone Files: are the zone files you create for the Domain Names that the
name server has authority for.
zone "." IN {
type hint;
file "named.ca";
};
zone "localhost" IN {
type master;
file "localhost.zone";
allow-update { none; };
};
zone "0.0.127.in-addr.arpa" IN {
type master;
file "named.local";
};
• Master Zone:
• has the master of the zone records
• Provides authoritative answers to lookup requests
• Slave Zone
• answer to lookup requests like masters
• transfer copies from the master zone. A configurable refresh interval defines
how often it checks for updated master zones
Non-authoritative Zone Files: Those data files contain only references but no
authoritative data
• Forward Zones
• provide DNS service to a private network behind a firewall
• cache responses to the queries that they pass on (BIND p266)
• Hint Zone
• A special zone that points to the zone file with the list of root name servers,
also called root hints
zone "apple.com." in {
file "apple.com.zone";
type master;
};
zone "oranges.com." IN {
file "oranges.com.bak";
type slave;
masters {65.119.3.11};
};
zone "lemon.com"
type forward;
forwarders { 138.52.3.20}
DNS - Domain Name System (2006-0411)
21 of 23
Zone File
The data and format of the zone data files is described in the DNS specification. The named.conf lists the location of the files, which is usually
"/var/named/ directory":
Rules - Syntax
• Most entries in the zone data files are recourse records
• Entries are case-insensitive
• Resource records must start in the first column of a line
• The order of resource records is recommended by the DNS specs but not mandatory.
• SOA record
• NS record
• A record
• PTR record
• CNAME
• Blank lines are ignored
• Lines starting with a semicolon are ignored (comment line)
• Records are formated in the following way:
Name
apple.com Class
Type
Data
IN
A
155.2.35.6
• The Class stands for Internet. There are other classes but not in widespread use.
Resource Records
TTL (caching)
The $TTL statement at the beginning of the zone file specifies the time to live for all records in the file that follows the statement and don't
have an explicit TTL. If the name server responds to a query with the data from the zone file it will also tell the querier how long it can cache
the data. The .com name servers usually caches data for 48h.
SOA Record
This is the first record in a zone file. It tells the server to be authoritative for that zone.
An SOA record or start of authority record specifies the
• The DNS server providing authoritative information about that zone (domain name): "This is the best information for the data within the
zone". There can be only one SOA record
• The email of the domain administrator, using a dot instead of the @ sign
• the domain serial number, and several timers relating to refreshing the zone, mainly used by the slave name server
The parenthesis allow the SOA record to span more then one line for better visualization
apple.com.
IN
SOA
ns1.apple.com. postmaster.apple.com. {
1
; Serial
3h
; Refresh after 3h
1h
; Retry after 1 hour
1w
; Expire after 1 week
1h }
; Negative caching TTL of 1 day
• Serial: the zone serial number, increments automatically or you have to set it manually every time you modify the zone file. The
name server application (BIND) notifies the slave name server(s) when the serial number changes, so it can transfer the new data.
Also when a slave name server gets restarted, it compares this serial number with the serial number of its backup zone file, to see if it
has the most updated data.
• Refresh: tells the slave name server in what time intervals it should check this file for updates
• Retry: the time the slave name server should wait before trying to request an update in case the master server is not responsive. Of
course this data has to be transfered once to the slave name server to know how to react in case of "no-connection to the master
name server"
• Expire: if a slave name server cannot reach the master name server for that specified amount of time, then it stops responding with
its backup zone file ("better respond with no data then with the wrong data")
• Minimum: used for negative caching. If a query for the current zone doesn't have any positive answers (i.e. the host name doesn't
exist), then the time interval tells the querier how long it can/should store the negative result in its cache before asking again.
NS Record
This lists all name servers (master and slave) that have authority for that zone
DNS - Domain Name System (2006-0411)
22 of 23
apple.com.
apple.com.
apple.com.
IN NS
IN NS
IN NS
ns1.apple.com.
ns2.apple.com.
ns3.apple.com.
Domain Delegation:
To delegate a subdomain (marketing.apple.com) you have to assign the domain "marketing.apple.com" to a name server that is authoritative
for that new zone. That delegation NS record often lists also the IP address of that name server to avoid having to lookup the name server IP
Address in order to look-up the IP address listed in the name server. That record is called a glue record. It glues the Domain Name of the
new authoritative Name Server with its IP Address (provided by A record) together so any queries for that name server don’t have to resolve
its IP address.
store.apple.com.
IN NS
marketing.apple.com.IN NS
ns3.apple.com..
132.54.3.66
A Record
The A record (Address Record) maps a domain name to the 32bit IPv4 IP Address. It is also called "Host Addres" because it maps a Domain
Name to a host (a computer) with a specific IP Address.
store.apple.com.
mail.apple.com.
ftp.apple.com.
IN A
IN A
IN A
123.44.55.1
123.44.55.2
123.44.55.3
CNAME Record
A CNAME (Canonical Name) maps an alias to its canonical name (real name). The aliased domain gets all the subdomains and DNS records of
the original.
Aliases should never appear in the data portion of a resource record (right side)
store1.apple.com.
mail2.apple.com.
ftp2.apple.com.
IN CNAME
IN CNAME
IN CNAME
store.apple.com.
mail.apple.com.
ftp.apple.com.
MX Record
An MX record or mail exchange record maps a domain name to a list of mail exchange servers for that domain.
An MX record or Mail exchange record is a type of resource record in the Domain Name System (DNS) specifying how Internet e-mail
should be routed. MX records point to the servers to send an email to, and which ones it should be sent to first, by priority.
When an e-mail message is sent through the Internet, the sending mail transfer agent makes a DNS query requesting the MX record for
the recipient's domain name, which is the portion of the e-mail address following the "@". This query returns a list of host names of mail
exchange servers accepting incoming mail for that domain, together with a preference number. The sending agent then attempts to
establish an SMTP connection to one of these servers, starting with the one with the smallest preference number, delivering the message
to the first server with which a connection can be made. If no MX records were present, a second request is made for the A record of the
domain instead.
The MX mechanism provides the ability to run multiple mail servers for a single domain and the order in which they should be tried,
increasing the likelihood that mail may be delivered and providing the ability to distribute the processing of incoming mail across multiple
physical servers.
PTR Record
A PTR record or pointer record maps an IPv4 address to the canonical name for that host.
Setting up a PTR record for a hostname in the in-addr.arpa domain that corresponds to an IP address implements reverse DNS lookup for that
address.
IP Addresses should always point to only one canonical name
Abbreviations
• Appending:
The second field of a zone statement specifies the Domain Name. This Domain Name is the Origin of all data in the zone file. The
Origin is appended to all names not ending in a trailing dot.
An "unqualified Domain Name" is a Domain Name not ending in a trailing. The Origin will automatically appended
A "fully qualified Domain Name" (FQDN) is a Domain Name anding with a trailing dot, that represents the "null label" of the root
domain
• @
If the Domain Name is the same as the Origin, then the name can be specified as the sign @
• Repeat last line
If the <name> of the resource record (the first column) repeats in multiple lines (multiple records), then you can omit it by typing
space or tap
DNS - Domain Name System (2006-0411)
23 of 23
OS X ServerAdmin
BIND - ServerAdmin
The diagram below shows the interaction between BIND and OSX ServerAdmin's DNS service:
DNS Server
Configuration
DNS
Request
(on port 53)
DNS application
(BIND)
ServerAdmin
start / stop DNS
load zone files
• at start up
• at ServerAdmin “save”
load config files
• at start up
• at ServerAdmin “save”
Re-Start forces
the DNS app to
reload the config
and zone files
“save” config file + reload DNS
/private/etc/named.config
config file
list of all zones
Refresh Server Admin
config file
contains list
of all zone
files
/private//var/named/”ZoneName.zone”
zone file A
BBEdit
Reload DNS app with
ServerAdmin “stop/start”
after editing text files
“save” zone files + reload DNS
zone file C
Zone B
Zone C
Refresh Server Admin
zone file E
Refresh
Zone A
zone file B
zone file D
Save
Zone D
Zone E