[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[cobalt-users] DNS - Basic Concepts and Instructions
- Subject: [cobalt-users] DNS - Basic Concepts and Instructions
- From: "Rodolfo J. Paiz" <rpaiz@xxxxxxxxxxxxxx>
- Date: Sun May 6 04:51:02 2001
- List-id: Mailing list for users to share thoughts on Cobalt products. <cobalt-users.list.cobalt.com>
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