DRAFT: "RIPE Guide To Setting Up a DNS Server"

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]