Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've a bind9.7.3 running on Debian squeeze. I've configured a zone to accept dynamic update using a key:

(I've replaced the key and the actual domain names ...)

key "yme" {
        algorithm hmac-md5;
        secret "topsecret";

zone "some-domain.de" in {
  type master;
  file "/etc/bind/zones/some-domain.de";
  allow-update {
    key yme;

zone "some-other-domain.net" in {
  type master;
  file "/etc/bind/zones/some-other-domain.net";
  allow-update {
    key yme;

Now, I send updates from a pfSense installation and I always get

22-Mar-2013 13:08:15.969 update-security: client update 'some-other-domain.net/IN' denied

The key is configured correctly on both sides, there is no clock skew between the both sides.

What else could be the problem, what might I have overlooked?

share|improve this question
You need to use the key that rndc-confgen created. The key is located in /etc/rndc.key – midnightsteel Apr 22 '13 at 0:58
Run the server in debug mode and try again? – EightBitTony Jun 13 '14 at 11:57
@networker how is the nsupdate tag useful? – Braiam Jun 13 '14 at 12:02
@Braiam , I guess nsupdate is used to dynamic update which is mentioned in the question. – Networker Jun 13 '14 at 12:14
@Networker nsupdate is already part of bind, so I don't see how adding another tag will be useful. We don't need to create a new tag for each binary out there. I'm removing them. – Braiam Jun 13 '14 at 12:38

Having checked my own (working) configuration, the only thing I can think is whether the permissions on /etc/bind/zones/some-other-domain.net are correct. If you're running bind as a non-root user, you need to make sure that it has write permission on that file. It may also need write permission on /etc/bind/zones to write its journal file.

Failing that, you could try straceing the bind process to check if anything untoward is happening when the update is attempted.

share|improve this answer
I can confirm this from my side as well. Making /etc/bind group-writable solved this issue for me once before. – Joseph R. Aug 3 '13 at 18:58

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.