[BETA] DNS master2slave

Our scripts have some important features for use when writing scripts for others; maybe you don't need them.

We use the "slaves" path because that's what it's actually there for.

We don't have a programmed task for removing zone files no longer in the named.conf file, as sometimes you need them for forensic purposes. We need to create one that can be run monthly, either manually by administrator, or through a cronjob, to keep the directory clean; may we use yours, broken into it's own script?

We run as a separate user (in the final release it'll have a more logical name; during the writing process the author tried to use ftp for transfers and the name stock) to limit damage if the script gets compromised or broken. We strongly believe in privilege separation in scripts we release into the wild.

And perhaps most importantly, we find and report dupes, and exclude them. Why? because they can cause your DNS server to fail. We'd rather your domains don't have slave DNS because of an exclusion than all our domains don't have slave DNS because of a failure. And being able to exclude on the master side is very important if you're slaving more than one machine, because then you'll get dupes of such things as localhost, and even of real domains while moving them between servers.

Anyway, that's why we did what we did.

We're doing a total rewrite as well, before it comes out of beta. But even in beta, it works fine for a lot of people, including us.

Jeff
 
freebsd

Any conversion on the readme to freebsd commands? for ie adduser etc and the chown?

Thanks.
 
Not by me; I don't have either FreeBSD server or current skills. It's Open Source software; you can convert it yourself :). Just remember the license.

Jeff
 
Zone Not Transfering

Hey There,

I got through the install of your script and it seems to be working. The master server correctly copies the ###.###.###.###.named.conf to the /var/www/html/namedftp directly and the slave seems to be able to access the file. My problem is that the zone database files are never created under the bind/slaves/namedftp/###.###.###.### directories. I don't see any error messages in /var/logs/messages related to this problem.

I am successfully getting the slaves.named.conf file copied to the ./slaves folder under bind.

Here is a quick shot of my named.conf on the slave.

How does the script copy over the zones? Is it using bind to do this? Is there some configuration work that I need to do in bind in order to allow this transfer to take place? Any help would be appreciated.

include "/etc/bind/named.conf.options";

// prime the server with knowledge of the root servers
zone "." {
type hint;
file "/etc/bind/db.root";
};

// be authoritative for the localhost forward and reverse zones, and for
// broadcast zones as per RFC 1912

zone "localhost" {
type master;
file "/etc/bind/db.local";
};

zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};

zone "0.in-addr.arpa" {
type master;
file "/etc/bind/db.0";
};

zone "255.in-addr.arpa" {
type master;
file "/etc/bind/db.255";
};

include "/etc/bind/named.conf.local";
include "/etc/bind/slaves/slaves.named.conf";
 
IPs

I'm not, I just figured it did not matter for this discussion. It's an internal IP 192.168.1.52.

I finally found the error in the syslog but can't figure out why I am getting a permission denied.

I tried setting the directory to 777 bind:bind and it's still throwing this permission denied error. Any help would be great!

Here's the error from the syslog.

Feb 16 19:11:43 ns1 named[15615]: zone donnystestdomain.com/IN: Transfer started.
Feb 16 19:11:43 ns1 named[15615]: transfer of 'donnystestdomain.com/IN' from 192.168.1.52#53: connected using 192.168.1.53#45041
Feb 16 19:11:43 ns1 named[15615]: dumping master file: /etc/bind/slaves/namedftp/192.168.1.52/tmp-MDKWiB0n5k: open: permission denied
Feb 16 19:11:43 ns1 named[15615]: transfer of 'donnystestdomain.com/IN' from 192.168.1.52#53: failed while receiving responses: permission denied
Feb 16 19:11:43 ns1 named[15615]: transfer of 'donnystestdomain.com/IN' from 192.168.1.52#53: Transfer completed: 0 messages, 13 records, 0 bytes, 0.001 secs (0 bytes/sec)
 
Figured it out!

I have Master2Slave working great on Ubuntu 8.10!

The root cause of my whole permissions problem was apparmor. I don't know much about apparmor but I found a tid that said slave files on Ubuntu need to be written to /var/cache/bind. Once I change this path on the Master2Slave scripts everything worked great!

Big thanks to Jeff for building these scripts! Nice work!

Donny
 
Glad you got it working. If you're using something like AppArmor it's up to you to make sure it's allowing you to do what you need to do :).

To answer one of your questions:

Years ago I complained to The Internet Systems Consortium (the folk who write and maintain BIND) that it was incomplete because it didn't manage the automatic addition of slave zones; it required that the slave domains became configured on the server used for slaving them.

They wrote back and said that was by design.

So I decided to have Master2Slave DNS Replicator written to fill that hole.

The only reason it's still in beta is because the gent who wrote it has disappeared and I need a few more pieces. If you're a good perl/shell script programmer (sorry, no PHP for this; it has to run on languages available in ALL linux/unix/posix OS distributions) and would like to work on a much needed GPL-licensed tool.

And for extra credit :), there's a fundamental bug in how BIND decides whether or not it's authoritative for a subdomain. Know what it is :D?

Jeff
 
I just wanted to post to say thanks for the great contribution to the DA community.

Getting this setup was quite simple, although I did modify the scripts to suit my needs a little more. Instead of using wget, I changed it to use scp and key authentication.

My named is chroot so I had some fun figuring that out was well, for those that don't know, in your .conf file for named, don't use the chroot folder, just use for ex. /var/named/domain.com.db, it will still look in the chroot folder.
 
jlasman said:
Glad you got it working. If you're using something like AppArmor it's up to you to make sure it's allowing you to do what you need to do :).

To answer one of your questions:

Years ago I complained to The Internet Systems Consortium (the folk who write and maintain BIND) that it was incomplete because it didn't manage the automatic addition of slave zones; it required that the slave domains became configured on the server used for slaving them.

They wrote back and said that was by design.

So I decided to have Master2Slave DNS Replicator written to fill that hole.

The only reason it's still in beta is because the gent who wrote it has disappeared and I need a few more pieces. If you're a good perl/shell script programmer (sorry, no PHP for this; it has to run on languages available in ALL linux/unix/posix OS distributions) and would like to work on a much needed GPL-licensed tool.

And for extra credit :), there's a fundamental bug in how BIND decides whether or not it's authoritative for a subdomain. Know what it is :D?

Jeff
Click to expand...
I already editted/rewrote the scripts to work on Debian, and in the beta files there are some bugs (can't remember if it was Debian related or all OS related).

I could have a look to see what items could be improved, i will email you the improved version + changelog when i am done.
 
I look forward to seeing your work. One missing piece would be a script that would run monthly (or more often) to compare the name of each slave zone file against the actual zone names in the slaves.named.conf file, and remove the slave zone files that aren't listed.

Why? Because reloading (or even restarting) BIND doesn't delete unused files, and eventually we end up with a lot of unnecessary files.

Another addition would be a script to resolve problems with zones not being properly updated when the zone serial numbers get out of synchronization. While ISC has a procedure in place to do it, it's complex, and requires two changes to all the serial numbers. Much easier is (on the slaves) to stop BIND, then remove all the zone files, then restart BIND. It's tested and it works, but I don't have a script for it.

I'm also currently testing a version that uses FTP rather than http to transfer the list. That was actually the original choice; that's why the user is called namedftp.

Any volunteers?

Jeff
 
frankc420 said:
I just wanted to post to say thanks for the great contribution to the DA community.
Click to expand...
Actually for the entire linux/unix community; I had my original argument with the folk at ISC long before DirectAdmin came about.
Getting this setup was quite simple, although I did modify the scripts to suit my needs a little more. Instead of using wget, I changed it to use scp and key authentication.
Click to expand...
Okay, but none of the information is secret, and I don't like the idea of allowing SSH for a user with otherwise limited privileges. As I've mentioned in my post just above, we're working on a version using FTP.
My named is chroot so I had some fun figuring that out was well, for those that don't know, in your .conf file for named, don't use the chroot folder, just use for ex. /var/named/domain.com.db, it will still look in the chroot folder.
Click to expand...
We've got an experimental version (nowhere near ready for release) that works with chroot BIND as well, but I thought DirectAdmin frowns on chroot BIND.

Jeff
 
I already forgot my promise.. i will wait untill your new version is released and check if i can improve that one.

We are planning to change from directadmin/bind nameservers to an independent DNS platform based on powerdns, the update latency is very annoying part of this script (.nl domains checks for valid DNS setup before registering a domain, so at the moment i have to wait a couple of minutes before sync is done).
 
We're very aware of the latency problem with .nl and certain other country level TLDs. We chose updating every fifteen minutes as a happy medium betwen too often and not often enough.

With our fifteen minutes between updates on the master, and then the slaves using an additional offset of five minutes, and then afterwards an additional offset of five minutes before the nameserver hosting the slaves is reloaded, the delay is almost 30 minutes. We're hoping to be able to shorten that significantly in the new release.

Jeff
 
run it.

why? paths and commands explained on readme.txt are for centos. I use debian sarge.

To do it working, I do some "tricks" in my box including permissions to named service. I'm not an expert in linux, maybe this was the situation.

But it's a great script, I will test into a fedora box.
 
We wrote it for CentOS/Red Hat. We've installed it on Debian and others, sometimes painfully, but we've never documented the differences as well as we should have :(. This is just one of the reasons it's still in beta.

Care to write up what you did? It would be helpful to me and to others.

Jeff
 
Why is this program even needed? It seems to be way more overkill then is even needed. I just use a shared key to my slave servers and then use a script that sends the list of updated zones. This script is only needed to be run when adding/deleting a domain. Then on the slave servers run a "rndc reload" on a cron. Its very simple.

Master server sends a text file with list of the zones.

Slave server uses a include line in the named.conf for those zones that master sent over.

Could run a cleanup cron script on slaves as well that removes zones that have been deleted on master.
 
Last edited:
I'm glad your systems are simple enough that you don't need a program. Our program is a series of scripts. It has to cover cases you've never thought of, such as how to verify that two masters aren't sending the same domain name (which can break BIND). It also has to be able to exclude domains which we don't want slaves.

Our system is very robust, and is in use in a commercial environment slaving thousands of domain names from multiple masters to multiple slaves.

We're happy to give it away, and we're happy to install it for anyone who wants to use it, at a cost often well under our hourly rate.

Of course you may not need it. Many others may not need it. But for those who do, it's great value for the price (free).

By the way, we don't have a cleanup script yet. Care to write it for us and donate it to the cause? If not, care to write it for a fair price?

Jeff
 
You must log in or register to reply here.
Back
Top