59
HOWTO: BIND 8 and BIND 9 on FreeBSD 4.x Glenn Sidman Updated: April 22, 2005 Note: This HOWTO is way out of date. Though the DNS specific information still applies today, the setup of BIND covered in this HOWTO no longer applies. Beginning with FreeBSD 5.3, BIND9 has replaced BIND8 as the default DNS server and comes installed to run in a chroot environment as user bind. Very briefly: With FreeBSD 5.3 and latter, simply run the "make-localhost" script from the /etc/namedbd directory. Then enable BIND9 by adding named_enable="YES" to the /etc/rc.conf file. You can then start named with the command: /etc/rc.d/named start. This will give you a caching-only DNS server that listens on the localhost interface. You can now configure "named.conf" to suite your needs, and DNS zone files if applicable. Perhaps someday I will finish the updated HOWTO, but know that this one will always remain posted for archival purposes. 1 - About This HOWTO 2 - Some Theory: How Does A Client Resolve Names? o 2.1 - Caching And Forwarding Name Servers o 2.2 - Master vs. Slave Name Server 3 - Installing BIND o 3.1 - Replacing The Base System's BIND o 3.2 - Using The Default Installation For BIND o 3.3 - Configuring rndc For BIND 9 o 3.4 - Old Tools Vs. New Tools 4 - Configuring BIND o 4.1 - Our foobar.example domain o 4.2 - Overview of zone data files o 4.3 - localhost.rev (Localhost Reverse Lookup Zone) o 4.4 - db.foobar.example (forward Lookup zone) o 4.5 - db.1.168.192 (Reverse Lookup Zone) o 4.6 - named.root (Root Hints File) o 4.7a - named.conf For Master Name Server

Bind Freebsd

  • Upload
    fahozo

  • View
    200

  • Download
    5

Embed Size (px)

Citation preview

Page 1: Bind Freebsd

HOWTO: BIND 8 and BIND 9 on FreeBSD 4.x

Glenn Sidman

Updated: April 22, 2005

Note: This HOWTO is way out of date. Though the DNS specific information still applies today, the setup of BIND covered in this HOWTO no longer applies. Beginning with FreeBSD 5.3, BIND9 has replaced BIND8 as the default DNS server and comes installed to run in a chroot environment as user bind. Very briefly: With FreeBSD 5.3 and latter, simply run the "make-localhost" script from the /etc/namedbd directory. Then enable BIND9 by adding named_enable="YES" to the /etc/rc.conf file. You can then start named with the command: /etc/rc.d/named start. This will give you a caching-only DNS server that listens on the localhost interface. You can now configure "named.conf" to suite your needs, and DNS zone files if applicable. Perhaps someday I will finish the updated HOWTO, but know that this one will always remain posted for archival purposes.

1 - About This HOWTO 2 - Some Theory: How Does A Client Resolve Names?

o 2.1 - Caching And Forwarding Name Servers o 2.2 - Master vs. Slave Name Server

3 - Installing BIND o 3.1 - Replacing The Base System's BIND o 3.2 - Using The Default Installation For BIND o 3.3 - Configuring rndc For BIND 9 o 3.4 - Old Tools Vs. New Tools

4 - Configuring BIND o 4.1 - Our foobar.example domain o 4.2 - Overview of zone data files o 4.3 - localhost.rev (Localhost Reverse Lookup Zone) o 4.4 - db.foobar.example (forward Lookup zone) o 4.5 - db.1.168.192 (Reverse Lookup Zone) o 4.6 - named.root (Root Hints File) o 4.7a - named.conf For Master Name Server o 4.7b - named.conf For Caching-Only Name Server o 4.8 - Configuring Forwarding and Forward Only

5 - Starting BIND o 5.1 - BIND 8 Only: Starting And Controlling named o 5.2 - BIND 9 Only: Starting And Controlling named o 5.3 - Testing BIND (Both versions) o 5.4 - Starting BIND (named) At Boot

6 - Securing BIND with chroot 7 - Updating named.root (Root server list) 8 - Troubleshooting and Testing BIND

Page 2: Bind Freebsd

o 8.1 - Troubleshooting Syntax And Other Configuration Errors o 8.2 - Testing Forward Name Resolution o 8.3 - Testing Reverse Name Resolution o 8.4 - Testing External Name Resolution o 8.5 - What Interface Is BIND Listening On? o 8.6 - What Version of BIND Is Running?

9 - Additional Resources

1.0 About This HOWTO

BIND, which is the Berkeley Internet Name Domain, is by far the most popular and best documented Domain Name System (DNS) server used on the Internet. The Domain Name System allows us to access other nodes by name rather than their IP addresses. It is obviously easier to remember a name rather than an IP address, but the biggest benefit of DNS is its ability lead us to the same node even if its IP address changes. There are currently two maintained branches of BIND--BIND 8 and BIND 9. BIND version 9 is a rewrite of version 8 intended to provide new features and improved security. This HOWTO covers both BIND 8 and BIND 9. Any differences in configuration will be noted.

While BIND's security reputation has been less than perfect, particularly with version 4, it has improved greatly and can be secured reasonably well. With a plethora of documentation available for BIND, you will probably want to learn with BIND and then consider securing it with 'chroot' or 'jail' or even using a different name server if security is an issue. Most importantly, if you do not intend to provide external name resolution (for outsiders), do not allow BIND to listen for queries from the Internet which is covered later in this HOWTO. I will also cover chrooting BIND into it's own virtual environment (sandbox) as well as running BIND with least privileges.

BIND 8.3 is included with the base system for FreeBSD 4.x and 5.0. It is recommended that you upgrade to the latest version whether it be the BIND 8 branch or the BIND 9 branch. Upgrading to BIND 9 requires only slightly more effort than upgrading the base system of BIND 8 (this assumes you do not already have an infrastructure build on BIND 8 and/or NT/2000 name servers). Also, BIND 9 is much simpler to chroot than BIND 8.

Before you proceeded, be sure you have a current backup of your system and any existing BIND configuration and zone files. Be aware that this HOWTO does not cover adequate security for a public DNS server. This HOWTO will help you build a DNS server for a private network to resolve local and external (Internet) names, but does not allow external client queries.

The following versions were used for this HOWTO:

FreeBSD 4.7 (All versions after 4.5 including 5.0 should work without changes). bind9-9.2.2 and/or bind8-8.4.1 (Be sure to use the latest release.)

Page 3: Bind Freebsd

2.0 Some Theory: How Does A Client Resolve Names?

There are many good tutorials explaining how the Domain Name System functions. One of which is available at www.cs.colorado.edu/~tor/sadocs/dns/dns.html. Rather than echo the same words, we will begin our look at name resolution from a client's perspective. After all that is the ultimate goal.

Before our client can retrieve www.google.com, our web browser must know the IP address of the 'www' node at 'google.com.' Both Unix-like and Windows clients will query the name in similar fashion in the order listed below.

1. Check the local machine's DNS cache for the address of www.google.com. o Stored in memory.

2. Check the local machine's host file for the address of www.google.com. o Unix-like: /etc/hosts o 98/ME: C:\Windows\hosts o 2000/XP: C:\WINNT\system32\drivers\etc\hosts

3. Check the primary name server (1st listed DNS server) for the address of www.google.com.

o Unix-like: /etc/resolv.conf o Windows: Look for TCP/IP Properties

4. Check the secondary name servers if the primary name server fails to respond. o Unix-like: /etc/resolv.conf o Windows: Look for TCP/IP Properties

Steps 3 and 4 are why we are here. By the way, step 4 is very important! If we receive a negative answer from the first name server, "host not found," our client will never check the additional name servers. Why should it, we received an answer. Additional name servers are only queried when the primary name server does not return an answer. Also, if you are using Windows machines, be aware that they can resolve NETBIOS names via broadcasts on the local subnet, or even a WINS server if one is configured. Even Windows 2000/XP without NetBEUI (NETBIOS) installed will use NetBEUI over TCP/IP (enabled by default) if DNS queries fail. This can really fool you.

Page 4: Bind Freebsd

Just as clients, the name servers themselves can also cache DNS data. This is controlled by the TTL (Time to Live) specified in the SOA (Start of Authority) record of a Zone's data. The TTL could be minutes for hosts that change IP addresses frequently, or several hours (or days) for hosts that rarely change. Keep this in mind when DNS changes are not immediately evident.

Now lets assume we are trying to access www.cool-lint.org and neither our client nor the name servers along the path have cached data. Our client machine first contacts it's primary DNS server, provided the name is not cached or listed in a host file. This is known as a recursive query. The name server will do all the work. Our client expects a complete answer, whether it is the IP address of www.cool-lint.org or the bad news that no records exist for www.cool-lint.org.

The primary name server receives the query from our client, but does not have information about cool-lint.org. The primary name server, as it does not have "zone data" and is not authoritative for cool-lint.org, will need to start searching from the top of the DNS tree. The top is fittingly known as the "root" domain and is specified by "." (dot). Note that 'www.cool-lint.org' is actually 'www.cool-lint.org.' Notice the dot at the end of org? Go ahead, try adding a dot to the end of www.google.com.

Remember that our client made a recursive query to our primary name server expecting the name server to do all the work? Now, our name server does not have it so easy. Our name server must plug away with iterative (non-recursive) queries until it can find an answer. Our name server will first query one of the "root" domain name servers for the addresses of the "org" name servers. Next, our name server will query one of the "org" name server for the addresses of the "cool-lint.org" name servers. Finally, our name server contacts one of the "cool-lint.org" name servers for the IP address of the "www" node at "cool-lint.org".

Our name server has used several iterative queries to answer our client's recursive query for www.cool-lint.org. I hope there was something good there at cool-lint. Our name server will also keep this information around for as long as the TTL will allow. This includes the "org" and the "cool-lint" name server addresses as well as www.cool-lint.org address.

There is at least one exception to the above scenario. If our name server had been configured as a "forwarder", it would have simply passed the duties of name resolution off to another name server. When a forwarder does not have an answer, it simply makes a recursive query to another name server on the client's behalf. This can help reduce Internet DNS traffic as the upstream name server (normally an ISP) will maintain a fairly populated cache.

2.1 Caching And Forwarding Name Servers

A caching-only name server does exactly that, caches answers and only seeks new answers when the cache does not have the answer. There are two primary advantages to a caching-only name server (aka: hint name server). First, it is simple to configure as it is not authoritative for any zones and thus zone database files do not have to be maintained or loaded. (Actually, a caching-name server still loads a hint file and reverse lookup zone for its loopback interface. These are

Page 5: Bind Freebsd

explained later.) Second, it does not need to transfer zone data between other servers such as master or slave name servers would. This can be beneficial for preserving bandwidth to remote sites on a slow link.

Large environments will often use caching-only name servers to distribute DNS load while forwarding non-cashed queries to a single name server capable of resolving internal and/or external queries. There is one primary disadvantage of caching-only name servers. They cannot be authoritative for any zone. If you need to resolve names on your local network, you will need at least one master name server. If you do not need to resolve DNS names on your local network, but still need to resolve names on the Internet, then a cashing-only name server would make good sense.

Forwarding is a feature that can be added to any name server configuration whether it be caching-only, master, or even a slave server. There are two primary reasons we might want to use forwarding. First, you can improve DNS performance by taking advantage of a larger DNS cache on an upstream name server. (Typically your ISP, or even a name server in your DMZ). This assumes that your upstream name server(s) are reliable. Second, you can add a layer of security by controlling whom your internal name servers converse with. This allows for much tighter firewall configurations.

A "forward only” name server will make recursive queries directly to specified name servers. Whereas iterative (non-recursive) queries, without using forwarding, will plug away at many different name servers. If we allow our internal name server(s) to perform iterative queries, we must also open our firewall to allow anyone and everyone to send answers back to our internal name server(s). With "forward only” configured, we can close off all external DNS traffic while allowing only responses from two or three "trusted” upstream name servers.

There is a catch however, in order to benefit from this added layer of security we must disallow all iterative queries from our internal network. This is known as forwarding-only as apposed to the default behavior of forward first. With "forward only”, if our upstream name server(s) go down, we go down. Whereas with "forward first”, our internal name server will sigh for a moment and then proceeded on its own with iterative queries until if finds an answer. In other words, we have the more secure option of always forwarding queries to specified name servers. Or, the less secure option of only forwarding queries to said servers if they are responding, otherwise go get the answer ourselves from strangers.

The options to configure forwarding are relatively simple and will be covered later in "4.8 - Configuring Forwarding and Forward Only”. Configuring a caching-only name server is even simpler as we simply omit zone statements from named.conf that would otherwise load local zone databases. The configuration you ultimately chose will depend on the reliability of your upstream name server(s), your firewall configuration and security needs, and whether or not you need a DNS zone for your internal network.

2.2 Master vs. Slave Name Server

Page 6: Bind Freebsd

This HOWTO focuses only on setting up a single master name server. However, slave name servers are simple to implement in small to medium size environments. Note that it is possible for a single name server to be both a master for one zone while being a slave for another zone. Do not confuse a master name server with a primary name server. The term "primary name server” typically refers to the client's primary name server which is the first name server in the client's list. Additional name servers on the client's list are referred to as secondaries. A primary name server for the client can be either a master name server or a slave name server.

Simply put, a primary name server loads its zone data from a zone configuration file while a slave name server contains a read-only copy of the zone data retrieved from its master name server. The slave name server will keep a copy of the zone data in a [zone_name].bak file in the event that it is restarted and cannot immediately contact the master name server to retrieve zone data.

3.0 Installing BIND

All versions of FreeBSD from 4.3 to 5.1 include BIND version 8.3 or lower with the base distribution. I would recommend upgrading to either the latest version of the BIND 8 branch (8.4.1 at this writing.) or the latest version of the BIND 9 branch (9.2.2 at the writing). If you prefer to use the base package you can skip the remainder of this section.

There are two paths to upgrade whether you are going with BIND 8 or BIND 9. The easiest method is to leave the base system's BIND in tact and install the new version in its default location. Some drawbacks would include the chance of starting the incorrect version if you do not have things configured correctly, configuring things correctly can be more confusing, and lastly you are left with out-of-date software (including the BIND tools) laying around on your system. The advantage is a simpler installation and the ability to easily revert back to the old version of BIND.

The more involved method is to replace the existing base system's BIND with the new version. The real benefit is a less confusion when you are looking for the correct configuration files. The drawback is that you should remove the base system's BIND and then you must tell the new version to compile and install with the base system's defaults. Also, if something goes wrong, you no longer have the old version to fall back on. I have not yet used this second method, thus I only provide hints to get you started.

3.1 Replacing The Base System's BIND (which I have not attempted as of yet)

The prefix for the base system's BIND is /usr, and the configuration files are stored in /etc/namedb. This puts the binaries primary in /usr/sbin. When installing form the ports

Page 7: Bind Freebsd

collection, you should be able to replace the base build with extra options for make: (May also need to add PREFIX=/usr DESTETC=/etc/namedb if the below fails to do the trick.)

# cd /usr/ports/dns/bind98 (previously /usr/ports/net/bind9)# make PORT_REPLACES_BASE_BIND98=yes install

If you are building from the tar, you will need to configure with --prefix=/usr and --sysconfdir=/etc/namedb. Also, if you plan on upgrading your base system, add "NO_BIND= true" to /etc/make.conf to keep 'buildworld' from blowing away your current BIND install.

3.2 Using The Default Installation For BIND 8 or 9

For this method, we will leave the base system's BIND alone and install BIND 9.2.2 (or BIND 8.4.1) using the default prefix of /usr/local. This will place the binaries in /usr/local/sbin and /usr/local/bin. Version 9.2.2 will look for named.conf in /usr/local/etc. If your version differs, it will tell you exactly where named.conf should be the first time you attempt to start it.

Moving on, we now have two more options (This excludes building from the tarball): Install the precompiled package with pkg_add or installing from the ports collection. Both are covered below though I prefer using the ports collection. For more information, check out the FreeBSD handbook: "Chapter 4 Installing Applications: Packages and Ports"

Installing the BIND 9 package with pkg_add: Grab the latest BIND 9 (or BIND 8) package from the FreeBSD ported applications or a mirror. From the directory you dropped the package, issue the following:

pkg_add bind9-9.x.x

Obviously, adjust the version to match your package. You can verify installation by issuing pkg_info.

Installing via the FreeBSD ports collection: You may want to check out HOWTO: Installing CVSup and the Ports Collection on FreeBSD 4.x. Be sure you have the latest port or that you have updated your ports collection with CVSup. You can issue the following to locate the BIND 9 port. Look for the "Path:". It should be /usr/ports/dns/bind9 (Previously /usr/ports/net/bind9).

make search name=bind9

Installation is quite simple. Change to the 'bind9' (or 'bind84') directory and make install. Running make install will download the source files, compile, and install. Use make clean if you want to delete the source tree when you are done. Note: Some folks use make all install. I have not found "all" necessary and quite honestly do not understand how it effects the ports build.

Page 8: Bind Freebsd

cd /usr/ports/net/bind9make install

If you are installing BIND version 8, then you are done and can skip the 'rndc' configuration below. If you are using one of the FreeBSD default c-shells you will need to issue 'rehash' before the BIND installation is recognized. (Newbie Note: Issue 'set | grep shell' (without the quotes) to discover which shell you are using. Result will be something like /bin/csh. csh is our shell.)

rehash

3.3 Configuring rndc For BIND 9

Bind 8 comes with 'ndc', name daemon control program, which allows us to easily send control signals to BIND that will restart the server, reload zones, etc. There is nothing to configure for 'ndc' thus you can skip this section if you are using BIND 8. BIND 9 uses 'rndc' which is the remote name daemon control program. As the name implies, rndc can send control signals to BIND from a remote machine. By default BIND listens for rndc signals on port 953. By now you are probably thinking that there must be some authentication mechanism configured for rndc to work? Yes, and we will cover a very basic configuration of rndc. You can gain some added security by changing the default key name, location, and using 256 bit encoding. Also, FreeBSD 4.x's random number generator can be improved greatly through entropy gathering. You may want to visit: How to prep the /dev/random device in FreeBSD 4.

Below is an outline of what we need to configure. I will use the BIND 9.2.2 default prefix of /usr/local and the default key names:

/usr/local/etc/rndc.key (secret key) /usr/local/etc/rndc.conf (config file for rndc) /usr/local/etc/named.conf (named config file that we will cover later.)

BIND 9.2.2 includes 'rndc-confgen' to create the rndc secret key. With previous versions of BIND 9 it was necessary to generate the key with 'mmencode' or 'dnssec-keygen'. Lets proceed with creating the default key for BIND 9.2.2: (Check the rndc-confgen man page if you would like to change any of the defaults--man rndc-confgen.)

rndc-confgen –a

You will now find 'rndc.key' in /usr/local/etc. Note: if rndc-confgen is not recognized, run 'rehash' and try again. Now lets look at /usr/local/etc/rndc.key:

more /usr/local/etc/rndc.key

key "rndc-key" { algorithm hmac-md5; secret "Sk1vCuEoa193gfj=your-key-will-vary";

Page 9: Bind Freebsd

};

The "key" statement defines our key name which defaults to "rndc-key". The only algorithm support at this time is "hmac-md5". Our randomly generated "secret" is "Sk1vCuEoa193gfjFQoZshw==".

That was simple. Now lets configure rndc.conf. You should already have either a rndc.conf or a rndc.conf.sample file in /usr/local/etc. We will not use either one, though you may want to look at the sample file. If you have rndc.conf just move it to rndc.conf.old (mv rndc.conf rndc.conf.old). The below method will allow us to create rndc.conf without having to type out the secret string.

cd /usr/local/etccp rndc.key rndc.conf

ee rndc.conf (Use the text editor of your choice. I use 'ee' here as it is simple.)

Now we just need to add the "options" statement to our new rndc.conf file. The "key" statement is already there. The sample file contains an "options" statement as well as a "server localhost" default key. We will not need the "server localhost" default key, but you may use it if you wish. It's intended for use when connecting to other BIND servers. Below is the basic rndc.conf file we will be creating. Yours should match assuming your key name is "rndc-key".

options { default-server localhost; default-key "rndc-key";};

key "rndc-key" { algorithm hmac-md5; secret "Sk1vCuEoa193gfj=your-key-will-vary";};

WATCH OUT: If you are not running IPv6 (Most of us still only use IPv4) and your /etc/hosts file has an IPv6 entry for localhost such as: "::1 localhost", then rndc will fail with "connection refused" when you use "default-server localhost;" in the rndc.conf file. This is because rndc will attempt to connect to IPv6 and will never try your real IPv4 address of 127.0.0.1. Either remove the line starting with "::1" from your /etc/hosts file, or change "default-server localhost;" to "default-server 127.0.0.1;" in rndc.conf.

.

Lastly, we need to configure named.conf--the named configuration file--though this might be a little difficult as you may not have one yet. Not to worry, I will explain how to modify named.conf here, and then include the needed statements later when we setup the real named.conf. First, we need a "controls" statement:

Page 10: Bind Freebsd

controls { inet 127.0.0.1 allow { localhost; } keys { "rndc-key"; };};

The "inet 127.0.0.1" tells named to only listen on the 127.0.0.1 interface and default port (TCP 953). The "allow { localhost; }" tells named to only accept connections from the local machine. The "rndc-key" must match your key name in the "key" statement.

Second, we need to add a "key" statement. By default named.conf is often world readable which is no big deal until we insert our secret key. Rather than trust ourselves to change permissions on named.conf, we will use an include statement to add the "key" statement. The beauty of this lies in the fact that our secret key, rndc.key, just happens to have the exact "key" statement we need to include in named.conf. So assuming your secret key is the default /usr/local/etc/rndc.key, we just need to include that path in named.conf:

include "/usr/local/etc/rndc.key";

Now we just need to ensure rndc.key, and rndc.conf are owned by root and only readable by root. (If you are running BIND under a different user, then that user should also have read access. This is covered later when we chroot BIND.) (Check the FreeBSD handbook if you are not familiar with setting permissions and/or changing owner/group.)

cd /usr/local/etcchmod 600 rndc.confchmod 600 rndc.key

Now lets list the /usr/local/etc directory to verify:

ls –la

-rw-r--r-- 1 root wheel 806 Sep 22 22:48 named.confdrwxr-xr-x 2 root wheel 512 Aug 17 21:47 rc.d-rw------- 1 root wheel 143 Sep 22 22:16 rndc.conf-r--r--r-- 1 root wheel 1195 Sep 20 23:59 rndc.conf.sample-rw------- 1 root wheel 77 Sep 21 21:30 rndc.key

Here we see that rndc.conf and rndc.key are readable and writeable only by the owner who happens to be root.

3.4 Old Tools Vs. New Tools

One caveat of installing a newer version of BIND without replacing the base system's BIND is that you will still be using the old version of tools such as 'nslookup', 'host', and 'dig'. This is not an immediate problem, but rather a potential problem. This occurs from the fact that the base

Page 11: Bind Freebsd

system's tools are typically found earlier in the path variable. If you specify 'dig' without specifying the full path, you will be using the old version. For example: The old version of 'dig' is located in /usr/bin, while the new version is located in /usr/local/bin.

A typical path variable is shown below:

% set | grep path path (/sbin /bin /usr/sbin /usr/bin /usr/local/sbin /usr/local/bin ......)

Below are the locations of BIND's two most popular tools:

/usr/sbin/nslookup (location of old 'nslookup')/usr/local/sbin/nslookup (location of new 'nslooklup') [This has moved to /usr/local/bin/nslookup]/usr/bin/dig (location of old 'dig')/usr/local/bin/dig (location of new 'dig')

There are several solutions. For one, just specify the full path every time you use the tool, or change the order of your path variable. If you are daring simply delete the old versions. Below, I will simply move the old tools to [name]-8.3.

cd /usr/sbinmv nslookup nslookup-8.3

cd /usr/binmv dig dig-8.3

Incidentally, the new version of 'nslooklup' will warn you that: "nslookup is deprecated and may be removed from future releases. Consider using the `dig' or `host' programs instead." Though 'dig' is more powerful, I will use 'nslookup' for this HOWTO as its output is simpler. Also, if you just ran 'nslookup', type "exit" to get out of interactive mode. We will cover 'nslookup' in greater detail later.

4.0 Configuring BIND

Before you begin configuring, you will need to decide what you want your BIND server to do. We began covering the options earlier in "Caching And Forwarding Name Servers”. This HOWTO will focus on what I will simply call a "master name server.” This configuration will allow us to maintain a database of local addresses as well as resolve Internet addresses. I will also cover the necessary configuration for a caching-only name server. If you are interested in forwarding, simply proceed with the configuration of your master or caching-only name server and then we will add the forwarding options. If you are unsure and want to learn DNS, then setup a master name server. The configuration options presented here are just the basics. There are many other options you may want to explore, especially for BIND 9. For clarity (I hope), I will use a mock "foobar.example” domain for all examples.

Page 12: Bind Freebsd

Some confusion may arise in distinguishing between the BIND configuration file and the DNS zone database files. Try to remember that named.conf is the configuration file for 'named' which is the BIND daemon. The named.conf file uses a structure specific to BIND while the zone database files are RFC compliant and can often be used on other flavors of name servers. Below is a list of files we will configure.

Master Name Server:   named.conf (Main configuration file for BIND's 'named' daemon)   named.root (List of Internet root servers. AKA: db.cache or root.hints)   localhost.rev (Localhost reverse lookup zone for 127.0.0.1)   db.foobar.example (Forward lookup zone. This example name of "db.foobar.example" is explained below.)   db.1.168.192 (Reverse lookup zone. AKA: in-addr.arpa. This example name is explained below.)

Caching-Only Name Server:   named.root (List of Internet root servers. AKA: db.cache or root.hints)   named.conf (Main configuration file for BIND's 'named' daemon)   localhost.rev (Localhost reverse lookup zone for 127.0.0.1)

4.1 Our foobar.example domain

I will use the following example for our configuration. This is a duel homed machine running NAT (Network Address Translation) with one internal (friendly) interface and one external (hostile) interface. Our internal domain, foobar.example, is private and we intend to keep it that way. (RFC2606 actually reserves ".example" as a top level domain name for documentation. You can use any name you want for your internal domain, even hello.world if you so choose.) This is our only name server for foobar.example, thus it is a master name server. We will not allow zone transfers to slave servers.

Internal Domain Name: foobar.example

Internal Interface: 192.168.1.1Internal Network: 192.168.1.0/24 (aka: 192.168.1.0/255.255.255.0)

External Interface: BIND doesn't care for our example.External Network: BIND doesn't care for our example.

Name Server: ns1.foobar.example 192.168.1.1Host One: host1.foobar.example 192.168.1.100Host Two: host2.foobar.example 192.168.1.200

IMPORTANT: The location of named.conf will vary depending on how you installed BIND (if you installed BIND). The base system's BIND is kept in /etc/namedb while the

Page 13: Bind Freebsd

default location after installing a new version of BIND (without replacing the base system's BIND) will be /usr/local/etc.

/etc/namedb (the assumed location of zone files for this HOWTO.)/etc/namedb/named.conf (default location for the base system BIND.)/usr/local/etc/named.conf (default location after installing BIND.)

4.2 Overview of zone data files

Assuming you also need to resolve internal names, there are normally at least four zone data files: A forward lookup zone to map names to addresses, a reverse lookup zone to map addresses to names, a root zone for the Internet root name servers, and a special zone for our loopback (127.0.0.1) interface. Zone data files are loaded when called from named.conf. You can name the zone data files anything you choose so long as they match your entries in named.conf.

Forward lookup zones are commonly named after the domain for which they hold authoritative data. We will name our forward lookup zone "db.foobar.example" for our foobar.example domain. Below are the most commonly used resource records for a forward lookup zone. There are many others, happily, they are rarely needed. The official IANA list is available here.

SOA (Start of Authority record) Provides information about this zone. Boring, but important.

NS (Name Server record) List of name servers for this zone. At a minimum, you will need the name of the name server that is loading this zone. This may seem absurd, but it is required and does make sense once you have a better understanding of DNS.

A (Address) Name to Address mapping

CNAME (Conical name or aliases name) This is used for mapping additional names to the same address.

MX (Mail Exchanger) Yes, used by mail servers to locate mail servers.

Reverse lookup zones are commonly named after the address for which they hold authoritative data. To stay hip with the reverse lookup theme, a zone for 192.168.1/24 is normally named in reverse: db.1.168.192 or 1.168.192.in-addr.arpa. (I suspect that in-addr.arpa stands for inverse address ARPA as DNS originated in the ARPAnet days, though I have yet to verified this.) The reverse lookup (in-addr.arpa) zones are an odd thing but required by certain applications, such as nslookup and mail, along with some authentication mechanisms. In other words, some things will not work if you do not configure you in-addr.arpa zones. Reverse lookups are beyond the

Page 14: Bind Freebsd

scope of this HOWTO. At this time, you just need to know that your in-addr.arpa zones map addresses to names. A reverse lookup zone contains the following resource records:

SOA (Start of Authority record) Provides information about this zone.

NS (Name Server record) You guessed it. This is the address to name mapping for your name server(s).

PTR (address to name 'pointer record') Address to name mappings: Each address or interface on your network should have one of these.

4.3 localhost.rev (Localhost Reverse Lookup Zone)

Easy, just use the make-localhost script provided with BIND to create the localhost zone. This will create the following two files in /etc/namedb: localhost.rev and localhost-v6.rev. IP version 4 and IP version 6 respectively. We need not do anything with the version 6 file unless you are actually using version 6. Remember, the examples in this HOWTO will assume you are using /etc/namedb for all zone files no matter how you installed BIND. It is a simple task to move them latter if needed.

cd /etc/namedbsh make-localhost

That is it for localhost.rev! If you would like, you can view it with the following:

more localhost.rev

Your output will be similar, but not necessarily identical to the below:

; From: @(#)localhost.rev 5.1 (Berkeley) 6/30/90; $FreeBSD: src/etc/namedb/PROTO.localhost.rev,v 1.6 2000/01/10 15:31:40 peter Exp $;; This file is automatically edited by the `make-localhost' script in; the /etc/namedb directory.;

$TTL 3600

@ IN SOA ns1.foobar.example. root.foobar.example. (1 ; Serial3600 ; Refresh900 ; Retry3600000 ; Expire3600 ) ; Minimum

IN NS ns1.foobar.example.

Page 15: Bind Freebsd

1 IN PTR localhost.ns1.foobar.example.

4.4 db.foobar.example (forward Lookup zone)

If you are building a caching-only name server you may skip this step, otherwise, you will need to create your own forward-lookup zone file. Use what ever method you prefer. (Newbie note: If you use a Windows text editor on an ASCII file--any Unix text file--you will need to remove the ^M's from the end of each line. If you insist on using a Windows editor, you can usually strip the ^M by FTPing it back to the BSD box so long as you use ASCII or text mode.)

For this example, we will copy localhost.rev to db.foobar.example and then add the records we need. Remember to substitute db.foobar.example for your domain name. Change directory to /etc/namedb if you are not already there.

cd /etc/namedbcp localhost.rev db.foobar.example

ee db.foobar.example (Use the text editor of your choice. I use 'ee' here as it is simple.)

You can delete the comments if you choose. Delete the PTR record and update the NS and A records as shown below. The CNAME records are optional and shown only for examples. Remember to use names appropriate for your domain.

$TTL 3600

@ IN SOA ns1.foobar.example. root.foobar.example. (1 ; Serial3600 ; Refresh900 ; Retry3600000 ; Expire3600 ) ; Minimum

@ IN NS ns1.foobar.example.

; Machine Nameshost1 IN A 192.168.1.100host2 IN A 192.168.1.200ns1 IN A 192.168.1.1

; Aliasesh1 IN CNAME host1h2 IN CNAME host2

As of this may seem a bit cryptic if you are new to DNS so I will try to briefly explain. But first, there are some things you should know about DNS zone file syntax:

Page 16: Bind Freebsd

A semicolon designates a one-line comment much like REM for DOS, or # for many other Unix configuration files.

The "@" is a shortcut character specifying the current domain or origin. You could replace this with foobar.example. (with the trailing dot) and it would have the same effect.

The "." (dot) at the end of a name designates the name as being fully qualified. Any name without a dot will have the origin "@" appended. For example, BIND would read foobar.example (without the dot) as foobar.example.foobar.example. Not the desired effect. The name, host1, without the dot would be host1.foobar.example. A desirable effect. However, include the dot on host1 and you have just indicated that host1 is a top-level domain completely separate form foobar.example.

$TTL 3600 - This control statement specifies the maximum time a name server can cache records from this zone. Ours is set for 3600 seconds or 1 hour. We could also write this as "1h". You can set your TTL to anything you want. Incidentally, both BIND 8 and 9 understand the TTL, however, BIND 9 requires it.

IN – Specifies the Internet Record class. There are other classes, but you will likely never need them.

SOA – Start of Authority record for @ (foobar.example.). This is the authoritative record for foobar.example. indicating that this is the end of the line for queries. If the answer is not here; it does not exist.

ns1.foobar.example. – Master name server for foobar.example. The trailing dot must be included.

root.foobar.example. – Email address indicating the responsible person of this zone. Again, include the trailing dot. The dot between root and foo is translated to "@", thus [email protected]. Inserting the actual "@" symbol here would likely have some ill effects.

( ) - The opening and closing parentheses allow a line to be extended until the closing parentheses are encountered. Thus the next five values are actually all on the same line as the SOA record and are part of the SOA record. BIND 9 requires that the opening parenthesis is on the same line as SOA.

serial, refresh, retry, expire, minimum - These values effect how this zone should be cached and/or handled by slave name servers. We really don't need to change these for our simple name server and they would take a while to explain. If you are employing slave servers, you will need to update the serial number before they will pull down new zone data. We have simply set ours at "1" though the common format is yyyymmdd## where "#" represents daily zone updates.

NS – List of authoritative name servers for this zone. We have one.

Page 17: Bind Freebsd

A – Hosts in our zone. Notice that host1 and host2 do not have dots appended to their names. We could have written these as host1.foobar.example. and host2.foobar.example. if we appended the dots.

CNAME – This is an alias for h1 to host1. We would see the same address if we pinged both h1 and host1.

4.5 db.1.168.192 (Reverse Lookup Zone)

If you are building a caching-only name server you may skip this step, otherwise, you will need to create an address to name mapping zone file. For this example, we will copy localhost.rev to db.1.168.192 and then add the records we need.

cd /etc/namedbcp localhost.rev db.1.168.192ee db.foobar.example

You can delete the comments if you choose. Add the appropriate PTR records for your domain. Our example domain looks like the following:

$TTL 3600

@ IN SOA ns1.foobar.example. root.foobar.example. (20021111 ; Serial3600 ; Refresh900 ; Retry3600000 ; Expire3600 ) ; Minimum

IN NS ns1.foobar.example.

; Machine Names100 IN PTR host1.foobar.example.200 IN PTR host2.foobar.example.1 IN PTR ns1.foobar.example.

Our origin is '1.168.192.in-addr.arpa' thus we only need to list the host portion of host1 and host2's addresses. Alternatively, we could have listed them as '100.1.168.192.in-addr.arpa.' and '200.1.168.192.in-addr.arpa.' respectively (with the trailing dots). We could have also included "@" at the beginning of our NS record, however, the "@" is implied and not needed. Again, do not forget the trailing dots.

4.6 named.root (Root Hints File)

Page 18: Bind Freebsd

The named.root file contains the list of DNS servers for the root domain. Both caching-only and master name servers will need this. You will be glad to know that you need not create, or even edit, a named.root file. One will be included in your /etc/namedb directory. You may want to take a look at it. You can get an updated named.root file from ftp.rs.internic.net, however, the recommended approach is to use 'dig'. Dig is simple and explained in "Updating named.root". Don't try it now though, as our server must be running before we can use dig. As with other zones, named.root can be named anything you choose so long as it matches your entry in named.conf. In fact, named.root is most commonly known as db.cache or root.hints, however, I will stick with the default name of named.root for this tutorial.

4.7a named.conf For Master Name Server

This section covers named.conf for a master name server. If you are building a caching-only name server, please refer to section 4.7b. The named.conf file is the main configuration file for BIND. Its primary function is to control which zones are loaded and which interfaces and ports to listen on. I should note that the syntax of named.root is completely different from the syntax of named.boot in BIND 4 and earlier. Fortunately, BIND 8 and BIND 9 use the same syntax. The named.root file will accept the following characters as comments.

// Single line comment/* Begin multiple-line comment. End a multiple-line comment with */# Another single line comment.You cannot use a semicolon for comments within named.conf. The semicolon is used to end control statements.

Below is the named.conf we will be using for our foobar.example domain. Look it over and then I will explain. After that, we will move on to creating the real thing.

# /etc/namedb/named.conf - for base system's BIND 8 or 9# /usr/local/etc/named.conf - for default install of BIND 8 or 9

options {directory "/etc/namedb";allow-query { 192.168.1/24; 127.0.0.1; };listen-on { 192.168.1.1; 127.0.0.1; };};

/* Remove comments and this sentence for BIND 9

controls { inet 127.0.0.1 allow { localhost; } keys { "rndc-key"; };

};

include "/usr/local/etc/rndc.key";

Page 19: Bind Freebsd

*/

zone "." {type hint;file "named.root";};

zone "0.0.127.IN-ADDR.ARPA" {type master;file "localhost.rev";};

zone "foobar.example" {type master;file "db.foobar.example";allow-transfer { none; };};

zone "1.168.192.in-addr.arpa" {type master;file "db.1.168.192";allow-transfer { none; };};

Remember that there are two thing we need to do with named.conf—set our options and load zones. Lets look at the options statement first:

options {directory "/etc/namedb";allow-query { 192.168.1/24; 127.0.0.1; };listen-on { 192.168.1.1; 127.0.0.1; };

};

First thing we do is to declare the options statement. It is very important to remember the opening and closing brackets, and to end the options statement with a semicolon.

options { ...Control statements go here. We can list each one on a new line for clarity.. };

The following are our option control statements. Remember to end each control statement with a semicolon.

directory "path_to_named_directory"; (BIND will change to this directory, thus we do not need to include the full path when we call our zone files. We will be using /etc/namedb for our zone files no matter which BIND version or install method we used.)

Page 20: Bind Freebsd

allow-query { list_of_networks_or_specific_addresses }; (This determines which networks or addressed BIND is allowed to answer queries for. You can disregard this if you only have one network card, or intend to allow external users to lookup names on your network. Our example uses a duel homed machine. For that reason, we will only allow BIND to answer queries from our internal network (192.168.1/24) and from the loopback interface (27.0.0.1). Note that our network is written as 192.168.1/24 rather than 192.168.1.0/24.)

listen-on { list_of_interfaces }; (Again, we only want BIND to answer queries for our internal network and our loopback. This tells BIND to not even bother listening on our external interface.)

NOTE: By default, BIND 4.9 and later will provide it's version information to anyone who asks. (dig txt chaos version.bind). You can tell BIND to return a text string in place of the version record. This helps keep the bad guys, and worms, guessing a bit should they have access to query your name server. Adding the below option would cause BIND to return the text string "unavailable":

version "unavailable";

BIND 9 Only: You will need to remove the comments ( /* and */ ) for BIND 9. Remember from earlier that the "controls" statement and "include" are used to configure BIND 9's rndc. Be sure that "include" contains the correct path to your rndc.key file.

controls { inet 127.0.0.1 allow { localhost; } keys { "rndc-key"; };

};

include "/usr/local/etc/rndc.key";

Next, we need to load our four zones. This should be fairly self-explanatory after looking over the named.conf file a few times. It goes as follows:

zone "origin_of_zone" { …zone control statements….};

The first zone we load is "." (the root zone.) This is our list of Internet root name servers in named.root. This zone type is 'hint' and the file containing the hints is named.root. BIND will look in the directory specified earlier by the 'directory' option.

zone "." {type hint;file "named.root";};

The next zone we load is our localhost or loopback zone. Its origin is '0.0.127.IN-ADDR.ARPA', the zone type is master, and the zone information is in the localhost.rev file we created earlier with the make-localhost script.

Page 21: Bind Freebsd

zone "0.0.127.IN-ADDR.ARPA" {type master;file "localhost.rev";

};

Moving on, we now load the foobar.example zone file. The only new control statement here is 'allow-transfer'. If we had slave name servers, we would list them here. As we have no salve servers we will allow transfers to 'none'. (NOTE: Change 'none;' to your local subnet or specific addresses if you need to list records with nslookup.)

zone "foobar.example" {type master;file "db.foobar.example";allow-transfer { none; };

};

By this time things should seem very redundant. The last zone we load is our network's reverse lookup zone.

zone "1.168.192.in-addr.arpa" {type master;file "db.1.168.192";allow-transfer { none; };

};

There are many more control statements available (especially for BIND 9), but we will not need them. You may, however, need to add the following to your 'options' section if you are going through a firewall:

query-source address [your_address] port [your_port];

The following would send queries out any interface via port 53:

query-source address * port 53;

By default BIND 8 and BIND 9 will send queries to other name servers from an unprivileged port (ports 1024 and above). The query will come from our port [1024+] to port 53 on the external name server. The response from that name server will come back to our port [1024+]. If you never receive answers from the root name servers, investigate 'query-source'. The sample named.conf suggests setting this to port 53. You will need to work with your "firewall engineer" to determine your best approach.

Now that we know what named.conf does, how do we create it? BIND does come with an /etc/namedb/named.conf file, however, I find it easer to just create a new one and keep a copy of the original around for reference.

Page 22: Bind Freebsd

cd /etc/namedb (default location for the base system BIND.)cd /usr/local/etc (default location after installing BIND.)mv named.conf named.conf.ori

ee named.conf (start typing)

Alternatively you can edit the original. It is up to you. The most common mistake is to have one too few or too many semicolons or braces. Thankfully BIND will help you find syntax errors the first time you start it up.

4.7b named.conf For Caching-Only Name Server

This section covers named.conf for a caching-only name server. If you are not building a caching-only name server, please refer to section 4.7a. The named.conf file is the main configuration file for BIND. Its primary function is to control which zones are loaded and which interfaces and ports to listen on. I should note that the syntax of named.root is completely different from the syntax of named.boot in BIND 4 and earlier. Fortunately, BIND 8 and BIND 9 use the same syntax. The named.root file will accept the following characters as comments.

// Single line comment/* Begin multiple-line comment. End a multiple-line comment with */# Another single line comment.You cannot use a semicolon for comments within named.conf. The semicolon is used to end control statements.

Below is the named.conf we will be using for our foobar.example domain. Look it over and then I will explain. After that, we will move on to creating the real thing.

# /etc/namedb/named.conf - for base system's BIND 8 or 9# /usr/local/etc/named.conf - for default install of BIND 8 or 9

options {directory "/etc/namedb";allow-query { 192.168.1/24; 127.0.0.1; };listen-on { 192.168.1.1; 127.0.0.1; };};

/* Remove comments and this sentence for BIND 9

controls { inet 127.0.0.1 allow { localhost; } keys { "rndc-key"; };

};

include "/usr/local/etc/rndc.key";

Page 23: Bind Freebsd

*/

zone "." {type hint;file "named.root";};

zone "0.0.127.IN-ADDR.ARPA" {type master;file "localhost.rev";};

Remember that there are two thing we need to do with named.conf—set our options and load zones. Lets look at the options statement first:

options {directory "/etc/namedb";allow-query { 192.168.1/24; 127.0.0.1; };listen-on { 192.168.1.1; 127.0.0.1; };

};

First thing we do is to declare the options statement. It is very important to remember the opening and closing brackets, and to end the options statement with a semicolon.

options { ...Control statements go here. We can list each one on a new line for clarity.. };

The following are our option control statements. Remember to end each control statement with a semicolon.

directory "path_to_named_directory"; (BIND will change to this directory, thus we do not need to include the full path when we call our zone files. We will be using /etc/namedb for our zone files no matter which BIND version or install method we used.)

allow-query { list_of_networks_or_specific_addresses }; (This determines which networks or addressed BIND is allowed to answer queries for. You can disregard this if you only have one network card, or intend to allow external users to lookup names on your network. Our example uses a duel homed machine. For that reason, we will only allow BIND to answer queries from our internal network (192.168.1/24) and from the loopback interface (27.0.0.1). Note that our network is written as 192.168.1/24 rather than 192.168.1.0/24.)

listen-on { list_of_interfaces }; (Again, we only want BIND to answer queries for our internal network and our loopback. This tells BIND to not even bother listening on our external interface.)

Page 24: Bind Freebsd

NOTE: By default, BIND 4.9 and later will provide it's version information to anyone who asks. (dig txt chaos version.bind). You can tell BIND to return a text string in place of the version record. This helps keep the bad guys, and worms, guessing a bit should they have access to query your name server. Adding the below option would cause BIND to return the text string "unavailable":

version "unavailable";

BIND 9 Only: You will need to remove the comments ( /* and */ ) for BIND 9. Remember from earlier that the "controls" statement and "include" are used to configure BIND 9's rndc. Be sure that "include" contains the correct path to your rndc.key file.

controls { inet 127.0.0.1 allow { localhost; } keys { "rndc-key"; };

};

include "/usr/local/etc/rndc.key";

Next, we need to load our four zones. This should be fairly self-explanatory after looking over the named.conf file a few times. It goes as follows:

zone "origin_of_zone" { …zone control statements….};

The first zone we load is "." (the root zone.) This is our list of Internet root name servers in named.root. This zone type is 'hint' and the file containing the hints is named.root. BIND will look in the directory specified earlier by the 'directory' option.

zone "." {type hint;file "named.root";};

The next zone we load is our localhost or loopback zone. Its origin is '0.0.127.IN-ADDR.ARPA', the zone type is master, and the zone information is in the localhost.rev file we created earlier with the make-localhost script.

zone "0.0.127.IN-ADDR.ARPA" {type master;file "localhost.rev";

};

That is it for a caching-only name server. If we were building a master name server, we would include additional zones for each domain our server would be authoritative for.

Page 25: Bind Freebsd

There are many more control statements available (especially for BIND 9), but we will not need them. You may, however, need to add the following to your 'options' section if you are going through a firewall:

query-source address [your_address] port [your_port];

The following would send queries out any interface via port 53:

query-source address * port 53;

By default BIND 8 and BIND 9 will send queries to other name servers from an unprivileged port (ports 1024 and above). The query will come from our port [1024+] to port 53 on the external name server. The response from that name server will come back to our port [1024+]. If you never receive answers from the root name servers, investigate 'query-source'. The sample named.conf suggests setting this to port 53. You will need to work with your "firewall engineer" to determine your best approach.

Now that we know what named.conf does, how do we create it? BIND does come with an /etc/namedb/named.conf file, however, I find it easer to just create a new one and keep a copy of the original around for reference.

4.8 Configuring Forwarding and Forward Only

As touched on earlier in "2.1 Caching And Forwarding Name Servers”, Forwarding provides advantages in speed and security for your name server by forwarding queries to an upstream name server. Forwarding can be added to master, slave, and caching-only name servers. We can specify the option of "forward only”, or use the default option of "forward first.” The later--forward first--provides a fall back in the event that the upstream name servers are down, but requires a "Swiss-cheese” firewall configuration.

Enable forwarding by adding the "forwarding” substatement to your list of option statements. You must also provide a semicolon-separated list of name servers to forward queries to. Typically, this will be a list of your ISP's name servers. Alternately, it could be name servers in your DMZ if you have one. (The addresses shown here are bogus.)

options {directory "/etc/namedb";allow-query { 192.168.1/24; 127.0.0.1; };listen-on { 192.168.1.1; 127.0.0.1; };forwarders { 10.1.2.3; 172.16.1.2; };};

You might be wondering what will happen when you attempt to resolve local host names? Well, those queries will also be sent to your upstream name servers which most likely do not have

Page 26: Bind Freebsd

information about your local network and will fail. To prevent local name queries from being forwarded, simply add a null forwarders statement to each zone that you do not want to forward.

zone "foobar.example" {type master;file "db.foobar.example";allow-transfer { none; };forwarders { };};

zone "1.168.192.in-addr.arpa" {type master;file "db.1.168.192";allow-transfer { none; };forwarders { };};

The above "forward first” examples will tell BIND to: First forward queries to upstream name servers. Second, in the event that none of the upstream name servers respond, then revert to iterative (non-recursive) queries. If you prefer that BIND only use forwarding, then simply add "forward only;” to your list of options statements.

options {directory "/etc/namedb";allow-query { 192.168.1/24; 127.0.0.1; };listen-on { 192.168.1.1; 127.0.0.1; };forwarders { 10.1.2.3; 172.16.1.2; };forward only;};

In reality, your firewall will determine whether or not BIND is free to partake in iterative queries with other name servers. However, using "forward only” will eliminate unnecessary traffic, excessive timeouts, and is just more professional.

5.0 Starting BIND

Still with me? Good. Now for the fun part--provided we completed the last sections correctly. First, we will need to add our localhost address--127.0.0.1--to resolv.conf before our name server will query itself for domain names. This is not required, but it would be rare for a DNS server to not use itself for name resolution.

ee /etc/resolv.conf

Replace your current 'nameserver' with 127.0.0.1. If you want to add additional name servers, add them to the list below 127.0.0.1. Our ns1.foobar.example resolv.conf looks like this:

domain foobar.examplenameserver 127.0.0.1

Page 27: Bind Freebsd

The domain part is the "search domain" which allows you to lookup 'ns1' rather than using the fully qualified name of 'ns1.foobar.example'. (NOTE: Alternately you can use 'search' in place of 'domain'. Just don't use them both.)

5.1 BIND 8 Only: Starting And Controlling named

First, we will need to start 'named' which is the BIND daemon. We will use 'ndc', the name daemon control program, to control BIND 8 and we could use 'ndc' to start BIND 8. The problem with starting BIND 8 with 'ndc' is that 'ndc' will start the first 'named' executable it finds. This is a bad idea if you have multiple 'named' versions on your system. So, we will start 'named' by specifying the path as shown below. The location of 'named' is dependent on how you installed BIND. If you are using the base system's BIND, or you replaced the base system's BIND, 'named' will be in /usr/sbin. If you installed a new version of BIND with the default options, then 'named' will be in /usr/local/sbin. As 'named' is executable, simply type the path to 'named':

/usr/sbin/named (default location for the base system's BIND.)/usr/local/sbin/named (default location after installing BIND)

BIND (specifically 'named') will immediately inform you of any syntax errors in your config files. Check out the "Troubleshooting and Testing BIND" section if you are having issues. If all is well we can move on to using 'ndc'. Happily 'ndc' does not require any configuration unlike 'rndc' of BIND 9.

You can check the status of BIND 8 with "ndc status".

You can use "ndc reload" to reload you zone files. You will need to do this anytime you make a change such as adding or removing a host address.

You can use "ndc restart" to restart named. This will be required before any changes to named.conf will be effective. You can also stop named with "ndc stop". (As "ndc restart" sends a signal directly to the running 'named' process, it will always restart the correct 'named' version unlike "ndc start".)

By the way, if you find yourself stuck in an interactive session with 'ndc', simply type "/h" for help or "/e" to exit.

5.2 BIND 9 Only: Starting And Controlling named

First we will need to start 'named' which is the BIND daemon. We use 'rndc', the remote name daemon control program, to control BIND 9 much as we use 'ndc' to control BIND 8. Some configuration of 'rndc' is necessary before it will work. This was covered earlier in "Configuring

Page 28: Bind Freebsd

rndc For BIND 9". Note that we can NOT use 'rndc' to start BIND 9 as 'rndc' requires BIND 9 to be running. Unfortunately the error is a bit misleading: "rndc: connect failed: connection refused".

Remember that the base system's BIND will use /usr/sbin/named. Use this only if you have replaced your base system's BIND. Otherwise you will be starting BIND 8.3.x. Start BIND 9 with one of the following unless you have installed with something other than the default prefix:

/usr/sbin/named (default location for the base system BIND.)/usr/local/sbin/named (default location after installing BIND.)

If everything started correctly you will be quietly returned to the command prompt. If not, BIND (specifically 'named') is usually quite verbose in telling you where you went wrong. Check out the "Troubleshooting and Testing BIND" section if you are having issues.

If you are familiar with BIND 8's 'ndc' you will find that BIND 9's 'rndc' uses options a little differently. For one, you cannot start 'named' with 'rndc'. For another, restart" is not yet implemented in 'rndc.' The good news is that "ndc reload" not only reloads zones but also forces 'named' to reread named.conf.

You can check the status of BIND 9 with "rndc status", and you can clear the cache with "rndc flush".

You can use "rndc reload" to reload you zone files and force 'named' to reread is configuration file--named.conf. You will need to do this anytime you make a change to a zone file or named.conf. You can also use "rndc reconfig" to reread named.conf and only load zones which have changed. Remember, you cannot use 'rndc' to start BIND 9, however you can stop it with "rndc stop".

5.3 Testing BIND (Both versions)

Assuming BIND is up-and-running, we will now run a couple simple checks to ensure BIND can resolve names. We will use 'nslookup' though other tools are available such as 'dig'. In the following examples "%" represents the command prompt (you will see a "#" if you are still logged in as root.) The output from our example domain will be listed below the command.

Lets see if BIND will answer an internal query.

% nslookup ns1 (replace 'ns1' with the name of your server.)

Server: localhost.foobar.exampleAddress: 127.0.0.1

Name: ns1.foobar.exampleAddress: 192.168.1.1

Page 29: Bind Freebsd

Hey, look at that. Our server resolved its own address. Notice that "Server" and its corresponding address is the name server we connected to for name resolution. "Name" and its corresponding address is the answer to our query. You can also try this for any other hosts entries you may have added. If this did not work, try using your servers fully qualified name, ie: 'ns1.foobar.example'. If the fully qualified name works, then you may want to set your 'domain' in /etc/resolv.conf.

Lets see if we can resolve and external name:

% nslookup www.google.com

Server: localhost.foobar.exampleAddress: 127.0.0.1

Name: www.google.comAddress: 216.239.39.99

If this failed with a "Non-existent domain" error, check out the "Troubleshooting and Testing BIND" section. This means that you are not able to contact the domain root servers—or google has vanished.

Now lets check our reverse lookup zone. You will need to use the IP address of one of your hosts.

% nslookup 192.168.1.100 (This is our 'host1' address. Use one of your real addresses here.)

Server: localhost.foobar.exampleAddress: 127.0.0.1

Name: host1.foobar.exampleAddress: 192.168.1.100

Worked? Good! Otherwise check out the "Troubleshooting and Testing BIND" section. Your in-addr.arpa zone is not loading or does not have correct data.

One last thing. You should also check which version of BIND you are actually running. This is covered in more detail in "Troubleshooting and Testing BIND", however, the following will give you the version when run from a console on your name server. (Don't use "named –v" as this will not necessarily give you the version of BIND that is actually running.)

%dig txt chaos version.bind @localhost

5.4 Starting BIND (named) At Boot

Both BIND version 8 and version 9 can be started from /etc/rc.conf. The only variation will be how you installed BIND.

Page 30: Bind Freebsd

Base system's BIND: If you are using the base system's BIND or have replaced the base system's BIND with a newer version, simply add named_enable="YES" to /etc/rc.conf:

cd /etc

cp rc.conf rc.conf.ori (always backup the original.)ee rc.conf

Add named_enable="YES" anywhere in rc.conf provided it is not already there.

Default installation of BIND: If you have installed a newer version of BIND and did not replace the base system's BIND, you will need to add the path to named and add named_enable="YES" to /etc/rc.conf. (Note: I do not recommend editing /etc/defaults/rc.conf)

cd /etc

cp rc.conf rc.conf.ori (always backup the original.)ee rc.conf

Add named_enable="YES" anywhere in rc.conf provided it is not already there.Add named_program="/usr/local/sbin/named" anywhere in rc.conf

That is it. If needed, you can now configure your clients to use your new name server as their primary DNS server. You can also use 'nslookup' from a command prompt on Windows NT/2000/XP hosts. Whenever you make a change to one of your zone files, remember to issue 'ndc reload' for BIND 8 or 'rndc reload' for BIND 9. Whenever you make a change to named.conf, remember to issue 'ndc restart' for BIND 8 or 'rndc reload' for BIND 9. Be sure to use 'netstat –n' if you want to check which interfaces BIND is listening on. More information is available in the "Troubleshooting and Testing BIND" section.

6.0 Securing BIND with chroot

By default, BIND runs with root permissions on FreeBSD. BIND is also a popular target for malicious hackers. If you are at all concerned about security, you will want run BIND as an unprivileged user. Additionally, you can configure BIND to chroot to a new environment for additional protection. (This is sometimes referred to as a jail, though not technically correct. Jail is another utility which can imprison processes. You can reference chroot and jail in the man pages for more information.) Using chroot to change BIND's environment is often referred to as running BIND in a sandbox. (Technically, just running BIND as an unprivileged user qualifies as a sandbox to some extent.) A sandbox, as I refer to it here, is directory created solely for BIND containing all necessary configuration files, device nodes, libraries, and binaries for BIND to operate. Once BIND is sent to its sandbox, it is difficult (though not impossible) for a malicious hacker or virus to access any part of our system that BIND was not specifically granted access to.

The following will describe how to run BIND as an unprivileged user and use chroot to place BIND in a sandbox where it cannot see our "real" file system. I will focus here on BIND 9 though the majority of this section will apply to BIND 8. There are a couple exceptions for

Page 31: Bind Freebsd

BIND 8 which have been noted. You may also want to reference the FreeBSD hand book, especially if you are working with BIND 8.

First we need an unprivileged user account and group to run BIND. It just so happens that FreeBSD already provides us with a user and group both named "bind”. Another popular name for the BIND user is "named.” If you need or want to create a new user account, be sure that the new user does not have a real logon shell.

Now we will need to create the directory structure. I prefer to use /var/chroot/named, though you can build the sandbox anywhere you wish. You can even use /etc/namedb. The "tmp" directory should not be needed, but I create it anyway. I prefer to keep my master and slave zones in separate directories because user 'bind' will need write access to the "slave" directory to create the [domain].bak files, but not the 'master' directory. The user 'bind' will also require write access to var/run to create the pid file, thus we will make 'bind' the owner of these directories only. Remember that the 'bind' user account could be compromised so we want to restrict it's access as much as possible. Warning: Remember that you are working in a mock root directory of 'named'. If you accidentally append '/' to var or another directory when you really meant /var/chroot/named/var then you have just modified your real var directory.

mkdir -p /var/chroot/namedchgrp bind /var/chroot/namedcd /var/chroot/namedmkdir -p etc dev tmp var/run master slavechmod 750 *chown bind:bind slave var/run

Now we need to create some device nodes. As long as you have already generated the rndc.key, you probably don't need the 'random' node, but we will create it anyway. Also, some versions of BIND 9 may require the 'zero' node, so will create it. You must have the 'null' device node otherwise 'bind' will not be able to take out the garbage. User 'bind' will need write access, so we will make 'bind' the owner and group as well. Again, be absolutely sure you are in the correct directory.

cd devmknod null c 2 2mknod zero c 2 12mknod random c 2 3chown bind:bind *

Now lets copy over the needed system file(s). For BIND 9 we just need localtime for logging. If you are having issues with syslog, you may need to copy syslog.conf to your etc directory. (If you are using BIND 8 and performing zone transfers, you will need to deal with building a statically linked copy of named-xfer and copying it over as well.)

cp /etc/localtime /var/chroot/named/etc

Now lets copy over the BIND configuration file, rndc.key, and zone files. I will assume your zone files are in the default location of /etc/namedb and that you performed a default installation

Page 32: Bind Freebsd

on BIND 9 which placed your named.conf file in /usr/local/etc. You can copy the entire /etc/namedb directory over with cp -R /etc/namedb /var/chmod/named, however, I will demonstrate by copying each required file separately. I am using our earlier 'foobar.example' zone files. (HINT: If your zone files begin with "db", you can save some typing with: cp db* /var/chroot/named/master)

cd /etc/namedbcp db.1.168.192 /var/chroot/named/mastercp db.foobar.example /var/chroot/named/mastercp localhost.rev /var/chroot/named/mastercp named.root /var/chroot/named/masterchmod 640 /var/chroot/named/master/*

cd /usr/local/etccp named.conf /var/chroot/named/etccp rndc.key /var/chroot/named/etccd /var/chroot/named/etcchmod 640 named.conf rndc.key

We will need to update our directory paths in named.conf to suit our new environment. Since we will be telling BIND to chroot to /var/chroot/named and run as user 'bind', the user 'bind' will think that /var/chroot/named is the "real" root directory. When you tell user 'bind' to look in "/", 'bind' will actually be looking in /var/chroot/named. An attacker who has taken control of BIND will also be unable to access our "real" root. (Provided he or she is not able to brake out of our chroot environment.) Below is our 'foobar.example' named.conf from earlier. Changes are in bold.

# /etc/namedb/named.conf - for base system's BIND 8 or 9# /usr/local/etc/named.conf - for default install of BIND 8 or 9

options {directory "/";allow-query { 192.168.1/24; 127.0.0.1; };listen-on { 192.168.1.1; 127.0.0.1; };};

/* Remove comments and this sentence for BIND 9

controls { inet 127.0.0.1 allow { localhost; } keys { "rndc-key"; };

};

include "etc/rndc.key";

*/

zone "." {type hint;file "master/named.root";

Page 33: Bind Freebsd

};

zone "0.0.127.IN-ADDR.ARPA" {type master;file "master/localhost.rev";};

zone "foobar.example" {type master;file "master/db.foobar.example";allow-transfer { none; };};

zone "1.168.192.in-addr.arpa" {type master;file "master/db.1.168.192";allow-transfer { none; };};

Now it is time to make BIND chroot to the new environment. For FreeBSD, the best method is through /etc/rc.conf. You can always refer to /etc/defaults/rc.conf for more information about rc.conf options. Your changes, however, should always be made in /etc/rc.conf rather than the defaults file in /etc/defaults. The first two options were covered earlier and do not change. We simply pass additional parameters to BIND through named_flags. The "-u" indicates which user BIND will change to. Initially, BIND will start as root, bind to the privileged DNS socket, and then change to the specified user. (Note: BIND 9 does not use the "-g" (group) option as did BIND 8. BIND 9 uses the primary group of the specified "-u" user. You would add "-u bind" for BIND 8 only.) The "-t" options tells BIND to chroot to /var/chroot/named. The "-c" options tells BIND where the configuration file is in reference to the chroot environment. (Our configuration file is actually in /var/chroot/named/etc/, however, BIND has already chroot'd to /var/chroot/named and will see this as the root directory.) Our /etc/rc.conf looks like this:

named_enable="YES"named_program="/usr/local/sbin/named"named_flags="-u bind -t /var/chroot/named -c /etc/named.conf"

One last thing. When BIND is chroot'd, it cannot access the system's syslogd socket and thus we will need to create a new socket just for BIND. Once BIND starts, the log socket will be created in /var/chroot/named/dev/ and you should see messages from BIND logged to /var/log/messages. We do this by passing additional parameters to syslogd through /etc/rc.conf. Specifically "-l" (ell) and the path to our new log socket. Since we will be overriding the default syslogd_flags we will need to include "-s" or "-ss". The default for FreeBSD seems to always be "-s" which allows syslogd to listen for remote logging, whereas "-ss" will tell syslogd to not bind to an inet socket. I prefer the "-ss" options as I do not need to listen for remote logging.

syslogd_flags="-ss -l /var/chroot/named/dev/log"

Page 34: Bind Freebsd

You may want to test BIND prior to rebooting. If so, we just need to restart syslogd and named manually with the following:

killall syslogd/usr/sbin/syslogd -ss -l /var/chroot/named/dev/log

rndc stop (or ndc for BIND 8)/usr/local/sbin/named -u bind -t /var/chroot/named -c /etc/named.conf

Hopefully your chroot experience was a good one. If not, most issues are usually related to a path or permissions issues and named will normally tell you exactly where the problem is. Also, you can use "ps -aux" to verify that named is now running under "bind" rather than "root".

7.0 Updating named.root (The root server list)

The named.root file provides a list of the Internet's root servers. These servers rarely change, however, you should probably update this file at least once. Take comfort in the fact that BIND will continue to function even if most of the root servers change. Though updating might prevent some query delays and will prevent annoying named messages such as: "check_hints: A records for A.ROOT-SERVERS.NET class 1 do not match hint records". You can quickly display your current named.root file by using 'dig' with no options:

% dig

; <<>> DiG 9.2.2 <<>>;; global options: printcmd;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47731;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 13

;; QUESTION SECTION:;. IN NS

;; ANSWER SECTION:. 490152 IN NS I.ROOT-SERVERS.NET.. 490152 IN NS J.ROOT-SERVERS.NET.. 490152 IN NS K.ROOT-SERVERS.NET.. 490152 IN NS L.ROOT-SERVERS.NET.. 490152 IN NS M.ROOT-SERVERS.NET.. 490152 IN NS A.ROOT-SERVERS.NET.. 490152 IN NS B.ROOT-SERVERS.NET.. 490152 IN NS C.ROOT-SERVERS.NET.. 490152 IN NS D.ROOT-SERVERS.NET.. 490152 IN NS E.ROOT-SERVERS.NET.. 490152 IN NS F.ROOT-SERVERS.NET.. 490152 IN NS G.ROOT-SERVERS.NET.. 490152 IN NS H.ROOT-SERVERS.NET.

;; ADDITIONAL SECTION:

Page 35: Bind Freebsd

A.ROOT-SERVERS.NET. 599366 IN A 198.41.0.4B.ROOT-SERVERS.NET. 599366 IN A 128.9.0.107C.ROOT-SERVERS.NET. 577232 IN A 192.33.4.12D.ROOT-SERVERS.NET. 577232 IN A 128.8.10.90E.ROOT-SERVERS.NET. 599366 IN A 192.203.230.10F.ROOT-SERVERS.NET. 577232 IN A 192.5.5.241G.ROOT-SERVERS.NET. 599366 IN A 192.112.36.4H.ROOT-SERVERS.NET. 599366 IN A 128.63.2.53I.ROOT-SERVERS.NET. 577232 IN A 192.36.148.17J.ROOT-SERVERS.NET. 576552 IN A 192.58.128.30K.ROOT-SERVERS.NET. 577232 IN A 193.0.14.129L.ROOT-SERVERS.NET. 577232 IN A 198.32.64.12M.ROOT-SERVERS.NET. 577232 IN A 202.12.27.33

;; Query time: 19 msec;; SERVER: 127.0.0.1#53(127.0.0.1);; WHEN: Wed Oct 1 18:43:16 2003;; MSG SIZE rcvd: 436

Notice that the output is conveniently formatted for a named.root file. Remember that semicolons are comments. Now change to the same directory that you store your named.root file. Backup your current named.root file. Then select any one of the Internet root servers from the list and issue the following: (We are using F.ROOT-SERVERS.NET as an example.)

cd /etc/namedbcp named.root named.root.old

dig f.root-servers.net > named.root

You will need to restart BIND before the changes become effective. That would be 'ndc restart for BIND 8 and 'rndc reload' for BIND 9.

8.0 Troubleshooting and Testing BIND

I will focus on using 'nslookup' for most of these tests. As far as I know, all distributions of BSD and Linux come with 'nslookup' as well as Windows NT/2000/XP, however, it is missing from Windows 95/98. ('dig' is a better tool, though you will not find it on Windows and 'nslookup' is easier for quick testing anyway.) The below examples use our 'foobar.example' domain noted earlier. Note that typing nslookup without options will land you in interactive mode much like ftp and telnet will. If you find yourself in interactive mode you can exit with exit or type help for help. The below examples will all use non-interactive mode. The syntax for nslookup is noted below:

nslookup [question] [name_server_to_ask]

The 'question' will typically be the name or address of a host, and 'name_server_to_ask' will be the address of the name server you are checking. You can omit the name server address so long as the name server you wish to query is the ONLY name server in your DNS list.

Page 36: Bind Freebsd

Note that you may need to clear the DNS cache on Windows clients for DNS changes to take immediate effect. This should not effect nslookup, but if all else fails, clear the cache or reboot. On Windows 2000/XP use 'ipconfig /flushdns'. Other Windows clients will need to be rebooted. Remember that you must use "ndc reload" for BIND 8 and "rndc reload" for BIND 9 before any zone files changes will be realized. Also, BIND must be restarted with "ndc restart" for BIND 8 and "rndc reload" for BIND 9 before changes to the main configuration file, named.conf, will be effective.

8.1 Troubleshooting Syntax And Other Configuration Errors

Thankfully BIND is very helpful in locating syntax errors. The best way to check, is by starting BIND and watching for error messages. If you are receiving the errors on boot, you can check the boot messages with the following:

grep named /var/log/messages

The most common mistake is the misuse of semicolons or braces "{ }" in named.conf. Remember that in named.conf semicolons end control statements and cannot be used as comments. However, semicolons ARE used as comments in zone data files. (This is due to the fact that zone files are RFC compliant while named.conf is specific to BIND). Remember that braces are used to contain control statements. Global control statements go within options { control_statement; }; and zone control statements go within zone "name_of_zone" { control_statement; };. Make sure you have set the directory option correctly in named.conf. The default location of the named directory on a non-jailed FreeBSD BIND is /etc/namedb, NOT /etc/named.

When configuring your zone data, remember that any name ending with "." (a dot) signifies an absolute name. For example: host1. (with the dot) will resolve to host1, whereas host1 (without the dot) will have the origin domain appended and resolve to host1.foobar.example. Remember that the "@" symbol is a shortcut for the origin. In our example, using "@" in our zone file is the same as using 'foobar.example'. Never us the "@" symbol for the administrative email address, instead use a dot.

The following are examples of some shortcuts:

Long: foobar.example. IN SOA ns1.foobar.example. root.ns1.foobar.example.Short: @ IN SOA ns1.foobar.example. root.ns1.foobar.example.Long: host1.foobar.example. IN A 192.168.1.100Short: host1 IN A 192.168.1.100

There are also some shortcuts for our reverse lookup zone:

Page 37: Bind Freebsd

Long: 1.168.192.in-addr.arpa. IN SOA ns1.foobar.example. root.ns1.foobar.example.Short: @ IN SOA ns1.foobar.example. root.ns1.foobar.example.Long: 100.1.168.192.in-addr.arpa. IN PTR host1.foobar.example.Short: 100 IN PTR host1.foobar.example.

Below is the correct and incorrect way to specify the administrative address:Correct: @ IN SOA ns1.foobar.example. root.ns1.foobar.example.Incorrect: @ IN SOA ns1.foobar.example. [email protected].

8.2 Testing Forward Name Resolution

We will start testing directly form the console of our name server. First, lets jump right in and try resolving a name for our own private internal network. Ensure that the server you are connecting to is 127.0.0.1. If not, then you will need to either configure /etc/resolv.conf with "nameserver 127.0.0.1" or append 127.0.0.1 to the end of your nslookup command as explained earlier. In the following examples "%" represents the command prompt (you will see a "#" if you are still logged in as root.).% nslookup host1 (replace 'host1' with a real name in your zone file.)

Server: localhost.foobar.exampleAddress: 127.0.0.1

Name: host1.foobar.exampleAddress: 192.168.1.100

If this failed with "Non-existent domain" or "NXDOMAIN" then the most obvious problem may be that the hostname you attempted to lookup is not in your forward lookup zone file. If you are sure that your forward zone contains the correct name, you may need to reload the zone or try using your client's fully qualified name, i. e. 'host1.foobar.example'. If the fully qualified name works, then you may want to set your 'domain' in /etc/resolv.conf. Below is an example. Alternatively you will need to use the fully qualified domain name for each lookup.domain foobar.examplenameserver 127.0.0.1

If you receive error "Can't find server name for address 127.0.0.1......" Then your name server is either not running or not listening on 127.0.0.1. Check that named is running with the following: (You will need to run ps as root.)

ps ax | grep named

This should return the process ID and path to named. (Note: sometimes, instead of the path to named "/usr/local/sbin/named", you will receive "grep named". This is not named running but rather the grep command.) If this is ok, check which interface BIND is listening on with 'netstat' as explained below in "Test which interfaces BIND is listening on".

If you are still receiving "Non-existent domain" error, then make sure you have entered the name correctly in your forward lookup zone. Use a trailing dot only when you use the fully qualified domain name for a host. If you make changes to named.conf you will need to issue 'ndc restart' for BIND 8 and 'rndc restart' for BIND 9 before the changes take effect. If you make changes to

Page 38: Bind Freebsd

any of your zone files, you will need to issue 'ndc reload' for BIND 8 and 'rndc restart' for BIND 9 before changes take effect.

Now lets try resolving names from a client. We can use nslookup to test our name server from any Unix or Windows NT/2000/XP client connected to your network. For this example we will be using a Windows command prompt from 'host2' to resolve the address of 'host1'. We will append our name server address to the end of nslookup to ensure we are querying the correct name server.

C:\>nslookup host1.foobar.example 192.168.1.1 (replace 192.168.1.1 with the IP of your name server)

Server: ns1.foobar.exampleAddress: 192.168.1.1

Name: host1.foobar.exampleAddress: 192.168.1.100

You are in good shape if your results were similar to the above example. If instead you received something similar to "*** Can't find server name for address 192.168.1.1: No response from server (or Time out:)" then your name server is not listening to you. We know it is running because we tested that earlier. First try to ping your name server:

ping 192.168.1.1

If, from a Windows machine, you received "Destination host unreachable" then you most likely have a networking issue on your local machine. If you received "Request timed out" then your name server is either not at the address you thought is was, your link to the server is broken, or your server is not returning ICMP ping requests. In any case you will need to endeavor in some basic network troubleshooting.

If on the other hand, you are receiving ping replies from your server then you know your DNS is either broken or blocked. You will need to ensure that a firewall on your server, a router, or even your host is not blocking UDP/TCP ports 53 out from your client and into the server. Also be aware that DNS responses will almost always come back on a port above 1024 (usually UDP). You will also need to ensure that your name server is listening on the correct interface and ports. This is covered in more detail later.

Note that you may need to clear the DNS cache on Windows clients for DNS changes to take immediate effect. This should not effect nslookup, but if all else fails, clear the cache or reboot. On Windows 2000/XP use 'ipconfig /flushdns'. Other Windows clients will need to be rebooted.

8.3 Testing Reverse Name Resolution

Page 39: Bind Freebsd

This is essentially the same as testing forward name resolution, with the obvious exception that we are using a host's IP address rather than the host's name. The following tests are intended to be run from our name server's console and assume your forward name resolution works. Choose an address of one of your own hosts and attempt to look it up: % nslookup 192.168.1.100

Server: ns1.foobar.exampleAddress: 127.0.0.1

Name: host1.foobar.exampleAddress: 192.168.1.100

If this fails, ensure your reverse lookup zone (in-addr.arpa) is configured correctly and loaded from your named.conf file. Ensure your host's name and address have been added correctly. Any other issues are likely to have shown up during our forward name resolution testing earlier.

8.4 Testing External Name Resolution

Now lets see if we can resolve the name to address mapping for an external address--www.freebsd.org. I will assume you are working form a console on the name server and that forward and reverse name resolution was successful. If you are not working from your name server console, you may need to append the address of your name server to the end of your nslookup command.% nslookup www.freebsd.org

Server: ns1.foobar.exampleAddress: 192.168.1.1

Name: www.freebsd.orgAddress: 216.136.204.117

If you received something such as the following: "*** ns1.foobar.example can't find www.freebsd.org: Non-existent host/domain" ensure that you have a "hints" file listing the Internet root servers and that it is being loading from named.conf. The "hints" file is installed by BIND 8 and BIND 9 as /etc/namedb/named.root. The name of the file does not matter so long as it matches your entry in named.conf. The following section form named.conf would load a hints file named named.root form the directory specified by the directory option in named.conf.

zone "." {type hint;file "named.root";

};

If you are using "forwarders” in your named.conf, then make cretin that those name servers (probably your ISP's) are accessible. The quickest was to check is to simply append your IPS's name server (123.123.123.123 for this example) to the end of your 'nslookup' command:

Page 40: Bind Freebsd

% nslookup www.freebsd.org 123.123.123.123

Server: name-server-at.myisp.netAddress: 123.123.123.123

Name: www.freebsd.orgAddress: 216.136.204.117

Also be aware that a forwarding name server still requires a hints file. If you have included the "forward only;” option, you will probably not need a hints file. If you are still having issues, ensure that your queries are not being dropped by a firewall and that you have Internet connectivity…Duh.

8.5 What Interface Is BIND Listening On?

We will use the 'netstat' command to list which ports are listening on each interface. Remember that the loopback 127.0.0.1 is an interface and should almost always be listening for DNS queries. We will through the "-n” option at 'netstat' to display the ports and addresses as numbers. If you leave the "-n” off, 'netstat' will instead list interfaces by name and the DNS port as "domain”. I find this confusing, but you may like it. Now lets look for open UDP/TCP ports 53 which are the standard DNS ports.

netstat –n

The output from our ns1.foobar.example name server includes the following:

tcp4 0 0 127.0.0.1.53 *.* LISTENtcp4 0 0 192.168.1.1.53 *.* LISTENudp4 0 0 127.0.0.1.53 *.*udp4 0 0 192.168.1.1.53 *.*

Using the first line as an example, the important things to note here is that tcp4 indicates TCP version 4 as apposed to version 6 (most everyone still uses version 4). The "127.0.0.1.53” indicates that local address 127.0.0.1 is listening on TCP port 53. If instead we had and entry such as "*.53” then we would be listening for DNS queries on all interfaces. Notice also that UDP is a connectionless protocol and does not show as "LISTENING” for connections like TCP. In case you are wondering, almost all DNS queries use UDP. In some cases, however, TCP will be used if the data is too large for UDP packets such as during complete zone transfers. So, if your server is not listening on the correct interfaces, or is listening on too many interfaces, you will want to look at named.conf. Below are the option statements which effect this behavior:

options {allow-query { 192.168.1/24; 127.0.0.1; };listen-on { 192.168.1.1; 127.0.0.1; };};

Page 41: Bind Freebsd

If all else fails, don't forget about firewalls. Ensure that a firewall on your server, a router, or even your host is not blocking UDP/TCP ports 53 out from your client and in to your server. Also be aware that DNS responses will almost always come back on a port above 1024 (usually UDP). By the way, if you want to be fancy, you can also use 'sockstat' instead of 'netstat'. In the below example "-4” indicates TCP version 4 and we will pipe the output to grep filtering for "named”.

sockstat –4 | grep named

8.6 What Version of BIND Is Running?

Now lets check which version of BIND we are running. I will cover several different options all of which will be run from a console on the name server. The easiest way to check the version is to use 'dig' as shown below. (If you added "version "some_text"; to your 'options' statement in named.conf, you will receive "some_text" rather than the version.) The below example shows the version information for BIND 9.2.2. in bold. Don't be fooled by "<<>> DiG 9.2.2 <<>>", this is the version of our tool, not our name server.

%dig txt chaos version.bind @localhost

; <<>> DiG 9.2.2 <<>> txt chaos version.bind;; global options: printcmd;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51001;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:;version.bind. CH TXT

;; ANSWER SECTION:version.bind. 0 CH TXT "9.2.2"

;; Query time: 3 msec;; SERVER: 127.0.0.1#53(127.0.0.1);; WHEN: Wed Oct 1 21:52:30 2003;; MSG SIZE rcvd: 48

Also, you can simply pass the "-v" option to 'named' to ask for the version. If, however, you have more than one 'named' on your server, you will need to ask the question carefully. First, lets find the location of the 'named' that is running on our server:

%ps -ax | grep named 74 ?? Ss 0:00.08 /usr/local/sbin/named

Now lets ask /usr/local/sbin/named which version it is:

%/usr/local/sbin/named -v BIND 9.2.2

Page 42: Bind Freebsd

Now we know BIND 9.2.2 is running. Just for fun, lets not specify the path to 'named':

%named -v

named 8.3.3-REL Wed Oct 9 12:19:59 GMT 2002 [email protected]:/usr/obj/usr/src/usr.sbin/named

Oops, looks like the old 'named' is found earlier in our path variable. Luckily it is not the version that is currently running. If you run a tight ship, you will want to get this old version off you machine or at least make it non-executable.

9.0 Additional Resources

I do hope you found this HOWTO helpful, though be aware that there is a lot more to DNS than what we have covered here. You will likely find the following resources beneficial if you would like to learn more, particularly in the area of security.

Internet Software consortium (The home of BIND):www.isc.org/products/BIND/

BIND specific links on bind9.netwww.bind9.net/links

General DNS links on bind9.netwww.bind9.net/dns-links

Ask Mr. DNS (Be sure to check the Ask Mr. DNS Archive)www.acmebw.com/askmrdns/

Upgrading to BIND 9: The Top Nine Gotchas: by Cricket Liuhttp://sysadmin.oreilly.com/news/dnsandbind_0401.html

DNS Resources Directory on DNS.netwww.dns.net/dnsrd/

Secure BIND Template: by Rob Thomaswww.cymru.com/Documents/secure-bind-template.html

Chroot-BIND HOWTO: by Scott Wunschwww.linuxsecurity.com/docs/LDP/Chroot-BIND-HOWTO.html

Dual chrooted BIND/DNS servers: by Dave Lugowww.etherboy.com/dns/chrootdns.html

Page 43: Bind Freebsd

Please feel free to contact me with corrections or comments.

Glenn Sidman