4 Úno
2015
4 Úno
'15
11:41
Hi,
I am trying to use nsupdate from knot 1.6.1. I have generated key files using
dnssec-keygen from BIND 9.9.5. i.e.
dnssec-keygen -a HMAC-MD5 -b 256 -n HOST -C host.example.com
Whenever I try to use the files with nsupdate -k <file> though I get:
; Error: failed to read key file: public key file is invalid
I have also tried without the “-C” to dnssec-keygen.
Are there different flags I need? Or does someone have an example of the file format
required?
Thanks,
Andrew
4 Úno
4 Úno
14:24
Hi Andrew,
Thanks for the report, it is a bug in knsupdate. There is an incorrect check for KEY type
in keyfile processing.
We will fix it in the 1.6.2 release.
A quick workaround would be a replacement of KEY type with a DNSKEY in keyfiles.
Dan
On 02/04/2015 11:41 AM, Andrew Stevenson wrote:
Hi,
I am trying to use nsupdate from knot 1.6.1. I have generated key files using
dnssec-keygen from BIND 9.9.5. i.e.
dnssec-keygen -a HMAC-MD5 -b 256 -n HOST -C host.example.com
Whenever I try to use the files with nsupdate -k <file> though I get:
; Error: failed to read key file: public key file is invalid
I have also tried without the “-C” to dnssec-keygen.
Are there different flags I need? Or does someone have an example of the file format
required?
Thanks,
Andrew
_______________________________________________
knot-dns-users mailing list
knot-dns-users(a)lists.nic.cz
https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users
16 Bře
16 Bře
0:47
On 04 Feb 2015, at 14:24, Daniel Salzman <daniel.salzman(a)nic.cz> wrote:
Thanks for the report, it is a bug in knsupdate. There
is an incorrect check for KEY type in keyfile processing.
We will fix it in the 1.6.2 release.
A quick workaround would be a replacement of KEY type with a DNSKEY in key files.
Thanks, I have updated to 1.6.2 now and knsupdate accepts keys without modification.
I still had some problems getting things going so, for the benefit of the archives, one
thing that got me was that the name you give to dnssec-keygen must be the name of the key
in the knot.conf file. So the steps I used were (with some details changed):
On the client
-------------
Generate a .key and a .private file containing the shared key:
dnssec-keygen -a HMAC-MD5 -b 512 -n HOST -C host.example.com
On the server
-------------
knot.conf must contain:
...
keys {
host.example.com hmac-md5 “SDFDSAFASDFASDFASDFASDFASDFASDFAF====";
}
remotes {
ddns_client {
address 2a1b:0cfd:ee00:10:4417:3e80:4a91::/112;
key host.example.com;
}
}
zones {
dyn.amic.zone.to.be.updated.com {
file “/path/to/zones/dyn.amic.zone.to.be.updated.com”;
update-in ddns_client;
}
}
...
host.example.com is the name given to the dnssec-keygen command.
The key (SDFDS...) is the key copied from the .key file generated about with the space
character removed.
2a1b:0cfd:ee00:10:4417:3e80:4a91::/112 is a network block that the client will be sending
the DNS updates from.
Back on the client
------------------
knsupdate -d -k Khost.example.com.+324+54211 < script
Where script contains:
server dns.server.com.
zone dyn.amic.zone.to.be.updated.com.
ttl 3600
add host.dyn.amic.zone.to.be.updated.com. AAAA 2a1b:0cfd:ee00:10:4417:3e80:4a91:a0a0add
show
send
answer
You should see a status of NOERROR if everything went OK. If it didn’t I couldn’t find any
useful logs from the server so just double check you have everything set correctly.
Thanks,
Andrew
3332
days inactive
3371
days old
2 comments
2 participants
participants (2)
-
Andrew Stevenson -
Daniel Salzman