[cobalt-users] DNS - Basic Concepts and Instructions

["aljuhani" <aljuhani@xxxxxxxxx>]

Hello List.

This FAQ about DNS were used to be posted on regular basis
by  Rodolfo J. Paiz (rpaiz@xxxxxxxxxxxxxx) to cobalt-users.

I thought to re-submit his latest dated May 2001.

Kind Regards,
aljuhani@xxxxxxxxx

DNS - Basic Concepts and Instructions:
=============================

There are so many questions on DNS--and so many of them are due to basic
ignorance--that I've decided to create a basic set of definitions and 
instructions that will be useful to anyone (and, of course, users of Cobalt 
products too).

Please read, and comment on any ways you see to improve this. Also, for the 
sake of my own education, if someone knows how to put this into a HOWTO 
format I'd appreciate hearing about it. Most of my afternoon has now gone 
into this, so please at least help me make it good, OK? Feedback from 
beginners who actually apply this and from experts who correct my errors 
are especially welcome.

DNS - Beginner HOWTO
====================

1. Table of Contents

    1. Table of Contents
    2. Intro
       2.1 Copyright and Disclaimer
       2.2 Assumptions
    3. Concepts and Definitions
       3.1 Server vs. Zone
       3.2 Master/Slave vs. Primary/Secondary
       3.3 Other Types of Zones
       3.4 Registered Nameservers
       3.5 FQDN - Fully-Qualified Domain Name
       3.6 Individual Records
          3.6.1 NS Records
          3.6.2 A Records
          3.6.3 MX Records
          3.6.4 CNAME Records
          3.6.5 Other Record Types
    4. Setting It Up
       4.1 Assumptions
       4.2 Scenarios
          4.2.1 You're A Large Network
          4.2.2 Two Independent, Fault-Tolerant Upstreams
          4.2.3 Swapping Slave DNS
          4.2.4 Two Machines
          4.2.5 One Machine
       4.3 My Typical Zone Records
       4.4 The Rest Of The Zone File
    5. Security
    6. Conclusion

2. Intro

2.1 Copyright and Disclaimer

This text is (c) copyright Rodolfo J. Paiz 2001. You may redistribute it in 
any form, written or electronic, and make any alterations you desire so 
long as: (1) such alterations are noted and delineated in the text to 
clearly communicate to the reader who wrote what text; (2) this copyright 
notice is included without alteration and the entire text you redistribute 
complies with the limitations and use restrictions of this copyright; and 
(3) you do not collect money or charge for this text in any way.

Of course, this text represents concepts which are correct, to the best of 
my knowledge. However, any use made of the concepts contained in this text 
by any person is their own responsibility as are the consequences of their 
actions. This text is offered "as is," without any warranty of any sort, 
anywhere on Earth or for any reason, without even any implied warranties of 
suitability for any purpose or merchantability.

You're on your own... if you muck it up, don't blame me.

2.2 Assumptions

I believe that the concepts contained herein are applicable to any DNS 
(Domain Name Service) server running on the Internet today, regardless of 
the particular software, server, or interface you use to implement them. 
However, it should be clear that I only have experience using BIND 
software, version 8, and that there may be variances of which I am not 
aware. Just one more reason to be cautious.

3. Concepts and Definitions

3.1 Server vs. Zone

One of the most widespread misconceptions that gets people in trouble comes 
directly from the terms "primary nameserver," "secondary nameserver," 
master nameserver," and "slave nameserver." Please note that these terms 
are used for convenience, and actually should be replaced with the 
much-more-accurate but much-less-convenient phrases below:

* Primary Nameserver: Nameserver acting in a primary role for this zone
* Secondary Nameserver: Nameserver acting in a secondary role for this zone

* Master Nameserver: Nameserver allowed to answer with authority for this 
zone, in which all zone records have been entered
* Slave Nameserver: Nameserver allowed to answer with authority for this 
zone, in which no zone records have been entered but which asks the master 
nameserver for information instead

You can quickly see that the most important word in all phrases is the 
"zone". One nameserver can have many roles... mine currently plays a master 
role for 35 domains and a slave role for another 50. Only one nameserver 
program should be running for each machine, generally speaking; and since 
this is a primer for beginners, any situations where this does not apply 
are automatically outside the scope of the text and can safely be ignored.

3.2 Master/Slave vs. Primary/Secondary

Contrary to popular belief (as well as popular usage of the terms) a master 
server is *not* the same as a primary server, just as a slave is *not* the 
same as a secondary. For Cobalt users, note that the Cobalt GUI in most 
cases does assume master=primary and slave=secondary, which is convenient 
but wrong. Here are my definitions:

Master Zone: This is the zone where you enter all records (NS, A, MX, etc.) 
individually. The server with the master zone will never ask anyone else 
for help; it will use only the information it contains to answer queries. 
When asked, it will answer authoritatively (big words for "I know this is 
the right answer so go ahead and use it with confidence.") Also, the server 
with the master zone will share this zone information with slave servers 
through a transaction called a "zone transfer."

Slave Zone: This zone is very easy to set up. Create a slave zone for a 
domain, tell it which nameserver holds the master zone, and you're done. A 
slave zone gets all its information from the master zone, and updates its 
information either: (1) if a certain period of time goes by; or (2) if it 
receives a NOTIFY message from the server with the master zone informing it 
that the zone info has changed.

Primary Server: In theory, the server which will receive all queries. In 
practice, not that important a designation. The primary nameserver really 
means the one that is listed first in the whois records for your domain 
(i.e. you registered it as the primary), and it's the one which *you hope* 
will receive and service all DNS queries. But a DNS client (called a 
"resolver") does not care which the primary is... if possible, it will ask 
the DNS server which provides the fastest response. So if my primary DNS is 
in Australia, and my secondary DNS is being done by America Online in the 
United States, anyone inside the AOL network who wants to see my sites is 
going to ask the nameserver closest to them (on the network, not in 
geography) and thus they are going to ask the AOL server.

Secondary Server: A server not listed first in the whois records. Also a 
server which you hope will not receive too many queries. But a server which 
should work properly, since some people *will* ask it for information, and 
because it will need to be fully up-to-date if the others go down. In 
reality, just another nameserver that holds your zone.

3.3 Other Types of Zones

Master and slave zones are not the only types of zones. However, they are 
the most frequently used types of zones and they are the only ones I have 
ever used. So clearly, in order to have basic DNS functionality you do not 
need to know anything about them and no information will be included in 
this text about them until I (a) learn about them or (b) someone teaches me 
about them.

3.4 Registered Nameservers

When you register your domain, you give the registrar the names and IP 
addresses of TWO OR MORE nameservers which are authoritative for your zone. 
(This means that you have configured one of them as the master and the rest 
as slaves.) These--and only these--servers are those which the rest of the 
world will look for when trying to find your domain; this is why it is 
important to work with a good registrar (not just the cheapest one) and to 
make sure that this information is always accurate.

3.5 FQDN - Fully-Qualified Domain Names

Domain names and host names are read "inside-out", which means that each 
component of the name is "inside" the next one. The components of a name 
are separated by dots, where usually the text to the left of the first dot 
is the hostname (name of the machine). The rest of the FQDN is the domain 
name (name of the network). An example of a FQDN:

george . jetson . com .

This means that:

www is the hostname, which is inside
jetson, which is a second-level domain name because it is inside
com, which is a top-level domain name, which is inside
 which represents the root-servers

Please notice that dot at the end! It denotes the root servers... and as 
with trees, everything comes from the root. DNS resolvers (clients) who 
don't know anything about a particular domain follow this sequence to 
resolve a name:

* Ask a root-server who answers for the "com" TLD (top-level domain).
* Ask a COM nameserver who answers for the "jetson" domain.
* Ask a JETSON.COM nameserver who the GEORGE host is.

BIND (and probably other DNS programs) assumes that a name is a "local" 
name if it does not end without a dot, and it adds the entire domain name 
to it. It will only treat a name as "complete" or "fully-qualified" if it 
is (duh) a Fully-Qualified Domain Name meaning it has a dot at the end. 
Concretely, if you create a record for "george" in the "jetson.com" domain, 
BIND will convert it to "george.jetson.com." If you should write 
"george.jetson.com." in the zonefile, BIND will see the final dot and leave 
the thing alone. All well and good; your only problem will come if you 
write "george.jetson.com" (no dot), because BIND will then convert that to 
"george.jetson.com.jetson.com." (with dot). And that's almost certainly not 
what you want.

3.6 Individual Records

A zone will contain several individual records. Remember, you will only 
directly add or edit individual records in a master zone.

3.6.1 NS Records

NS records point to FQDN's. You should have one NS record for each 
registered nameserver.

Example:

jetson.com.   IN   NS   ns1.jetson.com.
jetson.com.   IN   NS   ns2.jetson.com.

3.6.2 A Records

A records point a name to an IP address. They cannot point to a directory 
or file; only an IP address. You can have as many A records pointing to one 
IP address as you want. You can also use simple hostnames and have BIND 
convert them to FQDN's or you can use FQDN's in your zone.

Example:

george              IN   A   111.111.111.111
www                 IN   A   111.111.111.111
ftp                 IN   A   111.111.111.111

astro.jetson.com.   IN   A   111.111.111.112
mail.jetson.com.    IN   A   111.111.111.112

Notice that the machine with the 111.111.111.112 will get traffic to both 
the "mail" hostname and the "astro" hostname, and that the "george" machine 
is also the home of the website and FTP directories.

3.6.3 MX Records

MX records point to FQDN's. They do *not* point to IP addresses. They also 
have a priority field, which shows how much it "costs" to deliver mail to 
that host. Since it is a cost, the one with the lowest cost gets priority; 
and since it's your zone, the numbers can be anything you want. Usually 
multiples of 10 are chosen for simple convenience.

Example:

domain.com.   IN   MX   10   mail.jetson.com.

3.6.4 CNAME Records

CNAME records are aliases, and point to A records. I'm sure there are some 
uses to them, but I also happen to know there are times when CNAMEs will 
bite you hard. In particular, MX records hate being pointed to CNAMEs; they 
want A records only. So if you point your MX to a CNAME, your mail will not 
work.

In practice, since I can use however many A records I want, I simply use 
only A records and do not use any CNAMEs at all. Again, there may be some 
cases where they're great and wonderful, but this is a beginner document. 
Any who care are advised to buy a good book on DNS, but for now...

Forget CNAMEs. They are evil.

3.6.5 Other Record Types

There are several other types of records, including TXT records and others. 
They are used to provide more information, but since I live in fear of 
hackers I provide as little information as I can. A possible exception 
might be to provide an "abuse@xxxxxxxxxx" email address, but then again 
abuse, info, postmaster, and webmaster are addresses that should work for 
every domain anyway. So these other types of records are not necessary to 
the beginner. Read a book, then tell me about them.

4. Setting It Up

The following section should be enough to get you going properly. The 
scenarios are presented in order from Most Desirable ("You're A Huge 
Network") to Least Desirable ("One Machine").

REMEMBER: The whole point of network design is to avoid that most horrible 
of things: a Single Point of Failure. The ideal situation is where any 
individual component can fail and not cause an interruption of service; 
however, networks that really have no SPF cost serious money and, if you're 
reading this, you probably don't have that. So then the goal becomes to do 
the best you can.

4.1 Assumptions

This is supposed to be a teaching document for beginners, hence it reflects 
my opinion of Best Practices and good advice. You don't like the advice, go 
read someone else's text. But before you do that, write me and argue your 
point so that I can improve this text for the next guy.

4.2 Scenarios

4.2.1 You're A Large Network

If you have multiple good networks, with machines located in multiple NOC's 
(Network Operations Centers) in geographically separated locations, each 
with multiple upstreams and on different network backbones, you have more 
money at risk and more knowledge than most beginners do. Hence you have no 
business reading this document; you should either already know how to do 
this or have hired someone to do it for you.

4.2.2 Two Independent, Fault-Tolerant Upstreams

If you have two good, reliable Internet connections coming into your 
servers from different providers who are on different backbones, and you 
have your own IP space which is being announced via BGP so that you truly 
have fault-tolerance and the world can reach you when one of your providers 
goes down, then you're either: (a) probably shelling out at least US$2,000 
per month for connectivity to your NOC, or (b) using a dedicated server or 
a co-located server in big server farm or datacenter.

If (a), hire someone to do it right, then learn.
If (b), follow the instructions for the "Two Machines" scenario and be 
happy that the warnings don't apply to you.

4.2.3 Swapping Slave DNS

If you only have one upstream, or you're too small to announce via BGP (if 
you don't know what BGP is, you're not using it), then if your provider 
goes down so do you, regardless of anything you've done inside your 
network. In this case, (which will probably be most people) I suggest you 
swap slave DNS with someone else (whom you'll have to find).

Notice that the normal phrase is "swap secondary DNS" but you already know 
(now) that's a fallacy.

The way this works is...

    1. You run one nameserver (111.111.111.111).
       They run one nameserver (222.222.222.222).

    2. For every domain you register, you use:
          ns1.domain1.com   111.111.111.111
          ns2.domain1.com   222.222.222.222
       (Notice your nameserver is listed first.)

    3. For every domain *they* register, they use:
          ns1.domain2.com   222.222.222.222
          ns2.domain2.com   111.111.111.111
       (Notice their nameserver is listed first.)

    4. Every time you register a new domain name,
       you create the master zone in your server.
       Then you send them an email with the name
       of the domain, and they create a slave zone
       for it, pointing it to the master zone on
       your server.

    5. They do the same.

Voilà! You now both have secondary/slave DNS on some other network, on a 
different backbone, on a different machine, making the probability that 
your DNS service will experience an interruption much, much lower. (Of 
course, you actually have to ensure that they *are* on a different network 
on a different backbone and that they actually created the zone...)

4.2.4 Two Machines

Having two machines for DNS is far better than having just one, since you 
eliminate the SPF at the machine level. However, if you only have one 
upstream connection, then you still have a huge risk of service 
interruption if your host goes down. For the sake of being ultra-cautious, 
I would apply this logic even if I had servers in a datacenter unless it 
were really big... they can screw up their routing and bring down the whole 
data center, you know. Unlikely, yes; but we plan to prevent the unlikely 
from biting us in places where it would hurt very badly.

    1. Set up a DNS server program like BIND on two machines.

    2. Set up a master zone for your domain on the first server,
       and enter all the records you want.

    3. Set up a slave zone on the second server, and point it
       to the master zone so it gets the information.

4.2.5 One Machine

This is a *really* bad idea; go read the previous part on Swapping Slave DNS.

If you must do this:

    1. Set up a DNS server program like BIND on your machine.

    2. Make sure that you have two IP addresses assigned to
       your machine (111.111.111.111 and 111.111.111.112).

    3. Make sure your DNS server program is listening on both
       IP addresses (BIND default is to listen on all).

    3. Set up a master zone for your domain on the server, and
       create A records for ns1=111.111.111.111 and
       ns2=111.111.111.112.

4.3 My Typical Zone Records

I have only one server (I'm a beginner too), and I swap secondary/slave DNS 
with two friends so I actually register three nameservers per domain. More 
is not necessarily better (don't bother putting in more than three, but the 
why is left for more advanced document or the next revision of this one 
when I have more time to add material). These are the records I put in for 
every domain; then I add other records as required:

domain.com.   IN   NS   ns1.domain.com.
domain.com.   IN   NS   ns2.domain.com.
domain.com.   IN   NS   ns3.domain.com.
domain.com.   IN   MX   10   smtp.domain.com.

ns1      IN   A   111.111.111.111
ns2      IN   A   222.222.222.222
ns3      IN   A   333.333.333.333

www      IN   A   111.111.111.111
secure   IN   A   111.111.111.111
ftp      IN   A   111.111.111.111

smtp     IN   A   111.111.111.111
pop      IN   A   111.111.111.111
imap     IN   A   111.111.111.111

4.4 The Rest Of The Zone File

A real zonefile has more than just records; it also has data that shows 
contact information and sets variables such as the time-to-live of those 
records and the time interval at which slave DNS servers should talk to the 
masters. Beginners should not mess with those things and should not be 
editing those files by hand without understanding them.

My recommendation: if you are using a program to help you manage DNS, like 
Webmin (http://www.webmin.com/webmin) or the Cobalt GUI built into Sun's 
Network Appliance Division line of Cobalt servers, then the text contained 
herein will do you fine. If you do not have such an interface and you need 
to edit the files by hand, then by all means go by a book and learn more 
than this document teaches before messing with them.

4. Security

Security is beyond the scope of this document. I will only provide some 
pointers for you to do more research and self-education:

* Do not allow dynamic updates from anyone.
* Only allow zone transfers to your slaves.
* Make sure you're running the latest stable version
   of your DNS program.
* Make sure no vulnerabilities or hacks have been
   discovered in the version of the DNS program you
   use; if any have, upgrade immediately.

6. Conclusion

You learn by doing, so roll up your sleeves and dive in. Only please, don't 
play with it if you depend on it; you should *never* change anything or 
tinker with anything on a production machine. Play on a machine that you 
and customers don't depend on.


-- 
Rodolfo J. Paiz
rpaiz@xxxxxxxxxxxxxx