Kingston! (adrian's home)

Took a day trip to Kingston on Friday, which turned out to be fun! Kelly had some business to take care of down that way, so I went with her, and toured around town while she did what she had to. Drove through Queens University, which looked pretty nice, and then downtown Kingston, and then found a Chapters, and a Costco. After Kingston, we went to Brockville, and ate dinner at what's turning out to be a pretty popular spot for us, Swiss Chalet, and then headed home, where we skipped out on the work party. :)

Saturday morning turned out to be an interesting morning... I haven't heard an official report from IStop yet, but I have a feeling there was some connectivity turbulence early on Saturday morning that lasted for a few hours. During that time, I wrestled with iproute2 and it's alleged built-in "dead gateway detection", which isn't all it's chalked up to be. Details are sketchy, but I found that the best result I could come up with for redundancy was to set up two default routes on wolverine and have it automatically figure out which gateway to use for outbound traffic. This actually worked fine, except that it meant during regular operation, I'd end up load balancing between Rogers and IStop, which is less desirable since Rogers offers less bandwidth. Using iproute2's 'nexthop' syntax I can assign two default routes, and give them different 'weights' which in theory looked like it should do what I wanted to -- use IStop in preference to Rogers when it's up, and Rogers otherwise. In practise, it ends up not being that way at all, since when IStop is down, connections are all over the map, sometimes working, to most often timing out. As if that wasn't bad enough, BIND feels the need to send DNS queries out with a particular source IP, and it looks as though it *needs* to be a source IP that it's bound to. Bah. That was the last straw. Surfing over to DJB's world, I grabbed djbdns and started to set it up.

It was pretty easy to set up, all I wanted was 'dnscache' which provides a local/external cache for LAN DNS clients. Seemed easy enough, and I thought I'd leave BIND running on the external interface to publish my public zones, and provide AXFR's. Except that I had to either migrate my local zones to 'tinydns', or run another BIND daemon on a different interface to service delegations for local domains. Well, if BIND is running on the external interface, and dnscache is running on the loopback and local interface, where was I going to run another BIND daemon? Enter BINDv9. :)

Downloaded and installed BIND 9.2.0 as well, which supports split DNS with one daemon, through a new concept called 'views'. Turns out to be really, really, handy, and I'll get around to writing some info about it sometime. With BIND 9.2.0 configured to run only on the external interface, provide zone transfers, and also provide an internal 'view' for LAN clients, I was set, and started up dnscache on the local interface.

So far, everything's still running, and I've been pretty happy with dnscache. We'll see how things go, but DJB doesn't usually leave much to be desired with his software. :)

Kingston!

TrackBack

Post a comment

Search

About