DRAFT: "RIPE Guide To Setting Up a DNS Server"
- Previous message (by thread): DRAFT: "RIPE Guide To Setting Up a DNS Server"
- Next message (by thread): DRAFT: "RIPE Guide To Setting Up a DNS Server"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Peter Koch
pk at TechFak.Uni-Bielefeld.DE
Sat Jan 23 00:32:21 CET 1999
Dear RIPE DNS WG,
find below a draft document "RIPE Guide To Setting Up a DNS Server" to serve
as a basis for recommendations to customers on how to set up their DNS
server. The target audience is the maintainer of a zone with population
lower than 10 (the vast majority of zones, at least within the DE TLD),
who usually has very low operational experience and too few changes to apply
to develop such experience in "day to day" work.
It was started from scratch intentionally, so there are a few items missing
from previous similar drafts on this list. The document has already become
larger than I intended, but those missing pieces should be identified and
merged in (or part of this merged into the other).
Comments are very welcome. In particular I'd like to hear opinions concerning
the structure, volume and topics covered. The SOA values recommended here
are a proposal for the thursday WG meeting.
-Peter
PS: Although it may give the impression, the draft was not posted as an I-D,
I just borrowed that template.
-------------- next part --------------
INTERNET-DRAFT Peter Koch
Expires: July 1999 Universitaet Bielefeld
January 1999
RIPE Guide To Setting Up a DNS Server
<no file name, not yet submitted to the I-D maintainer>
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Comments should be sent to the author or the RIPE DNS WG mailing list
<dns-wg at ripe.net>.
Abstract
This document is intended to guide novice and/or part time DNS zone
administrators in getting their DNS zones up and running. It is not
sufficiently detailed to replace a book about DNS.
1. Introduction
The DNS is a distributed, redundant, hierarchical namimg scheme for
mapping so called "domain names" into addresses and other Internet
infrastructure elements. You will learn about those later.
You will normally use two distinct services within the DNS. While
using your web browser and email software your system will have to
translate (foreign) domain names into IP addresses. This is called
"resolving". The other task is presenting your domain name, once you
have one, to other parties on the Internet to enable them to resolve
your or your organisation's name into some address. This part is
called "serving". While both deal with DNS and both tasks may even
be carried out by the very same piece of software on your machine,
they are different. This document is primarily concerned with setting
up a DNS server, but at the end some information is provided on "DNS
Koch Expires July 1999 [Page 1]
INTERNET-DRAFT RIPE DNS Guide January 1999
resolving" issues.
There are different Top Level Domains (TLDs) to register with, such
as "COM" or those country-code based like "FR" for France and "DE"
for Germany. You may also find offers for registration within "new"
or "private" TLDs, e.g. "WEB". At the moment these are bogus. If in
doubt, check the official list at [TBD].
To register a domain name, in most cases two or more nameservers need
to be set up to serve the corresponding zones, i.e. answer queries
dynamically sent in from all over the Internet. "in most cases"
means, that some Top Level Domain (TLD) registries will allow the
existence of real data instead of just pointers to nameservers in
their database. Whether this is the case you should ask your ISP or
the registry responsible for the TLD you are interested in. Do not
forget to ask for the cost of making modifications to the data later.
If your organisation is going to expose only a small number of
systems to the globally visible Internet, maybe only a web server and
a mail relay, you will have to publish only a very small set of data
in the DNS. In this case - but sometimes also in others - it is not
really necessary to bother with the operation of an own DNS server.
Your ISP may offer running the DNS server and maintaining the zone
data for you. This value added service, however, may require an
additional fee. While DNS isn't rocket science, it is a mission
critical service, and there are some trapdoors potentially disturbing
the proper operation. You may wish to take the opportunity having
this done by somebody who makes a living out of it.
For those of you, who choose to do the job themselves, we want to
help you navigate around the most common pitfalls.
Apart from your own nameserver the DNS protocol requires a set of so
called "secondary" or "slave" servers, which will publish the same
data about your zones your server does, but which are placed at other
parts of the Internet. In most cases your ISP will offer help in
locating proper secondary servers or even run one or more of them
themselves. Again, this service may require an additional fee, so
please consult your ISP.
You may find some documentation suggesting to have two nameservers at
your installation. This is not considered reasonable practice and
will, apart from increasing your work (and even network) load, give
you nothing.
Now that you have a domain name, a list of secondaries for serving
your zone and some address space, you can start constructing a zone.
Consult the documentation of your DNS server software for where to
Koch Expires July 1999 [Page 2]
INTERNET-DRAFT RIPE DNS Guide January 1999
start, this document will assist you in filling in the proper values.
2. DNS Resource Records
The information in the DNS is handled in pieces of "resource records"
(RRs). There are different types of RRs, every resource record is
bound to a domain name (the "owner"). A single "owner" may own
several RRs of equal or different types. We will only talk about
"SOA", "NS", "MX", "A" and "CNAME" RRs.
2.1. The SOA RR Type
While some people claim the Internet being the end of all
authorities, one of the first things you will have to enter is a
"Start Of Authority" record. There is a single SOA record per zone
containing some meta information like who the maintainer is and how
often secondaries should check with the primary for modifications to
the zone.
There are seven elements in an SOA record:
1) The MNAME (master name) must give the name of the primary master
server for that zone, i.e. the machine you are running your DNS
server on. There is no need to reserve a special name, like "ns"
or "dns" for this system, so use the canonical name of that
machine. [XXX explain FQDNs]
2) The RNAME is to publish a mail address of a person or role account
dealing with this zone. The "@" must be converted to a "." before
you enter this, so postmaster at bricks.example becomes
postmaster.bricks.example. Be sure to name a working address here
(NB: your domain is not yet registered, but the local part should
be defined at your site). Do not accept any default your software
may suggest without checking its validity. If your addresses
follow the popular scheme "first.last at canonical.example", although
technically possible, do not use any of these here. The
distinction between the "." seperating first and last name and the
translated "@" will eventually be lost, leading to an unreachable
email adress due to wrong retranslation. The same caveat holds for
other addressing schemes with dots in the local part
("10000.0815 at kangooserve.example").
The best practice is to define (and maintain) a dedicated mail
alias "hostmaster" [RFC2142] for your DNS operations.
3) The SERIAL number
Secondaries have to check with the primary for new versions of a
Koch Expires July 1999 [Page 3]
INTERNET-DRAFT RIPE DNS Guide January 1999
DNS zone. For efficiency reasons, serial numbers are compared
only. If the serial number at the primary is higher than the
secondary's local copy, the zone is copied. If the serial at the
primary is equal to or less than the one at the secondary nothing
happens. This means that after every modification to the zone you
have to increase the serial and you should in any case avoid to
decrease it. Update the serial number even if you make mulltiple
changes within short intervals, one of the secondaries may have
fetched its new copy in the meantime.
The serial number is a an unsigned 32bit integer with no further
implied meaning. Also, the increments do not have any special
meaning. You can grow the serial by 1, 10 or 170 every time as
long as it just always increases. The serial number 0 should be
avoided due to some problems in certian software versions.
There is a popular scheme which builds the serial number by using
the actual date, e.g. 1999012300 for a zone changed at January,
23rd, 1999. The trailing two digits leave enough space for 100
modifications per day. This scheme is called YYYYMMDDnn, some
similar are also in use. Be sure to use a four digit year, notice
that the month preceeds the day and do not forget to update the
year value upon the first change every year.
4) The REFRESH value
This value controls how frequently the secondaries will check with
your primary to see whether your zone was modified and they must
update their copy. Modern DNS server software will send out
additional notifications from the primary to the secondaries upon
reload of a modified zoen, so usually the information is
distributed much faster than this. However, notification packages
may be lost, so the secondary-initiated checks are still useful. A
value of one day (86400 seconds) is recommended here.
5) The RETRY value
Should a secondary be unable to reach the primary for whatever
reason, the next attempt is started in intervals given by RETRY
until the zone could be successfully checked or it expires (see
below). Any value larger than REFRESH doesn't make sense, usually
the maximum of two hours and a fraction of 1/6 to 1/4 of REFRESH
are good choices. So, if you followed the recommendation above,
enter 7200 (two hours) here.
The lower the values for REFRESH and RETRY, the more load is put
on the secondary servers. This is not a big deal for a single
zone, but it has to scale for large nameservers serving several
Koch Expires July 1999 [Page 4]
INTERNET-DRAFT RIPE DNS Guide January 1999
thousand zones. Therefore your ISP resp. the operator(s) of your
secondaries may give you additional advice and will probably
recommend different values. If in doubt, ask them first.
6) The EXPIRE value
Should a secondary be unable to check the zone with the primary
for a period of time specified by EXPIRE, it will just do that -
expire the zone. Unfortunately it is not precisely specified what
that means, but from that time on you can no longer expect that
secondary to hand out any useful information about your zone. Of
course, this is a scenario you will want to avoid, benause it may
lead users to wrong addresses or even make them feel your or your
web site's domain name do no longer exist. There are several
reasons, why a secondary's check would fail: temporary line
failures, machine downtimes and most importantly: configuration
errors at your primary. To give yourself a chance of detecting
and repairing such problems, the EXPIRE value should be long
enough to cover even a short holiday. A value of 3600 hours
(3600000) is traditionally recommended here. Be especially warned
that values of a week or less, while having no benefit, have
drasticly proven to be too short.
7) The MINIMUM value
There are three different meanings applied to this, of which the
first appeared in the original protocol implementation but was
never widely implemented. To explain the other two we need to tell
about yet another DNS feature - caching. DNS servers are queried
by DNS resolvers, and those resolvers usually remember (cache) any
results seen for a certain amount of time. This way the total DNS
traffic on the Internet, the server load and most importantly the
response times will be reduced. There is both caching of RRs and
negative caching, which means the knowledge of non-existance of a
certain name or RR type will be maintained. The predicted lifetime
(TTL) of such information is to be controlled by the zone
administrator, every RR will be tagged with a TTL value when used
to answer a DNS query. There are different requirements for
caching and negative caching. While RRs in a well established,
stable zone can be cached for a day or two without problems,
negative responses should only be cached in the range of hours.
The remaining real meanings for the MINIMUM field now correspond
to values for either the default caching TTL or the negative
cahing TTL. We are in a transition phase from the former to the
latter, and actual interpretation depends on the software running
on the primary and secondary servers. If the old default TTL
meaning is implied, use 172800, otherwise 3600. If the servers
Koch Expires July 1999 [Page 5]
INTERNET-DRAFT RIPE DNS Guide January 1999
run different software, use 172800 here and explicitly set the TTL
for the SOA RR to 3600.
A complete example would look like this
bricks.example. 3600 IN SOA red.bricks.example. hostmaster.bricks.example. (
1999012300
86400
7200
3600000
172800 )
2.2. The A RR Type
One of the main tasks of the DNS is translating domain names in IP
adresses. This is done with A RRs. Their data portion contains a
single IP address in dotted quad notation, like here:
yellow.bricks.example. IN A 192.168.8.15
Publishing addresses from the private address space should be
avoided. [XXX so why doesn't the example comply?]
2.3. The NS RR Type
The NS RRs tell the world who is able to give out information about
your zone. Enter a single NS RR for every server which is intended
to provide secondary service for your zone, see the list mentioned
earlier. Do not enter random nameservers' names just because you have
seen them somewhere. The administrators may not want to deal with
that additional load and they may even - as a defense - provide
explicit non-service.
Apart from the secondaries you should enter a NS RR for your own name
server here. However, this will make random sources direct DNS
queries to your name server. There are several reasons why one might
want to avoid this. Amongst others, you may live behind a dialup line
and do not want it to be triggered by avoidable traffic. To
accomplish this, there's a concept called "stealth" or "hidden"
primary. It is implemented by not publishing NS RRs for the primary
(and to be efficient, no NS RRs for any other of your systems,
either). All the DNS queries are then answered by the secondaries.
This is only useful if the list of nameservers handed to the TLD
registry does not contain your server, so consult with your ISP
first. They may or may not support this concept and there may be an
additional charge.
Koch Expires July 1999 [Page 6]
INTERNET-DRAFT RIPE DNS Guide January 1999
The order of the NS RRs is not important, the protocol allows for
arbitrary reshuffling of RRs of the same type at the same owner. So
there's neither the need that the primary be the first in this "list"
nor the guarantee that it will always be handed out in any particular
position.
bricks.example. IN NS red.bricks.example.
2.4. The MX RR Type
Not every host is configured to receive mail and some domain names
represent organisations, not single hosts, and should nonetheless be
useful in addressing electronic mail. By using MX (mail exchanger)
RRs you can define which host or group of host mail addressed to a
certain domain should be sent to. Every MX RR has a precedence, lower
values resulting in higher priority. The values have no intrinsic
meaning, they're just for sorting the list.
In this example
bricks.example. IN MX 100 black.bricks.example.
bricks.example. IN MX 200 mail-relay.YourISP.example.
all mail to an address <user at bricks.example> will be sent to the host
"black.bricks.example". Should that machine be unreachable, the mail
would delivered to "mail-relay.YourISP.example" instead, which would
later repeatedly try to bring the message to its destination.
Do not enter any MX RRs pointing to a mail relay without prior
agreement from that system's maintainers. They will usually not act
as a relay for random targets, so your mail me be lost. In general
your ISP will provide one or more mail relays, so ask them for
assistance. Note that this relay for incoming mail may be different
from that machine you send yourt outgoing mail to.
As a target of an MX or NS resource record only domain names are
allowed which directly resolve into an address. That means:
1) The name you enter must exist. Note that your software may let you
enter names which do not exist without complaining. It is the DNS
administrators responsibility to check this. A very helpful tool
for this purpose is "host" [REF TBD].
2) The name must really be a name. The DNS will not understand IP
addresses here. Note however, that again your software may let you
make the mistake but that it will definitely not bring you the
results you wanted. Use only domain names here.
Koch Expires July 1999 [Page 7]
INTERNET-DRAFT RIPE DNS Guide January 1999
3) The domain name used must directly resolve into an address, which
means you must not use an alias name here and an A resource record
must exist for that name. Note that unless the name is part of
your namespace you must not enter that A record yourself.
2.5. The CNAME RR Type
It is possible to specify alias names for machines, e.g. if your
machine "yellow.bricks.example" is also your web server, you can
define an alias "www.bricks.example" to point to the canonical name,
"yellow.bricks.example" in this case.
www.bricks.example. IN CNAME yellow.bricks.example.
The name at the right hand side is the canonical name, whereas the
owner on the left turns out to be the alias name. There are some
caveats: CNAME RRs, like sharks, eat all their siblings before they
become visible, or in more formal wording: if a CNAME RR exists for
an owner, no other RR for that owner may exist, neither CNAME nor any
other type. This means you not only do not need to, but you must not
define any other RR in parallel. All RRs at the canonical name will
equally be valid for the alias. In the example above, a query for an
MX RR for "www.bricks.example" will return the MX RRs for
"yellow.bricks.example" if there are any, which better be the case.
If you want your web server to be addressable by "bricks.example" in
addition to "www.bricks.example", resist the temptation to define a
CNAME RR for the owner "bricks.example" pointing to
"www.bricks.example" (or anywhere else). This would invalidate your
zone, because the necessary SOA and NS RRs cannot coexist with the
CNAME RR. Your software may let you do this, but it will lead to
unfortunate results, including zone expiry at the secondaries.
Use CNAME RRs with care, and have them point to your own systems
only.
2.6. Wildcard owners
Apart from the owner names seen so far, the DNS supports "wildcard"
owners, which cover all names "below" a paricular domain name, unless
such owner name is explicitly defined.
*.bricks.example. IN MX 100 red.bricks.example.
This will make the DNS server return an appropriate response for
queries for MX RRs for "green.bricks.example", "blue.red-
bricks.example" and even "light.blue.bricks.example". However, the
wildcard has two counter-intuitive properties:
Koch Expires July 1999 [Page 8]
INTERNET-DRAFT RIPE DNS Guide January 1999
1) It does not cover any owner name for which *any* type of RR is
explicitly defined. If you associate an A RR with the name
"blue.bricks.example", the wildcard above will not lead to an MX
RR defined for "blue.bricks.example". It is even worse: the
wildcard would not even work for "blue.bricks.example" if you just
defined any record for "dark.blue.bricks.example".
2) It does not cover the name itself, which trivially follows from
the previous paragraph. So, the wildcard above does not cover
"red-bricks.example".
Use of wildcard owners is most common, but not restricted to, for
defining MX RRs. However, die to the problems described above and
some other problems your mail server may encounter when it lives in a
zone with wildcard MX RRs, they should be avoided. [XXX name useful
cases]
3. Valid hostnames
There has been a lot of confusion on which characters are valid in
hostnames. Partly this has come from the question what a hostname
is. A good rule of thumb is to consider every domain name with an A
RR attached to it and every domain name expected to have an A RR
attached to it (like targets in MX and NS RRs) a hostname.
For domain names in general, no character restrictions apply.
Hostnames are restricted to letters (since the DNS is case
insensitive, no further distinction is necessary), digits, the hyphen
and, of course, the dot to separate names on different domain levels
(labels). A hyphen must not be the first or last character in a
label. The underscore "_" is not a valid character for hostnames,
neither are the ampersand or a space, to name a few. There's nothing
magic about the "_", it is just that it seems to be popular but was
not included in the allowed set once it was defined.
TLD registries will usually, although registering domain names
instaed of just hostnames, enforce hostname restrictions. They may
also define additional syntax requirements.
4. Reverse Mapping
TBD
5. Mistakes to avoid
Practice has been showing that novice DNS administrators tend to make
some particular mistakes more often than others. The following list
deals with the most common misunderstandings.
Koch Expires July 1999 [Page 9]
INTERNET-DRAFT RIPE DNS Guide January 1999
5.1. Secondaries not necessarily act as resolvers or forwarders
As mentioned earlier, there is a difference between serving DNS zones
and resolving DNS queries. Both services may be offered by the same
machine, but for security, performance and various operational
reasons, your ISP may have dedicated different systems to either
task. [...]
5.2. Zone transfer restrictions can be too strict
A zone transfer (AXFR) is a bulk transfer of all the DNS data
contained in a DNS zone. Secondaries copy the zone data from the
primary by the way of an AXFR query. On several occasions, malicious
individuals or groups have been using this zone transfer for
harvesting names and addresses. Later they probe each system found
for well known security holes to find victims for system breakins. To
avoid this, some people suggest to restrict outgoing zone transfers
on your DNS server. While this "information hhiding" may stop some
kids, it will increase your system security be exactly zero. First,
to work, this scheme would have to be implemented at all your
secondaries, too. You can't be sure about that and doing so would
sometimes be infeasible for the respective server maintainers. Even
worse, nobody could stop a harvester from querying for particular or
popular names within your zone, like "www", "mail" or "ftp". At last,
an intruder would not have to bother with asking the DNS in advance.
They just scan complete IP address ranges for vulnerable systems. So,
to be safe, protect your end systems and network infrastructure, do
not just hide information.
However, even if you choose to restrict AXFR, you must not prevent
your zone's secondary servers from transferring the data. In addition
the TLD registry and your ISP may require to AXFR your zone data for
validation purposes.
A last word on this: not all AXFR attempts will show you some hacker
is looking at your data. Sometimes there are just curious
individuals, somebody tracking down a problem or one of the various
projects, which scan through the DNS to produce statistics (the
monthly RIPE DNS hostcount is a prominent example). If in doubt,
consult your ISP.
5.4. enabling WINS lookup
TBD
6. Acknowledgements
TBD
Koch Expires July 1999 [Page 10]
INTERNET-DRAFT RIPE DNS Guide January 1999
7. References
[ALLIU98] Albitz,P., Larson,M., Liu,C., "DNS and BIND", O'Reilly, 3rd
ed., September 1998
[ALLAL98] Albitz,P., Larson,M., Liu,C., "DNS on Windows NT",
O'Reilly, November 1998
[RFC1034] Mockapetris,P., "Domain Names - Concepts and Facilities",
RFC 1034, STD 13, November 1987
[RFC1035] Mockapetris,P., "Domain Names - Implementation and
Specification", RFC 1035, STD 13, November 1987
[RFC2219] Hamilton,M., Wright,R., "Use of DNS Aliases for Network
Services", RFC 2219, BCP 17, October 1997
[RFC2142] Crocker,D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND
FUNCTIONS", RFC 2142, May 1997
[.......]
8. Author's Address
Peter Koch
Universitaet Bielefeld
Technische Fakultaet
Postfach 10 01 31
D-33501 Bielefeld
Germany
+49 521 106 2902
<pk at TechFak.Uni-Bielefeld.DE>
Koch Expires July 1999 [Page 11]
- Previous message (by thread): DRAFT: "RIPE Guide To Setting Up a DNS Server"
- Next message (by thread): DRAFT: "RIPE Guide To Setting Up a DNS Server"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ dns-wg Archives ]