Recently I migrated core functionality from my home Windows 2000 Server to a new host running ESXi 4.0 with three Ubuntu Server 9.10 VMs. If you want to see a simple diagram on my set up, view my article on Linux Backup Shell Script. One of the core functionality that I migrated was my internal DNS services. Hence the title of this article, DNS Server with Bind9.

bind9

I am impressed, once again, with Linux and the services residing within this amazing operating system. The most amazing part about Linux services is that many of them have been around as long as I have — where have I been?

Before I begin rambling too much, let’s get started on creating DNS forward and reverse zones for your local network …

First ensure you have bind9 installed by running the following command:

whereis bind

If the results is blank, such as just “bind: “, then you will need to install bind9. On Ubuntu, I would imagine the command would look like this:

sudo apt-get install bind9

Forward Zones

We need to configure your DNS forward zones, which will provide name to address resolution in your internal network. As we progress the configuration, keep in mind that your specific configuration will be slightly different than mine; adapt as needed.

For simple networks, such as mine at home, there are only a few changes that you will need to make for Forward lookup zones. The first file is /etc/bind/db.local.

/etc/bind/db.local

The changes are fairly easy because we going to use most of what is provided in the original file. Change the Start of Authority (SOA) to be the domain environment for your network. My domain is dt.local and my primary DNS server is dtsfile.dt.local. Change the SOA to reflect your choices and also change the nameserver (NS) line to be your primary DNS server.

Also, you will want to add A records for your various servers/computers on the network. For this example, I added my Asterisk server:

dtsvoip.dt.local.	IN	A	192.168.0.11

The next file to change, which we will also make changes for reverse DNS at the same time, is the /etc/bind/named.conf.default-zones file.

/etc/bind/named.conf.default-zones

The line for the primary zone, which references the /etc/bind/db.local file must state your local domain in the quotes following the zone directive:

zone “dt.local” {
  type master;
  file “/etc/bind/db.local”;
};

As we have more changes in this file, leave it open and continue to the next section.

Reverse Lookup Zones

As you probably know, a reverse lookup provides a name to an IP address. In Windows you would find the name of 192.168.0.10 by typing “nslookup 192.168.0.10” from a command prompt. If you have configured reverse DNS properly, you will see output similar to this:

C:\>nslookup 192.168.0.10
Server:  dtsfile.dt.local
Address:  192.168.0.10

Name:    dtsfile.dt.local
Address:  192.168.0.10

You may be wondering why the entry appears twice. This is because the Server and the name that I am looking up is the same server. If I were to locate my Asterisk server, it would look like this:

C:\>nslookup 192.168.0.11
Server:  dtsfile.dt.local
Address:  192.168.0.10

Name:    dtsvoip.dt.local
Address:  192.168.0.11

On with the configuration…

/etc/bind/named.conf.default-zones

If you were paying attention in the previous section you would still have that file open. Regardless, let’s add another zone to the file that represents our reverse lookup for the IP subnet in your network. In my network I use 192.168.0.0/24 which is the same as saying 192.168.0.0 with a subnet of 255.255.255.0 (192.168.0.0 to 192.168.0.255).

Immediately after the zone directive for your domain, add the following text for your reverse lookup:

zone “0.168.192.in-addr.arpa” {
  type master;
  file “/etc/bind/db.0.168.192”;
};

If you’re sharp, you’ll immediately know that the file db.0.168.192 doesn’t exist. We’ll create it next. And yes, it’s backwards; in reverse DNS lookups the IP address is reversed as part of the requirements set in the RFC and obviously for functionality pointing back to the host name of the IP. Read more: http://en.wikipedia.org/wiki/Reverse_DNS_lookup

Save changes to named.conf.default-zones.

/etc/bind/db.0.168.192

Next we’ll create a new zone db file for our newly created reverse lookup. Start by copying db.0 into a new file named db.0.168.192 (or whatever your local subnet IP address is).

cp /etc/bind/db.0 /etc/bind/db.0.168.192

Just like in your db.local file, let’s change the SOA to reflect your domain and nameserver. This includes the NS line that should already exist in the file. Now let’s add pointer (PTR) records for your servers/computers on the network. I’ll use mine for examples:

10	IN	PTR	dtsfile.dt.local
11	IN	PTR	dtsvoip.dt.local

Save changes to db.0.168.192.

Forwarders

The last section, assuming you want to use this DNS server as your primary DNS on all computers, is to set up a forwarder for all names that are not a part of your network. You will need to edit /etc/bind/named.conf.options.

/etc/bind/named.conf.options

The change is really simple, uncomment the forwarders directive and modify the IP address within to be your local router or your ISP DNS servers. Mine is similar to the following:

forwarders {
  192.168.0.1;
};

Local Name Resolution

The final step is to change your /etc/resolv.conf file to point your DNS server and to set the domain and search realm. This is what mine looks like:

domain dt.local
search dt.local
nameserver 192.168.0.1

Restart the bind9 daemon

After making all of these changes, the final is to restart the bind9 daemon. Oh, one other step is to change your computers to use this DNS server as the primary.

Configuration Files Examples

/etc/bind directory listing

/etc/bind# ls -la
drwxr-sr-x   2 root bind  4096 2010-08-01 17:52 .
drwxr-xr-x 141 root root 12288 2010-08-01 17:54 ..
-rw-r--r--   1 root root   237 2009-08-19 15:00 db.0
-rw-r--r--   1 root root   271 2009-08-19 15:00 db.127
-rw-r--r--   1 root bind   295 2010-08-01 17:22 db.0.168.192
-rw-r--r--   1 root root   237 2009-08-19 15:00 db.255
-rw-r--r--   1 root root   353 2009-08-19 15:00 db.empty
-rw-r--r--   1 root root   316 2010-08-01 17:14 db.local
-rw-r--r--   1 root root  2940 2009-08-19 15:00 db.root
-rw-r--r--   1 root bind   463 2009-08-19 15:00 named.conf
-rw-r--r--   1 root bind   573 2010-08-01 16:50 named.conf.default-zones
-rw-r--r--   1 root bind   165 2009-08-19 15:00 named.conf.local
-rw-r--r--   1 root bind   570 2010-07-16 11:58 named.conf.options
-rw-r-----   1 bind bind    77 2010-01-30 11:50 rndc.key
-rw-r--r--   1 root root  1317 2009-08-19 15:00 zones.rfc1918

./db.0.168.192

;
; BIND reverse data file for broadcast zone
;
$TTL    604800
@       IN      SOA     dt.local. dtsfile.dt.local. (
        1         ; Serial
   604800         ; Refresh
    86400         ; Retry
  2419200         ; Expire
   604800 )       ; Negative Cache TTL
;
@       IN      NS      dt.local.
10     IN      PTR     dtsfile.dt.local.
11     IN      PTR     dtsvoip.dt.local.

./db.local

;
; BIND data file for local loopback interface
;
$TTL    604800
@       IN      SOA     dt.local. dtsfile.dt.local. (
        2         ; Serial
   604800         ; Refresh
    86400         ; Retry
  2419200         ; Expire
   604800 )       ; Negative Cache TTL
;
@       IN      NS      dtsfile.dt.local.
@       IN      A       127.0.0.1
@       IN      AAAA    ::1
dtsvoip.dt.local.       IN      A       192.168.0.11

./named.conf.default-zones

// prime the server with knowledge of the root servers
zone "." {
  type hint;
  file "/etc/bind/db.root";
};

// be authoritative for the localhost forward and reverse zones, and for
// broadcast zones as per RFC 1912

zone "dt.local" {
  type master;
  file "/etc/bind/db.local";
};

zone "0.168.192.in-addr.arpa" {
  type master;
  file "/etc/bind/db.0.168.192";
};

zone "127.in-addr.arpa" {
  type master;
  file "/etc/bind/db.127";
};

zone "0.in-addr.arpa" {
  type master;
  file "/etc/bind/db.0";
};

zone "255.in-addr.arpa" {
  type master;
  file "/etc/bind/db.255";
};

./named.conf.options

options {
directory "/var/cache/bind";

// If there is a firewall between you and nameservers you want
// to talk to, you may need to fix the firewall to allow multiple
// ports to talk.  See http://www.kb.cert.org/vuls/id/800113

// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses replacing
// the all-0's placeholder.

forwarders {
  192.168.0.1;
};

auth-nxdomain no;    # conform to RFC1035
  listen-on-v6 { any; };
};

/etc/resolv.conf

domain dt.local
search dt.local
nameserver 192.168.0.1

Creating the Link Aggregate

If your configuration was similar to mine, you will already have your interfaces plumbed – which means they cannot be added to the link aggregate until they are unplumb’ed.

Checking for Plumbing

If you try to create an aggregate with plumbed interfaces, you will receive a “dladm: create operation failed: link busy” error. You can check if they have been plumbed as they will show in the list for “ifconfig -a”:

e1000g0: flags=1000842<BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 8
 inet 0.0.0.0 netmask 0
 ether 0:15:17:b8:47:a8
e1000g1: flags=1000842<BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 9
 inet 0.0.0.0 netmask 0
 ether 0:15:17:b8:47:a9
e1000g2: flags=1000842<BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 10
 inet 0.0.0.0 netmask 0
 ether 0:15:17:b8:47:aa
e1000g3: flags=1000842<BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 11
 inet 0.0.0.0 netmask 0
 ether 0:15:17:b8:47:ab

If they appear, as shown above, unplumb them using the following commands:

ifconfig e1000g0 unplumb
ifconfig e1000g1 unplumb
ifconfig e1000g2 unplumb
ifconfig e1000g3 unplumb

Create the Aggregate and Plumb It!

Using the dladm tool, you can easily create the aggregate usign the following command:

dladm create-aggr -d e1000g0 -d e1000g1 -d e1000g2 -d e1000g3 1

You’lll notice a -d with each interface and a number 1 at the end. The number 1 references the aggregate number and it must start at 1, not 0.

Next we will plumb the newly created aggregate with an IP address:

ifconfig aggr1 plumb 192.168.0.101 up

Show me the Aggregate

If you are like me, then you will want to see the aggregate configured:

dladm show-aggr

You should see an output similar to the following:

LINK            POLICY   ADDRPOLICY           LACPACTIVITY  LACPTIMER   FLAGS
aggr1           L4       auto                 off           short       -----

Modify Aggregate for LACP

To ensure that LACP is functioning as I would hope, I modified the aggregate, changing LACPACTIVITY to active instead of off. Use the following command to modify LACPACTIVITY:

dladm modify-aggr -L active -T short 1

Now run the following command to verify the settings took:

dladm show-aggr

You should now see an output similar to the following:

LINK            POLICY   ADDRPOLICY           LACPACTIVITY  LACPTIMER   FLAGS
aggr1           L4       auto                 active        short       -----

Setting Aggregate IP Configuration as Persistent

To ensure that your IP address configuration for the aggregate is persistent across reboots, modify the /etc/hostname.aggr1 file and add the desired IP address. The /etc/hostname.aggr1 should contain one line consisting of the IP address:

192.168.0.101

Switch Configuration

Obviously, you must configure the switch for LACP otherwise your aggregate will fail. Each switch is different, refer to the manual for your switch.

I’m out…

PROSet Application?

The PROSet tool is no longer a separate application. Instead, Intel has integrated the PROSet functionality into the device properties of the Intel network interface cards. In my situation, I had to install the 64bit, “Windows 7” driver PROWIN7X64.EXE. Obviously, this will install the latest drivers for the Intel NIC, and it will install the PROSet device manager adaption – and hopefully you specified to have the Advanced Network Services (ANS) installed too.

Open a properties window for your network interface card and click on the Configure button – you should notice Advanced, Link Speed – and if you are lucky Teaming and VLAN!

The Teaming Tab

For those that know they should have the Teaming tab available, but for some reason do not (verify full support), you may need to disable and re-enable one of the ports on the adapter for Teaming to show up.

For those that had the teaming tab visible, you must disable iSCSI Remote Boot. There are apparently two ways to configure this: one is through configuring the adapter during the Intel boot message during, well a system boot; two is through flashing the ROM on the adapter, removing the iSCSI Remote Boot functionality all together. I ended up performing the latter…

Removing the iSCSI Remote Boot

Download the latest Intel tool package, PROBOOT.EXE, for your controller, for me, it was PROBOOT.EXE. Extract these files onto a form of media that you can access from a DOS prompt and boot your computer into DOS. If you do not have a DOS boot disk, there are plenty of sites available that can assist you with making a DOS boot disk/CD. Once you have access to the files from PROBOOT, run the following:

1. “ibautil -all -flashenable”
     -reboot your computer into DOS again-
2. “ibautil -all -upgrade”
     -reboot into Windows-

Creating the Team

Now that you know where the PROSet “application” resides, the Intel Proset for Windows Device Manager, and you have the Teaming tab available, create the Team.

Unsure if my situation is unique, however I used 802.3ad LACP for my team and had to wait for the team virtual adapter to be completely initialized PRIOR to modifying the properties of that team. The first round, I modified the IPv4 address on the team before it was done initializing and it completely messed up the team interface, rendering it useless. Need an example? See below:

Credits

For the closure of this issue, I had the assistance of a gentleman from Intel and another user that had a similar problem:

http://communities.intel.com/message/60941

A mapped network drive apparently does not “lock” the use of the drive letter and Windows will allow other devices that are attached at a later time to assign themselves a drive letter that is already in use via a mapped drive. As stated above a system with 4 physcial drives would use 4 drive letters which would normally take A: through F: (A: and B: are automatically assigned to floppy drives regardless if you even have a floppy drive).

So if you map a network drive file://server/share to drive letter G:, and then plug in a memory stick, there is a good chance that Windows will assign drive letter G: to the memory stick. The mapped drive will continue to work, but you will not be able to access your memory stick.

Resolution:

1. Make sure the memory stick is plugged in.
2. Right click on My Computer and choose Manage.
3. Under Storage \ Disk Management you should see the memory stick, and which drive letter it assigned it.
4. Right click that Memory Stick entry and choose Change Drive Letter and Paths.
5. Choose an unused drive letter. It should stick with this newly set drive letter everytime for that memory stick.

Note: This guide is for informational purposes only. Use the information provided at your own risk. I am not responsible for your actions or the outcome of any method or instruction given or used in this article.