16 Bře
2015
16 Bře
'15
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