Traditional DNS Howto

8/2/2019 Traditional DNS Howto

1/11

Traditional DNS Howto

Linux system administrators should learn traditional DNS. Front-ends and quick templates to setup domain

records have a place in managing sites. When confronted with DNS configurations already in existence, nothing

can substitute for knowing and using the fundamentals.

The vast majority of users on the Internet have no clue about DNS. They may have seen the term when they set up

their ISP connection, but they do not realize its connection to their lives. Simply put, DNS servers allow you to

use friendly names in your browser, email or other Internet applications to perform tasks which require IP

addresses.

The Internet uses TCP/IP protocol to send and receive everything on the Internet. When you typeGoogle.comin

your browser to do a search, you use DNS. Otherwise, you would have to use this numeric

value:64.233.187.99. Click on each one and see what you get.

You see Google.com is an name in a database that your browser consults to find the IP address of the Google web

site. But that's transparent to the user. How would you like to keep a notebook of IP addresses to manually look

up and find web sites you wish to visit? Well, the Domain Name System does that for you automatically.

If you're sitting there reading this and going, "Oh yeah, I already know about that", then hold on a minute or two.

Working with DNS requires considerable knowledge and discipline. The system administrators I know can do

many tasks, yet few can handle DNS. Almost without exception, they get lost because they don't understand thefundamentals.

The Domain Name System of the Internet makes up the largest distributed database on the planet and it's quite

ingenious. In theory, it has no flaws. In practice, people kludge it up all the time. People make DNS entries in

their part of the database that aren't formatted correctly or have inherent deficiencies which result in errors.

Internet surveys of DNS records have shown incidents of errors as high as 72%. We know the majority of those

errors come from lame delegations. Lame delegations include domains registered with DNS servers assigned to

them when no one is actually hosting the domain. Other causes include the failure to provide zone files, errors in

resource records, expired domain registrations.

If you attempt to learn DNS jargon, you will find that it is not intuitive. At first it just doesn't make sense. In many

ways, the jargon reminds me of a foreign language. You just have to work with it for a period of time before it

makes sense.

Linux uses BIND to perform DNS functions. Rather than attempt to use another program, system administrators

should start with BIND because it runs almost all the DNS servers in the world. I'm not going to offer a historylesson on BIND because this subject will put you to sleep anyway.

So, if you want to go forth and learn all about BIND please do. It won't help you do much DNS with one

exception. Some people still use BIND version 4. You want to upgrade from BIND 4 to BIND 8 or 9. It's just my

luck that you'll go out to create DNS configuration files and they won't make any sense. That's because a lot of

people still run BIND 4.

Tell Me About Configuration Files

BIND comes with three components. The first components we called namedor name-dee. It's a daemon that runs

the server side of DNS. That will make sense in a little while.

The second component of BIND we call the resolver library. People think of a resolver as the client side of BIND.

The resolver code makes queries of DNS servers in an attempt to translate a friendly name to an IP address. This

component uses the resolv.conf file. Does that sound like a UNIX abbreviation. It should because it is.

The third component of BIND provides tools for testing you DNS server. We call them tools but they are really aset of command line utilities like dig. Go to your console and type dig yahoo.com and see what happens. We will

look at this later.

What's My Responsibility In The DNS System?

As stated earlier, DNS is a distributed data base. When you pay a fee to register a domain one of the questions you

answer deals with your Name Servers. You have to list two and they have to be registered in the DNS system.

The domain name system database has three levels. The first group of servers we call "root" servers. The second

we call Top Level Domains or (TLDs). When your resolver needs to find the address for a web site, it makes a
http://google.com/http://google.com/http://google.com/http://64.233.187.99/http://64.233.187.99/http://64.233.187.99/http://64.233.187.99/http://google.com/


2/11

query.

Let's say you want to find Google.com. Your resolver asks the Root servers to identify Google.com's IP. The Root

server replies, I don't know but I do now where you can find the answer. Start with the TLD servers for COM.

So, Root sends your query to a COM server. It says, OK. I don't have that information but I know a Name Server

that does. It has an address of64.233.167.99 and the

namens1.google.com. So, go to that address and it

will tell you the web site address ofgoogle.comYour resolver takes the information

from ns1.google.com and returns with an IP address.

If Google's name server gave your resolver the

correct name, you'll get a web page.

The path traveled looks like Figure 1.

Figure 1 - From Root to your Domain.

In the upper left of Figure 1, we have depicted a set of servers with the annotation of Root. In the jargon of DNS,

these servers represent the beginning of the DNS path. You will see them represented by a period or dot ("."). In

your configuration files, your IP address to name mapping will end with a period. When we look at some of those

files in a few minutes this will become clearer.

The Root servers are the top of the distributed DNS database. They have information about the Top Level

Domains(TLDs). TLDs include com, net, org, mil, gov, edu, etc. When you contract to use a domain name, you

chose which TLD you want. In my case, I have a domain in the org name space called centralsoft.org.

When I registered my name servers, I gave the name ofserver1.centralsoft.org and ns0.centralsoft.org to my

registration agent. In the TLD servers for org, you will find my name servers. The org servers know where you

should find information on centralsoft.

When I registered, I told the agent that I would take responsibility for maintaining a database of IP addresses and

friendly names and map them to one another. So, we made an agreement and the Domain Name System said,

"OK, now you have authority for the data on centralsoft.org. When someone wants to find the services you offer

on the Internet, we will point them to you."

So, now I have to run an application which can answer your queries and say, "sure if you want to see my web

page or send mail to one of my users, you can find them here. If you ask me for a name, I'll give you an IP address

because I know you have this protocol which uses TCP/IP and I realize you need the address, even when you

specify a name".

How Do I Answer These Queries Now? Page 2

That's where BIND comes into play. The people who maintain the BIND codemake sure it meets the specifications of the Internet Engineering Task Force and will

run on your server. All you have to do is learn how it does what it does.

Named lives on a domain name server and answers queries from resolvers. Theapplication reads its data from a configuration file called named.conf.

named.confgets its information from something we call zone files.Severalzone files exist, but onezone file in particular keeps a database of recordsthat supply named with most of its answers.In Figure 2, namedhad received a query. It looks to its

configuration file named.conf, which looks to the primary zone file and hands off

the information requested to the resolver from the outside.

Figure 2 - Answering a query

Some people refer to configuration files as rule files. BIND's configuration files seem like rule files to me. The rules

of Domain Name Services require tight compliance. Making and resolving queries follow strict protocols on the

Internet as does the interprocess communication within BIND.


3/11

Figure 3 - named.conf

Using Named.conf

Let's refer to Figure 2 again and look at the

process. You should have BIND installed andrunning on your server. If not, we will address

installation and configuration in one of the next

sections.

The namedprocess listens on port 53 of a Linux system. When it

receives a query for an address, it looks to the first configuration file

about which it knows: named.conf.

The following table depicts a simplenamed.conffile. If you have seen a file like this and didn't understand it, then

let's break it down into its components. Once we do that, we can take the mystery out of it.

options {

pid-file "/var/run/bind/run/named.pid";

directory "/etc/bind";

// query-source address * port 53; };

//

// a master nameserver config

//

zone "." {

type hint;

file "db.root";

};

zone "0.0.127.in-addr.arpa" {

type master;

file "db.local";

};


type master;

file "pri.158.253.70.in-addr.arpa";};

zone "centralsoft.org" {

type master;

file "pri.centralsoft.org";};

This file refers to the four other configuration files. The third line down lists the directory containing them

all,/etc/bindwhere they exist.

Theoptionsstatement defines the default directory for named and the location of the process ID (pid)

file.named.pidrepresents the daemon itself. If you followed any of the Perfect Setup Tutorials, we put it in a

chrooted environment.

Thezonestatement identifies the location of the hints, localhost, zone and reverse zonefiles.

Hints file

This file contains the names and addresses of the root servers on the Internet. These know where the authoritative

servers for your domain exist - the first one being the Top Level Domain (com, net, org, etc.) and next being the

authoritative server for your domain.

Local host file

Name servers are the masters of their own loopback domain (127.0.0.1). The point of creating local zone files for

each aspect of your of localhost is to reduce traffic and allow the same software to work on your system as it does

on the network.


4/11

Zone file

This file, also called the domain database, defines most of the information needed to resolve queries about the

domain you administer. It maps names to IP addresses and provides information about the services offered by

your Internet computer including your web and ftp server, email, telnet, name servers, etc.

The zone file uses several record types including the SOA or start of authority; NS or name server; A or hostname to address map; PTR or pointer which maps addresses to names; MX or mail exchanger which identifies the

mail servers in the domain; and CNAME or canonical name which defines an alias for a host name.

Don't try to memorize or understand what these record

types mean at this point. Just realize that they exist and

you will have ample opportunity to use them.

Figure 4 - Zone filesReverse zone file

Another way to talk about zone files is to define them something that l inks all the IP addresses in your domain to

their corresponding server. The reverse zone file maps IP addresses to host files. It's a mirror image of the

database file above. You can recognize a reverse zone file because it has the extension of in-addr.arpa.

The Primary Zone File Page 3

Now let's look at the zone file for the centralsoft domain:pri.centralsoft.org:

@ IN SOA server1.centralsoft.org. root.localhost. (

2006012103; serial

28800; refresh, seconds

7200; retry, seconds

604800; expire, seconds

86400 ); minimum, seconds

;

NS server1.centralsoft.org.;

NS ns0.centralsoft.org. ;

;

MX 10 server1.centralsoft.org.;

;

centralsoft.org. A 70.253.158.42

www A 70.253.158.42

server1 A 70.253.158.42

ns0 A 70.253.158.45

SOA refers to "Start of Authority". When you look at Figure 1, remember that DNS distributes its database. By the

time you enter the picture, the system has handed off authority for part of the entire database to you. So, your zone

file has to indicate where your authority starts. Your authority starts in your zone file. Your Top Level Domain

servers are waiting for you to do your part of the job.

The data field of the SOA record contains several components or fields. You need to provide data or answers in the

record which will allow another server on the Internet to satisfy its query. Think of the data field as a computer

RECORD which has several fields.

They include:


5/11

NameThe root name of the zone. The "@" sign is a shorthand reference to the current origin (zone) in the /etc/named.conf

file for that particular database file. The host name of the master server for this zone is server1.centralsoft.org.

Don't worry if this jargon doesn't make sense. If just means that back in the named.conf configuration file an entry

points to this file and this fi le points back to the entry in the configuration file.

ClassA number of different DNS classes exist. For our purposes we will use the IN or Internet class used when defining IP

address mapping information for BIND. The other classes exist for non Internet protocols and functions.

TypeThe type of DNS resource record. In the example, this is an SOA resource record.

Name-serverFully qualified name of your primary name server. Must be followed by a period.

Email-addressThis is the email address of the person responsible for the domain. Notice that instead of an @ sign, the address

uses a period and is followed by a period. In this case, the email address is the root user or root.loalhost. In other

applications the email address would be root@localhost.

Serial-noA serial number for the current configuration is usually in a date format YYYYMMDD with an incremented double

digit number tagged to the end. This allows you to do multiple edits each day with a serial number that both

increments and reflects the date on which the change was made. It's a numeric value that the slave server can use to

check whether the zone file has been updated. The slave periodically checks the serial number to see if it has

changed. If it has, the slave will perform a zone transfer. 2006012103 is the serial number in the zone file above.

RefreshThis field tells a slave DNS server how often it should check the master. This field represents a length in seconds.

Every refresh cycle, the slave server checks to see whether it needs to perform a zone transfer. In this file we use

28800 as the value.

RetryThis field tells the slave how often it should try to connect to the master in the event of a connection failure. The

interval in our example is 7200.

ExpiryTotal amount of time a slave should retry to contact the master before expiring the data it contains. Future

references will be directed towards the root servers. This is the expiration time, the length of time that the slave

server should continue to respond to queries even if it cannot update the zone file. An expiration period exists under

the theory that out of date data is worse than no data at all. In our example we use 604800.

Minimum-TTLThis is the default time to live (TTL) for this domain in seconds. Times will occur when remote clients will make

queries for sub-domains that don't exist in your records. If so configured, your DNS server will respond with a nodomain or NXDOMAIN response that the client's remote server caches. The TTL value defines the caching duration

your DNS response. The value is included in your server's response. Any resource record that does not have a

specified TTL uses this default. Because 86400 seconds is one day, the querying cache's record should die in one

day.


6/11

The next database record type specifies the name servers for the domain. NS stands for name server. You already

know that server1.centralsoft.org represents the host name of the primary domain server. The secondary or slave

server for this domain follows. ns0.centralsoft.org is the hostname of the secondary name server for this domain.

Following the name servers you will see the MX record type which identifies the mail server for the domain.

Following the mail record you can see the A record type which maps a name to an IP address. In the file above we

have four A records which map the host names to IP addresses.

Let's write a zone file. You should name it for your own domain. Mine is pri.centralsoft.org. Name your zone file for

your domain.

The first line in our zone file looks like this:


The "@" sign in the line refers to the "origin" for this zone file which is server1.centralsoft.org. DNS uses this as

simply a label to designate the Start Of Authority (SOA) record that appears at the beginning of any zone file

defining a domain. Don't make too much out of this. If you read much about DNS, then you will see people using

this strange term "current origin". Few people explain what that means. It's just another bit of jargon.The next item on the line "IN" stands for Internet. People call this a class field. Three classes exist including "HS"

for Hesiod servers and "CH" which stands for Chaosnet servers. You will only see Internet servers, so don't sweat

the small stuff.

IETF RFC 1035, Domain Names - Implementation and Specification says:

The SOA record stores information about the name of the server that supplied the data for the zone; the

administrator of the zone; the current version of the data file [serial number]; the number of seconds a secondary

name server should wait before checking for updates; the number of seconds a secondary name server should wait

before retrying a failed zone transfer; the maximum number of seconds that a secondary name server can use data

before it must either be refreshed or expire; and a default number of seconds for the time-to-live file on resource

records.

What's next? The mailing address of the administrator in this file is root@localhost. Obviously, my mail server

delivers local mail so messages related to this process will go to root's mailbox.In case you missed it, the first line is only part of the SOA record. It has additional fields. Notice the "(" at the end of

the line. Here's the rest of the record.

2006012103; serial

28800; refresh, seconds7200; retry, seconds



The serial number is the only field in the record that does not refer to seconds. You designate the serial number as a

numeric value so when a slave server checks to the zone file on the primary server if will know if the zone file

changed. The slave can then do a zone transfer and populate its database with the current records.

The remaining fields use seconds to denote their values. For example, the number of seconds a secondary nameserver should wait before checking for updates is in the refresh record. 28800 seconds is 480 minutes or 8 hours.

Also notice that the SOA record ends at the end of the Minimum-Time to Live (TTL). You can see the ")" symbol

which closes the record values.


7/11

NS Records Page 4

Next we createNSrecords. These specify the name servers that are responsible for our domain. You must have at

least one, however it is common practice to at least list two (you can list as many as you want) - if the primary

name server fails, the secondary takes over:



Please note: the semicolon (';') does not mark the end of a line; instead it marks the beginning of a comment in a

zone file. You can write

NS server1.centralsoft.org.; This is my primary name server.

However, if you do not have any comments, you can as well write

NS server1.centralsoft.org.

MX RecordsAs we want to receive emails on centralsoft.org, we must list the mail exchanger(s) for the domain. This is done

with anMXrecord:

MX 10 server1.centralsoft.org.

This record says that emails for centralsoft.org should be delivered to server1.centralsoft.org (which is the

mailserver for the domain) with a priority of 10. You can list more than one mail exchanger:


MX 20 mail.someotherdomain.com.

Now if a mail is sent to centralsoft.org, the sending mailserver tries to connect to server1.centralsoft.org because it

has a priority of 10. If server1.centralsoft.org cannot be reached (for whatever reason), then the sending mailserver

will try to send the mail to mail.someotherdomain.com because it has a priority of 20 which comes next (you see:

although 20 is greater than 10, it means less priority in this case).

Until now we have defined MX records for centralsoft.org only which is good for email addresses of the form

[email protected]. Let's say we have an email address of the form [email protected]. Therefore

we must create an MX record for subdomain.centralsoft.org:

subdomain.centralsoft.org. MX 10 server1.centralsoft.org.

Please note the '.' at the end of subdomain.centralsoft.org. If you do not add it, then the origin of the zone is

appended to the name. For example, if you wrote

subdomain.centralsoft.org MX 10 server1.centralsoft.org.

without a '.', this would transfom to subdomain.centralsoft.org.centralsoft.org! Of course, this feature can be useful:

subdomain MX 10 server1.centralsoft.org.

Now we only have subdomain, but because the '.' is missing at the end, it transforms to subdomain.centralsoft.org

which is what we want. So

subdomain.centralsoft.org. MX 10 server1.centralsoft.org.

or

subdomain MX 10 server1.centralsoft.org.

are two notations for the same thing!


8/11

A Records Page 5Up to now we have used the domain names centralsoft.org, server1.centralsoft.org, and ns0.centralsoft.org, but

we did not specify anywhere to which IP addresses these domains should point to. That's where A records come

into play. A records are the most important DNS records; with them you can create host addresses. Let's create

our first A record:


This means that centralsoft.org has the IP address 70.253.158.42. Remember my hint about the '. '? You can also

write

A 70.253.158.42

which means exactly the same.

Now in a browser you are used to typing www.centralsoft.org instead of centralsoft.org, aren't you?

www.centralsoft.org is technically totally different from centralsoft.org, but obviously you expect to see the

same web site for both. Therefore we create this record:

www A 70.253.158.42

which is the same as

www.centralsoft.org. A 70.253.158.42

Finally we specify server1.centralsoft.org and ns0.centralsoft.org:server1 A 70.253.158.42

ns0 A 70.253.158.45

ns0.centralsoft.org points to a different IP address which makes sense because it is our secondary nameserver

which should be on a different system in case our primary nameserver goes down.CNAME Records

CNAME is short for "canonical name", you can think of it as an alias to an A record. For example,

ftp CNAME www

means, ftp.centralsoft.org is an alias for www.centralsoft.org, so ftp.centralsoft.org points to the same machine

as www.centralsoft.org.

A CNAME must always point to an A record; a CNAME must not point to another CNAME! In addition to

that, you must not use CNAME records for MX and SOA records. For example,

MX 10 ftp

is not allowed!

The usage of CNAMEs has its pros and cons. I can hear you say "If the usage of CNAME records has that many

restrictions, why don't we always use A records?" That's true, but imagine you have hundreds of machine names

as A records, pointing to the same IP address, and now you move the server to another data center where it is

assigned a different IP address. You'd have to update every single A record. If you had just one A record and all

other records were CNAMEs, you'd just have to update one A record...

TXT Records Page 6

TXT records give you the ability to assign some text/additional information to a zone. Normally this feature is

not much in use - with one exception: SPF (Sender Policy Framework) records. These are records that specify

from which machines you are allowed to send mail with the sender domain centralsoft.org. Technically, you can

send such mails from any machine, but big email providers such as Yahoo or Hotmail now make heavy usage of

SPF records, i.e.: if the sender domain does not have an SPF record or is sending from a machine that is notlisted in the SPF record, then the mail is classified as spam.

There is a wizard for creating SPF records athttp://www.openspf.org/wizard.html?mydomain=&x=26&y=8.

We use this wizard to create an SPF record for centralsoft.org, and add this to our zone file:

centralsoft.org. TXT "v=spf1 a mx ~all"

server1.centralsoft.org. TXT "v=spf1 a -all"

Putting It All Together
http://www.openspf.org/wizard.html?mydomain=&x=26&y=8http://www.openspf.org/wizard.html?mydomain=&x=26&y=8http://www.openspf.org/wizard.html?mydomain=&x=26&y=8http://www.openspf.org/wizard.html?mydomain=&x=26&y=8


9/11

Now we put all these records in our zone filepri.centralsoft.org. It looks like this:


2006012103; serial





;



;


;


www A 70.253.158.42

server1 A 70.253.158.42

ns0 A 70.253.158.45

ftp CNAME www

centralsoft.org. TXT "v=spf1 a mx ~all"

server1.centralsoft.org. TXT "v=spf1 a -all"

The Reverse Zone File Page 7Now programs can look up the centralsoft.org domain and all its subdomains in DNS, but now we need a

reverse zone which maps IP addresses to centralsoft.org. This reverse lookup is used by many programs that

will refuse to talk to you if the reverse lookup and the forward lookup (i.e. the normal lookup of

centralsoft.org) do not mtach each other. For example, many email providers use reverse lookups to classify

emails as spam or not spam.

Because we do not want emails originating from the centralsoft.org domain to be classified as spam, we create

a reverse zone.

Therefore we have this in our named.conffile:


type master;

file "pri.158.253.70.in-addr.arpa";

};

What are the numbers in there? As you noticed, centralsoft.org is in the 70.253.158.x net. Now we take this

string 70.253.158 and write it the other way round (158.253.70) and use it in the zone section we add

tonamed.conf.

We also name our reverse zone file like this:pri.158.253.70.in-addr.arpa. We createpri.158.253.70.in-

addr.arpain the same directory as our "forward" zone filepri.centralsoft.org.

The beginning ofpri.158.253.70.in-addr.arpalooks exactly like inpri.centralsoft.org:


2006012103; serial





; NS server1.centralsoft.org.;


But now, we do not create A, MX, CNAme, etc. records anymore, we only create PTR records.


10/11

PTR Records

PTR is short for pointer, and that's what it is: it points to a domain name. Let's create a PTR record for centralsoft.org:

42 PTR centralsoft.org.

centralsoft.org's IP address is 70.253.158.42, and we want 70.253.158.42 to point to centralsoft.org.

We create exactly one pointer for each IP address we use; the only other IP address we use is

70.253.158.45 (for ns0.centralsoft.org), so we add:

45 PTR ns0.centralsoft.org.

That's all. Our reverse zone file looks now like this:


2006012103; serial





;



42 PTR centralsoft.org.

45 PTR ns0.centralsoft.org.

Now we can test it by doing a lookup with the command line tool dig. First we look up the IP address of

centralsoft.org:

# dig centralsoft.org

; DiG 9.2.1 centralsoft.org

;; global options: printcmd

;; Got answer:

;; ->>HEADERHEADER


11/11

Our Secondary Name Server page 8Next let's set up our secondary name server ns0.centralsoft.org. It will act as a backup name server in case the

primary (server1.centralsoft.org) fails so that people can still look up ccentralsoft.org and its subdomains.

ns0.centralsoft.org's named.conf resembles that of the primary name server very much, with a few

differences:

options {

pid-file "/var/run/bind/run/named.pid";

directory "/etc/bind";

// query-source address * port 53;

};

zone "." {

type hint;

file "db.root";

};


type master;

file "db.local";};


type slave;

file "sec.centralsoft.org";

masters { 70.253.158.42; };

};

The most important part is this one:


type slave;

file "sec.centralsoft.org";

masters { 70.253.158.42; };

};

By writingtype slave, we define that this is a slave zone, and in themasters line we specify the IP address of

the primary name server. In the fileline we specify the file name where the slave zone should be stored.That's all we have to do. Restart named, and soon afterwards you should find the

file/etc/bind/sec.centralsoft.orgon your secondary name server. What has happened? The secondary has

contacted the primary name server, and the primary name server has transferred the zone to the secondary.

Now whenever you update the zone on the primary name server, make sure you increase the serial number,

otherwise the updated zone will not be transferred to the secondary!

Please make sure you have no firewall on the primary and the secondary name server that blocks port 53

(TCP and UDP) because otherwise zone transfers will fail!A Word On Security

In our current configuration every name server is allowed to transfer our centralsoft.org zone from our

primary name server. Since we want only our secondary name server (70.253.158.45) to be allowed to

transfer the zone, we add the following line to the centralsoft.org zone in named.conf on our primary name

server server1.centralsoft.org:

allow-transfer { 70.253.158.45; };

So the zone should look like this:


type master;

file "pri.centralsoft.org";

allow-transfer { 70.253.158.45; };

};

Congratulations! You have just set up your first zone!

Documents

Traditional DNS Howto