TSIG afxr failed while receiving responses: REFUSED

[micah]

Hi,

I've been struggling to get TSIG setup for securing the AXFR of my zone
transfers from the master to the secondaries. I've tried what feels like
everything I can think of, but I am still unable to get it to work
right. I must be missing something, and I hope that the bind community
can tell me what it is.

I'm using the new 9.10 version of bind, so I created the tsig file on
the master by doing tsig-keygen > /etc/bind/tsig.keys, it looks like
this:

key "tsig-key" {
algorithm hmac-sha256;
secret "weeetsigblobhere=";
};

my named.conf has:

include "/etc/bind/rndc.key";
include "/etc/bind/tsig.keys";
include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";

and my named.conf.options has:

zone "example.net" {
type master;
allow-transfer { key tsig.key.; };
also-notify { ip.address.here.x; };
file "/etc/bind/master/db.example";
auto-dnssec maintain;
inline-signing yes;
};

on the slave I have copied over the tsig.keys file and added to the
bottom of it:

key "tsig-key" {
algorithm hmac-sha256;
secret "weeetsigblobhere=";
};

server ip.of.master.here {
keys { "tsig-key"; };
};


now when I try to do a zone transfer:

root@owl:/etc/bind# rndc retransfer example.net
21-May-2014 09:34:11.828 received control channel command 'retransfer example.net'
21-May-2014 09:34:11.907 zone example.net/IN: Transfer started.
21-May-2014 09:34:11.987 transfer of 'example.net/IN' from ip.address.of.master#53: connected using ip.address.of.slave#48600
21-May-2014 09:34:12.068 transfer of 'example.net/IN' from ip.address.of.master#53: failed while receiving responses: REFUSED
21-May-2014 09:34:12.068 transfer of 'example.net/IN' from ip.address.of.master#53: Transfer completed: 0 messages, 0 records, 0 bytes, 0.080 secs (0 bytes/sec)

and I see on the master:

21-May-2014 16:34:12.031 client ip.address.of.slave#48600/key tsig-key (example.net): zone transfer example.net/AXFR/IN' denied

What am I missing?

thanks!
micah

[Mark Andrews]

I suggest that you stop obfuscating the details. Errors like this are
almost always in the details. Hide the secret ('x' it out) but nothing
else. The spelling of key names is important (they must match exactly)
as are the IP addresses.

Did you reload both servers after updating them. Did you update
the correct instances of named.conf. It is easy to update the wrong
instance when you are using chroot (-t).

Mark

> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

[Anand Buddhdev]

On 25/05/2014 16:58, micah wrote:

> zone "example.net" {
> type master;
> allow-transfer { key tsig.key.; };

Here's your mistake. You've written tsig.key, whereas your key is called
tsig-key. Those names don't match.

[Mark Andrews]

In message <538274B9...@ripe.net>, Anand Buddhdev writes:
> On 25/05/2014 16:58, micah wrote:
>
> > zone "example.net" {
> > type master;
> > allow-transfer { key tsig.key.; };
>
> Here's your mistake. You've written tsig.key, whereas your key is called
> tsig-key. Those names don't match.

Actually that isn't the mistake as they are both run through
dns_name_fromtext which will normalise them before comparison.

We don't know what the mistake is as all the details required to
determin where the error is have been changed.

> > also-notify { ip.address.here.x; };
> > file "/etc/bind/master/db.example";
> > auto-dnssec maintain;
> > inline-signing yes;
> > };
> >
> > on the slave I have copied over the tsig.keys file and added to the
> > bottom of it:
> >
> > key "tsig-key" {
> > algorithm hmac-sha256;
> > secret "weeetsigblobhere=";
> > };
> >
> > server ip.of.master.here {
> > keys { "tsig-key"; };
> > };

[Anand Buddhdev]

On 26/05/2014 01:53, Mark Andrews wrote:

Hi Mark,

> Actually that isn't the mistake as they are both run through
> dns_name_fromtext which will normalise them before comparison.

I didn't know that. Does this mean that dots and dashes are equivalent
or irrelevant in tisg key names?

Regards,
Anand

[Mark Andrews]

No. Dots and dashes are not interchangable. I missed that difference.

I was referring to "tsig.key." is the absolute form of "tsig.key"
but given "tsig.key" is relative to "." they become equal and thus
interchangable.

And no this sort of error is not checkable by named-checkconf as
the key could refer to a SIG(0) key.

Obfuscating makes everything suspect and makes it harder to spot
errors. This is a classic example.

Mark

> Regards,
> Anand