bind2nsd 

 

bind2nsd

This project builds scripts that translate DNS information in BIND format to NSD format, and then copy that translation to an NSD server. The goal is to make it simple to run redundant BIND and NSD servers and keep them in sync, using only the BIND configuration files.


Synopsis


Description

The basic problem that bind2nsd is trying to solve is to keep two Domain Name Servers in synchronization, with one running BIND, and one running NSD. That is, that their respective configurations -- what zones are being served, and so on -- cause BIND and NSD to respond to queries with the same results.

Why would one want to do this? By providing two different implementations of DNS, configured to serve up the same information, I can provide redundancy and reliability. In particular, this helps me avoid the situation where an exploit of some sort found in one implementation takes down all of my name servers of that type. If I've deployed a monoculture -- e.g., all BIND, or all NSD -- then DNS is completely shut down with one exploit. If I have some of each implementation, it is unlikely (though not impossible) that the exploit will take down both types of name server at the same time.

Since BIND is probably the most frequently used name server, it made sense therefore to provide a way to use the BIND configuration information as the source of all knowledge. Since I use NSD at work, it made sense to then translate to NSD form. The bind2nsd scripts read the BIND configuration data and convert it to a form understandable to NSD. Once that's been done, other scripts copy the NSD configuration to a system running NSD and restart the name server there as needed. These synchronization scripts can be run manually, or via cron, or as some folks do by inserting their invocation into /etc/init.d/bind9 so they're run when BIND is restarted, or by monitoring the BIND configuration files and synchronizing when they change.


Download

bind2nsd is available from Sourceforge:

From source

The source can be found in the files section of the bind2nsd project: http://sourceforge.net/project/showfiles.php?group_id=199888.

Once downloaded, ./install.sh will use Python distutils to install all of the needed modules (including pydes and pexpect -- see also Dependencies).

To install just the bind2nsd Python code, run python setup.py install.

From the repository

bind2nsd uses Mercurial for its source code control system. You can browse the current development tree at http://bind2nsd.sourceforge.net/cgi-bin/hgwebdir.cgi/bind2nsd/. Note that all available Mercurial repositories for this project (including older versions) may be found at http://bind2nsd.sourceforge.net/cgi-bin/hgwebdir.cgi.

Mercurial users can clone the complete tree with hg clone http://bind2nsd.sourceforge.net/cgi-bin/hgwebdir.cgi/bind2nsd


Dependencies

bind2nsd doesn't require too much to get it working. The code is written in Python (version 2.4) and requires the following packages:

distutils
normally included with most Linux distributions. For example, apt-get install python will usually bring in a version on Debian-based systems.

pexpect (>= 2.1)
a Python module providing functionality similar to the Linux expect command. This project can be found on SourceForge, too, at http://pexpect.sourceforge.net. Debian includes a version in the package python-pexpect.

pyDes (>= 1.2)
a Python module providing for simple encryption/decryption. This project can also be found on SourceForge at http://pydes.sourceforge.net


Support

There is currently one mailing list for bind2nsd:

bind2nsd-devel
All current traffic occurs on this list. The need for other lists will be contemplated when necessary. You can subscribe at http://lists.sourceforge.net/lists/listinfo/bind2nsd-devel


Reporting bugs

Before reporting bugs, please read the FAQs section.

For any bugs found, report them using to project bugs page for bind2nsd at http://sourceforge.net/tracker/?group_id=199888.

Please include enough info that the bug can be easily recreated.


FAQs

What is being translated?

A reasonably complete table of what's being translated from BIND to NSD3 and how it's being handled is found in the Compatibility Guide.

Why isn't feature xyz being translated?

The most likely reason is that it simply has not been tackled yet.

I've been parsing and/or translating the named.conf entries as I encounter them. If there's a construct not being translated, let me know about it and I'll see what I can do. Examples and semantic descriptions are of course essential.

Why not just run BIND?

In a single word: monoculture. As in, something to be avoided.

If all possible name servers run BIND, then a single exploitable flaw in BIND can bring down all name servers. That's not to say that BIND itself is inherently flawed; the same would be true if all name servers ran NSD.

By translating between BIND and NSD, I can maintain all of my DNS information in a single format, and still use both name servers. If I can then keep them in sync, I can now provide more robust and reliable name services through redundancy, and by having two different implementations of the same functionality. The exploit found in NSD probably won't affect BIND, and vice versa.


Plans


See Also


Author

Al Stone (ahs3 at users dot sf dot net)


Acknowledgements


Support This Project Last updated: 12 July 2007 SourceForge.net Logo