[Courses] [Domains] Techie interlude: nameservers
Mary
mary-linuxchix at puzzling.org
Sat Jun 19 11:53:33 EST 2004
This is the third lesson in the domain names course. This course is being
archived at http://www.linuxchix.org/content/courses/domains/
This lesson has four parts:
1. About DNS, a short introduction to what DNS does
2. About nameservers, what they do and why you need them
3. DNS hosting options, covering various different nameserver hosts
4. Changing IP addresses, covering the entire process of switching IP
addresses
--- About DNS ---
Every computer directly connected to the Internet has an IP (Internet
Protocol) address. An IP (version 4) address is a series of four numbers
between 0 and 255 (eg 10.7.123.255, 253.10.124.7) and uniquely identifies that
machine's connection, allowing answers to its queries to be delivered.
The Domain Name System (DNS), which maps domain names to IP addresses, lets
you do two things:
- use a domain name instead of an IP address in URLs, email addresses and so
on;
- move a domain name between IP addresses
There are a couple of reasons why this mapping is useful: the first is that
domain names are far easier to remember than IP addresses, the second is that
IP addresses are generally allocated to *providers* (like broadband and dialup
ISPs, domain hosting services, colocation facilities, telecommunication
providers...) rather than individuals. For most of us, that means we will
always be using an IP address associated with our host, and hence switching
hosts means switching IPs. The domain name system lets us keep our services at
the same address when we do it.
--- About nameservers ---
In order to discover the mapping between a domain name and an IP address, a
client needs to contact the nameservers for that domain.
A nameserver is simply a server that can respond to DNS queries in the
appropriate way. As with web servers, email servers and so on, it is possible
to run your own nameserver (the most common program used to do this on Linux
is called "BIND") but this course won't teach you how.
However, even if you do use a nameserver configured by a third party, you will
either have some control over the answers they give for your domain, or you may
need to know a little about DNS in order to move your domain from one IP to
another. Hence this lesson.
There's two obvious bootstrapping problems here: how do the nameservers know
the mapping, and how does the client find the nameservers?
The process by which the nameservers know your IP address is no more
mysterious than the process which your webserver uses to find your files, or
the process your SMTP server uses to put mail in your mailbox: someone has
configured it to know. The upshot of this is that somehow, your nameservers
are going to have to know about your IP. Configuration details vary widely
and will be covered by your host's documentation if you need to know. (See the
"DNS hosting options" section.)
Now, how do clients know where the nameservers are? What happens is that at
each level of the domain name, the nameservers for that domain know where to
find the nameservers for the subdomain.
So, for subdomain.example.com:
- the .com nameservers know where to find the example.com nameservers
- the .example.com nameservers know where to find the subdomain.example.com
nameservers
If the parent isn't itself the subdomain's nameserver and doesn't know where to
find the subdomain's nameservers, then the subdomain doesn't resolve.
Now for some questions about this bootstrapping process:
1. Where are the .com nameservers; and
2. how do I tell them the example.com nameservers?
1. Where are the .com (or .net, or .tv, or ...) nameservers?
There are nameservers that know the answer to this question. These are known as
"root nameservers." There are presently 13 of these servers and if you go to
http://root-servers.org/ you'll see that they're scattered pretty widely around
the world (they need to be massively redundant, if they vanish then so does the
DNS for most users -- although there are certainly other servers with copies of
their information)
Other nameservers need to know where these are, although if you know one of
them it can tell you where the others are. (If you want to see, run the command
"dig ns . @A.ROOT-SERVERS.NET") Their IPs change very seldom.
2. How do I tell the .com nameservers where the example.com nameservers are?"
You do this through your registrar. As soon as your domain is in their system
they provide a "Update nameservers" facility for you to enter the nameservers
for your domain. When you do that, they update the appropriate parent
nameservers for you.
Now, quite often when you register a domain you do not yet have a host for it,
or you don't know what the nameservers are going to be. In this case your
registrar will enter some default nameservers, normally ones under their
control.
If you don't change them for a day or so, a webpage will normally appear at
your domain saying something like "example.com, recently registered at SOME
REGISTRAR. Consider SOME REGISTRAR for your registration needs today!" While
they're controlling the nameservers, they'll do some advertising. Obviously
once you tell them where your nameservers are, then you'll be able to point
example.com at a different IP address and deprive your registrar of
advertising.
That concludes the basic DNS section. The next section is about actually
getting yourself some nameservers. In the last section of the mail, I've got a
discussion of "moving IPs", because despite my sales pitch in the first lesson
this isn't an entirely trivial task and you need to know some more about DNS to
understand why.
--- DNS hosting options ---
Your domain will generally need at least two nameservers. This is for
redundancy purposes and the normal setup is to have one -- the "slave" --
automatically updating itself from the other -- the "master". The fact that
there needs to be two is enforced to varying degrees: many registrars won't let
you enter just one, and if they do some clients will complain. Hence most DNS
providers will store your domain on at least two servers and you give both of
these to your registrar.
Here is a discussion of various DNS hosting options:
1. You use your host's nameservers.
2. You use a third party's nameservers.
3. You use your registrar's nameservers.
4. You run your own nameservers.
1. You use your host's nameservers.
This is a very common option for people using commercial domain hosting. It
will probably be the one you choose unless your arrangements are unusual.
Your host will have a couple of nameservers (or many more, depending on how
big they are), and they will store your information in their servers. They
will tell you which servers these are (generally after you sign up), and you
pass them onto your registrar.
If you use your host's nameservers your host may retain complete control over
the nameservers and enter the IP address details themselves. However, they may
give you some level of control over the contents of your servers. This could
be useful if you host example.com on their service, but subdomain.example.com
is hosted elsewhere and you want to tell them where. It may also be
educational for you to play around.
The precise way they let you configure it will vary on a case-by-case basis.
Usually, they will have worked up some interface (perhaps a web interface, or
a simple command line tool) that makes this relatively straightforward. It's
pretty rare to find them asking for "zone files" (by which they mean BIND's
configuration format) but I've seen that happen too. Check their
documentation.
2. You use a third party's nameservers.
There are a number of providers who only do DNS, usually allowing you to
configure your servers however you want (there's no point limiting it to
their IPs, otherwise you'd never use them!)
There are a few reasons you might want to do this:
- you're hosting your own domain, but you don't want to host a nameserver;
you don't have a second machine to use as the other nameserver; you're
worried about reliability; or you just want some backup
- your commercial host doesn't have nameservers they let you use (I've seen
this occasionally, often from very low budget hosts)
- your commercial host's nameservers aren't any good. I had a host once who
had their nameservers configured so that it took *5 weeks* for changes to
work. (Explanation for people who know about DNS: Their custom configuration
tool didn't update the serial number and only updated one server!)
- your commercial host doesn't provide all the options you need. For example,
perhaps you want to point "home.example.com" at your broadband connection's
IP so that you can connect to your home PC, but your host doesn't let you
point subdomains at different IP addresses.
A note on using a third party nameserver with a commercial host who has their
own servers. As long as your third party nameserver points at the right IP,
your domain's web, email etc services should work, but there are a couple of
pitfalls:
- your commercial host, who will be assuming you are using their nameservers,
might move you to a new IP address for some reason and because they assume
that you're using their nameservers which they update themselves, may not
tell you;
- your commercial host's DNS configuration tool might be tied in with their
website configuration tool and so on; or
- your commercial host's users and staff may ask *their* nameservers for your
domain, not your chosen nameserver. So if you do use a third party
nameserver and your commercial host also has DNS records for your domain,
make sure they agree.
As should be obvious by now, I suggest you use your host's nameservers if
they're available. If they're badly configured, consider switching hosts.
If you need third party nameserver hosting, there are a few free third party
DNS hosts. http://zoneedit.com/ seems to be the most commonly used, they will
host DNS records for up to 5 domains for free (I don't know if subdomains
count). http://www.granitecanyon.com/ is another. I haven't used either, so
you may want to ask around. There are some commercial providers too, but I
don't know anything about them.
One note on third party providers: at least some of them will run a "whois"
command on your domain name to check that you own it before they agree to host
your DNS. This is a pain if someone has given you subdomain.example.com and
you want to run nameservers for it, because whois won't respond for it.
3. You use your registrar's nameservers
As mentioned above, many registrars will enter some default nameservers for
you and point them at a "Register with us!" holding page. They expect you to
replace these nameserver entries with your own, and you'll have to if you want
to use the domain.
However, some registrars will let you use and update their nameservers.
register.com allows this by default (I think it's why they're relatively
expensive), some others will do it for an additional fee (dotster.com). This
is a special case of the "Use a third party's nameservers" option.
4. You run your own nameservers
As with hosting anything yourself, this requires more work than the other
options but allows you the most flexibility. I won't discuss configuring BIND
or any other DNS server program here, but I'll briefly discuss the
prerequisites:
- you need a "static IP" for all your nameservers. A static IP is a connection
with a permanent IP address that persists after re-connection. A "dynamic
IP" is one where a machine reconnecting to the Internet may get a new IP
address. Most dialup ISPs use a dynamic IP system and so do many home
broadband providers. If your IP can change rapidly, regularly or arbitrarily,
it isn't suitable for hosting a nameserver because the parent nameserver
won't be able to point at the nameserver's new IP fast enough.
- as with hosting web or email, you need to make your your provider's terms of
service allow hosting server programs -- many home ISPs don't allow this.
This won't be a problem if you've paid for a server hosting service though.
- ideally your two nameservers should be as independent as possible. I've
seen this described as "make sure they share as few of these as possible:
power supply, building, upstream provider, country, continent." That is,
the ideal nameservers for a domain would live in different continents.
- ideally you should have a lot of control over both nameservers. A common
scenario for nameserving is that you and a friend agree that you will each
use the other's nameserver as your second nameserver. However, in this
scenario, if your nameserver is down and you urgently need to update the
information in the other, you may not have access to it directly.
Obviously, as with many other hosting decisions, the urgency of these
considerations depends on how much you value consistent and correct DNS
information for your domain. (Although, it's amazing how much more valuable it
all becomes when you're at risk of losing email because a nameserver is
pointing at the wrong place!)
--- Changing IP addresses ---
One of the big advantages of the domain name system is that your host can move
IP addresses. But this is not an entirely simple process. To understand why,
you need to understand the system of "timeouts".
Fair warning: this section is long and fairly technical. Depending on your
inclinations you may want to skip it now. You don't need it for purchasing and
setting up a domain name, however, you'll need most of it the first time you
change hosts, especially if you want to do it quickly. Feel free to skip this
now and return to it when you're switching hosts, or to skim it now and return
to it when you're switching hosts. If you don't fully understand it now, feel
free to ask questions now, or later on the techtalk list.
As you can probably imagine, DNS has the potential to create a lot of Internet
traffic. To look up linuxchix.org, your client (or your client's nameserver,
most clients will connect to a local nameserver and get it to do the work)
must first ask the root nameservers what the .org nameservers are, then ask
the .org nameservers for the linuxchix.org nameservers, and then finally the
linuxchix.org nameservers for the linuxchix.org IP address. This is also
potentially a slow process.
In order to solve some of these problems, nameservers and clients are allowed
to store the results of their queries for a certain amount of time, known as
the "time to live".
Let's look for example at the linuxchix.org time to live, by examining the dig
result (I've cut a lot of it out):
$ dig linuxchix.org @NS2.ANTHILL.ECHIDNA.ID.AU.
;; ANSWER SECTION:
linuxchix.org. 86400 IN A 203.7.155.11
This means that the linuxchix.org server's address (A) is 203.7.155.11.
The time to live for this result is the numerical value 86400, meaning that
your client can store the results of this query for a maximum of 86400 seconds
(24 hours). After 86400 seconds, it must check back with the original servers
in case the information has changed.
You can actually see the cache time dropping if you're interested: leave off
the @NS2.ANTHILL.ECHIDNA.ID.AU. part of that dig command
(NS2.ANTHILL.ECHIDNA.ID.AU is authoritative for linuxchix.org -- you can
always cache its results for 86400 seconds) and run it repeatedly to see the
amount of time your local nameserver is allowed to cache the result dropping
off, for example:
$ dig linuxchix.org
;; ANSWER SECTION:
linuxchix.org. 76052 IN A 203.7.155.11
$ dig linuxchix.org
;; ANSWER SECTION:
linuxchix.org. 76009 IN A 203.7.155.11
$ dig linuxchix.org
;; ANSWER SECTION:
linuxchix.org. 75995 IN A 203.7.155.11
If you're interested in the gory details of the process as a whole, look at
RFC 1034 at http://www.faqs.org/rfcs/rfc1034.html and if you're really really
interested, all the updates as listed at http://www.dns.net/dnsrd/rfc/#rfc1034 .
However, none of this is necessary for the discussion here!
So, if your time to live is set to 86400, and client X asks for your IP
address, they will cache it and probably won't ask again for 24 hours. If you
change your IP within that 24 hours, client X will not notice because they'll
use their cached result. Only after 24 hours will they check again and notice
the change.
There's also a second ttl value known as the "negative time to live": the time
that errors (like "name not found") can be stored for, but here we're concerned
with the positive time to live: the time that answers can be stored for.
There's a further delay if you switch nameservers, as you will most likely do
if you switch hosts and you were using your old host's nameservers.
Consider the linuxchix.org lookup process, in which the .org nameservers tell
the client what the linuxchix.org nameservers are. Well, the .org nameservers
set their own timeout on the nameserver result which seems to be 48 hours
(172800 seconds) at the moment for linuxchix.org:
$ dig -t NS linuxchix.org @TLD1.ULTRADNS.NET.
;; ANSWER SECTION:
LINUXCHIX.ORG. 172800 IN NS NS2.ANTHILL.ECHIDNA.ID.AU.
LINUXCHIX.ORG. 172800 IN NS NS1.LINUXCHIX.ORG.
LINUXCHIX.ORG. 172800 IN NS NS.ANTHILL.ECHIDNA.ID.AU.
LINUXCHIX.ORG. 172800 IN NS NS3.LINUXCHIX.ORG.
LINUXCHIX.ORG. 172800 IN NS NS2.LINUXCHIX.ORG.
;; ADDITIONAL SECTION:
TLD2.ULTRADNS.NET. 86400 IN A 204.74.113.1
TLD1.ULTRADNS.NET. 86400 IN A 204.74.112.1
NS3.LINUXCHIX.ORG. 172800 IN A 66.93.78.112
NS2.LINUXCHIX.ORG. 172800 IN A 203.7.155.11
NS1.LINUXCHIX.ORG. 172800 IN A 203.27.58.91
and 24 hours (86400 seconds) for puzzling.org:
$ dig -t NS puzzling.org @TLD1.ULTRADNS.NET.
;; ANSWER SECTION:
puzzling.org. 86400 IN NS ns1.puzzling.org.
puzzling.org. 86400 IN NS ns.puzzling.org.
;; ADDITIONAL SECTION:
ns1.puzzling.org. 86400 IN A 218.214.66.203
ns.puzzling.org. 86400 IN A 64.91.227.43
TLD2.ULTRADNS.NET. 86400 IN A 204.74.113.1
TLD1.ULTRADNS.NET. 86400 IN A 204.74.112.1
(I'm not sure why there's a discrepancy, it may be because we have different
registrars.)
This information that the .org nameservers provide can be cached too, so even
if your new nameservers are giving the right answer, clients may be querying
the old ones! Additionally, it will take a while (in my experience, about 12
hours) for your registrar to update your parent nameservers in the first
place. So that means a delay while they update and a second delay while their
time to live causes old data to be cached.
Here's the important lesson to take away from this:
IP changes are not instantaneous. If you've changed IP addresses but not
nameservers, they won't take effect until your time to live is up. If you've
changed nameservers and only the new nameservers have the right information,
you will need to wait until the parent nameservers update, and then wait out
their time to live, which you normally can't control. Be conservative and add
48 hours to your minimum estimate.
What does this mean for you if you switch hosts? Well, it means either
downtime for some clients while everything updates, or maintaining two copies
of your information for a while, one at the old host and one at the new.
This tends to be a pain for email. The normal solution is either checking two
mailboxes or getting the old mailbox to forward to the new. If you have static
websites, websites are easy, just have a copy of your files at the old host
and the new. If you have dynamic web content this can be a bit harder: you may
have to keep two databases in sync for example. In this situation you will
want to do a fair bit of preparatory work and also make sure the IP address
change happens as fast as possible.
In an ideal situation (where you control the time to live value and can point
nameservers wherever you want), here's how you change your IP address as fast
and painlessly as possible:
- first make sure that mail arriving at the old host won't get lost and web
queries to the old host will get an appropriate answer, as above. Test that
both the old and new sites are working to your satisfaction before
beginning the move.
- a few days before the move, drop your time to live value to something
small, like 900 seconds (15 minutes) so that clients will only be 15
minutes behind. You can drop it to 0 if you're really sure that you don't
want any clients to cache any data at all during your move. Note that if
your time to live is 24 hours and you do this only 12 hours before the
move, some clients may have already cached the old data and won't check
again for up to 24 hours.
- if you're switching nameservers, update the *old* nameservers to point at
the new location too, so that clients who query those ones get the new IP.
- as soon as the new information goes in the nameservers, you can increase
the time to live again (you don't care about people caching the *new*
information for a while, after all). Leaving the time to live low isn't a
good idea: it increases the load on your nameservers, and increases the
lookup time for clients because they constantly need to check for updates.
- after about a week when you can be pretty sure that your parent's time to
live is up and everyone is querying the new nameservers, delete all your
domain information from the old nameservers. You do this because if a
nameserver has it's own information for a domain, it will return it when
asked, even if the parent nameserver no longer points to it. There's no
reason to let the old nameservers do this.
As you can imagine, there's a lot of ways this process can go wrong. A common
one is time to live values being accidentally set too high (if you set it to two
weeks and a client caches it, there's no way you can force them to check again
within two weeks). A safe default if you can manage it is about 24 hours: 24
hours downtime due to wrong information is seldom a disaster.
In conclusion, changing IP addresses and keeping your domain name is faster
and easier than changing URLs and waiting for the entire Web to link to your
new site (in my experience, links from old unmaintained pages will stick
around for 5 years or so) or changing your email address on all your mailing
lists and in your friend's address books. However it isn't trivial, and
requires some preparatory work. If it's just you and your personal website and
personal email, I'd estimate it would be something like 2 hours work, not
counting the setup at the new host which depends on their system. For me and
my 15 odd domains with their peculiar setups, and my 10 or so users, switching
IP addresses is now a solid day's work.
You should choose your host carefully so that you won't have to do this too
often. On the flip-side though, while the process is a bit of a pain, don't let
it deter you from switching hosts if your current host isn't providing what
you need. The cost of switching is not negligible but in my experience it's
nearly always lower than that of staying with an inadequate host. (The last
lesson will cover what "inadequate" might mean.)
-Mary
More information about the Courses
mailing list