generating TSIG keys with 'dnssec-keygen', get "error reading key file ... bad key type"?

[jas...@mail-central.com]

I'm working on generating TSIG keys for use with my bind server.

When I generate a 2nd set of keys in a dir, I get a "bad key type" error,

DIR="/home/me/test/nsupdate"
HOST="myhost.example.com"

dnssec-keygen -V
dnssec-keygen 9.10.3-P4

cd $DIR
rm -f *
ls *
(emtpy)

dnssec-keygen -a hmac-sha256 -b 128 -K $DIR -n HOST $HOST
Kmyhost.example.com.+163+35917
ls *
Kmyhost.example.com.+163+35917.key
Kmyhost.example.com.+163+35917.private

dnssec-keygen -a hmac-sha256 -b 128 -K $DIR -n HOST $HOST
dnssec-keygen: warning: dns_dnssec_findmatchingkeys: error reading key file Kmyhost.example.com.+163+39520.private: bad key type

dnssec-keygen: warning: dns_dnssec_findmatchingkeys: error reading key file Kmyhost.example.com.+163+35917.private: bad key type
Kmyhost.example.com.+163+16588
ls *
Kmyhost.example.com.+163+16588.key
Kmyhost.example.com.+163+16588.private
Kmyhost.example.com.+163+35917.key
Kmyhost.example.com.+163+35917.private

>From the manpage

Note 2: DH, HMAC-MD5, and HMAC-SHA1 through HMAC-SHA512 automatically set the
-T KEY option.

So it's auto-set here. What's "bad" about the automatically set key type?

Jason

[Evan Hunt]

On Tue, Apr 19, 2016 at 07:40:38AM -0700, jas...@mail-central.com wrote:
> I'm working on generating TSIG keys for use with my bind server.

I think you'll be happier if you use "tsig-keygen" instead of "dnssec-keygen".

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

[jas...@mail-central.com]

On Tue, Apr 19, 2016, at 02:24 PM, Evan Hunt wrote:
> On Tue, Apr 19, 2016 at 07:40:38AM -0700, jas...@mail-central.com wrote:
> > I'm working on generating TSIG keys for use with my bind server.
>
> I think you'll be happier if you use "tsig-keygen" instead of "dnssec-keygen".

Huh. Didn't come across that in any of the example I was using :-/

Looks like tsig-keygen is also from bind

rpm -q --whatprovides /usr/sbin/dnssec-keygen /usr/sbin/tsig-keygen
bind-utils-9.10.3P4-215.1.x86_64
bind-utils-9.10.3P4-215.1.x86_64

I'll sure read up and give tsig-keygen a try.

But, why's using dnssec-keygen 'bad' for TSIG ? Apart from all the online tutes that refer to it, from its manpage

DESCRIPTION
dnssec-keygen generates keys for DNSSEC (Secure DNS), as defined in RFC 2535 and
RFC 4034. It can also generate keys for use with TSIG (Transaction Signatures) as
defined in RFC 2845, or TKEY (Transaction Key) as defined in RFC 2930.

I'd still like to at least understand what the problem is.

Jason

[Evan Hunt]

On Tue, Apr 19, 2016 at 02:57:42PM -0700, jas...@mail-central.com wrote:
> Looks like tsig-keygen is also from bind
>
> rpm -q --whatprovides /usr/sbin/dnssec-keygen /usr/sbin/tsig-keygen
> bind-utils-9.10.3P4-215.1.x86_64
> bind-utils-9.10.3P4-215.1.x86_64
>
> I'll sure read up and give tsig-keygen a try.
>
> But, why's using dnssec-keygen 'bad' for TSIG ? Apart from all the
> online tutes that refer to it, from its manpage

It's not "bad", dnssec-keygen can generate TSIG keys fine, it's just that
it's cumbersome to remember all the options, and the keys are generated in
a format that isn't directly useful.

$ dnssec-keygen -a hmac-sha256 -b 256 -n host example.com
Kexample.com.+163+04122
$ cat Kexample.com.+163+04122.key
example.com. IN KEY 512 3 163 n7P55owwAgF5Ky9pts1jvGRtPoRy5tLl2RwAzRnyQvI=

To make this useful in named.conf, you have to cut and paste, thus:

key "example.com" {
algorithm hmac-sha256;
secret "n7P55owwAgF5Ky9pts1jvGRtPoRy5tLl2RwAzRnyQvI=";
};

...whereas that's exactly the format you'd get by simply typing
"tsig-keygen example.com".

(The name "tsig-keygen" was introduced in BIND 9.10; prior to that,
the tool was called "ddns-confgen", and it did essentially the same
thing as it does now, but with some extra comments in the output.)

[jas...@mail-central.com]

On Tue, Apr 19, 2016, at 04:25 PM, Evan Hunt wrote:
> It's not "bad", dnssec-keygen can generate TSIG keys fine, it's just that
> it's cumbersome to remember all the options, and the keys are generated in
> a format that isn't directly useful.

Sure that's what I was doing anyway.

To be clean, I'm not saying it's bad.

It's returning the "bad key type" .

I'm just trying to understand what the problem is.

Jason

[Evan Hunt]

> Sure that's what I was doing anyway.
>
> To be clean, I'm not saying it's bad.
>
> It's returning the "bad key type" .
>
> I'm just trying to understand what the problem is.

I'm sorry, I hadn't read your initial message clearly enough.

The "bad key type" message is a bug; it's been there for a while
but I never noticed it, probably because I never ran dnssec-keygen
twice in a row for the same name before. It's cosmetic and harmless,
but I'll open a ticket to fix it. I may not get to it very soon,
though.

What's happening is dnssec-keygen is looking for an existing
key whose keytag collides with the one just generated; it finds
a key file from the first time you ran dnssec-keygen, opens it,
and then complains because it contains type KEY instead of type
DNSKEY. KEY is in fact what *should* be there, but the collision-
checking function is expectingly DNSKEY, and so it complains.

[jas...@mail-central.com]

On Tue, Apr 19, 2016, at 05:19 PM, Evan Hunt wrote:
> The "bad key type" message is a bug; it's been there for a while

...

> KEY is in fact what *should* be there, but the collision-
> checking function is expectingly DNSKEY, and so it complains.

Ok, so the data's good; just the detection whines for now. Thanks.

Which leads me right back to my original problem -- unable to get nsupdates 'to' my remote server ( I was kinda hoping that there was something wrong with the key file :-/ )

But that's another issue.

Jason