A little while ago I started working on some DDNS on a RHEL6 box where a client would be able to update it’s own IP address after a reboot to remove the need for us to do it our selves. I was pretty sure this would be a walk in the park, but I hit one very odd issue with nsupdate which looks to be caused by a change recently in the way the keys are generated but this is getting ahead.

DDNs is actually really easy to set, and there’s a few sites out there that will tell you how easy it is, in fact a majority of them do this. However most of them have a section that will mention ddns-keygen, they all go through and tell you to do the same thing.

dnssec-keygen -a HMAC-MD5 -b 512 -n HOST domain.com

After you have generated the two files (.key and .private) Most are un clear as to what to do next, the answer is you use the .key file for everything and you might as well forget the .private file was created.

You have to take the secret from the key file and place it in your named.conf, either as an include or directly but the code you want is as follows:

key domain.com {
algorithm HMAC-MD5;
secret "SAdhkjhkjashdkjhasdkjbasdkbk8768/+sadfnasd asdkjahsdasdhkjhasdasd";

Worth noting I keyboard mashed the key…. but from the .key file you want to copy the whole key (spaces and all), the key above is in fact on one line with a space, so it may have line wrapped.

Once you have this in your named.conf you can start securing your zones with the allow-update command

zone "domain.com" {
type master;
file domain.com;
allow-update { key domain.com; };

Now, I got to this stage with about 20 different websites and all was fine. The issues followed on trying to get nsupdate to work with the key. A lot, if not all, tell you to take the private key and pass that into nsupdate with the -k option.

Well this failed for me.

[root at host etc]# nsupdate -d -k ./Kdomain.com.+157+27613.private
Creating key...
16-Jul-2012 18:17:45.111 ./Kdomain.com.+157+27613.private:1: unknown option 'Private-key-format:'
16-Jul-2012 18:17:45.111 ./Kdomain.com.+157+27613.private:14: unexpected token near end of file
could not read key from ./Kdomain.com.+157+27613.{private,key}: unexpected token

It took me a while to figure out that it was in fact the key file that was causing the problem, one way i helped work it out is with the -y option

nsupdate -y domain.key:SAdhkjhkjashdkjhasdkjbasdkbk8768/+sadfnasdasdkjahsdasdhkjhasdasd

This helped prove that there was an issue with the key format, not there was no space above but the key does normally have one. now, a quite important thing here is that everyone thats ays to use the private key also has a key with this line in it: Private-key-format: v1.2, well mine said Private-key-format: v1.3 and failed. I’m not even sure if that’s relavent.

The fix for this issue was in fact really simple, if you read through the nsupdate man page sufficiently you’ll find that it will take the key in the bind format so create a file containing the say info as…

key domain.com {
algorithm HMAC-MD5;
secret "SAdhkjhkjashdkjhasdkjbasdkbk8768/+sadfnasd asdkjahsdasdhkjhasdasd";

Try again and watch it work.

, ,

Join the conversation! 4 Comments

  1. hmm good article covering something rather obscure which you many not find out.

  2. Hi Matthew,

    I stumbled across your blog post having come up against this very same issue. Confusingly though I already had DDNS up and running but I was only facing this problem with a new domain I wanted to update – on the same client/server and with the same fundmental config!

    Whilst I’m sure your workaround works I managed to get to the bottom of the true cause from the nsupdate manpage:

    With the -k option, nsupdate reads the shared secret from the file keyfile. Keyfiles may be in two formats: a single file containing a named.conf-format key statement, which may be generated automatically by ddns-confgen, or a pair of files whose names are of the format K{name}.+157.+{random}.key and K{name}.+157.+{random}.private, which can be generated by dnssec-keygen.

    My problem, and I suspect yours also, was that I’d only copied the .private file over to the client. Afterall that’s all we’re referencing in the nsupdate command, right? Well, as the manpage hints, it requires ‘a pair of files’. Lo-and-behold as soon as I copied over the .key file to the client it worked even though I wasn’t explicitly referencing it in the nsupdate command.

    Note that with both files over, the -k option to nsupdate can be used against either the ,private or the .key file – it’ll read in both anyway.

    I thought I’d tag this on to your post in case it’s of interest to you and your readers.


    • Thanks for the info, I can’t remember now if I copied both over or not and it turned out to be a very short lived experiment, we ended up moving the dynamic DNS into a deployment portal we built on top of AWS which then generated and returned the zone file / reverse as needed and just scripted a pull from the rest service.

      There was nothing wrong with what we had but we were suffering some poor DNS performance at the time so tried something different.

  3. Many, many thanks! All other articles and tutorials miss the explanation and are confusing.


Don't be Shy, Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: