BIND v. 8 - An Overview
by Rick Moen
Revised: Thursday, 2001-08-23
Master version will be at http://linuxmafia.com/faq/Network_Other/bind-lecture.html, and I'll try to improve it there.
History and Context:
About the time the ARPAnet adopted TCP/IP (early '80s), admins of the several hundred machines involved realised they had a problem: The master HOSTS.TXT file listing all those machines, maintained by the Network Information Center (NIC) at SRI International in Menlo Park, CA, was getting unwieldy. HOSTS.TXT was/is a full listing of sundry details about those machines, issued weekly until 1992. Stripped of non-Unix-relevant details, it gave us the standard /etc/hosts file format.
HOSTS.TXT (and /etc/hosts) was a static association between hostnames and IP addresses, allowing either to be looked up, given the other. (Remember that lookup can go either way.) The NIC at SRI was passed to Network Solutions, Inc. of Virginia, a consortium formed by several companies initially under NSF grant (and now Dept. of Commerce contract), became known as the InterNIC, and now is in bureaucratic limbo as a result of organisational intrigue among the increasingly commercial Network Solutions (now owned by Verisign), the almost-self-appointed ICANN group, and the U.S. Dept. of Commerce.
Paul Mockapetris of U.C. Berkeley's Computer Science Research Group (CSRG, the BSD people) created the JEEVES program to be a scalable, decentralised replacement for HOSTS.TXT. Shortly afterwards, Paul Vixie of the Internet Software Consortium (ISC) wrote its replacement, BIND (Berkeley Internet Name Daemon) -- introducing the Domain Name System in so doing (replacing the increasingly unworkable "bang-path" system, where one specified an absolute path relative to a "well-known" host, e.g., "ucbvax!zgp!zork!uncle-enzo").
I call DNS decentralised, but it puts all names in a theoretical hierarchy relative to a "root" or "origin" point, denoted by a period. The divisions below root are the Top Level Domains (TLDs): com, net, org, mil, gov, edu, us, ca, mx, no, uk,....
One subdivides further into Second Level Domains (the "domains" one registers), and arbitrarily as desired beyond that, e.g., well.sf.ca.us .
BIND went up to v. 4.x, then was rewritten as v. 8.x to have more-flexible security archtitecture and a different configuration file format, and then stalled at 8.x for a long time. 8.x is obsolescent, as we'll discuss below.
Client/Server Architecture:
DNS requires at least one DNS server exist: This machine runs (e.g.) BIND. All machines that want to use DNS services must have the corresponding client software, called the DNS resolver. On Linux, this is built into the system libraries, and configured using /etc/resolv.conf . But don't forget that /etc/nsswitch.conf also controls the resolver's functioning, determining whether other sources of name information such as LDAP, NIS+, etc. should be consulted instead, and in what order of preference.
What Makes a Nameserver Tick:
A DNS nameserver, at a minimum, has a list (named.root, root.hints, or db.root) of servers that have guaranteed-accurate (authoritative) information about TLDs.[1] If it has only that, it is called a caching nameserver, in that it has no information of its own, but just stores answers to queries it has passed on to other nameservers. Linux distributions' default setup of BIND is exactly like this.
In addtition, it can have tables of DNS information (forward and reverse lookup) about specific parts of the total namespace. These are stored in "zonefiles". What zonefiles a nameserver manages is described in /etc/named.conf . Example:
options {
directory "/var/cache/bind";
forwarders {
209.81.9.1;
165.90.49.12;
};
};
zone "." {
type hint;
file "/etc/bind/db.root";
};
zone "localhost" {
type master;
file "/etc/bind/db.local";
};
zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};
#For Rick Moen
zone "linuxmafia.com" {
type master;
file "/etc/bind/linuxmafia.com.zone";
allow-transfer {
140.174.70.1;
140.174.70.58;
198.186.202.135;
};
};
#For Seth David Schoen
zone "loyalty.org" {
type slave;
file "/var/cache/bind/loyalty.org.zone";
masters {
63.192.8.227;
};
};
If you see /etc/named.boot (with a different internal format), then it's a BIND v. 4.x server, not 8.x. BIND v. 8 includes a perl script to generate named.conf from named.boot .
The "slave" vs. "master" distinction is one of whether this nameserver is publisher or publishee for the zone in question. A nameserver that is slave for a particular domain contacts its master occasionally to see if it needs to refresh its zonefile copy (called a "zone transfer").
Example forward-lookup zonefile:
; hosts file for named for linuxmafia.com /etc/bind/linuxmafia.com.zone
$ORIGIN linuxmafia.COM.
@ IN SOA linuxmafia.COM. rick.deirdre.NET. (
2001032301 ; serial
10800 ; refresh 3 hours
3600 ; retry 1 hour
3600000 ; expire 1000 hours
86400 ; minimum 24 hours
)
;
IN NS myrddin.imat.COM.
IN NS ns1.valinux.com.
@ IN A 209.81.22.250
IN MX 0 linuxmafia.COM.
uncle-enzo IN A 209.81.22.250
enzo IN A 209.81.22.250
mail IN A 209.81.22.250
www IN A 209.81.22.250
ftp IN A 209.81.22.250
IN HINFO AMI-486DX2/66 Linux-v2.0.36
IN MX 10 uncle-enzo
guido IN A 209.81.22.250
debian IN A 209.81.22.250
IN HINFO FIC-K6/233 Linux-v.2.2.1
IN MX 10 guido
tikihut IN A 24.6.199.191
IN MX 10 tikihut.linuxmafia.com.
IN HINFO unknown Linux
; "Ben Kennnedy" <bkennedy@haverford.edu>
tungsten IN A 63.193.247.201
IN MX 10 tungsten.linuxmafia.com.
IN HINFO unknown Linux
; "Bill Schoolcraft" <bill@billschoolcraft.com>
SOA (start of authority) header explanation:
serial = integer used to signal a querying slave server that there's
a new zonefile it must fetch. By convention, use date +
two digits, and count upwards from 00 as you save changes
and restart BIND.
refresh = how often in seconds slaves should start trying to ask the
master if there's a new zonefile.
retry = how often to subsequently reattempt contact after a refresh
attempt fails (shorter interval)
expire = time after which non-refreshed data should be regarded as
stale and no longer used (must be set higher than refresh)
TTL (minimum) = time to live at other caching servers other than slaves
Other items:
SOA = start of authority. Puts limits on how the data are
used, indicates what host is master, and indicates how
to reach the admin.
IN = Internet. There are not yet any other keyword for this
field.
A = Address. Regular forward name-to-IP record.
NS = Nameserver.
MX = Mail exchanger. Lower number indicates higher priority.
These are the places where mail addressed to the named
host should be delivered, instead. Each MX will accept
mail and then redeliver it to the lowest-numbered host
it can reach. Thus, the higher-numbered MXes function as
temporary mail caches.
HINFO = Host info (text field of arbitrary information you want
to put there).
CNAME = (not seen here) Canonical Name or host alias name
Note the period after complete hostnames: This is the root or origin. If you fail to specify it, BIND will assume you mean relative to the value of $ORIGIN (also denoted by "@").
Note the odd, unique-to-BIND convention for specifying the admin's e-mail address: "rick.deirdre.net": Turn the "@" symbol into a period, since "@" is reserved to mean $ORIGIN.
Spot the bonehead error: Only one mail exchanger (MX) for linuxmafia.com. I fixed this, only to be bitten by the fact that myrddin.imat.COM refuses to handle mail for hosts with no matching reverse DNS. (I fixed that next.) Which leads us to:
Example reverse-lookup file:
$ORIGIN 174.140.in-addr.arpa.
70 IN SOA myrddin.imat.COM. rrc.myrddin.imat.COM.
(
1998020301
3600
1000
604800
259200 )
IN NS myrddin.imat.COM.
IN NS lll-winken.llnl.GOV.
IN NS polaris.llnl.GOV.
IN NS mail.coffeenet.net.
$ORIGIN 70.174.140.in-addr.arpa.
1 IN PTR myrddin.imat.COM.
2 IN PTR nevyn.imat.COM.
3 IN PTR wyrm.imat.COM.
4 IN PTR grendel.imat.COM.
5 IN PTR taliesin.imat.COM.
10 IN PTR seahunt.imat.COM.
22 IN PTR ymir.imat.com.
21 IN PTR hugin.imat.COM.
31 IN PTR atlas.sfpcug.ORG.
32 IN PTR eos.sfpcug.ORG.
51 IN PTR mocha.coffeenet.NET.
52 IN PTR latte.coffeenet.NET.
53 IN PTR espresso.coffeenet.NET.
54 IN PTR sumatra.coffeenet.NET.
55 IN PTR java.coffeenet.NET.
56 IN PTR kenya.coffeenet.NET.
57 IN PTR macchiato.coffeenet.NET.
58 IN PTR mail.coffeenet.NET.
59 IN PTR crema.coffeenet.NET.
60 IN PTR americana.coffeenet.NET.
100 IN PTR mordred.imat.COM.
101 IN PTR www.kops59.com.
102 IN PTR www.txlonghorn.com.
103 IN PTR www.graphicmode.com.
104 IN PTR www.railsplitters.com.
105 IN PTR www.sourceservsf.com.
PTR = Pointer. Regular reverse IP-to-name record.
Note the reverse-naming convention that this zone's name is the IP net number (140.174.70.0) inverted (as 70.174.140) with "in-addr.arpa" appended. Thus, the first PTR record specifies what the reverse lookup value for reverse-domain entry "1.70.174.140.in-addr.arpa" is.
Note that "in-addr.arpa" is a TLD, just like ".com". (Well, technically, ".arpa" is the TLD and "in-addr.arpa" is its one and only SLD.)
There are many services on the Net -- e.g., extremely paranoid e-mail and ftp server hosts -- that refuse to do business with remote machines whose forward and reverse lookups don't match. If such a host got a connection from IP address 140.174.70.1, it would first see what reverse lookup value it got from "1.70.174.140.in.addr.arpa". From the above, it would get "myrddin.imat.COM." Then, it would do a forward lookup on that result: In the authoritative zonefile for SLD "imat.COM" (not shown), it would find an "A" record associating hostname "myrddin.imat.COM" to IP address 140.174.70.1 . And the check would be complete.
Omitting correct reverse DNS (or failing to ensure that it matchies the corresponding forward lookups) is a common configuration error: Most businesses fail to set up reverse DNS at all, and many ISPs drag their feet on either setting it up correctly or delegating it for their IP ranges.
If you have less than a class C subnet, delegating the reverse zone for just your netblock is tricky[2], and many ISPs don't even know how to do it.
Delegation Technique:
(Not detailed here.) For a given subdomain discussed in a zonefile, you can include an NS record to refer queries to that domain to the specified nameserver host. Thus, NS1.COMPANY.COM might refer queries about all hosts of the form *.hq.company.com to some subsidiary nameserver at HQ that holds all relevant records for that subdomain.
Inherent Security Problem in Any DNS:
DNS reveals information about the network it serves. If your company's complete DNS is publicly reachable, attackers can use it for "resource discovery": figuring out where the crown jewels are, and what's worth getting at. Some advanced techniques such as "split DNS" is used to limit the amount of outside exposure.[3]
Security Problems: BIND v. 8 end-of-life
Around 1999, ISC decided v. 8 could no longer be maintained and had ultimately hopeless security problems, and so commissioned a from-scratch rewrite, which resulted in BIND v. 9.x . 9.x is totally compatible, except that it will not tolerate syntax errors condoned by 8.x. Any clean set of 8.x zonefiles and named.conf will migrate perfectly to 9.x. Mine did.
The BIND v. 8 security problem can be partially contained by running it in a chroot jail, but this is just a band-aid solution because any process with root authority can break out of a chroot jail.
Common errors:
- Omitting the period from the end of hostnames (in DNS
zonefiles).
- Failing to increment serial numbers. (Thus the adage that
you always end up editing a zonefile twice.)
- Forgetting to restart BIND after editing
zonefiles.
- Failing to check /var/log/messages, after restarting
BIND. If you don't do this, you may not even notice that BIND
refused to load some zones because of syntax errors or other
problems.
- Failing to have reverse DNS.
- Failing to use an out-of-band e-mail address in the SOA
header: You don't want to be unreachable by people wanting to
tell you that your DNS has trouble, because your DNS has
trouble.
- Forgetting about the order of lookups in
/etc/nsswitch.conf
Tools:
dig, nslookup: General-purpose command-line tools for removely
querying DNS servers. nslookup is "deprecated" because
it relies on some BIND v. 8 characteristics that will
be going away.
nslint, dnswalk: Utilities to traverse zonefiles looking for errors.
cvs: Need I mention that you should check all your DNS
files into CVS? Otherwise, you'll have fun figuring
out how and when you messed them up.
pdnsd: Good caching-only DNS server. Unlike a caching-only
BIND server, this software stores its cache on-disk
rather than in RAM only. That makes it very useful
for workstations and laptops.
Exercises:
1. Configure your copy of BIND v. 8 to serve up deliberately-bogus zonefile "cabal.gov" (which you'll have to populate), as a master server. Make sure you also set up a matching reverse file reflecting your local IP addresses. Run it, and query some of its records using nslookup or dig.
You'll find a complete set of zonefiles and configuration files for your reference, at http://linuxmafia.com/pub/linux/network/zonefiles.tar.gz . This is from my former landlord Richard Couture's DNS setup, and has been frequently cited as a teaching example in serious, in-depth DNS classes.
2. Configure a second machine to do slave DNS for those domains. Update the DNS on the master server, restart. Verify that the updated information propagates to the slave server.
Further Information:
DNS and BIND by C. Liu and P. Albitz from O'Reilly & Associates (ISBN 0-937175-82-X). 3rd edition.
DNS HOWTO
http://en.tldp.org/HOWTO/DNS-HOWTO.html
Chroot BIND8 HOWTO (covers v. 8)
http://en.tldp.org/HOWTO/Chroot-BIND8-HOWTO.html
Chroot BIND HOWTO (covers v. 9)
http://en.tldp.org/HOWTO/Chroot-BIND-HOWTO.html
Secure BIND Template by Rob Thomas
http://www.cymru.com/Documents/secure-bind-template.html