flyinweb's blog - DNS技术

A Major Improvement in BIND 9 Startup Performance

shanyiwan@live.com() — Tue, 06 Sep 2011 01:03:52 GMT

One of the common complaints we've received over the years about BIND 9 is that large authoritative servers, particularly those with a very large number of small zones, are slow to launch. I've met some DNS operators who expressed a powerful aversion to upgrading their systems, because a shutdown and restart can literally take all day.

If that describes you, I have some good news. There is a simple optimization for BIND 9 that can dramatically improve your startup performance. New versions of BIND are being released soon to take advantage of it.

I recently did some profiling experiments on a server with tens of thousands of small zones, and discovered that the delay was not, as I had expected, primarily caused by loading the server configuration and the zone database. In fact, named was spending the vast majority of its time repeatedly walking very long linked-lists. Further examination to find the reason for this revealed a simple but significant tuning bug that's been overlooked for years: The zone tasks were massively overburdened.

In some ways, BIND 9 is almost like a miniature operating system. From the perspective of your real OS, named is just a single process. . . but within named, there are more processes, all taking turns doing their jobs, then yielding control to the next miniature process. These internal mini-processes are called "tasks", and they handle all the functions of the name server—sending queries, answering queries, cleaning the cache, and so on.

Each zone served by a BIND 9 server has a task associated with it, whose job is to do all the routine maintenance for an authoritative zone: sending SOA requests to masters, sending NOTIFY messages to slaves, dumping dynamic zone data to disk, regenerating expiring DNSSEC signatures, and so forth. Since these functions don't usually all happen at once, a single task can support many zones; but too many zones and the task can be overwhelmed.

It turned out that the pool from which the zone tasks were assigned was fixed in size, and much too small. And the damage this did to startup performance was immense: On a test server with 8 processors and 12G of memory, a server with a million zones took well over ten hours to begin serving queries. And no wonder, because those million zones were sharing the resources of only eight zone tasks.

When I tried increasing the size of the task pool, I expected to see a reduction in startup time. What I didn't expect was a near elimination of startup time:

Named started up and began serving queries in a little over fifteen minutes, most of which was spent parsing the very large named.conf file. Loading the zones, a process that had taken over ten hours in the previous run, now took 2-3 minutes. (Full details of the tests and results can be found here or this site.)

A larger task pool does take more memory, but it's negligible compared to the size of the zone data. If you serve hundreds of thousands or millions of zones, you can expect to see a factor-twenty improvement in startup time at the cost of about 2% more memory.

The single change to be made is in the file lib/dns/zone.c. When the function isc_taskpool_create() is called, the third argument—set to 8 in most versions of BIND—should be set to a number that's roughly one one-hundredth of the number of zones you expect to be serving. (There is also a slight theoretical benefit if the number happens to be prime, though in practice the difference is quite small.)

If you're running a million zones, you want about ten thousand zone tasks. 10007 happens to be prime. Changing the 8 to 10007 should dramatically improve your startup performance:

--- zone.c.00 2011-07-12 08:56:34.000000000 -0700
+++ zone.c 2011-07-12 14:46:44.000000000 -0700
@@ -12455,8 +12455,7 @@
zmgr->transfersperns = 2;

/* Create the zone task pool. */
- result = isc_taskpool_create(taskmgr, mctx,
- 8 /* XXX */, 2, &zmgr->zonetasks);
+ result = isc_taskpool_create(taskmgr, mctx, 10007, 2, &zmgr->zonetasks);
if (result != ISC_R_SUCCESS)
goto free_rwlock;

Better yet, though, don't bother editing C files, and just install the newest releases of BIND 9. In the upcoming 9.8.1, which will have its third beta release this week, named counts the zones at startup time and automatically scales its zone task table accordingly.

The upcoming 9.6-ESV-R5 and 9.7.4 releases were already very close to final release when this trick was discovered. Since they've already been through beta, we decided we'd make a smaller, less invasive change in those. When the final releases come out in the next week or so, you'll be able to set an environment variable—BIND9_ZONE_TASKS_HINT—with your desired number of zone tasks.

In later releases of 9.6 and 9.7, we will backport the automatic scaling code, and the environment variable will no longer be necessary.

出处：https://www.isc.org/community/blog/201107/major-improvement-bind-9-startup-performance

手动编译bind，并做chroot处理

shanyiwan@live.com() — Fri, 29 Jul 2011 01:38:12 GMT

需要的文件:

BIND的源码http://ftp.isc.org/isc/bind9/9.6.1-P2/bind-9.6.1-P2.tar.gz

目录列表:

/opt/bind 保存编译安装以后的bind
/opt/chroot bind的chroot运行环境根目录

目录结构如下:

bind
|-- bin
|-- etc
|-- include
| |-- bind9
| |-- dns
| |-- dst
| |-- isc
| |-- isccc
| |-- isccfg
| `-- lwres
|-- lib
|-- sbin
|-- share
| `-- man
| |-- man1
| |-- man3
| |-- man5
| `-- man8
`-- var
`-- run

安装步骤：

1.添加执行bind所用的用户(为了使用chroot)

#添加named组

groupadd named

#添加named用户，设定home目录为我们指定的chroot目录，shell设置成nologin，不允许从控制台登陆

useradd -g named -d /opt/chroot -s /sbin/nologin named

#锁定named帐户的密码

passwd -l named

2.构建chroot环境

#首先删掉useradd命令自己建立的/opt/chroot目录，然后再重建/opt/chroot目录，目的是清除.bash_profile这类文件，因为named不允许登陆，因此这些文件无用

rm -rf /opt/chroot
mkdir /opt/chroot

#建立etc, dev, var这三个必须的目录

mkdir -p /opt/chroot/{etc,dev,var/{run,named/{zones,slaves}}}

#建立必要的设备文件

mknod /opt/chroot/dev/null c 1 3
mknod /opt/chroot/dev/zero c 1 5
mknod /opt/chroot/dev/random c 1 8

#复制本机的timezone文件到chroot环境

cp /etc/localtime /opt/chroot/etc

3.解压缩bind源码

tar xvzf bind-9.6.1-P1.tar.gz

4.进入源码目录进行编译

cd bind-9.6.1-P1
./configure --prefix=/opt/bind --enable-threads --enable-largefile
make
make install

如果没有错误的话，已经编译好bind并安装到了prefix参数所指定位置(默认情况下所有的文件都在该目录，除非手工指定其他目录)。--enable-threads指定了使用多线程

5.建立BIND配置文件和zone文件

touch /opt/chroot/etc/named.conf
touch /opt/chroot/etc/var/named/zones/test.com.zone

6.削减，设置目录访问权限

chown root /chroot
chmod 755 /chroot

chown named:named /chroot/var/named
chmod 700 /chroot/var/named

chown -R named:named /chroot/named/var/named/slaves
chown named:named /chroot/named/var/run

7.启动BIND

/opt/bind/sbin/named -t /opt/chroot -u named -c /etc/named.conf

8.设置rndc

编辑/opt/bind/etc/rndc.conf (rndc.conf文件需要在rndc所在目录的上层etc目录中，本例rndc的位置为/opt/bind/sbin)

key "rndc-key" {
algorithm hmac-md5;
secret "O23s3DegwBjKrgXPfTB0g==";
};

options {
default-key "rndc-key";
default-server 127.0.0.1;
default-port 953;
};

Chroot-BIND HOWTO

Scott Wunsch, `scott at wunsch.org`

v1.5, 1 December 2001

This document describes installing the BIND 9 nameserver to run in a chroot jail and as a non-root user, to provide added security and minimise the potential effects of a security compromise. Note that this document has been updated for BIND 9; if you still run BIND 8, you want the Chroot-BIND8 HOWTO instead.

1.Introduction

2.Preparing the Jail

3.Compiling and Installing Your Shiny New BIND

3.1 Doing the Compile

4.Installing Your Shiny New BIND

5.The End

6.Appendix - Upgrading BIND Later

7.Appendix - Thanks

8.Appendix - Document Distribution Policy

1.Introduction

This is the Chroot-BIND HOWTO; see Where? for the master site, which contains the latest copy. It is assumed that you already know how to configure and use BIND (the Berkeley Internet Name Domain). If not, I would recommend that you read the DNS HOWTO first. It is also assumed that you have a basic familiarity with compiling and installing software on your UNIX-like system.

1.1 What?

This document describes some extra security precautions that you can take when you install BIND. It explains how to configure BIND so that it resides in a ``chroot jail,'' meaning that it cannot see or access files outside its own little directory tree. We shall also configure it to run as a non-root user.

The idea behind chroot is fairly simple. When you run BIND (or any other process) in a chroot jail, the process is simply unable to see any part of the filesystem outside the jail. For example, in this document, we'll set BIND up to run chrooted to the directory /chroot/named. Well, to BIND, the contents of this directory will appear to be /, the root directory. Nothing outside this directory will be accessible to it. You've probably encounted a chroot jail before, if you've ever used ftp to log into a public system.

Because the chroot process is much simpler with BIND 9, I have started to expand this document slightly, to include more general tips about securing a BIND installation. Nevertheless, this document is not (and is not intended to be) a complete reference for securing BIND. If you do only what is outlined in this document, you're not finished securing your nameserver!

1.2 Why?

The idea behind running BIND in a chroot jail is to limit the amount of access any malicious individual could gain by exploiting vulnerabilities in BIND. It is for the same reason that we run BIND as a non-root user.

This should be considered as a supplement to the normal security precautions (running the latest version, using access control, etc.), certainly not as a replacement for them.

If you're interested in DNS security, you might also be interested in a few other products. Building BIND with StackGuard would probably be a good idea for even more protection. Using it is easy; it's just like using ordinary gcc. Also, DNScache is a secure replacement for BIND, written by Dan Bernstein. Dan is the author of qmail, and DNScache appears to follow a similar philosophy.

1.3 Where?

The latest version of this document is always available from the web site of the Linux/Open Source Users of Regina, Sask., at http://www.losurs.org/docs/howto/Chroot-BIND.html.

There is now a Japanese translation of this document, maintained by Nakano Takeo nakano at apm.seikei.ac.jp. This is available at http://www.linux.or.jp/JF/JFdocs/Chroot-BIND-HOWTO.html.

BIND is available from the Internet Software Consortium at http://www.isc.org/bind.html. As of this writing, the current version of BIND 9 is 9.2.0. BIND 9 has been out for some time now, and many people are using it in production. Nevertheless, some more conservative sorts still prefer to remain with BIND 8. If you are such a person, please see my Chroot-BIND8 HOWTO (available from the same location) for details on chrooting it, but be warned that BIND 8 is much messier to chroot.

Keep in mind that there are known security holes in many earlier versions of BIND, so make very sure that you're running the latest version!

1.4 How?

I wrote this document based on my experiences in setting BIND up in a chroot environment. In my case, I already had an existing BIND installation in the form of a package that came with my Linux distribution. I'll assume that most of you are probably in the same situation, and will simply be transferring over and modifying the configuration files from your existing BIND installation, and then removing the package before installing the new one. Don't remove the package yet, though; we may want some files from it first.

If this is not the case for you, you should still be able to follow this document. The only difference is that, where I refer to copying an existing file, you first have to create it yourself. The DNS HOWTO may be helpful for this.

1.5 Disclaimer

These steps worked for me, on my system; your mileage may vary. This is but one way to approach this; there are other ways to set the same thing up (although the general approach will be the same). It just happens that this was the first way that I tried that worked, so I wrote it down.

My BIND experience to date has been installing on Linux servers. However, most of the instructions in this document should be easily applicable to other flavours of UNIX as well, and I shall try to point out differences of which I am aware. I've also received suggestions from people using other distributions and other platforms, and I've tried to incorporate their comments where possible.

If you run Linux, you need to make sure that you're running a 2.4 kernel before attempting this. The -u switch (to run as a non-root user) requires this newer kernel.

2.Preparing the Jail

2.1 Creating a User

As mentioned in the introduction, it's not a good idea to run BIND as root. So, before we begin, let's create a separate user for BIND. Note that you should never use an existing generic user like nobody for this purpose. However, some distributions, such as SuSE and Linux Mandrake have started providing a specific user (generally called named); you can simply adapt this user for our purposes, if you like.

This requires adding a line something like the following to /etc/passwd:

named:x:200:200:Nameserver:/chroot/named:/bin/false

And one like this to /etc/group:

named:x:200:

This creates a user and group called named for BIND. Make sure that the UID and GID (both 200 in this example) are unique on your system. The shell is set to /bin/false because this user will never need to log in.

2.2 Directory Structure

Now, we must set up the directory structure that we will use for the chroot jail in which BIND will live. This can be anywhere on your filesystem; the truly paranoid may even want to put it on a separate volume. I shall assume that you will use /chroot/named. Let's start by creating the following directory structure:

/chroot
  +-- named
       +-- dev
       +-- etc
       |    +-- namedb
       |         +-- slave
       +-- var
            +-- run

If you use GNU mkdir (such as on a Linux system), you can create this directory structure like this:

# mkdir -p /chroot/named
# cd /chroot/named
# mkdir -p dev etc/namedb/slave var/run

2.3 Placing the BIND Data

Assuming that you have already done a conventional installation of BIND and are using it, you will already have an existing named.conf and zone files. These files must now be moved (or copied, to be safe) into the chroot jail, so that BIND can get at them. named.conf goes in /chroot/named/etc, and the zone files can go in /chroot/named/etc/namedb. For example:

# cp -p /etc/named.conf /chroot/named/etc/
# cp -a /var/named/* /chroot/named/etc/namedb/

BIND would normally need to write to the namedb directory, but in the interests of tightening security, we will not allow it to do this. If your nameserver serves as a slave for any zones, it will need to update these zone files, which means we'll have to store them in a separate directory, to which BIND does have write access.

# chown -R named:named /chroot/named/etc/namedb/slave

Keep in mind that'll you have to move any slave zones you have into this directory, and update your named.conf accordingly.

BIND will also need to write to the /var/run directory, to put its pidfile and statistical information there, so let's allow it to do so:

# chown named:named /chroot/named/var/run

2.4 System Support Files

Once BIND is running in the chroot jail, it will not be able to access files outside the jail at all. However, it needs to access a few key files, although not nearly as many as BIND 8 did.

One file that BIND will need inside its jail is good ol' /dev/null. Note that the exact command necessary to create this device node may vary from system to system; check your /dev/MAKEDEV script to be sure. Some systems may also require /dev/zero, which can created similarly. It's reported that the BIND 9.2.0 release candidates now require /dev/random as well. For most Linux systems, we can use the following commands:

# mknod /chroot/named/dev/null c 1 3
# mknod /chroot/named/dev/random c 1 8
# chmod 666 /chroot/named/dev/{null,random}

For FreeBSD 4.3, this is:

# mknod /chroot/named/dev/null c 2 2
# mknod /chroot/named/dev/random c 2 3
# chmod 666 /chroot/named/dev/{null,random}

You also need another file in the /etc directory inside the jail. You must copy /etc/localtime (this is sometimes known as /usr/lib/zoneinfo/localtime on some systems) in there so that BIND logs things with the right time on them. The following command will take care of this:

# cp /etc/localtime /chroot/named/etc/

2.5 Logging

Unlike a conventional jailbird, BIND can't just scribble its log entries on the walls :-). Normally, BIND logs through syslogd, the system logging daemon. However, this type of logging is performed by sending the log entries to the special socket /dev/log. Since this is outside the jail, BIND can't use it any more. Fortuantely, there are a couple options to work around this.

The Ideal Solution

The ideal solution to this dilemma requires a reasonably recent version of syslogd which supports the -a switch introduced by OpenBSD. Check the manpage for your syslogd(8) to see if you have such a version.

If you do, all you have to do is add the switch ``-a /chroot/named/dev/log'' to the command line when you launch syslogd. On systems which use a full SysV-init (which includes most Linux distributions), this is typically done in the file /etc/rc.d/init.d/syslog. For example, on my Red Hat Linux system, I changed the line

daemon syslogd -m 0

daemon syslogd -m 0 -a /chroot/named/dev/log

Interestingly, as of Red Hat 7.2, Red Hat has apparently made this process even easier. There is now a file called /etc/sysconfig/syslog in which extra parameters for syslogd can be defined.

On Caldera OpenLinux systems, they use a daemon launcher called ssd, which reads configuration from /etc/sysconfig/daemons/syslog. You simply need to modify the options line to look like this:

OPTIONS_SYSLOGD="-m 0 -a /chroot/named/dev/log"

Similarly, on SuSE systems, I'm told that the best place to add this switch is in the /etc/rc.config file. Changing the line

SYSLOGD_PARAMS=""

to read

SYSLOGD_PARAMS="-a /chroot/named/dev/log"

should do the trick.

And, last but not least, for FreeBSD 4.3 you can apparently just edit the rc.conf file and put in the following:

syslogd_flags="-s -l /chroot/named/dev/log"

The -s is for security reasons, and is part of the default settings. The -l is a local path on which to put another logging node.

Once you've figured out how to make this change for your system, simply restart syslogd, either by killing it and launching it again (with the extra parameters), or by using the SysV-init script to do it for you:

# /etc/rc.d/init.d/syslog stop
# /etc/rc.d/init.d/syslog start

Once it's been restarted, you should see a ``file'' in /chroot/named/dev called log, that looks something like this:

srw-rw-rw-   1 root     root            0 Mar 13 20:58 log

The Other Solutions

If you have an older syslogd, then you'll have to find another way to do your logging. There are a couple programs out there, such as holelogd, which are designed to help by acting as a ``proxy'' and accepting log entries from the chrooted BIND and passing them out to the regular /dev/log socket.

Alteratively, you can simply configure BIND to log to files instead of going through syslog. See the BIND documentation for more details if you choose to go this route.

2.6 Tightening Permissions

First of all, feel free to restrict access to the whole /chroot directory to the root user. Of course, not everybody may want to do this, especially if you have other software installed in that tree that doesn't appreciate it.

# chown root /chroot
# chmod 700 /chroot

You can also safely restrict access to /chroot/named to the named user.

# chown named:named /chroot/named
# chmod 700 /chroot/named

For even more tightening, on Linux systems we can make a few of the files and directories immutable, using the chattr tool on ext2 filesystems.

# cd /chroot/named
# chattr +i etc etc/localtime var

Equivalently, on FreeBSD 4.3, you want to look into chflags if you wish to make things immutable. As an example, the following should change everything in the /chroot/named/etc directory to immutable:

# chflags schg /chroot/named/etc/*(*).

It would be nice to do this for the dev directory too, but unfortunately that would prevent syslogd from creating its dev/log socket. You may also choose to set the immutable bit on other files in the jail as well, such as your primary zone files, if they aren't expected to change.

3.Compiling and Installing Your Shiny New BIND

3.1 Doing the Compile

Compiling BIND 9 for use in a chroot jail should be a much more pleasant experience than BIND 8 was. In fact, you don't have to do anything special; the standard ./configure && make should suffice.

Keep in mind that if you want to enable IPv6 support in BIND (--enable-ipv6) on Linux systems, you need matching versions of kernel and glibc. If you have kernel 2.2, you need glibc 2.1, and if you have kernel 2.4, you need glibc 2.2. BIND is quite picky about this.

4.Installing Your Shiny New BIND

I should mention that if you have an existing installation of BIND, such as from an RPM, you should probably remove it before installing the new one. On Red Hat systems, this probably means removing the packages bind and bind-utils, and possibly bind-devel and caching-nameserver, if you have them.

You may want to save a copy of the init script (e.g., /etc/rc.d/init.d/named), if any, before doing so; it'll be useful later on.

If you are upgrading from an older version of BIND, such as BIND 8, you will want to read the migration documentation in the file doc/misc/migration in the BIND source package. I don't deal with any migration issues in this document; I simply assume that you are replacing an existing, working installation of BIND 9.

4.1 Installing the Binaries

This is the easy part :-). Just run make install and let it take care of it for you. Really, that's it!

4.2 Setting up the Init Script

If you have an existing init script from your distribution, it would probably be best simply to modify it to run the new binary, with the appropriate switches. The switches are... (drumroll please...)

-u named, which tells BIND to run as the user named, rather than root.
-t /chroot/named, which tells BIND to chroot itself to the jail that we've set up.
-c /etc/named.conf, which tells BIND where to find its configuration file within the jail.

The following is the init script I use with my Red Hat 6.0 system. As you can see, it is almost exactly the same as the way it shipped from Red Hat. I haven't tried the rndc commands yet, but I can't see any reason why they shouldn't work.


#!/bin/sh
#
# named           This shell script takes care of starting and stopping
#                 named (BIND DNS server).
#
# chkconfig: 345 55 45
# description: named (BIND) is a Domain Name Server (DNS) \
# that is used to resolve host names to IP addresses.
# probe: true
# Source function library.
. /etc/rc.d/init.d/functions
# Source networking configuration.
. /etc/sysconfig/network
# Check that networking is up.
[ ${NETWORKING} = "no" ] && exit 0
[ -f /usr/local/sbin/named ] || exit 0
[ -f /chroot/named/etc/named.conf ] || exit 0
# See how we were called.
case "$1" in
  start)
        # Start daemons.
        echo -n "Starting named: "
        daemon /usr/local/sbin/named -u named -t /chroot/named -c /etc/named.conf
        echo
        touch /var/lock/subsys/named
        ;;
  stop)
        # Stop daemons.
        echo -n "Shutting down named: "
        killproc named
        rm -f /var/lock/subsys/named
        echo
        ;;
  status)
        status named
        exit $?
        ;;
  restart)
        $0 stop
        $0 start
        exit $?
        ;;
  reload)
        /usr/local/sbin/rndc reload
        exit $?
        ;; 
  probe)
        # named knows how to reload intelligently; we don't want linuxconf
        # to offer to restart every time
        /usr/local/sbin/rndc reload >/dev/null 2>&1 || echo start
        exit 0
        ;;
  
  *)
        echo "Usage: named {start|stop|status|restart|reload}"
        exit 1
esac
exit 0

As with syslogd, as of Red Hat 7.2 this process is now even easier. There is a file called /etc/sysconfig/named in which extra parameters for syslogd can be defined. The default /etc/rc.d/init.d/named on Red Hat 7.2, however, will check for the existance of /etc/named.conf before starting. You will need to correct this path.

On Caldera OpenLinux systems, you simply need to modify the variables defined at the top, and it will apparently take care of the rest for you:

NAME=named
DAEMON=/usr/local/sbin/$NAME
OPTIONS="-t /chroot/named -u named -c /etc/named.conf"

And for FreeBSD 4.3, you can edit the rc.conf file and put in the following:

named_enable="YES"
named_program="chroot/named/bin/named"
named_flags="-u named -t /chroot/named -c /etc/namedb/named.conf"

4.3 Configuration Changes

You will also have to add or change a few options in your named.conf to keep the various directories straight. In particular, you should add (or change, if you already have them) the following directives in the options section:

directory "/etc/namedb";
pid-file "/var/run/named.pid";
statistics-file "/var/run/named.stats";

Since this file is being read by the named daemon, all the paths are of course relative to the chroot jail. As of this writing, BIND 9 does not support many of the statistics and dump files that previous versions did. Presumably later versions will; if you are running such a version, you may have to add additional entries to cause BIND to write them to the /var/run directory as well.

5.The End

5.1 Launching BIND

Everything should be set up, and you should be ready to put your new, more secure BIND into action. Assuming you set up a SysV-style init script, you can simply launch it as:

# /etc/rc.d/init.d/named start

Make sure you kill any old versions of BIND still running before doing this.

5.2 That's It!

You can go take a nap now ;-).

6.Appendix - Upgrading BIND Later

So, you had BIND 9.1.2 all nicely chrooted and tweaked to your taste... and then you hear this nasty rumour that BIND 9.1.3 is finally out, and you just have to give it a try right away. Do you have to go through this whole long process to install this new version?

Nope. In fact, you really just need to compile the new BIND and install it over top of the old one. Just don't forget to kill the old version and restart BIND, or it'll still be the old version running!

7.Appendix - Thanks

I'd like to thank the following people for their assistance in the creation of this HOWTO:

Lonny Selinger <lonny at abyss.za.org> for "testing" the first version of this HOWTO and making sure that I didn't miss any steps.
Chirik <chirik at CastleFur.COM>, Dwayne Litzenberger <dlitz at dlitz.net>, Phil Bambridge <phil.b at cableinet.co.uk>, Robert Cole <rcole at metrum-datatape.com>, Colin MacDonald <colinm at telus.net>, and others for pointing out errors, omissions, and providing other useful advice to make this HOWTO even better.
Erik Wallin <erikw at sec.se> and Brian Cervenka <brian at zerobelow.org> for providing good suggestions for further tightening the jail.
Robert Dalton <support at accesswest.com> for suggesting a couple more example commands, and pointing out BIND 9.2.0's need of /dev/random.
Eric McCormick <hostmaster at cybertime.net> for the FreeBSD 4.3 information.
Tan Zheng Da <tzd at pobox.com> for the details about the changes in Red Hat 7.2 that make this a little easier.

And last but certainly not least, I'd like to thank Nakano Takeo <nakano at apm.seikei.ac.jp> for translating the Chroot-BIND HOWTO into Japanese. You can find his translation at http://www.linux.or.jp/JF/JFdocs/Chroot-BIND-HOWTO.html.

8.Appendix - Document Distribution Policy

This HOWTO is free documentation; you can redistribute it and/or modify it under the terms of the LDP licence. It is distributed in the hope that it will be useful, but without any warranty; without even the impled warranty of merchantability or fitness for a particular purpose. See the LDP licence for more details.

Building and configuring BIND 9 in a chroot jail

This has turned out to be a very hard document to write: we work on it bits and pieces at a time. Sorry if it's incomplete. All of our main work has been done on various flavors of Red Hat, Debian, and Fedora Core, but we've included notes on porting to other systems as well.

Table of Contents

We're particularly fond of the outstanding O'Reilly DNS and BIND book.

But our goal is to make this a one-stop place to figure how to do do this, and we'd be really grateful if those that were stuck could send us suggestions to clarify. Kindly forward them to.

Introduction

There are plenty of people who've written about how to run BIND in a chroot jail, and we'll add our own experiences. We have done this on a handful of machines and have the routine down pretty well, and anybody else with the same problem set might find this helpful.

We've previously run BIND 8 in a jail, and it has always been a horrid nightmare to build and configure because the install paths had to be hacked up on a custom basis, and every operating system put files in different places. BIND 9 has changed this and decide that it all goes into /usr/local. This has made an enormous difference to consultants with widely varied customer bases. Thank you, ISC.

Most of our direct experience is with various flavors of Red Hat Linux, but we've set this up on Debian's "woody" release as well. These instructions are current as of BIND 9.2.2rc1.

What's a "Jail"?

Though the utility of a nameserver is probably clear to most people reading this tech tip, the concept of "jail" may not be: we've been asked to elaborate.

A "jail" is a software mechanism for limiting the ability of a process to access resources outside a very limited area, and it's done with security in mind. A nameserver often talks to the outside world, and time has shown that "the public internet" is a very hostile environment. Should a flaw in BIND be discovered, it could be exploited by one located anywhere on the planet: by isolating the process inside a jail, this restricts the harm that can be done to a compromised system.

A jail is created using the chroot() system call (named for "change root"), and it's given a directory name as a parameter. Once this call is made, the root - the top of the directory tree - for this process is changed from / to the directory given, and there is no way for the process to get outside this area. We typically use /chroot/named to jail our nameservers, but we'll note that the "chroot" in the directory name is just a convention: this is not required (e.g., "/usr/local/named" would make a fine jail location too).

By itself, this won't prevent some flaw in BIND from being exploited, but the worst that happens is that the nameserver is compromised: it can't be leveraged to taking over the whole system. In this way it's more of a general safety precaution providing defense in depth.

Much more information on chroot jails can be found in ourLinux Magazine article:Go Directly to Jail - Secure Untrusted Applications with Chroot

Pick up the source

Get the source at the Internet Software Consortium, and the home page for BIND is http://www.isc.org/products/BIND/. These instructions were written for 9.1.2 on a Red Hat Linux 6.2 system, and we'll try to keep them updated as we upgrade our and customer systems. We generally try to keep running the latest stable versions - we're not generally too adventurous with beta.

Our practice is to keep our own build stuff under a /source tree, and to unpack individual sources under it.

# cd /source
# gtar -xzvf bind-9.1.2.tar.gz

This unbundles everything into a subdirectory with the full name of the package, and the next step is to to configure and build it.

Configure and build

The BIND instructions say to simply run ./configure, but under Linux a couple of additions are required.

For many years, we have recommended disabling thread support, because in 2.2 kernels, chroot jailing did not work properly. We have never been brave enough to attempt it with more recent kernels, but we've been getting reports that threading works fine in 2.6.

In addition, BIND can support IPv6, the next generation IP addresses (current version is IPv4). BIND typically probes for IPv6 support at runtime, but since we are quite sure that we really don't need this on our networks, we disable it entirely as a safety measure.

NOTE: we prefer to remove any existing nameserver installations (especially those provided by the operating system) before installing the new one. This avoids problems with older versions of key binaries lying around and sometimes being at the wrong point in the command-search$PATH.

Under Red Hat Linux (for instance), this means removing three packages before doing installations.

# rpm -e bind bind-utils caching-nameserver

Finally, we want everything installed into the /usr/localhierarchy, so we provide the installation prefix. This said, configuration and installation is quite simple:

# cd /source/bind-9.1.2
# ./configure --prefix=/usr/local --disable-ipv6
# make
# make install

This takes about 15 minutes on a dual-CPU 200 MHz Pentium Pro machine and about three minutes on a 1 GHz Pentium III, and it installs around 200 files under /usr/local. Most of them are #includefiles for C language programming, and only about a dozen are really needed for a BIND installation. See the complete file list at the end of this document.

Build and configure the jail

Creating the actual jail itself is much easier than for BIND 8 because so much trash is not required - it's just tremendous. In particular, none of the shared libraries or named binary files are required to live in the jail, and this makes it easier and more secure for us. For more details on our thoughts on chroot operations, see our more detailed tech tipBest Practices for UNIX chroot() Operations

The initial steps to configure the jail are:

create initial named user and group
# groupadd named
# useradd -g named -d /chroot/named -s /bin/true named
# passwd -l named"lock" the accountRemove all the login-related trash under the newly-created home directory
# rm -rf /chroot/namedRe-create the top level jail directory
# mkdir -p /chroot/named
# cd /chroot/namedcreate the hierarchy
# mkdir dev
# mkdir etc
# mkdir logs
# mkdir -p var/run
# mkdir -p conf/secondariescreate the devices, but confirm the major/minor device
numbers with   "ls -lL /dev/zero /dev/null /dev/random"
# mknod dev/null c 1 3
# mknod dev/zero c 1 5
# mknod dev/random c 1 8copy the timezone file
# cp /etc/localtime etc

Noticeably absent are any ownership/permissions issues: this is deliberate. We'll get to it shortly. Note that the ls command used to verify the major/minor device numbers includes the -L parameter - this follows symbolic links and is required on some platforms such as Solaris.

Construct the configuration files

The named.conf configuration is central to named operation, and we'll go through creating it step by step. Though these files can get very complex, our first efforts will be for a minimal caching-only nameserver just to get the whole end-to-end process working correctly. Then we'll retrofit to add in needed features such as local domains and access controls.

The named.conf file lives in the jail's etc directory, which makes the full path /chroot/named/etc/named.conf. We usually create a symbolic link to make this visible to the rest of the system at /etc/named.conf.

# ln -s /chroot/named/etc/named.conf /etc/named.conf

Note - we're creating a symbolic link to a file thatdoes not yet exist - this is confusing. But when we edit the file (the next step), it is created properly.

Now, using your favorite editor, create the first version of theetc/named.conf file. We suspect that some of these parameters are not strictly necessary, as the defaults will do, but we feel that being explicit will make the daemon easier to debug for the new administrator (less searching for key files).

options {
	directory       "/conf";
	pid-file        "/var/run/named.pid";
	statistics-file "/var/run/named.stats";
	dump-file       "/var/run/named.db";
	# hide our "real" version number
	version         "[secured]";
};
# The root nameservers
zone "." {
	type   hint;
	file   "db.rootcache";
};
# localhost - forward zone
zone	"localhost" {
	type    master;
	file   "db.localhost";
	notify  no;
};
# localhost - inverse zone
zone    "0.0.127.in-addr.arpa" {
	type   master;
	file   "db.127.0.0";
	notify no;
};

Notice that the directory keyword says /conf, not/chroot/named/conf - this is intended. When running the nameserver inside the chroot jail, all the paths arerelative to the top of the jail at /chroot/named.

This configuration refers to three additional files -- db.rootcache,db.localhost and db.127.0.0 -- and they are all created in the/chroot/named/conf directory.

db.rootcache is a list of the roughly dozen "root servers" which are the starting points for virtually every name query done throughout the internet, and the latter describes the "localhost" address. Creating conf/db.rootcache file can usually be done automatically by querying the root nameservers directly.

If the current machine has working nameservers (say, via your ISP), you can just run the command:

# dig +tcp @a.root-servers.net . ns > /chroot/named/conf/db.rootcache

The +tcp option is require to get the full reply, not the truncated version due to UDP packet limits. In the absense of any working nameservice, a recent version of the file can be found here.

The two other required files serve to administrate the "localhost" address, and the files are static and need not really be understood:

db.localhost

;
; db.localhost
;
$TTL    86400
@       IN SOA   @ root (
                        42              ; serial (d. adams)
                        3H              ; refresh
                        15M             ; retry
                        1W              ; expiry
                        1D )            ; minimum
        IN NS        @
        IN A         127.0.0.1

db.127.0.0

;
; db.127.0.0
;
$TTL    86400
@       IN      SOA     localhost. root.localhost.  (
                            1 ; Serial
                            28800      ; Refresh
                            14400      ; Retry
                            3600000    ; Expire
                            86400 )    ; Minimum
        IN      NS      localhost.
1       IN      PTR     localhost.

They should be created one time, and thereafter won't ever be administered again.

Verifying permissions

Now we've created the files required inside the jail, but the matter of setting the permissions and ownership remains. It's possible to do this by hand, but unreliable: it's very hard to "keep up" with making sure that everything is set correctly on an ongoing basis. So we typically create a small shell script that will run through the entire jail and affirmatively set everything.

We typically put this in /chroot/named.perms - it lives outsidethe jail itself - and we've found that the same file has been usable without change on all of our installations.

#
# named.perms
#
#   Set the ownership and permissions on the named directory
#cd /chroot/named
# By default, root owns everything and only root can write, but dirs
# have to be executable too. Note that some platforms use a dot
# instead of a colon between user/group in the chown parameters}chown -R root:named .find . -type f -print | xargs chmod u=rw,og=r# regular filesfind . -type d -print | xargs chmod u=rwx,og=rx# directories# the named.conf and rndc.conf must protect their keyschmod o= etc/*.conf# the "secondaries" directory is where we park files from
# master nameservers, and named needs to be able to update
# these files and create new ones.touch conf/secondaries/.empty# placeholderfind conf/secondaries/ -type f -print | xargs chown named:namedfind conf/secondaries/ -type f -print | xargs chmod ug=r,o=chown root:named conf/secondaries/chmod ug=rwx,o=  conf/secondaries/# the var/run business is for the PID filechown root:root  var/chmod u=rwx,og=x var/chown root:named  var/run/chmod ug=rwx,o=rx var/run/# named has to be able to create logfileschown root:named  logs/chmod ug=rwx,o=rx logs/

The "placeholder" file simply insures that the secondaries directory is not empty, and it prevents the script from generating (harmless) error messages.

It's absolutely necessary to run this at least once after setting things up, and periodically whenever changes are made. The command to run this is sh /chroot/named.perms, but the -x option can be added if you want to watch it run:

# sh -x /chroot/named.perms
+ cd /chroot/named
+ chown -R root:named .
+ find . -type f -print
+ xargs chmod u=rw,og=r
+ find . -type d -print
+ xargs chmod u=rwx,og=rx
+ chmod o= etc/named.conf etc/rndc.conf
+ touch conf/secondaries/.empty
+ find conf/secondaries/ -type f -print
+ xargs chown named:named
+ find conf/secondaries/ -type f -print
+ xargs chmod ug=r,o=
+ chown root:named conf/secondaries/
+ chmod ug=rwx,o= conf/secondaries/
+ chown root:root var/
+ chmod u=rwx,og=x var/
+ chown root:named var/run/
+ chmod ug=rwx,o=rx var/run/

A few notes on the files in the jail:

It's not clear that splitting up the etc/ and conf/ directories is necessary, but we've done it this way for a long time and it seems to be a habit. We could probably put everything in conf/ (or etc/) with no impact on safety.
The conf/secondaries/ directory holds the transferred zone files received from the master nameservers, and they are in a separate place for two reasons. One, it helps separate files that you're allowed to modify (the master files) from those that you're not (the secondary).
But more importantly, even the nameserver user itself should not modify your master files, which could be possible if a vulnerability allowed a remote bad guy to run arbitrary code. If the db.master.com filesor its directory is writable, the bad guy could hijack a domain this way (with substantial effort). By putting the secondaries in a writable area, it limits the damage that can occur this way and helps keep things organized well.
named needs to puts its process ID somewhere, and this is usually in some variant of /var/run/named.pid. This name is mentioned in the named.conf file, recalling that it's relative to the jail's top directory:
```
options {
	pid-file	"/var/run/named.pid";
	...
};
```
The etc/named.conf and etc/rndc.conf files will soon both contain the secret key used to manage the nameserver, and this key must be protected from disclosure by making both files unreadable by anybody other than root or the named group. This is important.

Starting the nameserver

We're just about ready to try starting the nameserver, but since the daemon requires several key parameters - that we cannot omit - we prefer to put the full command in a script file. This small script is placed in /chroot/named.start:

#
# named.start
#
#       Note: the path given to the "-c" parameter is relative
#       to the jail's root, not the system root.
#
#       Add "-n2" if you have multiple CPUs
#
# usage: named [-c conffile] [-d debuglevel] [-f|-g] [-n number_of_cpus]
#              [-p port] [-s] [-t chrootdir] [-u username]cd /chroot/named# make sure the debugging-output file is writable by namedtouch named.run
chown named:named named.run
chmod ug=rw,o=r   named.run
PATH=/usr/local/sbin:$PATH named  \
        -t /chroot/named \
        -u named \
        -c /etc/named.conf

and made executable with chmod a+x /chroot/named.start. We willnever start the nameserver with just a "named" command - we must use the script. So let's do so:

# sh /chroot/named.start

If all is well, the nameserver will start running quietly, and the ps -fCnamedcommand may show it running in the background. It should now be ready to accept nameserver requests, and we can test it with the dig command. Though we'll need to modify the file /etc/resolv.conf to contain the local machine's address.

Daemon control with rndc

Very old BIND nameservers relied on UNIX signals to control their behavior, and this has always been a lousy mechanism. BIND 8 introduced a ndc command that communicated over a control channel (a UNIX domain socket), but BIND 9 is now doing this via a TCP socket. This allows for remote operation (say, reloading it) of the nameserver. The old ndc command is gone, replaced with rndc, though not all of the commands are implmented yet.

Configuring rndc is a little tricky: BIND supports substantial functionality that involves the use of keys, and rndc uses just a small part of it. This is aggravated by the fact that getting even a little bit of this wrong will cause the mechanism to fail without meaningful diagnostics. It's been very frustrating.

The rndc command reads the file /usr/local/etc/rndc.conf for its configuration data, but we prefer to locate this file under our chroot area to keep an eye on the permissions and ownership. We'll create a link between the two shortly, but we prefer to build the file first.

#
# /chroot/named/etc/rndc.conf
#
options {
        default-server  127.0.0.1;
        default-key     "rndckey";
};
server 127.0.0.1 {
        key     "rndckey";
};
key "rndckey" {
        algorithm       "hmac-md5";
        secret          "secret key here";
};

As with named.conf, the format is very peculiar and requires that all the semicolons go in the right places. In this file, the token "rndckey" is just the name of this key (as opposed to those keys required for other purposes), and any word could be used as long as they all agree in this file.

The variable part is the "secret", which is a long string of base-64-encoded data, and the BIND distribution provides a mechanism for creating one of these keys. The dnssec-keygen is used for generating multiple kinds of keys, and in our case we just care about generating one of them. We'll create the key into a file, then copy that key to our config file:

# cd /chroot/named/etc
# /usr/local/sbin/dnssec-keygen -a HMAC-MD5 -b 256 -n HOST rndc
Krndc.+157+13856
# cat Krndc.+157+13856.private
Private-key-format: v1.2
Algorithm: 157 (HMAC_MD5)
Key: hU9utBAdP6/dVKKfxOlv0bPOTnAd4A1qosMbs/dwVJI=
...
# rm Krndc.+157+13856.*after key has been saved

Odd note: we've seen the dnssec-keygen program simply hang for long periods of time even on very fast machines, and upon investigation found that there was no available random numbers from the /dev/random device (!). The system collects entropy (aka "randomness") into a pool, and when it's depleted for whatever reason, it waits for more to show up. To get around this, add the @BTT{-r /dev/urandom} option to the command line just before the -aoption: this pulls from a different device that won't block on depleted entropy.

The Krndc.+157+13856 is the name of the key, and we don't believe that any part of this name is interesting to us. The key itself is created into output filenames based on the key name: kname.keyand kname.private. We see above the contents of the private key file, and the key itself ishU9utBAdP6/dVKKfxOlv0bPOTnAd4A1qosMbs/dwVJI=. This data must be inserted into the rndc.conf file:

...
key "rndckey" {
        algorithm       "hmac-md5";
        secret          "hU9utBAdP6/dVKKfxOlv0bPOTnAd4A1qosMbs/dwVJI=";
};

Now the rndc.conf file is created, the "key" files created bydnssec-keygen can be deleted. We also wish to make this config file visible to the rndc program directly: it's looking in /usr/local/etc/rndc.conf for its configuration information. To do this, we perform a symbolic link:

# ln -s /chroot/named/etc/rndc.conf /usr/local/etc/rndc.conf
# ln -s /chroot/named/etc/rndc.conf /etc/rndc.conf

Note that we also have /etc/rndc.conf point to the real file: this is simply as a convenience for the administrator who has to edit this file often - it's easier to type.

Now, the nameserver itself must be configured to listen on a control channel and use this particular key. In the same /chroot/named/etcdirectory, we reconsider the named.conf file: We must add two sections to the beginning of this file. We add a controlssection that describes the network addresses that named will listen on, and a key section describes the key it will use. Copy the secret key from above into the file in the obvious place:

controls {
        inet 127.0.0.1 allow { 127.0.0.1; } keys { rndckey; };
};
key "rndckey" {
        algorithm       "hmac-md5";
        secret          "hU9utBAdP6/dVKKfxOlv0bPOTnAd4A1qosMbs/dwVJI=";
};
...

Note - previous versions of this document have suggested that the actual key name doesn't matter, but this has proven to be false. Once a key has a name, everybody has to agree on what that name is or things will fail outright.

The controlsand key sections must be first in the file: we're not surewhy it's a rule, but we're sure it is a rule.

This configuration tells named to listen only on the localhost interface, and as such won't accept any connections from the rest of the network. This is a useful security precaution, though it's possible to "open" the nameserver to accept connections from trusted others. Both of these config files contain these important private keys, so they must not be readable to nonprivileged users.

Now that the keys and controls have been set up properly, it's necessary to kick the nameserver to force it to reread the file. Simply send a SIGHUP (a -1) to the nameserver

# ps -fCnamed
UID        PID  PPID  C STIME TTY          TIME CMD
named    12527     1  0 12:42 ?        00:00:00 named -t /chroot/named {...}
# kill -1 1252712527 is process ID

Now the nameserver should have reread the configuration files and started listening on the control interface. Now let's try rndc:

# /usr/local/sbin/rndc status
number of zones: 2
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is OFF
server is up and running

This indicates that all is well: the keys are correct. But a common error seen from a bad configuration is:

rndc: send remote authenticator: permission denied

This is often the only diagnostics seen, and it means you have to doublecheck your configuration files. We're sorry that we can't offer much more useful guidance on this front. We'll add notes as we find them.

Starting named at boot time

Now that named is running correctly after being started "by hand", we usually wish for it to start automatically at boot time. The mechanism for this depends somewhat on the particular operating system, but we can give some overall guidelines. Automatic starting at boot time requires a base "init" file plus a couple of symbolic links.

The "base" startup file a small shell script that can start or stop the nameserver, and our version looks like:

#!/bin/sh## named#
export PATH=/usr/local/sbin:$PATH       # needed for rndc
case "$1" in
  start)
        # Start daemons.
        echo -n "Starting named: "
        sh /chroot/named.start
        echo
        ;;
  stop)
        # Stop daemons.
        echo -n "Shutting down named: "
        rndc stop
        echo "done"
        ;;
esac
exit 0

We only support start and stop commands, and this has been more than good enough for us: those wanting a more "full featured" control file are welcome to be adventurous. Be sure to make the file executable: chmod a+x named.

Once the startup script is in place, we have to make some symbolic links to make it start in the appropriate runlevels. The filenames are modified from the "base" name to account for the order in which things are started: we want the nameserver to start just after the IP subsystem has started because so many of the other daemons depend on nameservice.

Locating this init file depends on the operating system, and we'll make notes in this table as we learn about them.

Operating System	startup script	runlevel 2 file	runlevel 3 file
Red Hat Linux 6.X / 7.X	`/etc/rc.d/init.d/named`	`/etc/rc.d/rc2.d/S11named`	`/etc/rc.d/rc3.d/S11named`
Debian "Woody"	`/etc/init.d/named`	`/etc/rc2.d/S18named`	`/etc/rc3.d/S18named`

To create the "rc" files, we use symbolic links. This sample is for the Red Hat Linux organization, and it can be altered for your operating system. We also believe that other runlevels are used for things like X11 windowing, but we don't ever use them. Your mileage may vary.

# cd /etc/rc.d
# ln -s ../init.d/named rc2.d/S11named
# ln -s ../init.d/named rc3.d/S11named

We recommend rebooting the system once to be sure that the nameserver starts properly on an automatic basis: it's very frustrating to have a power outage (say) three months from now and find out that DNS is not available: better to test this while your mind is thinking about nameservice.

Adding local slave zones

(to be determined)

Adding local master zones

(to be determined)

Remote RNDC

The nameserver as installed only accepts rndc requests from the local system, but it's possible to do so over the network with a few changes in the config file.

The change is made in the named.conf file, and we add an entry to the controls section. The addition is made here in bold:

`
controls {
        inet 127.0.0.1    allow { 127.0.0.1; } keys { rndckey; };

        inet 192.168.1.31 allow { 127.0.0.1;         # localhost
                                  192.168.1.0/24;    # local Ethernet
                                  10.1.2.0/24;       # network at home
                                  172.27.217.6;      # our consultant
                          } keys { rndckey; };
};
...

The first inet line requests that named listed on the localhost interface only, but the second requests that it listen on the computer's public Ethernet address (here, 192.168.1.31). The access control lines limit the connections to addresses in the given list, and we can include as many as desired in either single IP address notation or /nbits netbits notation. Be careful to put semicolons in all places that matter - it's easy to get wrong.

Now the config files must be reread: but if we're adding a new interface to listen on, we have to fully stop and restart the daemon. Since we've configured it to run as a non-root user, it's simply not able to bind to the privileged port (953/tcp) on the additional interface. So we must stop and restart.

Now to the remote machine.

On some other machine that's in the access list of the nameserver to be controlled, we must modify rndc.conf to add the keys. We presume here that the rndc.conf file will be controlling the local machine as well as the remote ones, so we'll be adding to the file, not modifying it.

#
# /chroot/named/etc/rndc.conf
#
options {
        default-server  127.0.0.1;
        default-key     "rndckey";
};
server 127.0.0.1 {
        key     "rndckey";
};
key "rndckey" {
        algorithm       "hmac-md5";
        secret          "hU9utBAdP6/dVKKfxOlv0bPOTnAd4A1qosMbs/dwVJI=";
};

server remote.example.com {
	key		"remotekey";
};
key "remotekey" {
        algorithm       "hmac-md5";
        secret          "4TT2RNenA3JyHJAVHvWQTzgOo8GzqHowHUdB2i95peM=";
};

NOTE: we use 127.0.0.1 instead of localhost above because the latter requires name resolution and the former doesn't. We've seen cases where we messed up the "localhost" resource record and causedrndc to stop working. This obviates that problem.

Here, the entry for the remote computer includes a definition of the key used by that remote, and it's clearly different than the key used for the local one.

To control the remote nameserver, we use rndc with the-s servernameparameter:

# rndc -s remote.example.com status
number of zones: 13
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is OFF
server is up and running

We're able to stop and reload the remote server, but there is no wayto restart it via this mechanism. Be careful that you don't get surprised.

Views / Split DNS

It's possible to run BIND 9 in a "split DNS" configuration, where the nameserver will give different answers to the same question depending on who's doing the asking. This is mainly useful for sites that run private networks inside with a limited public footprint on the outside.

We've only barely touched the whole "view" thing and can't offer any real advice in configuration, but we did run into one maddening problem regarding rndc that we'll touch on here.

When configuration changes have been made to the zone or config files, one normally can do rndc reload to load them all, but it's also possible to reload just one zone: this can be useful for very busy systems.

But when views are used, it fails in a very unhelpful way:

# rndc reload unixwiz.net
rndc: 'reload' failed: not found

After fooling around with it for a while we realized that the command requires additional parameters: the class and view names. So we figured out that it's done this way:

# rndc reload unixwiz.net IN external

This requests the "internet" ( IN ) class and the external view: apparently these are not the defaults. We suspect that there are ways around this (say, by naming the view something else), but we very much think that the message from rndc was not very helpful. We might look into some patches to the 9.2.0 source to expand on this to provide a bit more feedback. It was very frustrating.

Files created by "make install"

One of the really ugly problems with previous versions of BIND is that the various important files got scattered all over the filesystem, and the locations varied by platform as determined by the operating system vendor. It was just a nightmare to configure a chroot nameserver for a new platform.

BIND 9 makes this dramatically easier because they have decided to put everything under one place (usually /usr/local/), but there are enough files installed that it can be a bit overwhelming to know just what you need.

This is a list of files that were installed by our own configuration of BIND 9, and it might help you decide what you need to take for a binary-only distribution. Note that this was as of an early BIND 9 installation: we've not updated this since we have upgraded our own installation.

Porting Issues

SCO UNIX 3.2v5.0.5 (OpenServer 5)

We've had all kinds of trouble building BIND 9.2.1 on SCO Open Server wtih gcc 2.7.2.2, though we think we've gotten around it. We have had zero luck with the stock C compiler (no "long long" support). Note for this platform can be found here.

Solaris

So that file-based logfiles have the correct time zone (as opposed to GMT), insure that the jail contains copies of the time-zone definition files found in /usr/share/lib/zoneinfo/US/*. They probably should be owned by root and be unwritable by all.

Solaris and *BSD use a colon instead of a dot between the user name and the group name in the chown command. *BSD uses wheel as the main root group, and Solaris uses other.

BSD

To get BIND to start automatically at boot time, add this bit to the startup file (often /etc/rc.conf, perhaps rc.conf.local):

/etc/rc.conf

...
named_enable="YES"
named_program="/usr/local/sbin/named"
named_flags="-t /chroot/named -u named -c /etc/named.conf"
...

Other Resources

Rob Thomas has a greatSecure BIND Template document, with more coverage of the named.conf file than I provide.

Andrew St. Jean has a good document on setting up DNS and DHCPhere.

mysql driver could not create database instance object(bind dlz)

shanyiwan@live.com() — Wed, 24 Nov 2010 02:50:03 GMT

bind dlz(mysql)运行过程时出现如下错误：

Nov 24 10:35:01 lbbackup named[4155]: starting BIND 9.7.1-P2 -u named -c /usr/local/bind/etc/named.conf.mysql

Nov 24 10:35:01 lbbackup named[4155]: built with '--prefix=/usr/local/bind' '--with-dlz-mysql=/usr/local/mysql' '--enable-threads=no

' '--enable-largefile'

Nov 24 10:35:01 lbbackup named[4155]: using up to 4096 sockets

Nov 24 10:35:01 lbbackup named[4155]: loading configuration from '/usr/local/bind/etc/named.conf.mysql'

Nov 24 10:35:01 lbbackup named[4155]: reading built-in trusted keys from file '/usr/local/bind/etc/bind.keys'

Nov 24 10:35:01 lbbackup named[4155]: using default UDP/IPv4 port range: [1024, 65535]

Nov 24 10:35:01 lbbackup named[4155]: using default UDP/IPv6 port range: [1024, 65535]

Nov 24 10:35:01 lbbackup named[4155]: listening on IPv4 interface lo, 127.0.0.1#53

Nov 24 10:35:01 lbbackup named[4155]: listening on IPv4 interface eth0, 192.168.146.155#53

Nov 24 10:35:01 lbbackup named[4155]: listening on IPv4 interface eth1, 10.0.0.155#53

Nov 24 10:35:01 lbbackup named[4155]: Required root permissions to open '/usr/local/bind/var/run/named.pid'.

Nov 24 10:35:01 lbbackup named[4155]: Please check file and directory permissions or reconfigure the filename.

Nov 24 10:35:01 lbbackup named[4155]: generating session key for dynamic DNS

Nov 24 10:35:01 lbbackup named[4155]: Loading 'Mysql zone' using driver mysql

Nov 24 10:35:01 lbbackup named[4155]: Required token $zone$ not found.

Nov 24 10:35:01 lbbackup named[4155]: Could not build all nodes query list

Nov 24 10:35:01 lbbackup named[4155]: mysql driver could not create database instanceobject.

段错误 (core dumped) #加-g -d 1时出现

配置文件如下：

dlz "Mysql zone" {
   database "mysql
   {host=localhost dbname=mydns_data ssl=false port=3306 user=root pass=sok12345}
   {select zone from dns_records where zone = '%zone%'}
   {select ttl, type, mx_priority, case when lower(type)='txt' then concat('\"', data, '\"')
        else data end from dns_records where zone = '%zone%' and host = '%record%'
        and not (type = 'SOA' or type = 'NS')}
   {select ttl, type, mx_priority, data, resp_person, serial, refresh, retry, expire, minimum
        from dns_records where zone = '%zone%' and (type = 'SOA' or type='NS')}
   {select ttl, type, host, mx_priority, data, resp_person, serial, refresh, retry, expire,
        minimum from dns_records where zone = '%zone%' and not (type = 'SOA' or type = 'NS')}";
#   {select zone from xfr_table where zone = '%zone%' and client = '%client%'}
#   {update data_count set count = count + 1 where zone ='%zone%'}";
};

解决办法：

将配置节dlz "Mysql zone"中的%号更改为$符号即可。

“Some versions of DLZ used '%' to demarcate tokens, but they can cause problems for the LDAP driver. Subsequent patches have changed the token demarcation to '$'. It looks like your updated version (that's failing) is using the '$' symbols. If your config file is a few years old and still using the '%', it will suddenly fail at startup.
Simple solution is to check what your file is using around the tokens, and if it's '%', change them to '$' after the upgrade.”

Bind+Berkeley DB实现DNS动态更新

shanyiwan@live.com() — Tue, 28 Sep 2010 00:29:23 GMT

简介：

本文介绍使用Bind+Berkerley DB驱动（BDBHPT）实现DNS的动态更新。

一、Bind配置

1．在named.conf下的基本配置

dlz "bdbhpt zone" {
database "bdbhpt T(or C or P) /dns-root dnsdata.db";
};

2．三种方式

Transactional mode.： Highest safety - lowest speed. support commit or rollback operations

Concurrent mode： Lower safety (no rollback) - higher speed.

Private mode： No inter-process communication & no locking. Lowest saftey - highest speed.

二、Berkerley DB

1．DB 综述

DB最初开发的目的是以新的HASH访问算法来代替旧的hsearch函数和大量的dbm实现（如AT&T的dbm，Berkeley的ndbm，GNU项目的gdbm）,DB的第一个发行版在1991年出现，当时还包含了B+树数据访问算法。在1992年，BSD UNIX第4.4发行版中包含了DB1.85版。基本上认为这是DB的第一个正式版。在1996年中期，Sleepcat软件公司成立，提供对DB的商业支持，后来被Oracle收购,全世界拥有达2亿多用户。在这以后，DB得到了广泛的应用，当前最新版本是4.6.19。

DB支持几乎所有的现代操作系统，如LINUX、UNIX、WINDOWS等，也提供了丰富的应用程序接口，支持C、C++、JAVA、PERL、TCL、PYTHON、PHP等,新版提供的只有C、C++、JAVA详细的文档API,对java有je-3.2.23工具包。

值得注意的是DB是嵌入式数据库系统，而不是常见的关系/对象型数据库，对SQL语言不支持，也不提供数据库常见的高级功能，如存储过程，触发器等。

2. DB的设计思想

DB的设计思想是简单、小巧、可靠、高性能。如果说一些主流数据库系统是大而全的话，那么DB就可称为小而精。DB提供了一系列应用程序接口（API），调用本身很简单，应用程序和DB所提供的库在一起编译成为可执行程序。这种方式从两方面极大提高了DB的效率。第一：DB库和应用程序运行在同一个地址空间，没有客户端程序和数据库服务器之间昂贵的网络通讯开销，也没有本地主机进程之间的通讯；第二：不需要对SQL代码解码，对数据的访问直截了当。

DB对需要管理的数据看法很简单，DB数据库包含若干条记录，每一个记录由关键字和数据（KEY/VALUE）构成。数据可以是简单的数据类型，也可以是复杂的数据类型，例如C语言中结构。DB对数据类型不做任何解释, 完全由程序员自行处理，典型的C语言指针的"自由"风格。如果把记录看成一个有n个字段的表，那么第1个字段为表的主键，第2--n个字段对应了其它数据。DB应用程序通常使用多个DB数据库，从某种意义上看，也就是关系数据库中的多个表。DB库非常紧凑，不超过500K，但可以管理大至256T的数据量。

DB的设计充分体现了UNIX的基于工具的哲学，即若干简单工具的组合可以实现强大的功能。DB的每一个基础功能模块都被设计为独立的,也即意味着其使用领域并不局限于DB本身。例如加锁子系统可以用于非DB应用程序的通用操作，内存共享缓冲池子系统可以用于在内存中基于页面的文件缓冲。

3. DB核心数据结构

数据库句柄结构DB：包含了若干描述数据库属性的参数，如数据库访问方法类型、逻辑页面大小、数据库名称等；同时，DB结构中包含了大量的数据库处理函数指针，大多数形式为（*dosomething）(DB *, arg1, arg2, …)。其中最重要的有open,close,put,get等函数。

数据库记录结构DBT：DB中的记录由关键字和数据构成，关键字和数据都用结构DBT表示。实际上完全可以把关键字看成特殊的数据。结构中最重要的两个字段是 void * data和u_int32_t size，分别对应数据本身和数据的长度。

数据库游标结构DBC：游标（cursor）是数据库应用中常见概念，其本质上就是一个关于特定记录的遍历器。注意到DB支持多重记录（duplicate records），即多条记录有相同关键字，在对多重记录的处理中，使用游标是最容易的方式。

数据库环境句柄结构DB_ENV：环境在DB中属于高级特性，本质上看，环境是多个数据库的包装器。当一个或多个数据库在环境中打开后，环境可以为这些数据库提供多种子系统服务，例如多线/进程处理支持、事务处理支持、高性能支持、日志恢复支持等。

4. DB数据访问算法

在数据库领域中,数据访问算法对应了数据在硬盘上的存储格式和操作方法。在编写应用程序时，选择合适的算法可能会在运算速度上提高1个甚至多个数量级。大多数数据库都选用B+树算法，DB也不例外，同时还支持HASH算法、Recno算法和Queue算法。

B+树算法：B+树是一个平衡树，关键字有序存储，并且其结构能随数据的插入和删除进行动态调整。为了代码的简单，DB没有实现对关键字的前缀码压缩。B+树支持对数据查询、插入、删除的常数级速度。关键字可以为任意的数据结构。

HASH算法：DB中实际使用的是扩展线性HASH算法（extended linear hashing），可以根据HASH表的增长进行适当的调整。关键字可以为任意的数据结构。

Recno算法：要求每一个记录都有一个逻辑纪录号，逻辑纪录号由算法本身生成。实际上，这和关系型数据库中逻辑主键通常定义为int AUTO型是同一个概念。Recho建立在B+树算法之上，提供了一个存储有序数据的接口。记录的长度可以为定长或不定长。

Queue算法：和Recno方式接近, 只不过记录的长度为定长。数据以定长记录方式存储在队列中，插入操作把记录插入到队列的尾部，相比之下插入速度是最快的。

对算法的选择首先要看关键字的类型，如果为复杂类型，则只能选择B+树或HASH算法，如果关键字为逻辑记录号，则应该选择Recno或Queue算法。当工作集关键字有序时，B+树算法比较合适；如果工作集比较大且基本上关键字为随机分布时，选择HASH算法。Queue算法只能存储定长的记录，在高的并发处理情况下，Queue算法效率较高；如果是其它情况，则选择Recno算法，Recno算法把数据存储为平面文件格式。

注：bind+bdbhpt中我们使用了hash+btree,以下介绍都是以此为基。

5．Berkeley Db的详细API，方法见Berkerley的文档

三、Dns数据在Berkeley中的关系以及存储方式

1．数据结构

定义：

typedef struct bdb_instance { 
       DB_ENV  *dbenv;         
       DB   *data;            
       DBC *cursor;  
       DBC *cursor2;  
       DBC *cursor3;  
       DBC *cursor4;  
       DB   *zone;           
       DB   *xfr;               
       DB   *client;    
} bdbhpt_instance_t;

2．表及算法
包括：
dns_data
dns_zone
dns_host
dns_client

Dns_data	Hash	key	Zone+a space+host
		value	Dns data
Dns_xfr	Hash	key	zone
		value	host
Dns_zone	Btree	key	Reverse zone
		value	NULL
Dns_client	Hash	key	Zone
		value	Xfr ip

3. dns data字段：

Order	Name	Data Type	Description
1	replication_id	string	a unique alpha-numeric id for this record.
2	host	string	DNS host name
3	ttl	string (num)	Time to live (string must convert to number)
4	type	string	DNS data type
5	mx_priority	string (num)	MX Priority (only for MX DNS types)
6	data	string	IP address / Host name / Full domain name
7	primary_ns	string	Primary name server SOA record (SOA ONLY)
8	resp_person	string	Responsible person SOA record (SOA ONLY)
9	serial	string (num)	Serial # for SOA record (SOA ONLY)
10	refresh	string (num)	Refresh timefor SOA record (SOA ONLY)
11	retry	string (num)	Retry time for SOA record (SOA ONLY)
12	expire	string (num)	Expire time for SOA record (SOA ONLY)
13	minimum	string (num)	Minimum time for SOA record (SOA ONLY)

4.各表之间的逻辑关系

Dns_client是控制客户端多台同步
Dns_xfr是Dns_client允许增量传输的zone和host
Dns_zone是reverse zone能提高查询速度，其值为空，当查询zone的时候其关系为：
Dns_zone-->dns_xfr-->dns_data
Dns_data 是最终数据集，当查host时的关系为：
Dns_xfr-->dns_data

5.实例数据
注：bind+bdbhpt官方文档有几个错误，数据要严格按照下面的来定义

[dns_zone] key: moc.tset , data:
[dns_client] key: test.com , data: 127.0.0.1
[dns_client] key: test.com , data: 192.168.1.10
[dns_xfr] key: test.com , data: @
[dns_data] key: test.com @ , data: 1 @ 86400 SOA ns1.test.com. hostmaster.test.com. 2006112401 28800 7200 604800 86400
[dns_xfr] key: test.com , data: download
[dns_data] key: test.com download , data: 18 download 600 A 192.168.1.15
[dns_data] key: test.com download , data: 19 download 600 A 192.168.1.16
[dns_xfr] key: test.com , data: video
[dns_data] key: test.com video , data: 20 video 600 A 192.168.1.17
[dns_data] key: test.com video , data: 21 video 600 A 192.168.1.18
[dns_xfr] key: test.com , data: www
[dns_data] key: test.com www , data: 10 www 600 A 192.168.1.19
[dns_data] key: test.com www , data: 11 www 600 A 192.168.1.10
[dns_data] key: test.com www , data: 12 www 600 A 192.168.1.20

四、程序设计与实现（以下是以c来实现的）

1．需求:

据以上来看，由于数据库只有API,不支持sql,也没server概念，数据库的维护管理全由程序来完成，其基本模块为：

A：添加
B：查找
C：删除
D：同步

2．细节（子模块）

从上面我们知道要实现上面的功能，其子模块有：

A：复制ID的获得

通过取得dns_xfr中的zone+a space+host遍历dns_data的值，复制ID初值为1(为SOA的),其后相同的zone，复制ID++;

B：reverse zone

也就是把zone反向存储.

C：分离字符串判断是否为SOA记录，如果是则repid=1,否则repid++;

D：把整数转化为字符串函数

E：字符串分离与连接函数

F：命令行getop获取参数函数

H：btree和hash表要实现一Key多值，必须支持key值的复制，而且要提高查找的速度的话，还要支持数据的排序，默认为字典顺序，实现更好的算法则以自定义的callback函数来实现。

3．程序实现

#include <sys/types.h> 
#include <stdio.h> 
#define dlz_data "dns_data" 
#define dlz_zone "dns_zone" 
#define dlz_xfr "dns_xfr" 
#define dlz_client "dns_client" 
 
//………………………………………………. 
void Usage(void) 
char *soa(char *str); 
int bdbhpt_open(DBTYPE db_type, DB **db_out, const char *db_name, int flags); 
int bdbhpt_create(void); 
void put_data(char *db_name, char *input_key, char *input_data); 
void bdbhpt_close(void); 
void bdbhpt_find(void ); 
void bdbhpt_dele(); 
void bdbhpt_add(void); 
static char * bdbhpt_strrev (char *str); 
int get_last_repid(void); 
int IntToStr(int num, char *buffer); 
//………………………………………………………… 
 
int main(int argc, char *argv[]) 
{ 
    char ch; 
    int ret; 
    opterr = 0; 
    while ((ch = getopt(argc, argv, "c:f:h:i:j:m:z:adsn")) != -1) 
    { 
        switch (ch) 
        { 
            case 'a': 
                operation = add; 
                break; 
            case 'd': 
                operation = dele; 
                break; 
            case 's': 
                operation = list; 
                break; 
            case 'n': 
                key_val =1; 
                operation = add; 
                break; 
            case 'z': 
                zone = optarg; 
                break; 
            case 'h': 
                host = optarg; 
                break; 
            case 'c': 
                c_zone = optarg; 
                break; 
            case 'i': 
                c_ip = optarg; 
                break; 
            case 'j': 
                a_data = optarg; 
                break; 
            case 'm': 
                db_envdir = optarg; 
                break; 
            case 'f': 
                db_file = optarg; 
                break; 
            case '?': 
            default: 
                printf("please use -H\n"); 
                Usage(); 
        } 
      } 
    if (argc < 2) 
    { 
        fprintf(stderr, "Both a Berkeley DB environment and file must be specified\n"); 
    } 
 
    switch(operation) 
    { 
        case list: 
            bdbhpt_find(); 
            break; 
        case dele: 
            bdbhpt_dele(); 
            break; 
        case add: 
            bdbhpt_add(); 
            break; 
        default: 
            fprintf(stderr, "\nNo operation was selected. "\ 
                          "Select an operation (s d a f)\n"); 
            break; 
    } 
}

四、应用

1．帮助

###############show record##################

Find Zone=> bdbhpt -s -z test.com

Find Host=> bdbhpt -s -z test.com -h www

Find Client=> bdbhpt -s -c test.com

###############show record##################

Drop Zone=> bdbhpt -d -z test.com

Drop Host=> bdbhpt -d -z test.com -h www

Drop Client=> bdbhpt -d -c test.com

###############show record##################

New Create=> bdbhpt -n -z test.com -h @ -j "@ 10 SOA ns1.example.com. root.example.com. 2 2800 7200 604800 86400" -m /dns-root -f dbfile

Append Data=> bdbhpt -a -z test.com -h www -j "www 10 A 192.168.0.1" -m /dns-root -f dbfile

Append Client=> bdbhpt -a -c test.com -i 192.168.1.11

1. 添加数据

A: 添加SOA

新建库：

bdbhpt -n -z test.com -h @ -j "@ 86400 SOA ns1.test.com. hostmaster.test.com. 2006112401 28800 7200 604800 86400" -m /dns-root -f demo.db

追加：

bdbhpt -a -z test1.com -h @ -j "@ 86400 SOA ns1.test1.com. hostmaster.test1.com. 2006112401 28800 7200 604800 86400" -m /dns-root -f demo.db

添加A记录：

bdbhpt -a -z test.com -h www -j "www 600 A 192.168.1.11" -m /dns-root -f demo.db

添加client：

bdbhpt -a -c test.com -i 192.168.1.10 -m /dns-root -f demo.db

2. 查找数据

查找zone:

bdbhpt -s -z test.com -m /dns-root/test/main/ -f demo.db

查找host:

bdbhpt -s -z test.com -h www -m /dns-root/test/main/ -f demo.db

查找client:

bdbhpt -s -c test.com -m /dns-root/test/main/ -f demo.db

3. 删除数据

删除整个client:

bdbhpt -d -c test.com -m /dns-root/test/main/ -f demo.db

删除一个client的IP:

bdbhpt -d -c test2.com -i 192.168.1.15 -m /dns-root/test/main/ -f demo.db

删除整个zone:

bdbhpt -d -z test.com -m /dns-root/test/main/ -f demo.db

删除zone所属host:

bdbhpt -d -z test2.com -h www -m /dns-root/test/main/ -f demo.db

删除zone所属host的一个记录:

bdbhpt -d -z test2.com -h www -j "4 www 600 A 192.168.1.13" -m /dns-root/test/main/ -f demo.db

五、测试

测试环境: linux AS4 kernel: 2.6.9-22.Elsmp
bind9.4.1
测试工具: DnsPerf

服务器配置: 双cpu Intel(R) Xeon(TM) CPU 3.00GHz L2
CPU: L2 cache: 2048K
RAM:4G
测试方法 : 查询10个WIDIP,时间限定6分,不同测试点并发,查看其CPU与RAM的使用情况以及qps数

Node	Chn-hz-3-574	Cnc-xa-1-571	Chn-fs-1-573	Chn-sh-2-571
Queries sent	173295	27033	90522	178760
Queries completed	173274	26927	90259	178512
Queries lost	21	106	263	248
Percentage completed	99.99%	99.61%	99.71%	99.86%
Percentage lost	0.01%	0.39%	0.29%	0.14%
Queries per second	481.27	73.45	245.83	484.41

Cpu占用：80%左右

Ram占用：0.2%

Bind-DLZ with MySQL

shanyiwan@live.com() — Thu, 02 Sep 2010 00:43:53 GMT

Bind-DLZ with MySQL

DNS management with Bind has traditionally been flat files and slave/master configurations. Bind also has a feature/extension called DLZ — dynamically loaded zones. This feature can be very useful when designing applications that use databases or directories for storage rather than having to design your application to address a filesystem to create resource records or zone files.

In this article, I will explain how to set this up for a configuration where there are thousands of name-based virtual hosts hosted on the same VIP/email infrastructure using the same resource record on a CentOS 5.X system using MySQL to store records. The Bind version is 9.6.0-P1.

The first step is to install any pre-requisites:

yum install openssl-devel mysql-devel openldap-devel unixODBC-devel gcc

Note that you’ll want to uninstall gcc after this process is complete to reduce the likelihood of an attacker compiling an exploit on this box if they were to gain unprivileged access.

Next, download and extract the Bind sources:

pushd /tmp/
curl -C - -L -O 'http://ftp.isc.org/isc/bind9/9.6.0-P1/bind-9.6.0-P1.tar.gz'
tar xzvf bind-9.6.0-P1.tar.gz
pushd bind-9.6.0-P1

If compiling on a 64 bit system, you might have to setup some variables so that the appropriate mysql libraries are found:
export CPPFLAGS="-I/usr/lib64/mysql $CPPFLAGS" export LDFLAGS="-L/usr/lib64/mysql $LDFLAGS" export LD_LIBRARY_PATH="/usr/lib64/mysql"

The next step is to run configure — this example uses mysql only:

./configure  \
  --prefix=/usr/local/bind  \
  --disable-openssl-version-check \
  --with-dlz-mysql=yes

Once successful with configure, the next step is to install:
make && sudo make install

Be sure to add a user and group, as well as setup some basic directories for data:
groupadd -r -g 25 named useradd -r -u 25 -s /bin/nologin -d /usr/local/named -g named named mkdir /var/cache/bind chown named:named /var/cache/bind

Now that the easy part is finished, the next step is to setup MySQL to store the appropriate DNS records.

In this example, data is populated in MySQL via a stored procedure in SQL Server via a linked server to a MySQL master (ODBC). A python script then creates the necessary entries in the postfix database to allow mail routing to occur. One of the tables populated here is the postfix.domains table. This is simply a list of all domains that are hosted at this site. I take advantage of this to replicate only this table to each of my DNS servers running MySQL and Bind-DLZ locally. This explanation will help the reader understand the next portion where I setup tables and views and populate them with data.

The next step is to create the database which will store the records. I use a database called postfix since my setup is tightly coupled with email routing and replication from the email database. (Login to MySQL to perform the following actions or script as appropriate.)
mysql> create database postfix;

Next, I create a template of resource records that will apply to all zones hosted within MySQL. (Note that this is a site which hosts thousands of domains on the same VIP/email architecture.)

DROP TABLE IF EXISTS dns_values;
CREATE TABLE dns_values (
  host VARCHAR(255) DEFAULT '' NOT NULL,
  type ENUM('SOA','NS','MX','A','CNAME','TXT','HINFO','PTR') NOT NULL DEFAULT 'SOA',
  data VARCHAR(255),
  ttl INT(11) DEFAULT 300 NOT NULL,
  mx_priority VARCHAR(10),
  refresh INT(11) DEFAULT 0 NOT NULL,
  retry INT(11) DEFAULT 0 NOT NULL,
  expire INT(11) DEFAULT 0 NOT NULL,
  minimum INT(11) DEFAULT 0 NOT NULL,
  serial BIGINT(20) DEFAULT 0 NOT NULL,
  resp_person VARCHAR(255),
  primary_ns VARCHAR(255),
  key host_index (host),
  key type_index (type)
) ENGINE=MyISAM;

The next step is to populate the basic set:
mysql> LOCK TABLES `dns_values` WRITE; /*!40000 ALTER TABLE `dns_values` DISABLE KEYS */; INSERT INTO `dns_values` VALUES ('@','SOA','root.mail.example.com.',300,NULL,10800,900,604800,600,2009020401,'root.mail.example.com.','ns1.example.com.'), ('@','NS','ns1.example.com.',300,NULL,10800,900,604800,600,2009020401,NULL,NULL), ('@','NS','ns2.example.com.',300,NULL,10800,900,604800,600,2009020401,NULL,NULL), ('@','A','xxx.xxx.xxx.xxx',300,NULL,10800,900,604800,600,2009020401,NULL,NULL), ('images','A','xxx.xxx.xxx.xxx',300,NULL,10800,900,604800,600,2009020401,NULL,NULL), ('mail','A','xxx.xxx.xxx.xxx',300,NULL,10800,900,604800,600,2009020401,NULL,NULL), ('*','A','xxx.xxx.xxx.xxx',300,NULL,10800,900,604800,600,2009020401,NULL,NULL), ('imap','CNAME','mail.example.com.',300,NULL,10800,900,604800,600,2009020401,NULL,NULL), ('smtp','CNAME','mail.example.com.',300,NULL,10800,900,604800,600,2009020401,NULL,NULL), ('@','TXT','v=spf2.0/pra mx ip4:xxx.xxx.xxx.0/24 -all',300,NULL,10800,900,604800,600,2009020401,NULL,NULL), ('@','TXT','v=spf1 mx ip4:xxx.xxx.xxx.0/24 -all',300,NULL,10800,900,604800,600,2009020401,NULL,NULL), ('@','MX','mail.example.com.',300,'10',10800,900,604800,600,2009020401,NULL,NULL), ('webmail','CNAME','mail.example.com.',300,NULL,10800,900,604800,600,2009020401,NULL,NULL); /*!40000 ALTER TABLE `dns_values` ENABLE KEYS */; UNLOCK TABLES;

Create the postfix.domains table:

mysql> CREATE TABLE domains (
  domain varchar(128) NOT NULL default '',
  PRIMARY KEY  (domain)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

Go ahead and populate the domains table with some values. Note that I replicate data from another table but you can just as well enter any values manually.
mysql> insert into domains (domain) values('example.com');

The next step is to create a view that will combine the dns_values table with the domains table to present all records as one table:

mysql>CREATE VIEW dns_records AS
SELECT
  d.domain        as zone
  ,dv.host        as host
  ,dv.type        as type
  ,dv.data        as data
  ,dv.ttl         as ttl
  ,dv.mx_priority as mx_priority
  ,dv.refresh     as refresh
  ,dv.retry       as retry
  ,dv.expire      as expire
  ,dv.minimum     as minimum
  ,dv.serial      as serial
  ,dv.resp_person as resp_person
  ,dv.primary_ns  as primary_ns
FROM domains d, dns_values dv ;

Next, setup grants on MySQL to allow the user who is accessing MySQL from Bind access:
mysql> GRANT USAGE,SELECT ON postfix.* TO binddlz@localhost identified by 'trickypassword'; FLUSH PRIVILEGES;

I started with a pretty basic named.conf file:

key rndc {
  algorithm hmac-md5 ;
  secret "longsecret";
};
controls {
  inet 127.0.0.1 allow { localhost; } keys { rndc; };
};
include "/usr/local/bind/etc/named.conf.options";
// prime the server with knowledge of the root servers
zone "." {
  type hint;
  file "/usr/local/bind/etc/db.root";
};
// setup local zones
zone "localhost" {
  type master;
  file "/usr/local/bind/etc/db.local";
};
zone "127.in-addr.arpa" {
  type master;
  file "/usr/local/bind/etc/db.127";
};
zone "0.in-addr.arpa" {
  type master;
  file "/usr/local/bind/etc/db.0";
};
zone "255.in-addr.arpa" {
  type master;
  file "/usr/local/bind/etc/db.255";
};
include "/usr/local/bind/etc/named.custom.zones";
include "/usr/local/bind/etc/named.dlz.zones";

As far as named.conf.options, it is also pretty basic:

options {
  directory "/var/cache/bind";
  allow-transfer { xxx.xxx.xxx.xxx; xxx.xxx.xxx.xxx; };
  zone-statistics yes;
  statistics-file "/usr/local/bind/var/stats/named-stats.out";
  recursion no;
};

As you can see, I simply included the following configuration portion as named.dlz.zones.

dlz "mysql zone" {
  database "mysql
  {host=localhost dbname=postfix user=binddlz pass=trickypassword ssl=false}
  {select zone from dns_records where zone = '%zone%'}
  {select ttl, type, mx_priority, case
      when lower(type)='txt' then concat('\"', data, '\"')
      when lower(type) = 'soa' then concat_ws(' ', data, resp_person, serial, refresh, retry, expire, minimum)
    else data end from dns_records_view where zone = '%zone%' and host = '%record%'}";
};

Now start Bind with the following command and test:
/usr/local/bind/sbin/named -c /usr/local/bind/etc/named.conf -f -g -u named

Useful tips:
* do not include both ns and contact in SOA record, use only respo_contact in either data or resp_contact fields
* make sure you restart Bind every time you restart MySQL or you will lose your connection(s)
* if you would like to create the dns_records table without a view, simply use the dns_values table and add the zone as the first column

来源：http://itsecureadmin.com/2010/09/bind-dlz-with-mysql/

Logfile format for BIND queries

shanyiwan@live.com() — Fri, 23 Apr 2010 08:09:26 GMT

BIND查询日志格式分析

Nov 21 12:34:41 dns named[780]: [ID 866145 local0.info] client 1.2.3.4#32773: query: yikes.com IN MX -E

23-Apr-2010 15:21:15.316 queries: client 192.168.146.18#55771: query: 2030m.com IN A +ED (192.168.146.149)
23-Apr-2010 15:21:15.348 queries: client 192.168.146.18#47779: query: 20304050.cn IN A +ED (192.168.146.149)
23-Apr-2010 15:21:15.348 queries: client 192.168.146.18#21651: query: 2032.cc IN A +ED (192.168.146.149)
23-Apr-2010 15:21:15.348 queries: client 192.168.146.30#33151: query: 2mysite.net IN A + (192.168.146.150)
23-Apr-2010 15:21:15.351 queries: client 192.168.146.30#39878: query: 2mysite.net IN A +T (192.168.146.150)

The entries should be clear enough: the date and time the query was received; the source IP address and port number used by the client;and the name, class and qtype. The final field shows if the query had the rd (recursion desired) bit set (+) or not (-) -- typically showing if the query came from a name server or stub resolver -- or if EDNS0 (E) was used.

All of the text up to the record type (MX in this case) made sense, but I had no idea what the “-E” meant. Being the curious person I am, I dug through the BIND source code to locate the logging code. After a couple of find statements, I was able to locate the logging code in query.c:

ns_client_log(client, NS_LOGCATEGORY_QUERIES, NS_LOGMODULE_QUERY,
                     level, "query: %s %s %s %s%s%s", namebuf, classname,
                     typename, WANTRECURSION(client) ? "+" : "-",
                     (client->signer != NULL) ? "S": "",
                     (client->opt != NULL) ? "E" : "");

So a “+” or “-” in a query log entry indicates that a client requested recursion, and the “E” means that the query requested EDNS0. I would like to thank Knobee for his feedback on this post.

High Performance caching-only (recursive) BIND9 Setup

shanyiwan@live.com() — Sun, 27 Sep 2009 07:04:21 GMT

High Performance caching-only (recursive) BIND9 Setup

In The Beginning there was nothing, which exploded. -- Terry Pratchett

Ok, so what happened here? Well we migrated our two singlethreading BIND8 processes to one multithreading BIND9 process. The query-load did not change at all, but keeping its in-memory database in order using a modell that is thread-safe seems to have cost us a huge amount of user cpu time. Wasn't BIND9 supposed to even work better on an SMP system with two CPUs than two BIND8 processes for it only needs to keep one database in order? Well apparently not. Lets ask the bind9-workers Mailinglist i thought, and i got the following very helpful replies from Jinmei Tatuya:

 I'd first like to recommend disabling threads.  From my experiences,
 enable-threads buys almost nothing for most OSes, unfortunately.  If
 you can allow the configuration with 2 named processes, it should
 provide better performance than a single BIND9 process with 2 threads.
 
 Secondly, according to your memory usage and configuration (i.e.,
 max-cache-size=700M, 623m used), it looks like named reaches the
 high-water mark for the specified maximum, and tries to purge some
 cache entries.  If this periodically happens, it may be the reason for
 the high CPU usage.  So, if possible, it might help if you can add
 more memory which can afford the typical use case under the high-water
 level.
 
 ...
 
 If you go with disabling threads, you may also want to enable
 "internal memory allocation".  (I hear that) it should use memory more
 efficiently (and can make the server faster) but is disabled by
 default due to response-performance reasons in the threaded case.  You
 can enable this feature by adding the following line
 
 #define ISC_MEM_USE_INTERNAL_MALLOC 1
 
 just before the following part of bind9/lib/isc/mem.c:
 
 #ifndef ISC_MEM_USE_INTERNAL_MALLOC
 #define ISC_MEM_USE_INTERNAL_MALLOC 0
 #endif
注：9.6.1-P1版本位置：lib/isc/include/isc/mem.h，其中已经设置：#define ISC_MEM_USE_INTERNAL_MALLOC 1

I opted for the latter option, to disable threading, and applied this patch and set up my BIND9 configuration and loadbalancer to support two processes. You can achieve this by taking care never to bind more than one BIND9 process to the same IP-Address, giving it a custom pidfile and last but not least configure rndc to connect for another port on localhost for the second process.

From:http://zaphods.net/~zaphodb/high-performance-bind9.html

支持海量域名的dns架构

shanyiwan@live.com() — Fri, 25 Sep 2009 07:54:48 GMT

支持海量域名的dns架构

环境操作系统： Redhat 5.2 64位

dns服务器：bind9.5.0-p1

数据库： mysql5.1

1. 缘起

公司前些年成为了域名注册商，起初采用一个zone文件存放一个zone配置的传统方式。后了解zone的增长量将会非常大，在n个百万级。在进行了测试和使用一段时间后，发现当zone数量巨大的情况下，采用传统的zone文件存放zone配置，存在着很大的问题。如将所有域名都放在同一服务器上，在需要重新启动bind时，花费的时间惊人，从下图看出当zone的数量达到30万时，载入时间已经需要近1小时，这显然是不能接受的

后经过权衡，决定以10万为分界，毎10万域名使用一主一辅2台服务器。这种结构尽管有一些不方便，但因为传统的方式稳定性好、查询效率高，所以也用了一段时间。然而当zone的数量到了60多万时，服务器达到了14台，终于觉得不能容忍这种方式了，因为一、太浪费服务器了，二、管理非常不方便，于是乎决心寻找替代的方案

2. 方案选择

在查找一些资料之后，毋庸置疑，基于bind的DLZ（dynamic load zone）是首选。但在DLZ支持的诸多后台数据库中，并不是起初就选择mysql的。bind的查询效率可以达到2万~3万每秒，在DLZ官方，性能评测只有Berkerly DB的查询效率可以达到4000至12000 bps每秒，比较接近bind的原始查询效率，而其他的mysql什么的都只有600~800每秒，Berkerly DB的优势非常明显，因此起初试图使用Berkerly DB作为后台数据库，但最终还是选择了mysql，主要原因如下：

使用Berkerly DB的资料非常少
使用Berkerly DB不支持类似mysql的sql语句，而仅仅支持api接口，测试和使用门槛比较高
没有熟悉Berkerly DB的人员支持，而mysql有同部门的DBA支持 = 性能问题 =

在初步确定采用mysql作为数据库之后，必需要解决查询效率的问题，否则就很难真正投入生产环境。mysql作为后台的查询效率经测试在600-800之间，而我们预期的查询效率必需要达到3k~4k。该结构为什么会慢呢？主要原因就是采用mysql作为后台数据库时，bind不能起用多线程，只能采用单进程。而毎查询一个域名需要执行3~5条sql，所有的sql只能串行处理，所以效率才这么低。解决办法：

修改DLZ源码，将单进程改为多线程

该方法经一位熟悉C的同事验证，不可行。(也许CU有大虾能搞定的，那就更方便易行了)

在bind和mysql之间加一层cache

在我们的结构中，zone数量非常大，单个域名在短时间被重复查询的几率并不高，分析认为该方法不是特别适合我们的结构，因此未进行测试

人造“多线程”

查询效率低的关键原因是串行，因此我们试图人为的实现并行，经过测试后发现可以通过起多个named进程的方式，实现该想法。最终是服务器起8个地址，每个地址单独起一个named。起8个named之后的查询效率如下图，我们可以看出，单个named的查询效率随着named数量的增加从700多降至400，特别是到后期下降趋势很不明显。总体性能从700升至3200左右，两台dns服务器可达到6000多，完全可以满足我们的需要：

3. 框架结构

这个系统的结构最前端是两台F5的负载均衡设备（这原来就有），后面是两台dns服务器，每台起8个named进程，分别连至后台的mysql数据库。F5的每个vip对应每台dns服务器4个进程，这样整个系统没有任何单点。任何一台设备down了bouquet不影响使用。结构图如下：

4. 安装配置

4.1. 首先安装mysql（不然bind找不到mysql，无法安装mysql的dlz插件）

4.1.1. 创建OS帐号

#添加mysql组和用户，之所以指定为601，主要是为了方便各台服务器之间权限统一

groupadd -g 601 mysql   
useradd -c “mysql software owner” -g mysql -u 601 mysql

4.1.2. 目录结构准备

#编辑自己的配置文件my.cnf和log以及innodb的相关目录

mkdir /usr/local/mysql 
mkdir /usr/local/mysql/sock 
mkdir /usr/local/mysql/log  
 
su - mysql 
mkdir /home/mysql/mysqldata 
mkdir /home/mysql/mysqldata/binlog 
mkdir /home/mysql/mysqldata/mydata 
mkdir /home/mysql/mysqldata/innodb_ts 
mkdir /home/mysql/mysqldata/innodb_log 
mkdir /home/mysql/mysqldata/tmpdir  
 
exit   
mkdir /data 
ln -s /home/mysql/mysqldata /data/mysqldata  
 
chown -R mysql:mysql /usr/local/mysql/log 
chown -R mysql:mysql /usr/local/mysql/sock 
chown -R mysql:mysql /data/mysqldata 
chown -R mysql:mysql /data/mysqldata/mydata 
chown -R mysql:mysql /data/mysqldata/binlog 
chown -R mysql:mysql /data/mysqldata/innodb_ts 
chown -R mysql:mysql /data/mysqldata/innodb_log 
chown -R mysql:mysql /data/mysqldata/tmpdir

4.1.3. 编译安装源码

make clean

#这里的config参数可以根据数据库相关需求稍作调整

./configure –prefix=/usr/local/mysql \  
 –without-debug \  
 –without-bench \  
 –disable-shared \  
 –enable-thread-safe-client \  
 –enable-assembler \  
 –enable-profiling \  
 –with-mysqld-ldflags=-all-static \  
 –with-client-ldflags=-all-static \  
 –with-charset=latin1 \  
 –with-extra-charset=utf8,gbk \  
 –with-innodb \  
 –with-csv-storage-engine \  
 –with-federated-storage-engine \  
 –with-mysqld-user=mysql \  
 –without-embedded-server \  
 –with-server-suffix=-community \  
 –with-unix-socket-path=/usr/local/mysql/sock/mysql.sock \   
–with-mysqld-libs=-lmtmalloc \  
 
make make install

#准备my.cnf文件需要注意的几个目录配置：

log-error=/usr/local/mysql/log/error.log   
log_slow_queries=/usr/local/mysql/log/slow_query.log   
datadir=/data/mysqldata/mydata tmpdir=/data/mysqldata/tmpdir   
bin-log=/data/mysqldata/binlog/mysql-bin   
innodb_data_home_dir=/data/mysqldata/innodb_ts   
innodb_log_group_home_dir=/data/mysqldata/innodb_log

其他相关参数进行针对性调整将准备好的my.cnf配置文件cp一份到/etc/my.cnf

创建系统表并修改目录权限

cd /usr/local/mysql  
bin/mysql_install_db –user=mysql –socket=/usr/local/mysql/sock/mysql.sock   
chown -R root .   
chgrp -R mysql .   
chown -R mysql sock   
chown -R mysql log

4.1.4. 启动

bin/mysqld_safe –socket=/usr/local/mysql/sock/mysql.sock –user=mysql &

4.2. 安装bind

4.2.1. 创建用户

useradd -d /etc/namedb -s /bin/false named

4.2.2. 创建var目录并修改权限

mkdir -p /var/named 
chown -R named:named /etc/namedb 
chown -R named:named /var/named

4.2.3. 编译安装

tar -xzvf bind-9.5.0-p1.tar.gz   
./configure –prefix=/opt/named.9.5.0-p1 –sysconfdir=/etc/namedb –with-dlz-mysql=yes –enable-largefile

注：采用mysql做后台数据库，千万不能用–enable-threads选项启用多线程，网上有一些朋友使用mysql做后台，谈到bind会莫名中断服务，大部分都是因为打开了多线程。

4.2.4. 修改/etc/init.d/named文件

关键部分如下：

[ -f /opt/named/sbin/named ] || exit 0  
 
[ -f /etc/namedb/named.conf.11 ] || exit 0  
 
# See how we were called.  
case "$1" in  
  start)  
        # Start daemons.  
      echo -n "Starting named: "  
      daemon /opt/named/sbin/named -c /etc/namedb/named.conf.11 -u named  
      daemon /opt/named/sbin/named -c /etc/namedb/named.conf.12 -u named  
      daemon /opt/named/sbin/named -c /etc/namedb/named.conf.13 -u named  
      daemon /opt/named/sbin/named -c /etc/namedb/named.conf.14 -u named  
      daemon /opt/named/sbin/named -c /etc/namedb/named.conf.15 -u named  
      daemon /opt/named/sbin/named -c /etc/namedb/named.conf.16 -u named  
      daemon /opt/named/sbin/named -c /etc/namedb/named.conf.17 -u named  
      daemon /opt/named/sbin/named -c /etc/namedb/named.conf.18 -u named

4.2.5. named.conf配置

关键部分如下,替代了原来对每一个zone的配置：

dlz "Mysql zone" {  
   database "mysql  
   {host=localhost dbname=dns user=dns pass=12345678}  
   {SELECT zone FROM records WHERE zone = '%zone%'}  
   {SELECT ttl, type, mx_priority, data  
    FROM records  
    WHERE zone = '%zone%' AND host = '%record%' AND type <> 'SOA' AND type <> 'NS'}  
   {SELECT ttl, type, data, primary_ns, resp_contact, serial, refresh, retry, expire, minimum  
    FROM records  
    WHERE zone = '%zone%' AND type='NS'}  
   {SELECT ttl, type, host, mx_priority, data, resp_contact, serial, refresh, retry, expire, minimum  
    FROM records  
    WHERE zone = '%zone%' AND type <> 'NS'}";  
};

5. 可扩展性

该结构的可扩展性非常好，可采用的方式如下：

在单台服务器上增加named的数量
增加物理服务器，作为新节点添加到负载均衡设备里
增加授权的dns服务器，例如：原授权dns服务器为ns1.test.com,ns2.test.com,我们可将授权dns增加到4台为ns1.test.com,ns2.test.com、ns3.test.com,ns4.test.com，通过在ns3.test.com,ns4.test.com后搭建同样的架构系统，可大大增加系统的查询能力，同时将该架构放置在不同的地理位置，还可以实现dns的灾备、冗余。
如果mysql的压力大，也随时可以扩充mysql的节点。分担mysql的压力。

6. 使用现状

目前dns上的zone数量为约90万，查询速率为500，系统的load不到1，启动可以在秒级完成，并且已稳定运行近两个月。现在的架构，dns和mysql在同一物理机上，仅仅需要两台服务器，而这个数据量按原来的架构需要18台服务器，同时维护非常不便。

注：

1、dns一开始会有启动报错：

#service named start  
Starting named: /opt/named/sbin/named: error while loading shared libraries:

2、libmysqlclient.so.15: cannot open shared object file: No such file or directory [FAILED]
解决办法：
a、编辑/etc/ld.so.conf 将mysql的lib目录加入

include ld.so.conf.d/*.conf  
usr/local/mysql/lib/mysql/

b、执行ldconfig 命令

3、dns是否关闭递归查询，对该结构的查询效率有一定影响。因为关闭递归会少执行n多sql语句。

Building Scalable DNS Cluster using LVS

shanyiwan@live.com() — Thu, 24 Sep 2009 01:42:06 GMT

Introduction

DNS (Domain Name Service) is one of the primary Internet services, which is to map human-friendly domain names to machine-friendly IP address. If there are a lot of people using DNS service (for example, subscribers use ISP's DNS server), one DNS server might be becoming a bottleneck, and the server might fail.

Scalable DNS cluster can help provide scalability and availability of DNS service.

The Example below is about setting up a cluster for recursive DNS but you can just as well use the same method for authorative DNS as well. Just remember that clients who use your cluster as a secondary nameservice would need to also-notify{} each of your realservers, not just the service-IP.

Architecture

DNS is a simple service, there is no affinity between requests from the same client. DNS usually listens for queries at UDP port 53 and TCP port 53.

LVS can simply load balance UDP port 53 and TCP port 53 among a set of DNS servers, and there is no need to setup any persistence options.

Configuration Example

keepalived.conf:

! Balancer-Set for udp/53  
virtual_server 194.97.173.124 53 {  
   delay_loop 10  
   lb_algo wrr  
   lb_kind DR  
   protocol UDP  
   ! persistence_timeout 1  
   ! persistence_granularity 255.255.255.255  
   ! eth1.105 -> kai eth1.105  
   real_server 10.1.53.2 53 {  
       weight 1  
       MISC_CHECK {  
           misc_path "/usr/bin/dig -b 10.1.53.1 a resolve.test.roka.net @10.1.53.2 +time=1 +tries=5 +fail > /dev/null"  
           misc_timeout 6  
       }  
   }  
   ! eth1.109 -> kai eth1.109  
   real_server 10.3.53.2 53 {  
       weight 1  
       MISC_CHECK {  
           misc_path "/usr/bin/dig -b 10.3.53.1 a resolve.test.roka.net @10.3.53.2 +time=1 +tries=5 +fail > /dev/null"  
           misc_timeout 6  
       }  
   }  
}

As you can dig (;-) we are using an A record with a low TTL to test the service for this setup is a recursive DNS cluster. So far dig works fine with 44 real_servers configured on an idle Dual PIII 800.

on real_server kai we use the following netfilter setup to be able to direct the traffic to different BIND processes on the same machine/mac:

#DNAT 194.97.173.124->10.1.53.2 eth1.105  
iptables -t nat -A PREROUTING -i eth1.105 -s $net -d 194.97.173.124 -p tcp --dport 53 -j DNAT --to-destination 10.1.53.2:53  
iptables -t nat -A PREROUTING -i eth1.105 -s $net -d 194.97.173.124 -p udp --dport 53 -j DNAT --to-destination 10.1.53.2:53  
#DNAT 194.97.173.124->10.3.53.2 eth1.109  
iptables -t nat -A PREROUTING -i eth1.109 -s $net -d 194.97.173.124 -p tcp --dport 53 -j DNAT --to-destination 10.3.53.2:53  
iptables -t nat -A PREROUTING -i eth1.109 -s $net -d 194.97.173.124 -p udp --dport 53 -j DNAT --to-destination 10.3.53.2:53

BIND9

When i wrote this example we were using two BIND processes on the same machine for BIND9 currently just runs faster when it is not threading. Here is something JINMEI Tatuya told me on the bind9-workers Mailinglist which turned out to be very true:

If you go with disabling threads, you may also want to enable  
"internal memory allocation".  (I hear that) it should use memory more  
efficiently (and can make the server faster) but is disabled by  
default due to response-performance reasons in the threaded case.  You  
can enable this feature by adding the following line

#define ISC_MEM_USE_INTERNAL_MALLOC 1

just before the following part of bind9/lib/isc/mem.c:

#ifndef ISC_MEM_USE_INTERNAL_MALLOC  
#define ISC_MEM_USE_INTERNAL_MALLOC 0  
#endif

Try it and you will keep it. ;)

BIND 9.4 line makes use of this new internal malloc library by default now, but disabling threading will probably free you from the hickups some BIND9 users are experiencing.

PowerDNS recursor

This one is a recursive-only Nameserver with very limited authorative DNS capabilities. The author of this Example uses PowerDNS recursor exclusively for his caching-only DNS cluster by now and is glad that while giving roughly the same queries per second performance it generates less SERVFAIL answers and is generally several times more robust than BIND9.

added redundancy via iBGP

If you have more than one Loadbalancer at different locations and you can convince your local Networker to let you speak BGP4+ to his routers you can use quagga with something like the following configuration to failover the service IP to the second LB if the first one goes down:

!  
router bgp 5430  
 no synchronization  
 bgp router-id a.b.c.d  
 redistribute connected route-map benice  
 neighbor c.d.e.f remote-as 5430  
 neighbor c.d.e.f description ffm4-j2  
 neighbor c.d.e.f send-community both  
 neighbor c.d.e.f soft-reconfiguration inbound  
 neighbor c.d.e.f route-map nixda in  
 neighbor c.d.e.f route-map benice out  
 neighbor d.c.f.e remote-as 5430  
 neighbor d.c.f.e description ffm4-j  
 neighbor d.c.f.e send-community both  
 neighbor d.c.f.e soft-reconfiguration inbound  
 neighbor d.c.f.e route-map nixda in  
 neighbor d.c.f.e route-map benice out  
 no auto-summary  
!  
access-list line permit 127.0.0.1/32 exact-match  
access-list line deny any  
!  
ip prefix-list cns-dus2 description dus2 high-metric eq low-perference  
ip prefix-list cns-dus2 seq 5 permit 194.97.173.125/32  
ip prefix-list cns-dus2 seq 10 deny any  
ip prefix-list cns-ffm4 description ffm4 low-metric eq high-preference  
ip prefix-list cns-ffm4 seq 5 permit 194.97.173.124/32  
ip prefix-list cns-ffm4 seq 10 deny any  
!  
route-map benice permit 10  
 match ip address prefix-list cns-ffm4  
 set local-preference 100  
 set metric 0  
!  
route-map benice permit 20  
 match ip address prefix-list cns-dus2  
 set local-preference 100  
 set metric 1  
!  
route-map nixda deny 10  
!

This is the LB at FFM4. Note that the metric at the DUS2 LB is just the other way around. Here we fancy talking to two core-routers from each LB for extra redundancy. You can also have an internal anycast ServiceIP if you use the same metric at both LBs and make sure they are attached to the same level of router network-topology-wise. This way traffic gets shared between the two loadbalancers according to your network-topology most interesting of course for large dialin ISPs.

Problem

dig does not return a non-zero error code when receiving a SERVFAIL but there are situations when some BIND9 versions return SERVFAIL for any query for example when they are out of memory. For a recursive DNS cluster situation we would want to take such BIND processes out of service.

Workaround

use the following perl script as a wrapper for dig which is quite ugly for perl is an interpretated language and forking it is not much fun so this consumes much user cpu when executed every 6 seconds.

#!/usr/bin/perl  
use strict;  
use warnings;  
# cmdline arguments: <FromIP> <Class> <QTYPE> <QNAME> <ToIP> <Times> <Tries> <ErrrorMatch> <Transport>  
# /usr/bin/dig -b 10.5.53.1 IN A 2.0.0.127.my.test @10.5.53.2 +time=1 +tries=5 +fail  
if(  
       ((defined $ARGV[0])&&($ARGV[0]=~/^\d+\.\d+\.\d+\.\d+$/))  
       &&((defined $ARGV[1])&&($ARGV[1]=~/^(IN|CHAOS)$/))  
       &&((defined $ARGV[2])&&($ARGV[2]=~/^(A|ANY|MX|PTR|SRV|TXT|AAAA|NS|CNAME|SOA)$/))  
       &&((defined $ARGV[3])&&($ARGV[3]=~/^[A-Za-z0-9\-\.]+$/))  
       &&((defined $ARGV[4])&&($ARGV[4]=~/^\d+\.\d+\.\d+\.\d+$/))  
       &&((defined $ARGV[5])&&($ARGV[5]=~/^\d+$/))  
       &&((defined $ARGV[6])&&($ARGV[6]=~/^\d+$/))  
       &&((defined $ARGV[7])&&($ARGV[7]=~/^\S+$/))  
       ) {  
       my $transport="notcp";  
       if((defined $ARGV[8])&&($ARGV[8]=~/^tcp$/i)) {  
               $transport="tcp";  
       } elsif ((defined $ARGV[8])&&($ARGV[8]=~/^udp$/i)) {  
               $transport="notcp";  
       }  
       my (@res)=`/usr/bin/dig -b $ARGV[0] $ARGV[1] $ARGV[2] $ARGV[3] \@$ARGV[4] +time=$ARGV[5] +tries=$ARGV[6] +fail +$transport 2>&1`;  
       my $return=$?;  
       if(my $error=(map {/status:\s*($ARGV[7])/ ? $1 : ()} @res)[0]) {  
               die("$error");  
       } elsif ($return!=0) {  
               die("dig returned: \"$return\"");  
       } elsif ($return==0) {  
               exit 0;  
       } else {  
               die("error: \"$return\" HAS BAD VALUE!");  
       }  
} else {  
       die("dig-wrapper.pl <FromIP> <Class> <QTYPE> <QNAME> <ToIP> <Times> <Tries> <ErrrorMatch> <Transport>");  
}

Ah yes, forgot to say: The Dual PIII 800 is not idleing around anymore - its busy running this script 44 times every 6 seconds, which accounts for roughly 12% user cpu and 5% system used at a query rate of ~3600q/s.

Solution

use a patched version of dig?

Conclusion

It still just works.

From
http://kb.linuxvirtualserver.org/wiki/Building_Scalable_DNS_Cluster_using_LVS

chroot DNS无法写日志到/var/log/messages解决办法

shanyiwan@live.com() — Tue, 01 Sep 2009 03:40:09 GMT

通常情况下，进程通过“/dev/log”向syslogd发送消息。由于“虚拟”根环境的限制，这种通信被禁止。因此syslogd需要改为监听“/var/named/chroot/dev/log”。可以通过编辑syslog的启动脚本来设定新的监听地点。
编辑syslog脚本（vi +24 /etc/rc.d/init.d/syslog），改变SYSLOGD_OPTIONS

[root@ns8 log]# cat /etc/rc.d/init.d/syslog   
#!/bin/bash  
#  
# syslog        Starts syslogd/klogd.  
#  
#  
# chkconfig: 2345 12 88  
# description: Syslog is the facility by which many daemons use to log \  
# messages to various system log files.  It is a good idea to always \  
# run syslog.  
### BEGIN INIT INFO  
# Provides: $syslog  
### END INIT INFO  
 
# Source function library.  
. /etc/init.d/functions  
 
[ -f /sbin/syslogd ] || exit 0  
[ -f /sbin/klogd ] || exit 0  
 
# Source config  
if [ -f /etc/sysconfig/syslog ] ; then  
        . /etc/sysconfig/syslog  
else  
        #SYSLOGD_OPTIONS="-m 0" 
        SYSLOGD_OPTIONS="-m 0 -a /var/named/chroot/dev/log" #修改此处
        KLOGD_OPTIONS="-2" 
fi  
...

[root@ns8 log]# vi /etc/sysconfig/syslog   
 
# Options to syslogd  
# -m 0 disables 'MARK' messages.  
# -r enables logging from remote machines  
# -x disables DNS lookups on messages recieved with -r  
# See syslogd(8) for more details  
#SYSLOGD_OPTIONS="-m 0" 
SYSLOGD_OPTIONS="-m 0 -a /var/named/chroot/dev/log" #修改此处
# Options to klogd  
# -2 prints all kernel oops messages twice; once for klogd to decode, and  
#    once for processing with 'ksymoops'  
# -x disables all klogd processing of oops messages entirely  
# See klogd(8) for more details  
KLOGD_OPTIONS="-x"

flyinweb's blog - DNS技术

A Major Improvement in BIND 9 Startup Performance

手动编译bind，并做chroot处理

Chroot-BIND HOWTO

Scott Wunsch, scott at wunsch.org

The Ideal Solution

The Other Solutions

Introduction

What's a "Jail"?

Pick up the source

Configure and build

Build and configure the jail

Construct the configuration files

Verifying permissions

Starting the nameserver

Daemon control with rndc

Starting named at boot time

Adding local slave zones

Adding local master zones

Remote RNDC

Views / Split DNS

Files created by "make install"

Porting Issues

Other Resources

mysql driver could not create database instance object(bind dlz)

Bind+Berkeley DB实现DNS动态更新

Bind-DLZ with MySQL

Bind-DLZ with MySQL

Logfile format for BIND queries

High Performance caching-only (recursive) BIND9 Setup

High Performance caching-only (recursive) BIND9 Setup

In The Beginning there was nothing, which exploded. -- Terry Pratchett

支持海量域名的dns架构

1. 缘起

2. 方案选择

3. 框架结构

4. 安装配置

4.1. 首先安装mysql（不然bind找不到mysql，无法安装mysql的dlz插件）

4.1.1. 创建OS帐号

4.1.2. 目录结构准备

4.1.4. 启动

4.2. 安装bind

4.2.1. 创建用户

4.2.2. 创建var目录并修改权限

4.2.3. 编译安装

4.2.4. 修改/etc/init.d/named文件

4.2.5. named.conf配置

5. 可扩展性

6. 使用现状

Building Scalable DNS Cluster using LVS

Introduction

Architecture

Configuration Example

added redundancy via iBGP

Problem

Workaround

Solution

Conclusion

chroot DNS无法写日志到/var/log/messages解决办法

Scott Wunsch, `scott at wunsch.org`