DNS

Switching to NSD

Whilst BIND is a nameserver I use nearly every day, it’s somewhat large and unwieldy being a reference implementation of the DNS spec.

Where possible, I always like to split out resolving and authoritative functionality into two seperate pieces of software. Unbound does a great job in the latter role – also from the authors of NSD, NLnetlabs – so I thought I’d give NSD a go on ns.spoofedpacket.net.

This machine serves only handful of zones, so it’s easy enough to migrate. The transition is made even simpler since NSD supports the old bind zonefile format out of the box. I decided to install NSD from source, following the tried and tested method:

 cd /usr/local/src
 wget http://www.nlnetlabs.nl/downloads/nsd/nsd-3.2.4.tar.gz
 tar zxvf nsd-3.2.4.tar.gz
 cd nsd-3.2.4
 ./configure
 make
 make install

The dependencies are very few, it should compile without much fuss on nearly any modern *nix system.

By default, all configuration files and zones go into /etc/nsd. There is also an nsd.conf.sample that you can use as a base config. The config file is extremely simple, for a basic setup you only need to look at the server: and the n-number of zone: sections. In the server: section, I only changed the location of the zone files:

 zonesdir: "/etc/nsd/zones"

At this point, it’s always good practice to organise your zonefiles into directories according to their roles. Here is what I have:

 /etc/nsd/zones/master
 /etc/nsd/zones/slave (nothing here yet)
 /etc/nsd/zones/master/forward
 /etc/nsd/zones/master/reverse
 /etc/nsd/zones/master/reverse/IPv4
 /etc/nsd/zones/master/reverse/IPv6

If you have an old BIND install that you are replacing, it is just a simple matter of copying/moving the existing zonefiles to their new locations. The zones can then be configured in nsd.conf as follows:

# spoofedpacket.net
zone:
        name: "spoofedpacket.net"
        zonefile: "master/forward/spoofedpacket.net.zone"

        notify: 193.1.193.194 NOKEY
        provide-xfr: 193.1.193.194 NOKEY

name and zonefile are pretty self explanatory, just remember that the path to your zonefile is always prefixed with the zonesdir statement from earlier on. notify lists all the nameservers you wish to send DNS notifies to when a zone is updated. provide-xfr controls who can carry out zone transfers (AFXR) from your nameserver. The NOKEY statement tells NSD that no cryptographic keys are required to authenticate the notifies or zone transfers between your nameserver and the secondary nameservers.

Once you’ve finished editing nsd.conf, you must now compile your zonefiles into the binary format that NSD understands. This is one of the main reasons for NSDs speed and low footprint:

 nsdc rebuild
 nsdc reload

Verify that nsd is running and serving zones:

 pgrep -lf nsd

 dig @ns.spoofedpacket.net www.spoofedpacket.net

spoofedpacket.net signed

I recently signed spoofedpacket.net, here’s the DS sets:

  spoofedpacket.net.      IN DS 15871 5 1 6D6B3C370091ECF38D81B2D91B54C7B2EB6D47E6
  spoofedpacket.net.      IN DS 15871 5 2 41D36F7DEC5827F650E772DE1DA33A219B3B994757DDF763830EBC12 E2DCEC80

And the keysets:

  spoofedpacket.net       604800  IN DNSKEY 257 3 5 (
                                        AwEAAa1qyDcvEEsXZYvzI5TwlJks8pK95OSE
                                        RjMtg0aN/cBfpNeyyYwX1O5zQy1G13qklxYR
                                        CbPHbbeZkxMxfVxc3pUSDOqYtu6IBhhPTv9Z
                                        Gwnjn6CRBdKVrkdMI5ZPJ3uwvMj9yk6a9jjg
                                        tUZZfIRkbURa/Q75AaqB8ihQN7pU5N9Tui0i
                                        V3eoKZrVfc5mUDATnggSw/Pk7blHKn8OWwEJ
                                        b7Q5Uulg4fmHYSxX2sTzt5kgZxWAVbaZ5IWn
                                        XwMJkUN7kM9Lz04exn4JmpeMpfAo3+tyDC1F
                                        LLJVPAk4KmhDKPhiY1y9yeZxLiloYh8KvG4b
                                        W18D465/RQRkoLufF+/6htk=
                                        ) ; key id = 15871

Domain renewal scams

Some of my domains are coming up for renewal, right on cue the scam letters start arriving in the post. The scammers trawl whois information and send out demands for “renewal” to unsuspecting domain users. Send enough of them and somebody, somewhere will pay up.

Domain renewal scam

They’re getting pretty sophisticated compared to the ones from previous years, an accounts department could be easily tricked into paying them.

SpamAssassin DNS lookups over IPv6

With the recent surge in AIB phishing mails, I thought it might be worth looking at our SpamAssassin setup to see if there was anything that could be done to filter them out.

AIB helpfully publish SPF records for the aib.ie domain, so the first port of call was SAs SPF lookups. Which I noticed weren’t happening, despite being enabled some time ago. Reloading SA resulting in the following log message in spamd.log:

Tue Aug 11 11:26:52 2009 [2221] warn: Error creating a DNS resolver
socket: at /usr/share/perl5/Mail/SpamAssassin/DnsResolver.pm line 233.

Aw snap, SA can’t do any DNS lookups, at all. Which means all of the DNS-based tests will be silently skipped. Going back through the spamd.log, I noticed these messages first started occurring when we enabled IPv6 DNS resolvers a number of months ago. Hmm, perl is obviously missing something fundamental.

So, it turns out a perl library required to create IPv6 sockets wasn’t installed, IO::Socket::INET6. This is conveniently packaged in Ubuntu:

aptitude install libio-socket-inet6-perl

A quick reload of spamassassin and we can say goodbye to all those “URGENT NOTIFICATION”s about our AIB online banking accounts. Although, the spammers have now copped on and aren’t even bothering to send from aib.ie addresses anymore..

Updates to bind and the open resolver project

If you haven’t done so already, now would be a good time to update bind9. A remote exploit is doing the rounds.

In related news, Team Cymru is running a scan for open DNS resolvers. It’s surprising the amount of DNS servers out there that are un-intentionally left wide open and, even worse, don’t implement split-horizon DNS. Looks like they’ve been busy probing ns.spoofedpacket.net:


22-Jun-2009 23:33:54.393 security: client 38.229.0.10#55251: query (cache) 'recursion-test.cymru.com/A/IN' denied
23-Jul-2009 23:34:08.350 security: client 38.229.0.10#45412: query (cache) 'recursion-test.cymru.com/A/IN' denied