BIND rejecting key to update a zone

[Mark E. Jeftovic]

I'm sure this is something obvious I'm overlooking while I futz around
with setting up an RPZ (9.10.3-P4-Debian)

BIND config has:

key "dns-update" {
        algorithm HMAC-SHA512;
        secret "KEYREDACTED==";
};

and

zone "test.rpz." {
        type master;
        allow-transfer { key "dns-tsig"; };
        allow-update { key "dns-update"; };
        file "/etc/bind/zones/db.test.rpz";
};

Generated my key with:

dnssec-keygen -a HMAC-SHA512 -b 512 -n HOST -r /dev/urandom dns-update

Also, transfers work fine from another host using the dns-tsig key.

But updates are not working:

Whether I invoke nsupdate with:

nsupdate -y hmac-sha512:dns-update:KEYREDACTED==
or

nsupdate -k ./Kdns-update.+165+33140.private

server 127.0.0.1
add some.test.rpz 60 a 1.1.1.1
send

update failed: REFUSED

                                   

and in the logs:

Jun  1 20:19:34 rpz0 named[30999]: client 127.0.0.1#64585/key
dns-update: signer "dns-update" denied
Jun  1 20:19:34 rpz0 named[30999]: client 127.0.0.1#64585/key
dns-update: update 'test.rpz/IN' denied

What am I missing here?  

Thx

- mark
--
Mark E. Jeftovic <***@easydns.com>
Co-founder & CEO, easyDNS Technologies Inc.
[phone] x 225

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

bind-users mailing list
bind-***@lists.isc.org
https://lists.isc.org/m

[Michał Kępień]

Hi Mark,

Post by Mark E. Jeftovic
Jun  1 20:19:34 rpz0 named[30999]: client 127.0.0.1#64585/key
dns-update: signer "dns-update" denied
Jun  1 20:19:34 rpz0 named[30999]: client 127.0.0.1#64585/key
dns-update: update 'test.rpz/IN' denied
What am I missing here?  

Interesting, you do not seem to be missing anything: this works as
expected for me (i.e. the update is allowed) on a fresh Debian 9 VM.

AFAICT without looking at your entire configuration, in order for both
of the log messages you quoted to be generated, named would need to
recognize the key used for signing the request (otherwise you would get
a BADKEY response), but not allow it to update the relevant zone.
Perhaps a long shot, but is there any chance there are non-ASCII
characters in your configuration file, like some Unicode variant of the
hyphen character (‐, ‑, ‒, etc.)? If not, could you please bump the
debug level to at least 3, retry, and paste the log messages generated?
Please also feel free to open an issue at https://gitlab.isc.org.

[Mark E. Jeftovic]

Hi Michal, thanks for the reply and sorry for the delay on my end.

I've started a fresh install here and started over and still having the
same issue, even when I crank the debug trace up to 5, I'm not seeing
anything additional in the logs:

08-Jun-2018 14:56:50.281 update-security: info: client
127.0.0.1#32983/key rpz-update: signer "rpz-update" denied
08-Jun-2018 14:56:50.281 update-security: error: client
127.0.0.1#32983/key rpz-update: update 'test.rpz/IN' denied

I've also tried taking the allow-update out of the zone statement and
moving it back up globally, and trying both (defining it globally and in
the zone) because I remembered bug #46603 (kinda sorta in the ballpark)
- but no dice there either.

- mark

Post by Michał Kępień
Hi Mark,

Post by Mark E. Jeftovic
Jun  1 20:19:34 rpz0 named[30999]: client 127.0.0.1#64585/key
dns-update: signer "dns-update" denied
Jun  1 20:19:34 rpz0 named[30999]: client 127.0.0.1#64585/key
dns-update: update 'test.rpz/IN' denied
What am I missing here?  

Interesting, you do not seem to be missing anything: this works as
expected for me (i.e. the update is allowed) on a fresh Debian 9 VM.
AFAICT without looking at your entire configuration, in order for both
of the log messages you quoted to be generated, named would need to
recognize the key used for signing the request (otherwise you would get
a BADKEY response), but not allow it to update the relevant zone.
Perhaps a long shot, but is there any chance there are non-ASCII
characters in your configuration file, like some Unicode variant of the
hyphen character (‐, ‑, ‒, etc.)? If not, could you please bump the
debug level to at least 3, retry, and paste the log messages generated?
Please also feel free to open an issue at https://gitlab.isc.org.

--
Mark E. Jeftovic <***@easydns.com>
Co-founder & CEO, easyDNS Technologies Inc.
[phone] x 225

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

bind-users mailing list
bind-***@lists.isc.org
https://lists.isc.org/mailman/listi

[Matthew Pounsett]

Post by Mark E. Jeftovic
I've started a fresh install here and started over and still having the
same issue, even when I crank the debug trace up to 5, I'm not seeing
Another long shot... any chance there is an overlapping ACL in the

config? Maybe an overly-restrictive allow-query? Something would need to
be overriding your allow-update in order to get a REFUSED response, I
think.

[Michał Kępień]

Post by Mark E. Jeftovic
Hi Michal, thanks for the reply and sorry for the delay on my end.
I've started a fresh install here and started over and still having the
same issue, even when I crank the debug trace up to 5, I'm not seeing
08-Jun-2018 14:56:50.281 update-security: info: client
127.0.0.1#32983/key rpz-update: signer "rpz-update" denied
08-Jun-2018 14:56:50.281 update-security: error: client
127.0.0.1#32983/key rpz-update: update 'test.rpz/IN' denied

Ah, it seems I did not make myself clear enough, sorry. What I was
really hoping for is to see debug logs for the entire process of
handling the UPDATE query that is being denied, not just the last part
where the denial itself is being reported. These logs would probably
contain interesting bits that could help prove or disprove my Unicode
theory.

In any case, since you got the same, unexpected result after starting
over, this looks like a potential bug, but I am afraid I really need to
take a look at your full configuration to make any headway here,
otherwise this will mostly be an exercise in tasseography as it seems to
work as expected for me. Tracking this further as a GitLab issue makes
most sense to me. I assume that the configuration you are using is not
deployed in production, but if you nevertheless have any confidentiality
concerns, you can use "named-checkconf -px" to conceal your key secrets
and/or mark the GitLab issue as confidential. Also feel free to contact
me off-list if that suits you best.

Thanks,