Preventing Vexation and Woe: DNS Fundamentals, Part 2

By Carla Schroder | Feb 4, 2003 | Print this Page
http://www.enterprisenetworkingplanet.com/netos/article.php/10951_1579041_3/Preventing-Vexation-and-Woe-DNS-Fundamentals-Part-2.htm

In Part 1 of our tutorial on DNS fundamentals, we looked at what happens on the client side of DNS. Today we leap into managing DNS on the server side.

Running your own DNS server offers greater control and flexibility. I want to emphasize the importance of being careful when running a public DNS server. Please be sure you know what you are doing and are willing to do what it takes to manage it competently. Any connected machine has the potential to spread havoc far and wide.

Note that it isn't necessary to run a DNS server to manage your own DNS, as there are all kinds of third-party DNS services available. They bear the headaches of keeping the machines running -- all the customer needs to know is how to enter their own configurations.

When studying DNS, you'll notice that teaching materials and training courses are very BIND-centric. While standards are supposed to be application- and platform-agnostic, horrid BIND hacks such as TSIG, IXFR, and NOTIFY have somehow wormed their way into DNS standards. Admins who choose DNS servers other than BIND must pay extra-close attention to their documentation. To quote my favorite guru, Ed Sawicki of Alcpress.com:

"The djbdns folks think it's silly to use these BIND-specific mechanisms when we already have excellent general purpose protocols and software to do these things. If you want to move zone files between computers -- and the files might be large -- you can use rsync, which only moves changes. If you're concerned that these file transfers should be secure, run rsync on top of SSL. If you want to be sure you're sending a zone file to a legitimate secondary and you're not being spoofed, configure your firewall and, optionally, use certificates."

djbdns is a collection of DNS-management programs, including tinydns (the name server) and dnscache (the caching component). In my opinion, djbdns is preferable in every way -- it's small, fast, stable, scalable, and secure. See Resources for further discussions of the technical merits of BIND and djbdns. The examples on the following pages use tinydns syntax.

Page 2: Receiving Delegations

Receiving Delegations

No, this isn't a black-tie diplomatic event, sorry. This is the official term for registering your public name server so that the Internet can find it. You need to own a domain name and a static, routable IP. First get your DNS server installed, configured, and thoroughly tested, then register it using the FQDN of your nameserver and the IP address. This puts your name server into the Verisign Global Registry. Many domain name registrars, ISPs, and DNS service providers offer name server registration. Be sure to check with your ISP's hostmaster for possible conflicts. There's no need to register a private, internal name server.

RR

Resource records are the foundation of DNS; everything about a domain or a host is recorded in resource records. A (address) records are the most commonly queried RR. An A record maps a given hostname, which is called a label, to an IP address. An A record must point to a single address only. Multiple labels 7can be assigned to the same IP; just be sure to give each one its own line. Multiple IPs can also be given to the same label; again, each gets its own line. An increasing number of Web sites no longer require the 'www' prefix:

+www.foosite.com:1.2.3.4
+foosite.com:1.2.3.4

On the other hand, some admins forget the A record specifiying 'www'. In this case, Web surfers who do use the 'www' prefix get an error message and do not reach the site. This stuff ain't magic -- computers are completely literal and must be told exactly what to do.

Perhaps there are multiple servers for load balancing or round robin DNS:

+www.foosite.com:1.2.3.4
+foosite.com:1.2.3.4
+www.foosite.com:1.2.3.5
+foosite.com:1.2.3.5

CNAME

Canonical names are simply aliases pointing to A records:

+www.foosite.com:1.2.3.4
Cfoosite.com:www.foosite.com

A CNAME must point only to a hostname with a valid A record. The advantage is when you need to change the IP, only one record needs to be changed. The disadvantage is that it forces an extra query -- two hits to get to a CNAME instead of one for an A record. I prefer making more A records. Changing IPs should be a relatively rare occurence -- why create a performance hit for daily operations?

Page 3: PTR

PTR

Pointers are reverse lookups, resolving IPs back to hostnames. They are not required but are useful when certain applications use reverse queries for authentication. In tinydns, the equals sign creates an A record and PTR:

=www.foosite.com:1.2.3.4

The plus sign creates a forward-lookup only.

NS

The authoritative name server for the domain. Every domain is required to have at least two authoritative name servers. You may have as many as you like.

SOA

Start of authority defines the primary name server and global variables. Every zone file must contain one SOA. A zone file is simply the DNS settings for a particular domain.

TTL

Time to live tells a querying name server how long to keep a record in its cache before coming back and pestering your name server again.

MX

Mail exchange provides the hostname for your mail server. MX records, like CNAMEs, must point to an A record -- never ever an IP address (which is a common mistake).

Zone Transfers

This means keeping a particular DNS database, or zone file, synchronized between two nameservers. This provides redundancy in case one should fail. To quote Ed Sawicki again: "Zone files are plain text files, so it doesn't take much sophistication to move them between computers." There's no shortage of file transfer protocols, yet BIND uses a file transfer protocol that is unique to it. With djbdns, administrators are told to simply push the updated zone file to the secondary using whatever combination of protocols/software does the job:

  • rsync
  • rsync over SSL
  • rsync over SSH
  • scp
  • cp over a VPN
  • etc... "

djbdns provides axfrdns for zone transfers between tinydns and BIND. Zone transfers are more of an issue if you run a public nameserver; redundancy and transfers are not required for private name servers.

Page 4: Separating DNS Caches From DNS Servers

Separating DNS Caches From DNS Servers

This is a crucial step for securing DNS. Caches and servers must have different IP addresses. If they share the same IP, an intruder who gains control of one will be able to control both, which means controlling both your incoming and outgoing DNS. It also means they can hijack your email and all traffic intended for your domain.

The modular structure of djbdns means installing only what you need to use. Rule #1 of security is unnecessary services increase vulnerability.

dig

dig, domain information groper, is a dandy little utility and study tool. Use it to study how other DNS admins configure their zones and to see how your own zones look from the outside.

Final Words

DNS is a surprisingly large subject. The djbdns home page is a great place to start, as it contains tutorials for every aspect of DNS. See also the relevant RFCs, they explain what all those mysterious abbreviations mean in more detail.

Resources
RFC 1035. See also 1591, 2181, and 3071
djbdns home page
Stroud's CWSApps, search here for Windows DNS and proxy software
Alcpress
Global Registry
Tinydns: Kiss Your Bind Good-Bye
Kiss Your BIND Good-bye: In-Depth Configuration with Tinydns
Webopedia
bind vs djbdns thread on the BIND Users Mailing List


» See All Articles by Columnist Carla Shroder