August 29, 2014
 
 
RSSRSS feed

Buck DNS Monoculture with BIND Alternatives

Painless DNS, part 1

  • July 31, 2008
  • By Carla Schroder
Painless DNS, part 1 by Carla Schroder

DNS is fundamental to network operations, but rather surprisingly, given the usual free/open source software community's habit of having multiple versions of everything, it has evolved into a DNS server monoculture dominated by ISC BIND (Berkeley Internet Name Domain). All other issues aside, such as security and performance, monoculture is not healthy. There's a whole world outside of BIND; a pleasant world full of DNS servers that are simple to configure, and reliable and secure to use.

Out of several good choices, we're going to look at MaraDNS and Dnsmasq. MaraDNS is great for both caching and authoritative name serving, and claims to be highly secure. Dnsmasq is a great program for name services on the LAN: DNS caching, local name resolution, and DHCP.

Honorable mentions go to PowerDNS and NSD, which I'll get to at some future date. PowerDNS, like MaraDNS and BIND, is both an authoritative name server and caching resolver. NSD is a robust, fairly-simple-to-use authoritative-only server. How robust? At least one of the root nameservers, k.root, switched from BIND to nsd.

Other DNS Servers
Admins who want to plan for the future have to choose carefully. There are a number of DNS server corpses littering the landscape — projects that were started, then abandoned for one reason or another. GnuDIP, MooDNS, Dents, OakDNS, CustomDNS and dproxy are just a few examples.

The most reliable way to future-proof software is to give it the right license. MaraDNS is released under a BSD-type license, and Dnsmasq uses the GPL. There are no guarantees, of course, but if they ever do become abandonware, or turn closed-source like Nessus, it will be legal for someone else to pick them up and carry on.

This is why I started looking for alternatives to my personal favorite DNS server suite, djbdns. Professor D. J. Bernstein, its creator and maintainer, does not allow the distribution of modified binaries. You may distribute patches, and you may modify it for personal use to your heart's content. Which is nice, but there is no way to build a community of developers and users to monitor and improve it, or to keep it alive. The future of djbdns is entirely dependent on Professor Bernstein. [note: Since this was originally published, djbdns has been released into the public domain.]

Being Your Own Hostmaster
Suppose you are running some public services, and you want to control your own authoritative DNS server. The alternative is to use a third-party service to manage your DNS, such as the hostmaster at your ISP, or your domain name registrar. But you would rather retain control yourself, for faster (and possibly better) service. While I think it is good for network and system administrators to have as much control as possible, the Internet is infested with mis-configured DNS servers, so please be careful and make sure you get it right.

Other considerations are security and uptime — can you keep your DNS server running and available, and keep the bad persons out? No DNS means visitors cannot reach your sites, unless they are canny and motivated enough to dig up and use your IP addresses. Cracked DNS means cracked everything on your network, including encrypted sessions.

To let the world know about your authoritative server you must register it. Your domain name registrar should provide this service. They usually require two IP addresses. It's not a bad idea to have a second DNS server hosted remotely, instead of having both of them on the same network. Ask a friend to host your secondary in exchange for you returning the favor, or use a commercial service.

Different registrars have slightly different requirements for the information they need from you. MaraDNS comes with the askmara command to help with this. After you set up your zone files, query them like this:

$ askmara my.domain.com. 127.0.0.1
Using your own domain name and IP address, of course. This will spit out information that you may need to complete your server registration.

Authoritative MaraDNS
First of all, make sure you get a current release in the 1.12 series. Ubuntu Dapper has the old moldy 1.0.35 release. Debian Testing and Unstable contain current releases. Fedora users can either use the spec file from Dag Wieers' repository and build their own RPMs, or build from sources. Building from sources is very easy.

The main MaraDNS configuration file is /etc/maradns/mararc. Start with a nice clean fresh one and save the old one as a reference. (You'll also find example configuration files in the source tarball.) Suppose your domain is alrac.com, with the IP address of 33.44.55.66:

ipv4_bind_addresses = "33.44.55.66"
chroot_dir = "/etc/maradns"
csv2 = {}
csv2'"alrac.com."' = "db.alrac.com"

The first line is the IP address of the DNS server. The second line tells Maradns to run in a chroot jail, and the location of the chroot. The third line tells MaraDNS to run in authoritative mode. This line must come before any lines defining the zone files. The fourth line configures /etc/maradns/db.alrac.com as the zone file for alrac.com. Don't forget the trailing dot on alrac.com.

Now we can create the zone file, /etc/maradns/db.alrac.com. Zone files contain the following fields:

name 'optional +time-to-live' 'optional record type' record-data
This example contains entries for our name server, Web server and mail server, all of which have different IP addresses. You must always have at least one nameserver:
alrac.com.     		  NS    ns1.alrac.com.
ns1.alrac.com. 	  FQDN4	  A    33.44.55.66
alrac.com.     	  FQDN4	  A    33.44.55.67
www.alrac.com. 	  	  A    33.44.55.67
mail1.alrac.com.  FQDN4   A    33.44.55.68
alrac.com.   		  MX 10 mail1.alrac.com.

You may order your entries however you like. MaraDNS contains a nifty shortcut for PTR records — the FQDN4 field, or "Fully-qualified domain name, IPv4", which automatically creates the PTRs. Be careful to not create duplicates — you just want one per IP address. If you prefer to write them out the long way, they look like this:

alrac.com.   A    33.44.55.67
67.55.44.33.in-addr.arpa. PTR alrac.com.

What if you have additional sub-domains, like forums.alrac.com and support.alrac.com? No problem, just add more A records:

forums.alrac.com.    A    33.44.55.69
support.alrac.com.   A    33.44.55.69

Multiple Domains
What if you have multiple domains under your all-powerful control? Add them to /etc/maradns/mararc, then create the appropriate zone files:

csv2'"alrac.net."' = "db.alrac.net"
csv2'"foober.org."' = "db.foober.org"
csv2'"pinball.name"' = "db.pinball.name"

Simple Load Balancing
MaraDNS performs simple load-balancing. Just list your servers like this in your zone file:

www.alrac.com.   A    33.44.55.70
www.alrac.com.   A    33.44.55.71
www.alrac.com.   A    33.44.55.72

Delegations
MaraDNS supports delegations. For example, compliments.alrac.com is hosted on a separate network, bignet.com, which is equipped to handle the huge traffic loads generated by alrac's adoring fans. This example, which goes in alrac.com's zone file, sends those requests to bignet.com's nameservers:

compliments.alrac.com. NS ns1.bignet.com.
compliments.alrac.com. NS ns2.bignet.com.
# glue records pointing to the other
# nameservers- always have these
ns1.bignet.com. 44.55.66.77
ns2.bignet.com.  1.22.33.44 
Then bignet.com has its own zone records for compliments.alrac.com.

Come back next week for more MaraDNS and Dnsmasq fun, and don't forget to read MaraDNS' exceptionally good documentation and man pages.

Resources

Article courtesy of Enterprise Networking Planet, originally published October 24, 2006

Sitemap | Contact Us