Page is a not externally linkable
- Hardware and OS Related Technologies
-- Website Technology Issues
---- DNS and Name Servers Setup Help

bakedjake - 3:41 pm on Jan 2, 2004 (gmt 0)


Hi Avitar, Welcome to WebmasterWorld!

First, I'd recommend that you do DNS on UNIX. There are significant advantages to using a UNIX box to do so, as well as significant disadvantages to using Microsoft's DNS software solution. I say this not to start a flame, but strictly from 8 years of operational experience running a service provider.

With that in mind, I'm going to approach this from a UNIX perspective.

If you can find an old box lying around, it will be fine for DNS. A pentium 233 with 64 MB of RAM will be plenty enough for a DNS only box, unless you're a major service provider. Start out by installing your favorite flavor of UNIX on the box. Any of the Linux/BSDs will work fine. I wouldn't recommend Solaris due to the often strange library implications, but it will certainly work as well.

You'll want as minimum of an install as possible. since you won't be serving web or using this box as a desktop, forget the FTP server, the web server, or any of the X11 components. As a matter of fact, you can even forget the documentation, all program sources (but leave the kernel sources just in case), most of the image and other graphical libraries, etc. My DNS boxes use about 100MB of space for the entire system, and most of that is external utilities (such as midnight commander) that I use for administration. The object here is lean.

You'll want SSH on the system for file transfers and administration. Both commercial SSH and OpenSSH work fine. I prefer commercial SSH.

Next, you'll need to install DNS software on the machine. You have a decision to make here: Which software, (and in BIND's case) which version. The two major DNS servers on UNIX are BIND and djbdns. Which software is a touchy subject and the debate of many-a-flame-war. Here's the facts, and then I'll tell you my opinion, and then you can decide for yourself.

BIND:

  • Widest support from providers - most of your upstream providers will probably be using BIND, and that will probably be the only software they will support.
  • Largest Userbase - Most people in the world do run BIND. Therefore, most people running DNS servers are familiar with it. You won't have to look far on public mailing lists for help.
  • Wider software support - There are many, many more utilities available for BIND to make administration easier. That said, this isn't always a good thing.
  • DHCP dynamic updates - BIND supports dynamic DNS naming vis-a-vis DHCP. This is really only useful if you're running some sort of service provider or large corporate network, but is important in those situations.
  • Professional support is available from the people that write the software.

    djbdns:

  • Secure - djbdns hasn't seen a release in 3 years, with good reason. There's a $500 security reward if a security bug is found. None have been found so far.
  • Efficient - It's up to 10x faster than BIND in my tests. Others have reported even better results.
  • Easy to setup and administer - BIND and djbdns use different syntax for DNS files, but IMHO, if you're new to DNS, you won't notice a difference.
  • Clueful userbase - Honestly, in my experience, the level of user knowledge on the djbdns lists vs. the BIND lists is several notches higher.

    I prefer djbdns. The remainder of this guide will focus on concepts, however, and should be pertinent to any DNS software used. Please have your DNS server software's documentation handy - it is the final source on the syntax used to create the records I'll discuss below.

    Keeping this as simple as possible, let's look at the layers of DNS that you'll be concerned with:

  • TLD servers - .com/.net/.org/etc. servers tell the world where the respective DNS servers for domains below them are located.
  • Domain servers - This is the level you'll be setting up a server at. For example, mydomain.com's DNS servers hold all of the information for all information related to mydomain.com's systems, and either delegation or address information for subdomains contained under mydomain.com.

    When you register a domain, you tell the registrar where the DNS servers for your domain are located. The registrar then gives the TLD servers that information. These are the entries that you see in WHOIS. Most registrars' default is to keep the domain located on their DNS servers, so you'll probably have to change this. Pick two IP addresses from your assigned space and two names for the servers. The rest of this guide will use the following as an example:

    Our domain:
    mydomain.com

    The locations and names of our nameservers:
    10.10.10.1 - ns1.mydomain.com
    10.10.10.2 - ns2.mydomain.com

    Our other servers:
    10.10.10.3 - www.mydomain.com
    10.10.10.4 - mail.mydomain.com
    10.10.10.5 - proof.mydomain.com

    Once you've selected those, go to the registrar and enter the information into their systems for the domain you wish to serve DNS for. It will take a day to propagate.

    For the purposes of this lesson, we're going to set both servers up as primary DNS servers. There alternate ways of setting them up so that they automatically replicate, but these are complex and often unnecessary. What this means for you is that you'll replicate each of the steps below on both (or all) of the nameservers you'll be setting up.

    Note: There are preliminary steps necessary in setting up the software on your computer. You'll have to compile the software, make sure it runs at startup, and set up the control files. Please do this first: This guide strictly concentrates on the actual dns datafiles.

    The Real Work

    There are really only three types of records that are required to serve DNS. Besides those two records, there are two other records that are highly desirable to have.

    First step - You'll have to create a START OF AUTHORITY (SOA) record for your datafile. The default values below will be fine to use. I won't delve into this record here (it's dumb, and sort of a BIND-ism), but feel free to look it up in your server's documentation. Example:

    BIND9 - SOA Record

    @ IN SOA ns1.mydomain.com. postmaster (
    2003081302
    3H
    15M
    1W
    1D)

    Note: on ns2.mydomain.com, you'll need to change the SOA record to say ns2.mydomain.com instead of ns1.mydomain.com. This is the only part where the information in the servers will differ.

    No SOA record is required for djbdns - the server creates it automatically.

    The second step in setting up you DNS datafiles are to tell your serving software that it is an authoritative nameserver. You'll need to do this for all of the nameservers that will be serving DNS for your domain. Do this by adding a NAMESERVER (NS) entry to your software's DNS datafile. Example:

    BIND9 - NS Record

    NS ns1.mydomain.com.
    NS ns2.mydomain.com.

    djbdns - NS Record

    .mydomain.com::ns1.mydomain.com
    .mydomain.com::ns2.mydomain.com

    Good! Now, our name servers know that they are the authority for mydomain.com. The third step is to assign a forward mapping - basically, assigning a name to an IP address. This is called an ADDRESS (A) record. You'll want an address record for every name you wish to use within your domain. Now, let's go ahead and assign the mappings for our example setup:

    BIND9 - A Record

    ns1.mydomain.com. A 10.10.10.1
    ns2.mydomain.com. A 10.10.10.2
    www.mydomain.com. A 10.10.10.3
    mail.mydomain.com. A 10.10.10.4
    proof.mydomain.com. A 10.10.10.5

    djbdns - A Record

    =ns1.mydomain.com:10.10.10.1
    =ns2.mydomain.com:10.10.10.2
    =www.mydomain.com:10.10.10.3
    =mail.mydomain.com:10.10.10.4
    =proof.mydomain.com:10.10.10.5

    Great! Actually, at this point, once you've set up these files, fired up your DNS server, and the changes propagate from your registrar, you'll be serving DNS to the world! Someone can type in www.mydomain.com, and your DNS server will happily point them to your web server.

    Now, let's examine the other two desirable records I talked about.

    The first is called the MAIL EXCHANGER (MX) record. Even though we've assigned an address to the mail server above, we still need to tell other mail servers that want to deliver mail to us which server(s) is running a mail service. We do this by giving our mail server an MX record:

    BIND9 - MX Record

    MX 10 mail.mydomain.com.

    (The 10 in this example is called the mail exchanger priority. It's outside of the scope of this guide, but it basically tells the world which order mail should be delivered when multiple mail servers are used. You can safely use the value of 10).

    djbdns - MX Record

    @mydomain.com::mail.mydomain.com

    Guess what? At this point, your friends can send you email @mydomain.com, provided you've set up a mail server on mail.mydomain.com!

    The next type of record you might want is called a REVERSE NAME MAPPING (PTR) record. This functions much like an A record, except that it maps an IP address to a name, instead of the other way around. This record is not required, but many administrators like to have it for completeness, and some mail servers won't deliver to other mail servers without a PTR address.

    In order to use PTR records, you'll have to ask the provider of your IP address space to deligate responsibility of reverse name mapping to you. Read that again, please. It's the biggest source of misunderstanding of reverse address mapping. In order to use PTR records, you'll have to ask the provider of your IP space (usually the guys who provide your Internet connectivity) to delegate control of reverse mapping for your IP block to you.

    Once you've done that, it's easy to use a PTR:

    BIND9 - PTR Record

    1.10.10.10.IN-ADDR.ARPA. PTR ns1.mydomain.com.
    2.10.10.10.IN-ADDR.ARPA. PTR ns2.mydomain.com.
    3.10.10.10.IN-ADDR.ARPA. PTR www.mydomain.com.
    4.10.10.10.IN-ADDR.ARPA. PTR mail.mydomain.com.
    5.10.10.10.IN-ADDR.ARPA. PTR proof.mydomain.com.

    Notice the notation: It's backwards. Please keep an eye on that. :)

    No PTR records are necessary when using djbdns - the server creates them for you automatically.

    Whew, take a breath. You're done, and now serving DNS!

    Thread source:: http://www.webmasterworld.com/website_technology/3009.htm
    Brought to you by WebmasterWorld: http://www.webmasterworld.com