| 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.
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.
bind2nsd is available from Sourceforge:
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.
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
bind2nsd doesn't require too much to get it working. The code is written in Python (version 2.4) and requires the following packages:
There is currently one mailing list for bind2nsd:
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.
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.
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.
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.
key{} usagecontrol{} settings?
Al Stone (ahs3 at users dot sf dot net)
|
|
Last updated: 12 July 2007 |
|