Mon, 24 Jan 2005

bind9 init script update

I’ve been re-visiting my bind9 init scripts now that some time has passed and I’ve had them in production for about 6 months or so. I’ve changed the chroot to use a tmpfs filesystem instead of an ext2 loopback; this makes some error cases easier to handle, as well as simplifying the script by quite a bit.

The downside to using tmpfs is that all changes made by named to the zone files are lost when the machine restarts; this is not a safe config to use if you are using Dynamic DNS.

The new init script and default file:

[/config/bind9] permanent link

Fri, 24 Sep 2004

Defensive fuckery

Let’s pretend that some fucko has setup a zone and pointed it at your nameserver without asking you first. Let’s say that it pisses you off. What to do?

Play defense.

First, setup a zonefile that looks like this:

    $TTL 7D
    @           SOA localhost hostmaster.localhost 42 3600 1800 604800 3600
                NS  localhost
    localhost   A   127.0.0.1
    *           MX  0 localhost
                A   127.0.0.1

and save it into db.smackdown.

Note that this zone is general purpose; it doesn’t matter what the zone that’s being pointed at you is called. Then, in the named.conf, add something like this:

    zone "fucko.com"
    {
        type master;
        file "master/db.smackdown";
    };

That’s all you have to do. Any query that anyone sends to your server for that zone will get bounces to their local machine. Eventually, the zone owner will realize that this is hurting them, and they will (hopefully) stop. If not, you can at least rest easy, knowing that you’re fucking with the foolish.

Again, this was Paul Vixie’s idea; I just wanted to keep a copy.

[/config/bind9] permanent link

Tue, 21 Sep 2004

TTLs

The BIND master Paul Vixie gave some good advice on NANOG about default TTLs for DNS records that seemed worth remembering here.

A default TTL of 1 or 2 hours is plenty for standard internet traffic; you’ll get the caching benefit for the immediate repeat visitor, but you probably won’t see much of a caching benefit beyond that. However, you should increase the TTLs of your NS records to 2 days. This helps reduce DNS load, since your NS records are what keeps people from chasing all the way up to the root servers.

People used to throw around a week or so as a default TTL, but since it doesn’t really gain you much performance-wise there’s little reason to leave the TTL that high. It only limits your options for changing that record in case of emergency.

[/config/bind9] permanent link

Thu, 19 Aug 2004

forward first

Found out yesterday that if you configure BIND9’s named to use forwarders, it will timeout and fail if it can’t reach any of the forwarders. I guess if you’re behind a firewall this may be what you want, but in general I’d imagine that you’d want your local named to try the lookup if it can’t get to the forwarders as a last resort. Adding a forward first; clause to your options stanza causes named to try the forwarders first, but if they don’t respond in time it will perform the DNS lookup itself.

I’ve modified /etc/bind/named.conf to do this, as I think it’s a better default behavior.

[/config/bind9] permanent link

Sun, 25 Apr 2004

BIND9 Config

The Debian sarge bind9 package now defaults to running named as a non-root user. This is great, and the bind9 maintaner rocks for taking the time to do this.

If you are not using sarge or a sarge bind9 backport, you need to create a user for named: adduser —system —home /var/cache/bind —group —disabled-password bind

Then, download and install this script and default file:

You should change the defaults in /etc/default/bind9 if you don’t want the chroot to be in /srv/bind/chroot. The init script takes care of building the chroot loopback device, mounting it, and creating the chroot directory structure inside of the loopback filesystem. It also copies your config files from /etc/bind into your chroot on start and reload. This means you don’t have to change any habits to take advantage of the chroot!

The chroot on a loopback is due to Linux (and Unix in general) using filesystems as security boundries. Traditionally, a secure chroot must be located on its own partition and filesystem. Normally, running a loopback incurs an undesireable amount of overhead, but named has such low disk IO requirements that the increased security is worth while. If you don’t have the Linux loopback device, or if you don’t want to use it for this, set bind_use_loopback="no" in /etc/default/bind9.

If you are running Red Hat, Stephen Gildea has a version of this init script available.

Occasionally the root name servers change. A running named will notice, but the db.root still needs to be kept up to date so that named will know about changes after a restart. Putting this script in your monthly cron will take care of it for you. You will need to install the dnsutils package.

This config is designed for an infrastructures.org scenerio. Every host runs a local copy of bind which is used as the local nameserver. The local bind uses the organization’s primary name servers as forwarders. The local bind can optionally use TSIG to communicate with the primaries which prevents DNS poisoning attacks, which can be handy when you want to store your Kerberos information in DNS. Note that every machine can act as a caching nameserver for Win32 or MacOS clients; this makes it easier to recover from some disasters (since you can just reconfigure clients to point at any of your Debian hosts for name service immediately). Obviously, your authoritative nameservers will not be using this configuration, but they shouldn’t be the same as your caching nameservers anyway.

[/config/bind9] permanent link

Tue, 30 Mar 2004

BIND9 policy

[/config/bind9] permanent link