convert Knot DNS sigantures certs to BIND format.

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

convert Knot DNS sigantures certs to BIND format.

Milan Jeskynka Kazatel
Hello Comunity, 

can I somehow convert Knot DNS stored certificates for a signed zone to BIND 
format? 
 
My use case is to change used topology for authoritative servers. I ´m manage existing zones in Knot, now I would like to transfer it to BIND 
and use existing certificates for signing it on BIND due to DS records in parent zones. The Knot will be reconfigured as a slave. 
 
Is it possible to achieve it? 

I received a hint for a tool which allows converting .pem format used in Knot to .key and .private used in BIND, but it, unfortunately, does not support ECDSAP256SHA256 algorithm which I used. (http://manpages.ubuntu.com/manpages/xenial/en/man1/softhsm-keyconv.1.html)

Have You any other advice?
 
Thanks. 

--
Jeskyňka Kazatel

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: convert Knot DNS sigantures certs to BIND format.

Tony Finch
Milan Jeskynka Kazatel <[hidden email]> wrote:
>
> I received a hint for a tool which allows converting .pem format used in
> Knot to .key and .private used in BIND, but it, unfortunately, does not
> support ECDSAP256SHA256 algorithm which I used.

Ah, sounds like Knot uses a relatively familiar key format, so we can hack
around with OpenSSL command line tools.

Unless I have missed something, BIND doesn't have any support for non-BIND
key files: it has its own code for reading and writing keys, which knows
about OpenSSL's in-memory key format. (I think this is related to support
for multiple crypto providers, and the fact that supporting PEM implies
supporting ASN.1 which is not a task any wise programmer would take on.)

So I think you'll have to get dirty with the key internals; fortunately
the modern key types handle the private material as a blob so you don't
have to fiddle around with half a dozen parameters.

If you have an ECDSA key in PEM format, you can break it open like
this. The short blob is the private key and the long one is the public
key.

$ openssl ec </var/lib/knot/keys/keys/c3e8539dc582bb2ceeca0ab9fb7b89d521a4f658.pem |
  openssl asn1parse -dump
read EC key
writing EC key
    0:d=0  hl=2 l= 119 cons: SEQUENCE
    2:d=1  hl=2 l=   1 prim: INTEGER           :01
    5:d=1  hl=2 l=  32 prim: OCTET STRING
      0000 - f5 60 92 ac fe 6f 49 3a-cf 32 b3 16 21 2c f7 37   .`...oI:.2..!,.7
      0010 - 46 94 eb 06 4f 71 11 f1-71 92 84 f6 0d 16 73 de   F...Oq..q.....s.
   39:d=1  hl=2 l=  10 cons: cont [ 0 ]
   41:d=2  hl=2 l=   8 prim: OBJECT            :prime256v1
   51:d=1  hl=2 l=  68 cons: cont [ 1 ]
   53:d=2  hl=2 l=  66 prim: BIT STRING
      0000 - 00 04 87 d7 36 06 dc d7-86 36 07 49 d2 c2 f9 7b   ....6....6.I...{
      0010 - 2d 30 64 3a 1c 12 e0 a1-ea dc cd 1f be a4 0f e8   -0d:............
      0020 - c2 d5 af fe 30 71 be 12-62 60 ba 07 ea 07 17 28   ....0q..b`.....(
      0030 - 97 5d 08 cd c4 55 c1 88-bf db b6 e5 34 12 1d 0e   .]...U......4...
      0040 - d2 ac                                             ..

BIND wants these in base64. A not completely impossible way to do this is
to feed the binary (DER) form of the key to a bit of perl. (PEM is base64
encoded DER.) This involves some magic numbers for the offsets of the
blobs derived from the asn1 dump above.

$ openssl ec -outform der </var/lib/knot/keys/keys/c3e8539dc582bb2ceeca0ab9fb7b89d521a4f658.pem |
  perl -Mv5.10 -MMIME::Base64 -e '
    undef $/; my $k = <STDIN>;
    print encode_base64 substr $k, 7, 32;
    print encode_base64 substr $k, -64;'
read EC key
writing EC key
9WCSrP5vSTrPMrMWISz3N0aU6wZPcRHxcZKE9g0Wc94=
h9c2BtzXhjYHSdLC+XstMGQ6HBLgoerczR++pA/owtWv/jBxvhJiYLoH6gcXKJddCM3EVcGIv9u2
5TQSHQ7SrA==

The first line is the private key; the second and third lines are the
public key. We can check it matches:

$ cat /var/lib/knot/keys/zone_example.com.json
{
  "policy": "\u0006policy",
  "nsec3_salt": null,
  "nsec3_salt_created": null,
  "keys": [
    {
      "id": "c3e8539dc582bb2ceeca0ab9fb7b89d521a4f658",
      "keytag": 19633,
      "algorithm": 13,
      "public_key": "h9c2BtzXhjYHSdLC+XstMGQ6HBLgoerczR++pA/owtWv/jBxvhJiYLoH6gcXKJddCM3EVcGIv9u25TQSHQ7SrA==",
      "ksk": false,
      "created": "2019-03-12T15:44:02+0000"
    }
  ]
}

Probably the easiest way to turn this into BIND key files is to run
`dnssec-keygen -a ecdsa256 example.com` and edit the output to insert the
short private and long public base64 blobs emitted by the perl. You will
also need to rename the files to match the keytag in knot's zone_*.json
file.

Tony.
--
f.anthony.n.finch  <[hidden email]>  http://dotat.at/
public services available on equal terms to all
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: convert Knot DNS sigantures certs to BIND format.

Milan Jeskynka Kazatel
Hollo Tony,

many thanks, it´s an awesome trick.

I can confirm, that I´m able to "hack" private and public key from KNOT. I tried to re-write information in .key and .private files in BIND, but now it seems to be an issue with the chain used in the zone.

When I tried to re-sign my zone in BIND by Webmin, then I get this error message below. My original "keytag" is 43121. I don´t understand, where is written information like example.com/ECDSAP256SHA256/45623

***
Failed to sign zone : dnssec-signzone: warning: /var/named/example.com:458: signature has expired dnssec-signzone: warning: dns_dnssec_keylistfromrdataset: error reading private key file example.com/ECDSAP256SHA256/45623: file not found dnssec-signzone: warning: dns_dnssec_keylistfromrdataset: error reading private key file example.com/ECDSAP256SHA256/43121: private key is invalid dnssec-signzone: fatal: failed to load the zone keys: private key is invalid
***

Could you please help me dig, where I´m wrong?
Best regards, 
--
Smil Milan Jeskyňka Kazatel


Milan Jeskynka Kazatel <[hidden email]> wrote:
>
> I received a hint for a tool which allows converting .pem format used in
> Knot to .key and .private used in BIND, but it, unfortunately, does not
> support ECDSAP256SHA256 algorithm which I used.

Ah, sounds like Knot uses a relatively familiar key format, so we can hack
around with OpenSSL command line tools.

Unless I have missed something, BIND doesn't have any support for non-BIND
key files: it has its own code for reading and writing keys, which knows
about OpenSSL's in-memory key format. (I think this is related to support
for multiple crypto providers, and the fact that supporting PEM implies
supporting ASN.1 which is not a task any wise programmer would take on.)

So I think you'll have to get dirty with the key internals; fortunately
the modern key types handle the private material as a blob so you don't
have to fiddle around with half a dozen parameters.

If you have an ECDSA key in PEM format, you can break it open like
this. The short blob is the private key and the long one is the public
key.

$ openssl ec </var/lib/knot/keys/keys/c3e8539dc582bb2ceeca0ab9fb7b89d521a4f658.pem |
openssl asn1parse -dump
read EC key
writing EC key
0:d=0 hl=2 l= 119 cons: SEQUENCE
2:d=1 hl=2 l= 1 prim: INTEGER :01
5:d=1 hl=2 l= 32 prim: OCTET STRING
0000 - f5 60 92 ac fe 6f 49 3a-cf 32 b3 16 21 2c f7 37 .`...oI:.2..!,.7
0010 - 46 94 eb 06 4f 71 11 f1-71 92 84 f6 0d 16 73 de F...Oq..q.....s.
39:d=1 hl=2 l= 10 cons: cont [ 0 ]
41:d=2 hl=2 l= 8 prim: OBJECT :prime256v1
51:d=1 hl=2 l= 68 cons: cont [ 1 ]
53:d=2 hl=2 l= 66 prim: BIT STRING
0000 - 00 04 87 d7 36 06 dc d7-86 36 07 49 d2 c2 f9 7b ....6....6.I...{
0010 - 2d 30 64 3a 1c 12 e0 a1-ea dc cd 1f be a4 0f e8 -0d:............
0020 - c2 d5 af fe 30 71 be 12-62 60 ba 07 ea 07 17 28 ....0q..b`.....(
0030 - 97 5d 08 cd c4 55 c1 88-bf db b6 e5 34 12 1d 0e .]...U......4...
0040 - d2 ac ..

BIND wants these in base64. A not completely impossible way to do this is
to feed the binary (DER) form of the key to a bit of perl. (PEM is base64
encoded DER.) This involves some magic numbers for the offsets of the
blobs derived from the asn1 dump above.

$ openssl ec -outform der </var/lib/knot/keys/keys/c3e8539dc582bb2ceeca0ab9fb7b89d521a4f658.pem |
perl -Mv5.10 -MMIME::Base64 -e '
undef $/; my $k = <STDIN>;
print encode_base64 substr $k, 7, 32;
print encode_base64 substr $k, -64;'
read EC key
writing EC key
9WCSrP5vSTrPMrMWISz3N0aU6wZPcRHxcZKE9g0Wc94=
h9c2BtzXhjYHSdLC+XstMGQ6HBLgoerczR++pA/owtWv/jBxvhJiYLoH6gcXKJddCM3EVcGIv9u2
5TQSHQ7SrA==

The first line is the private key; the second and third lines are the
public key. We can check it matches:

$ cat /var/lib/knot/keys/zone_example.com.json
{
"policy": "\u0006policy",
"nsec3_salt": null,
"nsec3_salt_created": null,
"keys": [
{
"id": "c3e8539dc582bb2ceeca0ab9fb7b89d521a4f658",
"keytag": 19633,
"algorithm": 13,
"public_key": "h9c2BtzXhjYHSdLC+XstMGQ6HBLgoerczR++pA/owtWv/jBxvhJiYLoH6gcXKJddCM3EVcGIv9u25TQSHQ7SrA==",
"ksk": false,
"created": "2019-03-12T15:44:02+0000"
}
]
}

Probably the easiest way to turn this into BIND key files is to run
`dnssec-keygen -a ecdsa256 example.com` and edit the output to insert the
short private and long public base64 blobs emitted by the perl. You will
also need to rename the files to match the keytag in knot's zone_*.json
file.

Tony.
--
f.anthony.n.finch <[hidden email]> http://dotat.at/
public services available on equal terms to all

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: convert Knot DNS sigantures certs to BIND format.

Tony Finch
Milan Jeskynka Kazatel <[hidden email]> wrote:
>
> When I tried to re-sign my zone in BIND by Webmin, then I get this error
> message below. My original "keytag" is 43121. I don´t understand, where is
> written information like example.com/ECDSAP256SHA256/45623

BIND often does not refer to key files by filename, so it helps if you
know how the mnemonic description of the key maps to the filenames. In
this case, example.com/ECDSAP256SHA256/45623 corresponds to
Kexample.com+013+45623.key and .private - 13 is the algorithm number for
ecdsa256 and 45623 is the key tag.

> dnssec-signzone: warning: dns_dnssec_keylistfromrdataset:
> error reading private key file example.com/ECDSAP256SHA256/45623:
> file not found

I think this means there is a DNSKEY record in the zone with tag 45623, so
dnssec-signzone is looking for the corresponding private key file.

> dnssec-signzone: warning: dns_dnssec_keylistfromrdataset:
> error reading private key file example.com/ECDSAP256SHA256/43121:
> private key is invalid

This error happens if there's a cryptographic mismatch between the private
key and the public key.

The unexpected key tag might be caused by the same mismatch, but I can't
be sure about that.

It might help if I go through the details of the parts I omitted from the
end of my previous message.

Remember, I had:

$ cat /var/lib/knot/keys/zone_example.com.json
{
  "policy": "\u0006policy",
  "nsec3_salt": null,
  "nsec3_salt_created": null,
  "keys": [
    {
      "id": "c3e8539dc582bb2ceeca0ab9fb7b89d521a4f658",
      "keytag": 19633,
      "algorithm": 13,
      "public_key": "h9c2BtzXhjYHSdLC+XstMGQ6HBLgoerczR++pA/owtWv/jBxvhJiYLoH6gcXKJddCM3EVcGIv9u25TQSHQ7SrA==",
      "ksk": false,
      "created": "2019-03-12T15:44:02+0000"
    }
  ]
}

$ openssl ec -outform der </var/lib/knot/keys/keys/c3e8539dc582bb2ceeca0ab9fb7b89d521a4f658.pem |
    perl -Mv5.10 -MMIME::Base64 -e '
        undef $/; my $k = <STDIN>;
        print encode_base64 substr $k, 7, 32;
        print encode_base64 substr $k, -64;'
read EC key
writing EC key
9WCSrP5vSTrPMrMWISz3N0aU6wZPcRHxcZKE9g0Wc94=
h9c2BtzXhjYHSdLC+XstMGQ6HBLgoerczR++pA/owtWv/jBxvhJiYLoH6gcXKJddCM3EVcGIv9u2
5TQSHQ7SrA==

The JSON metadata says "algorithm": 13, "ksk": false, so I run

$ dnssec-keygen -a 13 example.com
Generating key pair.
Kexample.com.+013+11891

(If ksk is true then I need to add the -f KSK option.)

The JSON says "keytag": 19633, so I run

$ mv Kexample.com.+013+11891.key Kexample.com.+013+19633.key
$ mv Kexample.com.+013+11891.private Kexample.com.+013+19633.private

Now I need to edit the files.

In the .key file I change the keyid (aka keytag) and the public key to
match the JSON metadata. Note that the public key is very long, and you
need to avoid unwanted line breaks. (The perl magic ouput has an unwanted
line break so you might prefer to use the blob from the JSON.)

Before:

$ cat Kexample.com.+013+19633.key
; This is a zone-signing key, keyid 11891, for example.com.
; Created: 20190314133836 (Thu Mar 14 13:38:36 2019)
; Publish: 20190314133836 (Thu Mar 14 13:38:36 2019)
; Activate: 20190314133836 (Thu Mar 14 13:38:36 2019)
example.com. IN DNSKEY 256 3 13 1cZ3gTd2P3su+pWjBj+wGjGsWt22T/cZmlxrwB1Be91lW0BvrOHN1SDZ togkoCBsdb70zj2//W6QQQcgQudVEQ==

After:

$ cat Kexample.com.+013+19633.key
; This is a zone-signing key, keyid 19633, for example.com.
; Created: 20190314133836 (Thu Mar 14 13:38:36 2019)
; Publish: 20190314133836 (Thu Mar 14 13:38:36 2019)
; Activate: 20190314133836 (Thu Mar 14 13:38:36 2019)
example.com. IN DNSKEY 256 3 13 h9c2BtzXhjYHSdLC+XstMGQ6HBLgoerczR++pA/owtWv/jBxvhJiYLoH6gcXKJddCM3EVcGIv9u25TQSHQ7SrA==

I also need to change the private key to match the output from the perl magic.

Before:

$ cat Kexample.com.+013+19633.private
Private-key-format: v1.3
Algorithm: 13 (ECDSAP256SHA256)
PrivateKey: ysGhvWvE6fJcTxC9d9FXPn4qYuVkILE7l3Ei5VS2pMs=
Created: 20190314133836
Publish: 20190314133836
Activate: 20190314133836

After:

$ cat Kexample.com.+013+19633.private
Private-key-format: v1.3
Algorithm: 13 (ECDSAP256SHA256)
PrivateKey: 9WCSrP5vSTrPMrMWISz3N0aU6wZPcRHxcZKE9g0Wc94=
Created: 20190314133836
Publish: 20190314133836
Activate: 20190314133836

Now I should be able to sign the zone. I'm using the -S smart signing
option, and -P to suppress the error that is reported because my zone has
no KSK.

$ dnssec-signzone -S -P example.com
Fetching ZSK 19633/ECDSAP256SHA256 from key repository.
example.com.signed

Done.

Tony.
--
f.anthony.n.finch  <[hidden email]>  http://dotat.at/
Viking: Variable 3 or less, becoming southwest 4 or 5, occasionally 6 later.
Moderate or rough. Showers then rain. Good, occasionally poor.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: convert Knot DNS sigantures certs to BIND format.

Milan Jeskynka Kazatel
Hello Tony,

ok, I did exactly what you adviced.
Now I´m able to sign my zone. But in dsset file, which should contain the same DS as I already have in the parent zone a have different "keytag" and different hash. 
In my case is "keytag" in dsset file is 43120.

i.e.
example.com.    IN DS 43120 13 1 28844871EB1835E6EA3EE5554B5E7BLABLABLA
example.com.    IN DS 43120 13 2 7777AEB8EE54BE246EA6A83637E39EE47AB13EAD8B3E287D3BLABLABLA

I hoped for the same result which I already have in the parent zone.

Could you please advice me once again?
--
Smil Milan Jeskyňka Kazatel


Milan Jeskynka Kazatel <[hidden email]> wrote:
>
> When I tried to re-sign my zone in BIND by Webmin, then I get this error
> message below. My original "keytag" is 43121. I don´t understand, where is
> written information like example.com/ECDSAP256SHA256/45623

BIND often does not refer to key files by filename, so it helps if you
know how the mnemonic description of the key maps to the filenames. In
this case, example.com/ECDSAP256SHA256/45623 corresponds to
Kexample.com+013+45623.key and .private - 13 is the algorithm number for
ecdsa256 and 45623 is the key tag.

> dnssec-signzone: warning: dns_dnssec_keylistfromrdataset:
> error reading private key file example.com/ECDSAP256SHA256/45623:
> file not found

I think this means there is a DNSKEY record in the zone with tag 45623, so
dnssec-signzone is looking for the corresponding private key file.

> dnssec-signzone: warning: dns_dnssec_keylistfromrdataset:
> error reading private key file example.com/ECDSAP256SHA256/43121:
> private key is invalid

This error happens if there's a cryptographic mismatch between the private
key and the public key.

The unexpected key tag might be caused by the same mismatch, but I can't
be sure about that.

It might help if I go through the details of the parts I omitted from the
end of my previous message.

Remember, I had:

$ cat /var/lib/knot/keys/zone_example.com.json
{
"policy": "\u0006policy",
"nsec3_salt": null,
"nsec3_salt_created": null,
"keys": [
{
"id": "c3e8539dc582bb2ceeca0ab9fb7b89d521a4f658",
"keytag": 19633,
"algorithm": 13,
"public_key": "h9c2BtzXhjYHSdLC+XstMGQ6HBLgoerczR++pA/owtWv/jBxvhJiYLoH6gcXKJddCM3EVcGIv9u25TQSHQ7SrA==",
"ksk": false,
"created": "2019-03-12T15:44:02+0000"
}
]
}

$ openssl ec -outform der </var/lib/knot/keys/keys/c3e8539dc582bb2ceeca0ab9fb7b89d521a4f658.pem |
perl -Mv5.10 -MMIME::Base64 -e '
undef $/; my $k = <STDIN>;
print encode_base64 substr $k, 7, 32;
print encode_base64 substr $k, -64;'
read EC key
writing EC key
9WCSrP5vSTrPMrMWISz3N0aU6wZPcRHxcZKE9g0Wc94=
h9c2BtzXhjYHSdLC+XstMGQ6HBLgoerczR++pA/owtWv/jBxvhJiYLoH6gcXKJddCM3EVcGIv9u2
5TQSHQ7SrA==

The JSON metadata says "algorithm": 13, "ksk": false, so I run

$ dnssec-keygen -a 13 example.com
Generating key pair.
Kexample.com.+013+11891

(If ksk is true then I need to add the -f KSK option.)

The JSON says "keytag": 19633, so I run

$ mv Kexample.com.+013+11891.key Kexample.com.+013+19633.key
$ mv Kexample.com.+013+11891.private Kexample.com.+013+19633.private

Now I need to edit the files.

In the .key file I change the keyid (aka keytag) and the public key to
match the JSON metadata. Note that the public key is very long, and you
need to avoid unwanted line breaks. (The perl magic ouput has an unwanted
line break so you might prefer to use the blob from the JSON.)

Before:

$ cat Kexample.com.+013+19633.key
; This is a zone-signing key, keyid 11891, for example.com.
; Created: 20190314133836 (Thu Mar 14 13:38:36 2019)
; Publish: 20190314133836 (Thu Mar 14 13:38:36 2019)
; Activate: 20190314133836 (Thu Mar 14 13:38:36 2019)
example.com. IN DNSKEY 256 3 13 1cZ3gTd2P3su+pWjBj+wGjGsWt22T/cZmlxrwB1Be91lW0BvrOHN1SDZ togkoCBsdb70zj2//W6QQQcgQudVEQ==

After:

$ cat Kexample.com.+013+19633.key
; This is a zone-signing key, keyid 19633, for example.com.
; Created: 20190314133836 (Thu Mar 14 13:38:36 2019)
; Publish: 20190314133836 (Thu Mar 14 13:38:36 2019)
; Activate: 20190314133836 (Thu Mar 14 13:38:36 2019)
example.com. IN DNSKEY 256 3 13 h9c2BtzXhjYHSdLC+XstMGQ6HBLgoerczR++pA/owtWv/jBxvhJiYLoH6gcXKJddCM3EVcGIv9u25TQSHQ7SrA==

I also need to change the private key to match the output from the perl magic.

Before:

$ cat Kexample.com.+013+19633.private
Private-key-format: v1.3
Algorithm: 13 (ECDSAP256SHA256)
PrivateKey: ysGhvWvE6fJcTxC9d9FXPn4qYuVkILE7l3Ei5VS2pMs=
Created: 20190314133836
Publish: 20190314133836
Activate: 20190314133836

After:

$ cat Kexample.com.+013+19633.private
Private-key-format: v1.3
Algorithm: 13 (ECDSAP256SHA256)
PrivateKey: 9WCSrP5vSTrPMrMWISz3N0aU6wZPcRHxcZKE9g0Wc94=
Created: 20190314133836
Publish: 20190314133836
Activate: 20190314133836

Now I should be able to sign the zone. I'm using the -S smart signing
option, and -P to suppress the error that is reported because my zone has
no KSK.

$ dnssec-signzone -S -P example.com
Fetching ZSK 19633/ECDSAP256SHA256 from key repository.
example.com.signed

Done.

Tony.
--
f.anthony.n.finch <[hidden email]> http://dotat.at/
Viking: Variable 3 or less, becoming southwest 4 or 5, occasionally 6 later.
Moderate or rough. Showers then rain. Good, occasionally poor.

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: convert Knot DNS sigantures certs to BIND format.

Tony Finch
Milan Jeskynka Kazatel <[hidden email]> wrote:
>
> Now I´m able to sign my zone. But in dsset file, which should contain the
> same DS as I already have in the parent zone a have different "keytag" and
> different hash. 
>
> In my case is "keytag" in dsset file is 43120.

OK, referring to your previous message...

> > My original "keytag" is 43121.

The keytag calculation is a very simple checksum so the fact that the
correct and incorrect tags differ by 1 is a big clue :-) The KSK flag's
value is 1 (ZSK flags == 256, KSK flags == 257) so it looks like you
missed out the `-f KSK` option to dnssec-keygen when making the template
key files.

You can fix this by changing 256 to 257 in the .key file(s) that should be
KSKs and re-signing the zone. Double check that the key file names match
the key tags, e.g. this is wrong:

$ dnssec-dsfromkey Kexample.com.+013+19633.key
example.com. IN DS 19634 13 1 32CF6889AEBABD43F2A87A59D4EC13A18A91AA0A

(Unexpectedly, BIND does not always get upset when the keytag in a key
file name doesn't match the computed keytag, so it's possible to get
things slightly wrong and not notice unless you double check.)

Tony.
--
f.anthony.n.finch  <[hidden email]>  http://dotat.at/
Southeast Iceland: Cyclonic, mainly northeasterly, 5 to 7, decreasing 4 at
times. Rough or very rough. Wintry showers. Good, occasionally poor.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: convert Knot DNS sigantures certs to BIND format.

Milan Jeskynka Kazatel
Hello Tony,

Awesome. 
Many thanks for your explanation and clarification. 

Now is everything as I expected.

Best regards,
--
Smil Milan Jeskyňka Kazatel


Milan Jeskynka Kazatel <[hidden email]> wrote:
>
> Now I´m able to sign my zone. But in dsset file, which should contain the
> same DS as I already have in the parent zone a have different "keytag" and
> different hash. 
>
> In my case is "keytag" in dsset file is 43120.

OK, referring to your previous message...

> > My original "keytag" is 43121.

The keytag calculation is a very simple checksum so the fact that the
correct and incorrect tags differ by 1 is a big clue :-) The KSK flag's
value is 1 (ZSK flags == 256, KSK flags == 257) so it looks like you
missed out the `-f KSK` option to dnssec-keygen when making the template
key files.

You can fix this by changing 256 to 257 in the .key file(s) that should be
KSKs and re-signing the zone. Double check that the key file names match
the key tags, e.g. this is wrong:

$ dnssec-dsfromkey Kexample.com.+013+19633.key
example.com. IN DS 19634 13 1 32CF6889AEBABD43F2A87A59D4EC13A18A91AA0A

(Unexpectedly, BIND does not always get upset when the keytag in a key
file name doesn't match the computed keytag, so it's possible to get
things slightly wrong and not notice unless you double check.)

Tony.
--
f.anthony.n.finch <[hidden email]> http://dotat.at/
Southeast Iceland: Cyclonic, mainly northeasterly, 5 to 7, decreasing 4 at
times. Rough or very rough. Wintry showers. Good, occasionally poor.

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users