BIND (named) server remidiation [part 2]

Following up from my previous post (BIND (named) server remidiation), I spent a good couple hours further developing and testing the configuration but failing to get a bind9 reverse lookup zone to load only to find out that I had a slight typo in the reverse lookup zone definition

named-checkzone was returning OK, but named itself was failing to load the zone file with the error:

zone X.X.X.in.addr.arpa/IN: has 0 SOA records
zone X.X.X.in.addr.arpa/IN: has no NS records
zone X.X.X.in.addr.arpa/IN: not loaded due to errors.

It wasn't until I had a friend take a closer look at then the problem became clear:

I defined the zone as .in.addr.arpa instead of .in-addr.arpa in the named.conf include file which references the zone file.

Some things I have learned is:

• Check the logs (in my case, on a default debian/bind9 install this was /var/log/syslog) when things don't work.
• Always check your config with the bind DNS tools before reloading
• Always check your zones files with the bind DNS tools before reloading
• Keep zone files neat and group together similar resource record types.

Now that I have the dev domain DNS working, I just need to look at setting up DHCP and testing dynamic DNS.

I also considered moving different resource records for each zone into a separate file, but this is not necessary, due to the (current) size of the network.

Once this is all done, tested and implemented in 'production', I will also consider keeping a similar configuration in dev as a slave for all zones from the primary DNS or just as it is and just for testing.

BIND (named) server remidiation

Since I virtualised my old failing physical server into a VM, I have found it less and less easy to administer and maintain (read: configuration files).

So, I am looking and spinning up new Debian servers for more specific tasks, network services, games servers, file services etc.

The fist, and most important thing I need to migrate is DNS. That way I can have it simply running in parallel with the old, ready to essentially, stop the service (after making sure DHCP serves out this DNS IP address as well of course!).

Now, here comes the "clever" part or the goals of this approach (or so I thought):

1. Install named.
2. Configure it to be a slave for the existing zones
3. re-configure it to be a master (complete with zone files)

Pretty simple right? Not so much. Well, thanks be to the 'Debian' way of doing things, it was very quick and easy to have a the zones slaved, but when I went to look at the files I was expecting, they where still empty, since I had created empty zone files to begin with.

Some poking around later and I discover that it is transferring the zones fine, but there was an issue with permissions for the zone files, or more specifically, the directory where they lived. A quick chmod -R 0777 /zone/file/directory later and a restart of the service, voila! Except.... something was not right...

The zone files seemed to be in a binary format as file would have me believe they were of type: data

I could have converted them back to plain text using the bind-tool named-compilezone(8) but, I couldn't commit my time to learning how to get the syntax correct for one small job, besides I learned that it is a crazy default in order to get a performance increase, however minuscule that would be given such a small DNS server implementation (for now).

So as per the article "Bind 9.9 – Binary DNS Slave file format" (linked above) or more authoratively as per the Chapter 6. BIND 9 Configuration Reference section of the BIND 9.9 Administrator Reference Manual (ARM) which states (incorrectly):

masterfile-format

Specifies the file format of zone files (see the section called “Additional File Formats”). The default value is text, which is the standard textual representation, except for slave zones, in which the default value is raw. Files in other formats than text are typically expected to be generated by the named-compilezone tool, or dumped by named.

So, knowing this I edited /etc/bind/named.conf.options to include the following:

masterfile-format text;

Perfect. (Just like me ;-) I now have a duplicate of the zones served on the master server, which can, and will soon be decommissioned, not to mention the new servers zones getting a makeover with many many more zones as well as a dynamic-update zone - more to come on this soon.

Great Success

Finally after weeks, no months of agonising failure though trial and error, I finally managed to get the outcome I desired with my Raspberry Pi 2!

History

A few years back I acquired a Cisco 3560 and quickly realised the potential of vlans and separate subnets for the purposes of testing among other valid reasons, and came to find that the nodes on most of the vlans could not communicate with the outside world (read: internet). It was then that I realised that something was wrong...

Long story short: the Netgear DGND4000 that I own does not route/NAT anything other than its resident subnet and I sure as heck was not going to implement double NAT!




Thanks be to LIbVirt's NAT networking which gave me an interim workaround and helped confirm this.

Getting the necessary bits

NAT issues aside, I began by purchasing a second-hand Netgear DM111P v2 from some random guy on Gumtree. The ADSL Modem in itself wasn't enough because it too, seemed to suffer from the same issue as the DGND4000 did, although admittedly, I didn't put much effort into testing that theory as I wanted a solution not more testing.

I then purchased a Raspberry Pi 2 along with a bunch of accessories. In the meantime (while I was waiting the excessively long shipping time). I did some research on the distributions that are capable of running on the bcm2709-based board and decided with OpenWRT. Yes, I know that I could have used Raspbian but OpenWRT seemed the most logical choice given the fact that it is essentially an internet router anyway, just without the wireless and ADSL modem.

Turns out I made the right choice despite the fact that OpenWRT is still in trunk (RC3 at the time of writing this).

Lastly (after destroying the extremely cheap Rpi2 case) I managed to get an image booted (helps when you use the bcm2709 not the bcm2708 barrier breaker version, thats for the Raspberry Model B!).

Configuration

First of all, this would have gone a lot smother had I have just tested with the USB network adapter I bought along with the Pi, but it didn't get here in time with partial shipping.

I configured the switch with a trunk port with two vlans, one for the LAN side of things (internal link) and another for the WAN or pppoe (public/external/internets) and set the mode appropriately.

NOTE: VLANS and IP addresses have been altered so as to protect the actual configuration used in my network infrastructure. Call me paranoid.

Cisco 3650 partial configuration

!
vlan 20
vlan 69
!
interface Vlan69
 description DMZ/LAN
 ip address 192.168.69.1 255.255.255.248
 no shutdown
!
! no interface defined for WAN because we do not want any L3 traffic
!

interface GigabitEthernet0/2
 description Trunk port for Rpi2 VLAN's: 20, 69
 switchport access vlan 69
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 20,69
 switchport mode trunk
 no shutdown
!
interface GigabitEthernet0/1
 description Link to DM111Pv2 modem (bridged) for PPPoE/L2 traffic
 switchport access vlan 20

 no shutdown

exit
!
ip route 0.0.0.0 0.0.0.0 192.168.69.66
!
end

OpenWRT network configuration

root@OpenWRT# vi /etc/config/network

config interface 'loopback'
        option ifname 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config interface 'lan'
        option proto 'static'
        option delegate '0'
        option _orig_ifname 'eth0'
        option _orig_bridge 'false'
        option ifname 'eth0.69'
        option ipaddr '192.168.69.66'
        option netmask '255.255.255.248'

config route
        option interface 'lan'
        option target '192.168.0.0'
        option netmask '255.255.0.0'
        option gateway '192.168.69.1'

config interface 'WAN'
        option proto 'pppoe'
        option ifname 'eth0.20'
        option delegate '0'
        option username 'myusername'
        option password 'mY$eCr3tP4sSw0rD'

Caveats/Adendums/Extra information

By now you may be wondering, "Why is there no IP addresses or switch virtual interface for vlan 20"? There is no need for it! That, and the fact one might only want traffic to go via one vlan and then the other (remember, this is essentially a router on a stick implementation and we want to separate the vlan's into L3 traffic for one and L2 for the other per requirements).

If you were thinking: "The netmask and destination network IP for the LAN route is wrong!", you would be incorrect. This is a perfectly legitimate summary route. It allows for much easier (read: slack) administration so one does not have to manage multiple static routes for subnets added or removed from the network (short of running a routing protocol) and it has the added benefit of consuming less memory and is a much more flexible approach for this design. Neat huh? I thought so too :-)

Conclusion

Let it be said that although this configuration is very simple, there where many hurdles accompanied by many choice words along the way. The one single most important thing that I kept getting wrong was routing. I had to remember to change the 'gateway of last resort' (Cisco's way of saying default route) on the switch so that all the subnets will route to the internet and the static (summarised) route for traffic to get back into the network from whence they came. That and trying to test this when the internet is depended upon so much by the two people in this household, was frustrating as my change windows where often short and had to be rolled back constantly.

Lastly, I must say that "out-of-the-box" pppoe/nat/routing on OpenWRT worked with like a charm with minimal configuration, however I will need to develop the scenario a little further so I can secure the connection by way of its firewall (read: iptables), but that itself is a beast I have yet to conquer.

Rasbpberri Pi Internet Connectivity Lab

I have successfully built a lab for testing internet connectivity to the Raspberry Pi 2, by using my phone in a USB tethering configuration.

I followed the majority of the configuration listed in the OpenWRT wiki, except I used the LuCI web configuration instead of the final manual step of using uci to use usb0 as the WAN connection

This will now allow me to test various scenarios including multiple default routes with different metrics as well as testing firewall configurations using OpenWRT running on the Rpi2.

The one gotcha is that I forgot to set the rout back to the internal network for which was previously miss-configured.

I am getting one step closer to having much more control of my internet as well as being able to NET/Route all of my subnets!

failure to focus

I have confirmed that I can get the Raspberry Pi to connect to the ISP using PPPoE through a VLAN, however, I cannot (or rather my brain cannot) get the OpenWrt to accept traffic other then ICMP to/from the device itself (I probably need to understand iptables or I am overlooking something very simple).

I'm finding it extremely hard to focus and get the networking part of this lab working right now when I don't actually have a lab to do it on and when others in the household rely on internet so much including myself, when I need to refer to something while trying to troubleshoot and find a solution to this 'router-on-a-stick' model of networking to overcome the shortfall of the existing router.

I've also lost my 4Gb micro SD for which I was planning using for building a Bluetooth (A2DP) Audio receiver from the Raspberri Pi which is making me a little less than happy considering they are not as easy to come by due to the size and I will have to spend another $10 (effectively $20 now) in order to get one.

For now, I'm going to go watch something and try again later (including looking for the SD card).