Bind, Debian, BADSIG

[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]

Originally Posted by 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??

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/l...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!