Friday 18 February 2011

HOWTO: MASTER and SLAVE with Bind

So you have built yourself an authoritative nameserver and now you want to build a slave for it to replicate to.

Unfortunately, this is one of those things that is unnecessarily difficult to do on Linux. There are lot's of guides and howto's but they all seem to be missing bits and pieces of the puzzle. The good news is that after a few days of frustration I've figured out how to do it and I'm here to share the secret. Once you know what to do it is really extremely simple.

I'm using Ubuntu LTS Server 10.04 "Lucid Lynx", but as usual any debian based distro should be fine.

Pre-requisites:
Two working authoritative DNS servers built according to this guide. Both of these servers should be able to authoritatively resolve names for your local network.

Note:
In this howto we will using an MD5 key. The key used in this guide is sanitized (ie: not a real key) and should not be used "as is".

Example Network:
For the example network the domain I will be using is tuxnetworks.net, the MASTER server will be on 10.1.1.1 and the SLAVE server on 10.1.1.2. Of course you should substitute these values for ones that are valid on your own network. The two servers will be named ns1 and ns2.

OK, let's get cracking.

First up, before we can start doing zone transfers, we need to enable "dns security extensions" on both servers;

On BOTH servers, edit your named.conf.options file;

sudo vi /etc/bind/named.conf.options

Add this line within the options { }; section;

dnssec-enable yes;

Modify the allow recursions line so that it looks similar to this (using your own IP address's of course).

allow-recursion { 127.0.0.1; 10.1.1.0/24; };

Note:
These are all the hosts and networks that will be allowed to query the server(s) and should include both the Bind servers we are building. Since both our servers are in the 10.1.1.0/24 subnet we don't need to explicitly define them, if they weren't you would put their IP address in here too.

When we install bind, it will create a key that we can use. However, the keys will be different on the two servers. Let's copy the key from the MASTER to the SLAVE.

On the SLAVE, backup the old key file;

sudo cp /etc/bind/rndc.key /etc/bind/default.rndc.key

Cat the rndc.key file on the MASTER;

sudo cat /etc/bind/rndc.key
key "rndc-key" {
algorithm hmac-md5;
secret "BCRNAwUG2DRqz3fYleLO/g==";
};


On the SLAVE edit the rndc.key file and change the "secret" so that it is the same as the secret in the MASTER key.

sudo vi /etc/bind/rndc.key

The "secret" line should be changed to look the same as on the MASTER;

secret "BCRNAwUG2DRqz3fYleLO/g==";

Great. Now we need to edit the zone definition files on both servers. If you followed my guide to build your servers then it will be in named.conf.myzone-net. Other guides might put this info into named.conf or named.conf.options. The file is the one with the zone myzone { }; definition for your zone in it.

On BOTH servers, edit your zone definition file;

sudo vi /etc/bind/named.conf.tuxnetworks-net

Add this line to the end of the file.

include "/etc/bind/rndc.key";

Now we reach the part where the MASTER and SLAVE servers are configured differently.

We will begin with the MASTER server. On the MASTER, edit your zone definition file again;

sudo vi /etc/bind/named.conf.tuxnetworks-net

Add this section (using the IP address of the SLAVE server);
server 10.1.1.2 {
keys {
rndc-key;
};
};


Next we configure the SLAVE. Again, we edit the zone definition file;

sudo vi /etc/bind/named.conf.tuxnetworks-net

Inside the definition for the zone change the type from "master" to "slave" and add two lines to define the master servers details and specifically allow it to update the SLAVE.

Here is an example (use the IP address of your MASTER server here);
# This is the zone definition for the tuxnetworks.net zone.
zone "tuxnetworks.net" {
type slave;
file "/etc/bind/db.tuxnetworks.net";
masters { 10.1.1.1; };
allow-notify { 10.1.1.1; };
};

Also, add another section (using the MASTER IP address) to tell it to use the rndc-key;
server 10.1.1.1 {
keys {
rndc.key;
};
};


And that's it. We also need to ensure that both the servers are listed in the SOA section of your zone file (the zone file is the one where all the IP addresses for your network are located.

On BOTH servers open your zone file;

sudo vi /etc/bind/db.tuxnetworks.net

The top or second line should look like this (ie it should be showing both your DNS servers);

tuxnetworks.net. IN SOA ns1.tuxnetworks.net. ns2.tuxnetworks.net. (


Your NS servers should be defined properly;
; DNS Servers
tuxnetworks.net. IN NS ns1.tuxnetworks.net.
tuxnetworks.net. IN NS ns2.tuxnetworks.net.

We also need to define the IP address for both servers;
ns1             IN      A       10.1.1.1
ns2 IN A 10.1.1.2


Finally, for replication to occur, the two servers must be in close time sync. To ensure their internal clocks are synced properly, we will install ntpdate on both servers (this may already be installed on your systems)

sudo apt-get install ntpdate

Update the system time on both servers;

sudo ntpdate ntp.ubuntu.com

Check that the times are both in sync with the date command on both servers;

date
Wed Feb 11 10:30:16 EST 2011


Both systems should be within a few seconds. If they are way out, check that the timezones on both systems are the same;

dpkg-reconfigure tzdata

NOTE:
There is a bug in Ubuntu 10.04 bind package. When you it installs bind it fails to set the permissions correctly on the /etc/bind directory. I'm not sure if this affects other debian based distro's or not. A tell tale sign that the bug is in place (apart from slave updates not working) is an error in the syslog "bind dumping master file permission denied". To fix this change the ownership of the directory to the bind user;

sudo chown bind:bind /etc/bind

To make all the changes, restart bind on both servers;

sudo service bind9 restart

To test if your replication is working, go to the master server and edit the zone file. Increment the "serial" by one and issue a reload command on both servers;

sudo rndc reload

Now, if you look at the zone file on the slave, it should have been updated with the new serial.

When you are satisfied that both servers are working properly, you should remember to update your clients (or more likely your DHCP server) so that all your clients use both of your servers for resolving names.

Troubleshooting:
- Check your server times are in sync
- Check the permissions on /etc/bind
- Check that there are no firewalls between the two servers

A word on zone files:
Any time you make a change to the zone file on the master you need to update the serial. There is no set rule as to how the serial number should be formed. It can simply be an integer that you increment for each change if you like. I prefer to use the date in the form YYYMMDD with two trailing digits to allow for multiple increments within a day. That way I can know the date the last time the file was modified. As always YMMV.

I've tried to make this as simple to follow as possible. If there is something I haven't made clear enough then by all means leave me a message in the comments and I will tweak this howto accordingly.

Also, to make things a bit easier, you might like to download copies of all the example config files and modify them to suit your network.

Otherwise, enjoy your new DNS servers!

Friday 4 February 2011

HOWTO: Configure A Router

Now we get to turn our debian or ubuntu server into a router. Read on!

Prerequisites;
1) A server as per this guide.

2) A working PPPoE or PPPoA based Internet connection. Most consumer ADSL and Cable Internet is provided using one of these protocols, support for which is built into the consumer "router" I am assuming you are currently using.

3) The ISP provided username and password combo for your Internet connection. If you have a "router" that was provided by your ISP they sometimes print these on a label attached to the device, otherwise it will be written on the documentation you received when you signed up (and promptly lost I'm sure). You will have to call your ISP on the actual telephone to retrieve this information if you have lost it.

4) An Ethernet switch and sufficient cables to connect at least two devices. Your current Internet Gateway may currently have the Ethernet switch built in to it. Alternately, you may use a separate switch if you prefer.

5) If you are intending to use a discreet modem (cable or ADSL) and a separate switch then two LAN cards are required. Unless you are one of the incredibly lucky few who have access to FttH you will most likely have some form of ADSL or Cable service with speeds measured in single-figure MegaBits. This means that it is perfectly OK to reuse a discarded old 100baseT adapter (or indeed even a 10baseT if you still have one of those in the antiques cupboard) for your WAN interface. Even the slowest LAN card will be considerably faster than most current Internet connections. If you intend to go down the Router-in-bridged-mode road then a single Ethernet adapter will suffice.

OK, now that you have all the prerequisites in order, and a basic server up and running we can get on with bidness proper.

The first thing we need to do is install a few packages we will need before we disconnect ourselves from the Internet.

apt-get install pppoeconf ppp

Next we configure the LAN side of the network.

Note: I will assume that your LAN adapter is eth0 from this point onwards. If you are using two Ethernet adapters this would make your WAN interface eth1.

Because we are configuring a router, we must use a static IP address for our LAN adapter. If you followed my server guide then you have already done that, otherwise you should backtrack and configure a static IP address as per that guide.
Pro Tip: For testing purposes, I recommend that you configure some other PC on your LAN with a static IP in the 10.1.1.x subnet with a default gateway of 10.1.1.1. We will be using this PC from time to time for testing. This can be either a Linux or Windows PC.

Plug both the server and client hosts into your LAN and check that you can ping the server at 10.1.1.1 from the client.

OK. Once you can ping your server from the test PC we can continue.
The next step varies depending on whether you are using a single adapter and a router in "bridged mode" or a separate modem and 2 Ethernet adapters.

Separate modem and two adapters: You must configure eth1 as per the above instructions for eth0 using any old IP address you like. I suggest you use 192.168.254.254/24. The address will not be used for anything on your network but is required so that the pppoeconf utility in the next section can locate your modem. Make sure you plug your modem into this interface

Consumer router in "bridged" mode: You will need to configure the router in "bridged" mode[1] according to the instructions provided by the manufacturer of the device. On my DG834G it is a simple matter of browsing to http://192.168.0.254/setup.cgi?next_file=mode.htm (where 192.168.0.254 is the address of my gateway) and setting the drop-down box to "Modem Only". I found that info via a Google search here. You should do a Google search for something like my-gw-model-number +"bridged mode" or similar to find instructions on how to configure your particular router.

Once you have your router in bridge mode, we can use the pppoeconf utility to configure a PPP connection to our ISP;

sudo pppoeconf

Go through each screen choosing the default option until you get to the "ENTER USERNAME" screen. Enter the username for your ISP account here.

The next screen asks for your password, enter that too.

In the "USE PEER DNS" screen select "No"

Select the default option on all the remaining screens.

You should now have Internet connectivity on this host. You can check this with the ifconfig command;

ifconfig ppp0
ppp0 Link encap:Point-to-Point Protocol
inet addr:123.4.56.789 P-t-P:123.4.8.1 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1
RX packets:59687317 errors:0 dropped:0 overruns:0 frame:0
TX packets:50606162 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:2967668270 (2.9 GB) TX bytes:2950135549 (2.9 GB)



You should (hopefully) see a ppp0 adapter in the output similar to this. If you do, we should do a few more tests. First, lets check we can ping our DNS server. To find your DNS server type;

cat /etc/resolv.conf

There should be an entry "nameserver" with an IP address in the output.

Let's ping that IP address and see if it works;

ping -c 4 208.67.222.222
PING 208.67.222.222 (208.67.222.222) 56(84) bytes of data.
64 bytes from 208.67.222.222: icmp_seq=1 ttl=55 time=322 ms
64 bytes from 208.67.222.222: icmp_seq=2 ttl=55 time=196 ms
64 bytes from 208.67.222.222: icmp_seq=3 ttl=55 time=281 ms
64 bytes from 208.67.222.222: icmp_seq=4 ttl=55 time=547 ms

--- 208.67.222.222 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 196.763/337.020/547.292/129.589 ms


(The IP above is for OpenDNS)

We can test that DNS is working by pinging by name;

ping -c 4 www.google.com
PING www.l.google.com (74.125.237.18) 56(84) bytes of data.
64 bytes from 74.125.237.18: icmp_seq=1 ttl=57 time=261 ms
64 bytes from 74.125.237.18: icmp_seq=2 ttl=57 time=285 ms
64 bytes from 74.125.237.18: icmp_seq=3 ttl=57 time=24.2 ms
64 bytes from 74.125.237.18: icmp_seq=4 ttl=57 time=122 ms


If you got this far then that is great, but please be aware that although our Internet connection is now up and working, we have not done enough to get our LAN clients up and on the 'net. For that we need to configure routing, NAT and a firewall.

We can configure routing by issuing editing the following file;

sudo vi /etc/sysctl.conf

Find the following line and change it from 0 to 1;

net.ipv4.ip_forward=1

To configure an extremely basic firewall, create a file in a suitable location such as /usr/sbin/ with the following contents;

sudo vi /usr/sbin/firewall
8< - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
#!/bin/bash

WAN=ppp0
LAN=eth0

sudo /sbin/iptables --flush

# Accept ALL packets inbound from our local networks
sudo /sbin/iptables -A INPUT -i $LAN -j ACCEPT
sudo /sbin/iptables -A INPUT -i lo -j ACCEPT

# Do NAT for LAN clients
sudo /sbin/iptables -t nat -A POSTROUTING -o $WAN -j MASQUERADE

# Allow ping packets
sudo /sbin/iptables -A INPUT -p icmp -j ACCEPT

# Allow returning packets for established sessions
sudo /sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
sudo /sbin/iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow all traffic out from this host and our LAN clients
sudo /sbin/iptables -A OUTPUT -j ACCEPT
sudo /sbin/iptables -A FORWARD -i $LAN -j ACCEPT

# Drop all other traffic inbound from the Internet
sudo /sbin/iptables -A INPUT -i $WAN -j DROP
sudo /sbin/iptables -A FORWARD -i $WAN -j DROP

8< - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Note: This is not a particularly secure firewall, it basically allows any host on your LAN to send anything out and only drops unwanted packets coming in via the WAN interface (ppp0).

Make the firewall script executable;

chmod +x /usr/sbin/firewall

To make the firewall start at boot simply edit your rc.local file.

vi /etc/rc.local

Add this line to the end (but before the "exit 0" line)

/usr/sbin/firewall

You should reboot your router/server now and redo the ping tests as shown above.

Now that the router has been rebooted and assuming the ping tests have worked OK, you should be able to use your LAN client with the static IP address and ping/browse to the Internet.

That's great, but we don't want to be configuring all our clients with static addresses, so we probably should configure our router as a DHCP server as well.

And while we are at it, why don't you take the next step and turn your router into a funky caching DNS server too.

Or even better, connect your sites together with encrypted VPN's using this super easy Five Minute VPN Guide

[1] AKA "modem" or "modem only" mode.

-