Bind, Debian, BADSIG

[CodeChris]

Hi,

I am setting up a master slave DNS system using two debian boxes, they
are the latest version using the dev branch. I roughly followed this
tut http://www.howtoforge.org/debian_bind9_master_slave_system

With the IP's .24 is master and .25 is slave

My issue is my two servers (same location so it's not a router/ACL
problem) cannot sync, the times are correct and in syslog I see this
on the master

client 5.59.5.25#22342: request has invalid signature: TSIG transfer:
tsig verify failure (BADSIG)

and this on the slave

zone example.co.uk/IN: refresh: failure trying master 5.59.5.24#53
(source 0.0.0.0#0): tsig indicates error

I will post named.conf, I am sure the secret hash key comes from
Kservername.co.uk.private I made using dnssec-keygen....

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

key "TRANSFER" {
algorithm hmac-md5;
secret Cyo81M1X5SHjOz126BSW2w==;
};

server 5.59.5.25 {
keys {
TRANSFER;
};
};


and here is the slave

include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";

include "/etc/bind/rndc.key";

key "TRANSFER" {
algorithm hmac-md5;
secret "vGldxHA618+Om0y/uPfn+w==";
};

server 5.59.5.24 {
keys {
TRANSFER;
};
};

I have searched around but nobody seamed to have any answer that
called out to me, and as I said that tut has worked for other
people...

Thanks
Chris

[CodeChris]

Has nobody seen this before?

Chris

[falko]

No, I haven't seen this before... :confused:

[CodeChris]

bollocks....maybe I should format and run through the tut again, I can't see anything I have done wrong though

[CodeChris]

Just checking a few basic things, ntpdate has been updated on both servers, that is fine, here is the named.conf.local on both servers master then slave


//
// Do any local configuration here
//

// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";
zone "domain.co.uk" {
type master;
file "/etc/bind/master/db.domain.co.uk";
};

zone "example.co.uk" {
type master;
file "/etc/bind/master/db.example.co.uk";
};



//
// Do any local configuration here
//

// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";
zone "domain.co.uk" {
type slave;
file "/etc/bind/slave/db.domain.co.uk";
masters { 5.59.5.4; };
allow-notify { 5.59.5.4; };
};
zone "example.co.uk" {
type slave;
file "/etc/bind/slave/db.example.co.uk";
masters { 5.59.5.24; };
allow-notify {5.59.5.24; };
};

I am guessing they are fine?

[gary_gb]

Hi,

Just had exactly the same problem myself and found that I needed to restart bind on the 'master':

sudo /etc/init.d/bind9 restart

Had me confused for quite a while, and like you, seems I double checked everything else, grrr.

Here were the errors that I was getting:
(test setup - master:ns1:192.168.0.101 slave:ns2:192.168.0.102 domain/zone:test.local)

MASTER:
tail /var/log/syslog
Oct 26 23:39:35 ns1 named[4481]: client 192.168.0.102#37378: request has invalid signature: TSIG transfer: tsig verify failure (BADKEY)

SLAVE:
tail /var/log/syslog
Oct 26 23:40:22 ns2 named[5111]: zone test.local/IN: refresh: failure trying master 192.168.0.101#53 (source 0.0.0.0#0): tsig indicates error

Stopped bind on slave, restarted on master, started on slave and lo and behold...

Oct 27 00:10:37 ns2 named[5303]: zone test.local/IN: Transfer started.
Oct 27 00:10:37 ns2 named[5303]: transfer of 'test.local/IN' from 192.168.0.101#53: connected using 192.168.0.102#33584
Oct 27 00:10:37 ns2 named[5303]: zone test.local/IN: transferred serial 2009102101: TSIG 'transfer'
Oct 27 00:10:37 ns2 named[5303]: transfer of 'test.local/IN' from 192.168.0.101#53: end of transfer

[CodeChris]

Thank you very much Gary, I will look at this when I get back in the office.

So stop on master and slave, start on master, start on slave...ok seams simple enough after the hardship :)

[CodeChris]

Annoyingly, that didnt fix my problems :( It just tries to do the transfer of the two domains I have specified and gives that error...I guess my problem is a bit more complicated then yours...bloody thing!!! :(

[matey]

I noticed you use names and Gary used IP addresses. may be you need to edit your resolv.conf, restart /init.d/networking and try bind again?

[CodeChris]

Thank you for your reply...I am struggling to see where you think I am using names and he is using IP address's, however??

[gary_gb]

Yeah, can't say I can see the difference either.

I sort of mashed together instructions from several guides myself when I set up my test Master and Slave, but I think I mostly followed that guide too, and I'm getting various issues (using Ubuntu 8.04.3) like the slave doesn't seem to update unless I force it to using "sudo rndc reload" even though I turned down the TTL and refresh.

I think your problem may be related to having the 2 different "secret" keys. From what I understand, I thought that "secret" had to be the same on both Master and Slave:

Here's just a little cut n paste from:


http://www.bind9.net/manual/bind/9.3.2/Bv9ARM.ch04.html

Informing the Servers of the Key's Existence

Imagine host1 and host 2 are both servers. The following is added to each server's named.conf file:

key host1-host2. {
algorithm hmac-md5;
secret "La/E5CjG9O+os1jq0a2jdA==";
};

The algorithm, hmac-md5, is the only one supported by BIND. The secret is the one generated above. Since this is a secret, it is recommended that either named.conf be non-world readable, or the key directive be added to a non-world readable file that is included by named.conf.

At this point, the key is recognized. This means that if the server receives a message signed by this key, it can verify the signature. If the signature is successfully verified, the response is signed by the same key.

hth,
G.

[matey]

Thank you for your reply...I am struggling to see where you think I am using names and he is using IP address's, however??

Oh I am sorry, I was reading his logs and got confused with the config file.
:(

This must be something simple, like the secret as mentioned by Gary. or a missing semicolon etc...

The zones files confuse me cuz I am noob, earlier I was looking at our server trying to figure out a solution but there are few zone files with diff. variation of our domain name there and also may be some sym links to the same files??(not sure? I am not at work right now)...


anyway, This may be unrelated but I have had a lot of problems with Ubuntu 9x (Jaunty).
I believe 8.x was much better more stable and more config-able.
we still use feisty at work ,7.04 has been obsoleted for a while tho? :(
it seemed a lot more stable than 9.x

In any case I hope this gets solved soon, interested in the outcome (the solution really). please let us know...
Good Luck!

[CodeChris]

Thank you both for your repilies, I am very grateful. So lets take a step back. The key, which I have defined in a conf file and added an include line in named.conf, should be the same on both servers?? Is that correct?...also, at the start mine says

key "rndc-key" {

I think it doesn't matter what is between the " " as long as it's the same on both servers? Correct?

Hmm I don't have the same key: on both servers...I am sure this is all down to this key business, I have fucked up somewhere


Chris

[matey]

ours goes something like this:


cat rndc.key

key "rndc-key" {
algorithm hmac-md5;
secret "eNJHxxxxxxx/xxyyA==";
};

may be copy the secret and paste it to the secondary?

[gary_gb]

Still trying to understand and get it all clear in my head too.

But, I think that they're actually 2 different things.

The rndc key is just so that you can issue rndc commands on the local machine:
http://www.redhat.com/docs/manuals/linux/RHL-7.2-Manual/ref-guide/s1-bind-rndc.html
In order to prevent unauthorized users on other systems from controlling BIND on your server, a shared secret key method is used to explicitly grant privileges to particular hosts. In order for rndc to issue commands to any named, even on a local machine, the keys used in /etc/named.conf and /etc/rndc.conf must match.

And it seems like I've been setting BIND up to use a seperate key/secret for zone transfers to the slaves.

So, I think the rndc secret needs to be there so that the local machine can speak to itself at the very least.

But it looks like maybe using the rndc secret may work for the secret in the slave as well. Haven't tried or tested yet though, it's heavy reading eh!