tsig indicates error

[Managed Pvt nets]

Hi All,

 

I have recently built a server to act as a secondary / slave for my zones. Built on Debian 8.1 and running BIND 9.9.5. On trying to transfer zones from my master I am getting this error here, what could I be missing:

 

===

Jul 24 15:33:55 huffer named[493]: zone myzonename.co.zw/IN: refresh: failure trying master aaa.bbb.ccc.ddd#53 (source 0.0.0.0#0): tsig indicates error

===

 

regards,

 

Mollatt.

[John Miller]

Hi Mollatt,

This usually means what it says: there's an error with the TSIG authentication between master and slave.  Make sure you've got your allow-transfer statements configured with the proper keys, that you've got server {} blocks configured with the proper keys, and that a copy of the slave key lives on the master.

If you're not intending to use TSIG, make sure your master doesn't require it and that your slave doesn't try to use it for its AXFRs.

John

--

John Miller
Systems Engineer
Brandeis University
john...@brandeis.edu

[Alan Clegg]

Possible problems:
   Mismatched keys.
   Mismatched key names.
   Mismatched clocks.

On 7/24/2015 10:52 AM, Managed Pvt nets wrote:

Hi All,

 

I have recently built a server to act as a secondary / slave for my zones. Built on Debian 8.1 and running BIND 9.9.5. On trying to transfer zones from my master I am getting this error here, what could I be missing:

 

===

Jul 24 15:33:55 huffer named[493]: zone myzonename.co.zw/IN: refresh: failure trying master aaa.bbb.ccc.ddd#53 (source 0.0.0.0#0): tsig indicates error

===

 

regards,

 

Mollatt.

_______________________________________________
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

[Managed Pvt nets]

 

 

On 24/07/2015 5:03:12 PM, "John Miller" <john...@brandeis.edu> wrote:

 

 

If you're not intending to use TSIG, make sure your master doesn't require it and that your slave doesn't try to use it for its AXFRs.

 

I think this is what I have to figure out to do. 

 

[Managed Pvt nets]

 

 

On 24/07/2015 5:05:24 PM, "Alan Clegg" <al...@clegg.com> wrote:

 

Possible problems:
   Mismatched keys.
   Mismatched key names.
   Mismatched clocks.

 

Most likely mismatched key.  I have to figure out how to make sure my master does not require TSIGs and my slave does not try to use them. 

 

[John Miller]

On Fri, Jul 24, 2015 at 11:52 AM, Mark Elkins <m...@posix.co.za> wrote:

TSIG is a step towards better security. Rather learn how to use it than
go backwards. I see TSIG as a step towards DNSSEC...

I'm with Mark on this.  TSIG isn't that tough to figure out--a couple hours and you should have it down.  Cricket/Paul's book, and Pro DNS and BIND 10 are good intros to the subject.  I'm installing a copy of Debian 8.1 for myself right now--I'm curious to see what the stock BIND config looks like (we use RHEL here at the office).

John

[Anand Buddhdev]

On 24/07/15 17:52, Mark Elkins wrote:

> TSIG is a step towards better security. Rather learn how to use it than
> go backwards. I see TSIG as a step towards DNSSEC...

I also agree with this principle. At the RIPE NCC we've been trying to
get all the operators we provide secondary for to use TSIG. It's an
uphill struggle. Some don't even know how to generate the keys, while
others configure it incorrectly, or have the incorrect time on the
server. Nevertheless, we're getting there, and I'm hopeful that these
operators have slightly better configurations as a result of our
insistence on TSIG.

Regards,
Anand

[Managed Pvt nets]

 

 

On 24/07/2015 6:07:09 PM, "John Miller" <john...@brandeis.edu> wrote:

 

On Fri, Jul 24, 2015 at 11:52 AM, Mark Elkins <m...@posix.co.za> wrote:

On Fri, 2015-07-24 at 15:44 +0000, Managed Pvt nets wrote:
>
>
> On 24/07/2015 5:05:24 PM, "Alan Clegg" <al...@clegg.com> wrote:
>
> > Possible problems:
> >    Mismatched keys.
> >    Mismatched key names.
> >    Mismatched clocks.
>
> Most likely mismatched key.  I have to figure out how to make sure my
> master does not require TSIGs and my slave does not try to use them.

TSIG is a step towards better security. Rather learn how to use it than
go backwards. I see TSIG as a step towards DNSSEC...

I'm with Mark on this.  TSIG isn't that tough to figure out--a couple hours and you should have it down.  Cricket/Paul's book, and Pro DNS and BIND 10 are good intros to the subject.  I'm installing a copy of Debian 8.1 for myself right now--I'm curious to see what the stock BIND config looks like (we use RHEL here at the office).

 

Thanks all. I finally got this working.

 

===

Jul 27 14:40:24 hostname named[6016]: zone myzone.co.zw/IN: transferred serial 2015072400: TSIG 'rndc-key'

===

 

many thanks

 

 

 

[Tony Finch]

Managed Pvt nets <m...@icabs.co.zw> wrote:
>

> Jul 27 14:40:24 hostname named[6016]: zone myzone.co.zw/IN: transferred serial 2015072400: TSIG 'rndc-key'

It isn't a very good idea to use the same key for zone transfers and
for rndc. It is common to allow zone transfers to third parties, and
you don't want them to be able to fiddle with your name server!

Best to have separate keys for rndc and different keys for each secondary
(or for each set of secondaries under the same management).

Tony.
--
f.anthony.n.finch <d...@dotat.at> http://dotat.at/
Biscay: Northwest 5 or 6, occasionally 4 later. Moderate or rough. Fair. Good.

[Evan Hunt]

On Mon, Jul 27, 2015 at 04:33:06PM +0100, Tony Finch wrote:
> It isn't a very good idea to use the same key for zone transfers and
> for rndc. It is common to allow zone transfers to third parties, and
> you don't want them to be able to fiddle with your name server!

Sometimes, in my experience, people do this because rndc-confgen is
relatively easy to use, but generating other keys using dnssec-keygen
is cumbersome.

So I'll just take this opportunity to mention that in the more recent
versions of BIND you can use 'tsig-keygen <name>', it's much easier. Or
if you're on an older release, 'ddns-confgen -q -k <name>' does the same
thing.

--
Evan Hunt -- ea...@isc.org
Internet Systems Consortium, Inc.