I have a Bind9 hidden primary configured with views, and I need a secondary to transfer all the views of the same zone. Example: On **primary**: view "dmz-view" { match-clients { server-dmz; }; allow-transfer { transfer-dmz; }; recursion yes; allow-query-cache { server-dmz; }; zone "example.com" IN { type master; file "/var/cache/bind/db.dmz.example.com"; notify yes; }; }; view "untrust-view" { allow-query { any; }; allow-transfer { transfer-untrust; }; recursion no; zone "example.com" IN { type master; file "/var/cache/bind/db.untrust.example.com"; notify yes; }; }; Now, my problem is that if I put the secondary's IP in both acls (transfer-dmz and transfer-untrust), it will match the first view and will transfer only that. I've read examples 3,4 in https://kb.isc.org/docs/aa-00851 but it doesn't seem to fit my needs (or am I misunderstanding?) I also read https://flylib.com/books/en/2.684.1/setting_up_a_slave_name_server_for_a_zone_in_multiple_views.html but since it's aged I suppose it's outdated . Any cookbook or advice?

I have a local DNS server running on my Linux router. I have it configured to only allow requests from my LAN (192.168.1.0/24). I also want the server to be able to query itself for DNS. To that end I did allow 127.0.0.1 as a source as well. The problem is that every query the box makes to itself has its source IP set to my external IP. I confirmed this with tcpdump; when the server queries itself at 127.0.0.1, a packet arrives on interface lo with the destination IP 127.0.0.1 but the source IP is that of my ISP. Using dig -b does not help. The same exact effect occurs. This means that unless I explicitly add the IP of my ISP to the allowed IPs, DNS lookup will not work locally. Since my IP can be dynamic, this actually means adding an entire range of IPs to the DNS server. This is obviously not a problem on machines on my LAN as they are setting their source IPs properly. The problem is specific to local queries on the server to itself. I want to be able to tell the server to use an explicit source IP address (not just a source interface necessarily) to make queries to itself. Can this be done?

I use BIND as my DNS server at home. For my Start Of Authority (SOA record) I always use a serial in the recommended format > YYYYMMDD## where ## is the counter for changes on that day. Unfortunately I changed the serial and added 1 more digit by mistake. After updating the name-daemon, I couldn't revert this anymore. Is there a possible way to reset the serial / counter inside BIND's internal libraries?

This is on a Debian 12.10 lxc machine. I'm trying to get bind9/named to listen on a second localhost IP: /etc/bind/named.conf.options: options { listen-on port 53 { 127.0.0.1; 192.168.18.2; }; listen-on port 5353 { 127.0.0.2; }; [...] } I've also tried listen-on port 53 { 127.0.0.1; 127.0.0.2; 192.168.18.2; }; but it's not working (yes, I restarted named after making this configuration change): $ sudo netstat -tunapl4 Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 2126/named tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 2126/named tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 339/master tcp 0 0 127.0.0.1:953 0.0.0.0:* LISTEN 2126/named tcp 0 0 127.0.0.1:953 0.0.0.0:* LISTEN 2126/named tcp 0 0 192.168.18.2:53 0.0.0.0:* LISTEN 2126/named tcp 0 0 192.168.18.2:53 0.0.0.0:* LISTEN 2126/named udp 0 0 192.168.18.2:53 0.0.0.0:* 2126/named udp 0 0 192.168.18.2:53 0.0.0.0:* 2126/named udp 0 0 127.0.0.1:53 0.0.0.0:* 2126/named udp 0 0 127.0.0.1:53 0.0.0.0:* 2126/named What am I missing, and why are most of my sockets showing up twice? Edit: I forgot to mention - there's nothing in my logs about this.

On various, mostly security and privacy related reasons, I would be more happy if my caching-only bind9 would only use TCP to make outward connections. Of course, it should be able to accept and handle UDP queries. How can I do that?

I cannot *for the life of me* work out **why** BIND9 is refusing queries. I have followed so many tutorials and watched so many configuration setup videos, both using Webmin and in the CLI, following them to the letter, but my BIND9 simply will not answer queries. BIND9 is installed on a debian VM on Proxmox. - I can ping the server - I can SSH to the server - I can access Webmin and configure everything in there - named-checkzone returns OK - neither iptables nor ufw are installed - the Proxmox Firewall is disabled at the Datacenter, Host and VM levels - the server can reach the internet - nslookup and dig both fail on the DNS server itself using nslookup example.com 127.0.0.1 and dig @127.0.0.1 example.com

admin@vm-server:~$ nslookup example.com localhost
Server:         localhost
Address:        ::1#53

** server can't find example.com: REFUSED

admin@vm-server:~$ dig @127.0.0.1 example.com

; > DiG 9.18.28-1~deb12u2-Debian > @127.0.0.1 example.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER";
        };
controls {
        inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys { rndc-key; };
        };
logging {
        };

**/etc/bind/named.conf.options**:

options {
	directory "/var/cache/bind";

	dnssec-validation auto;

	listen-on-v6 { any; };
	listen-on port 53 {
		127.0.0.1;
    	127.0.1.1;
		10.0.0.2;
		};
	allow-query {
		localhost;
    	ACL_RFC1918;
		};
	multiple-cnames yes;
};

**/etc/bind/named.conf.local**:

zone "example.com" {
	type master;
	file "/var/lib/bind/example.com.hosts";
	};

**/etc/bind/named.conf.default-zones**:

zone "." {
	type hint;
	file "/usr/share/dns/root.hints";
};

zone "localhost" {
	type master;
	file "/etc/bind/db.local";
};

zone "127.in-addr.arpa" {
	type master;
	file "/etc/bind/db.127";
};

zone "0.in-addr.arpa" {
	type master;
	file "/etc/bind/db.0";
};

zone "255.in-addr.arpa" {
	type master;
	file "/etc/bind/db.255";
};

**/var/lib/bind/example.com.hosts**:

$ttl 3600
example.com.	IN	SOA	vm-server. admin.example.com. (
			2025042448
			3600
			600
			1209600
			3600 )
example.com.	IN	NS	vm-server.example.com.
vm-server.example.com.	IN	A	10.0.0.2
dns.example.com.	IN	CNAME	vm-server

**/etc/bind/rndc.conf**:

key "rndc-key" {
	algorithm hmac-sha256;
	secret "";
};

options {
	default-key "rndc-key";
	default-server 127.0.0.1;
	default-port 953;
};

**/etc/bind/rndc.key**:

key "rndc-key" {
	algorithm hmac-sha256;
	secret "";
};

The named process is giving this kind of error the whole day: Jun 17 12:50:43 s named: socket.c:5274: unexpected error: Jun 17 12:50:43 s named: connect(198.41.0.4#53) 22/Invalid argument What is this error? Named (BIND 9.8.4-rpz2+rl005.12-P1) runs on Debian GNU/Linux squeeze/sid x32. From machine I can telnet to this address (a.root-servers.net.), also I can resolve IP address to name with nslookup

I am implementing a custom DNS server, but when I try using it, it clashes with port 53 being in use.  Changing resolved.config file doesn't help.  My resolved.conf file looks like this: [Resolve] DNS=127.0.0.1 #FallbackDNS= #Domains= #LLMNR=no #MulticastDNS=no #DNSSEC=no My /etc/resolv.conf file looks like this: nameserver 127.0.0.1 nameserver 192.168.1.1 search lan1 Port 53 is still used to resolve DNS... $ sudo lsof -i :53 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE systemd-r 636 systemd-resolve 12u IPv4 22828 0t0 UDP 127.0.0.53:domain systemd-r 636 systemd-resolve 13u IPv4 22829 0t0 TCP 127.0.0.53:domain (LISTEN) When I run the custom DNS Server, I get an error, File "/usr/lib/python3.8/socketserver.py", line 466, in server_bind self.socket.bind(self.server_address) OSError: [Errno 98] Address already in use I would greatly appreciate any advice.

I want to restart the named service but I got error : [root@KAASH-HIS-1 named]# service named restart Redirecting to /bin/systemctl restart named.service Job for named.service failed because the control process exited with error code. See "systemctl status named.service" and "journalctl -xe" for details. then I run the command systemctl status named.service to check the status of named service but its failed also : [root@KAASH-HIS-1 named]# systemctl status named.service ● named.service - Berkeley Internet Name Domain (DNS) Loaded: loaded (/usr/lib/systemd/system/named.service; disabled; vendor preset: disabled) Active: failed (Result: exit-code) since Fri 2023-02-17 02:11:18 +03; 13s ago Process: 10560 ExecStartPre=/bin/bash -c if [ ! "$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/sbin/named-checkconf -z "$NAMEDCONF"; else echo "Checking of zone files is disabled"; fi (code=exited, status=1/FAILURE) Feb 17 02:11:18 KAASH-HIS-1 systemd: Starting Berkeley Internet Name Domain (DNS)... Feb 17 02:11:18 KAASH-HIS-1 bash: /etc/named.conf:62: missing ';' before '}' Feb 17 02:11:18 KAASH-HIS-1 systemd: named.service: control process exited, code=exited status=1 Feb 17 02:11:18 KAASH-HIS-1 systemd: Failed to start Berkeley Internet Name Domain (DNS). Feb 17 02:11:18 KAASH-HIS-1 systemd: Unit named.service entered failed state. Feb 17 02:11:18 KAASH-HIS-1 systemd: named.service failed. [root@KAASH-HIS-1 named]# this is /etc/named.conf file [root@KAASH-HIS-1 named]# cat /etc/named.conf // // named.conf // // Provided by Red Hat bind package to configure the ISC BIND named(8) DNS // server as a caching only nameserver (as a localhost DNS resolver only). // // See /usr/share/doc/bind*/sample/ for example named configuration files. // // See the BIND Administrator's Reference Manual (ARM) for details about the // configuration located in /usr/share/doc/bind-{version}/Bv9ARM.html options { listen-on port 53 { 127.0.0.1;10.93.200.34; }; listen-on-v6 port 53 { ::1; }; directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt"; memstatistics-file "/var/named/data/named_mem_stats.txt"; recursing-file "/var/named/data/named.recursing"; secroots-file "/var/named/data/named.secroots"; allow-query { localhost; }; /* - If you are building an AUTHORITATIVE DNS server, do NOT enable recursion. - If you are building a RECURSIVE (caching) DNS server, you need to enable recursion. - If your recursive DNS server has a public IP address, you MUST enable access control to limit queries to your legitimate users. Failing to do so will cause your server to become part of large scale DNS amplification attacks. Implementing BCP38 within your network would greatly reduce such attack surface */ recursion yes; dnssec-enable yes; dnssec-validation yes; /* Path to ISC DLV key */ bindkeys-file "/etc/named.root.key"; managed-keys-directory "/var/named/dynamic"; pid-file "/run/named/named.pid"; session-keyfile "/run/named/session.key"; }; logging { channel default_debug { file "data/named.run"; severity dynamic; }; }; zone "." IN { type hint; file "named.ca"; }; zone "kaash.local" IN { type master; file "forward.kaash.local"; allow-update {none;}; }; zone "200.93.10.in-addr.arpa" IN { type master; file "reverse.kaash.local"; allow-update {none; }; }; include "/etc/named.rfc1912.zones"; include "/etc/named.root.key"; this is forward.kaash.local zone file : [root@KAASH-HIS-1 named]# cat forward.kaash.local $TTL 1D @ IN SOA kaash-his-1.kaash.local. root.kaash.local. ( 2014051001 ; serial 3600 ; refresh 1800 ; retry 604800 ; expire 86400 ; minimum ) @ IN NS kaash-his-2.kaash.local. @ IN PTR kaash.local. kaash-his-1 IN A 10.93.200.34 KAASH-HIS-2 IN A 10.93.200.37 kaash-scan IN A 10.93.200.81 kaash-scan IN A 10.93.200.82 kaash-scan IN A 10.93.200.83 34 IN PTR kaash-his-1.kaash.local 39 IN PTR kaash-his-2.kaash.local 81 IN PTR kaash-scan.kaash.local 82 IN PTR kaash-scan.kaash.local 83 IN PTR kaash-scan.kaash.local this is reverse file zone : [root@KAASH-HIS-1 named]# cat reverse.kaash.local $TTL 1D @ IN SOA kaash-his-1.kaash.local. root.kaash.local. ( 2014051001 ; serial 3600 ; refresh 1800 ; retry 604800 ; expire 86400 ; minimum ) @ IN NS kaash-his-2.kaash.local. @ IN PTR kaash.local. kaash-his-1 IN A 10.93.200.34 KAASH-HIS-2 IN A 10.93.200.37 kaash-scan IN A 10.93.200.81 kaash-scan IN A 10.93.200.82 kaash-scan IN A 10.93.200.83 34 IN PTR kaash-his-1.kaash.local 39 IN PTR kaash-his-2.kaash.local 81 IN PTR kaash-scan.kaash.local 82 IN PTR kaash-scan.kaash.local 83 IN PTR kaash-scan.kaash.local How to solve this error Failed to start Berkeley Internet Name Domain (DNS) and restart named.service ? UPDATE: I added the ; and another error show now : [root@KAASH-HIS-1 named]# systemctl status named.service ● named.service - Berkeley Internet Name Domain (DNS) Loaded: loaded (/usr/lib/systemd/system/named.service; disabled; vendor preset: disabled) Active: failed (Result: exit-code) since Fri 2023-02-17 09:14:20 +03; 16s ago Process: 37422 ExecStartPre=/bin/bash -c if [ ! "$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/sbin/named-checkconf -z "$NAMEDCONF"; else echo "Checking of zone files is disabled"; fi (code=exited, status=1/FAILURE) Feb 17 09:14:20 KAASH-HIS-1 bash: _default/kaash.local/IN: no owner Feb 17 09:14:20 KAASH-HIS-1 bash: zone localhost.localdomain/IN: loaded serial 0 Feb 17 09:14:20 KAASH-HIS-1 bash: zone localhost/IN: loaded serial 0 Feb 17 09:14:20 KAASH-HIS-1 bash: zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: loaded serial 0 Feb 17 09:14:20 KAASH-HIS-1 bash: zone 1.0.0.127.in-addr.arpa/IN: loaded serial 0 Feb 17 09:14:20 KAASH-HIS-1 bash: zone 0.in-addr.arpa/IN: loaded serial 0 Feb 17 09:14:20 KAASH-HIS-1 systemd: named.service: control process exited, code=exited status=1 Feb 17 09:14:20 KAASH-HIS-1 systemd: Failed to start Berkeley Internet Name Domain (DNS). Feb 17 09:14:20 KAASH-HIS-1 systemd: Unit named.service entered failed state. Feb 17 09:14:20 KAASH-HIS-1 systemd: named.service failed.

I have bind9 running for local LAN DNS. I also have an APT caching server. So, I set up an RPZ file to poison certain domain names and have them resolve to my internal caching server instead. Running e.g. apt update is returning resolution errors _I think_ because the caching server is unable to resolve the true (external) records and fetch the data. I think this means I’d have to set up a view for the caching server as a /32. So the question is, can I set it up so that my caching server hitting domains in the poisoned zone just get forwarded, while the rest of the network gets the poisoned data? I’m just not sure how to go about doing that.

I'm using Fedora 36 as my everyday desktop machine and I try to do something that I though was fairly simple but I can't find another person on the net providing a proper configuration for this. Basically, everything is in the title: I want to find the proper systemd-resolved configuration to use my local Bind server as a DNS (nothing complex so far), *but also* fallback on any DHCP-provided DNS. What I tried so far is to force NetworkManager to provide my local Bind instance in the DHCP-provided DNS in the first place with the following configuration:

# /etc/dhcp/dhclient.conf
prepend domain-name-servers 127.0.0.1;
require subnet-mask, domain-name-servers;

# /etc/NetworkManager/conf.d/dhcp-client.conf
[main]
dhcp=dhclient

But that doesn't work. systemd-resolved still queries DHCP-provided DNS prior to my local Bind server. I found a systemd-resolved configuration that queries my local Bind server:

# /etc/systemd/resolved.conf
DNS=127.0.0.1 ::1
Domains=~.

But I'm unsure that it falls back to DHCP-provided DNS.

I‘m just in the process of rebuilding a system which includes BIND and Webmin. Zone files for BIND are on an external disk, which worked fine on the previous setup. After installing the server from scratch, I went into webmin and edited /etc/bind/named.conf.default-zones, adding the entries for the zone files as they were on the old setup, then restarted BIND. If I query one of these zones (using nslookup and first setting server 127.0.0.1), I can resolve names in these zones. However, Webmin tells me there are no DNS zones defined for this name server. Restarting BIND through Webmin, reloading Webmin modules and even restarting the server does not work. It seems to be just Webmin that is having issues, as querying the zone works. How do I get these zone files to show up in Webmin?

Yesterday I play with old bind on old unix vm (1998, Interactive Unix 4.1.1) dig www.google.it return this dig +noedns www.google.it @192.168.0.15 ; > DiG 9.18.30 > +noedns www.google.it @192.168.0.15 ;; global options: +cmd ;; Got answer: ;; ->>HEADER> DiG 9.18.30 > +noedns www.google.it @192.168.0.4 ;; global options: +cmd ;; Got answer: ;; ->>HEADER> DiG 9.18.30 > www.google.it @192.168.0.4 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35264 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 3ef6be6f29a5772001000000672a11a41858b37880b6f84b (good) ;; QUESTION SECTION: ;www.google.it. IN A ;; ANSWER SECTION: www.google.it. 4m32s IN A 142.251.209.35 ;; Query time: 3 msec ;; SERVER: 192.168.0.4#53(192.168.0.4) (UDP) ;; WHEN: Tue Nov 05 13:37:56 CET 2024 ;; MSG SIZE rcvd: 86 Why old bind return more results?

This should be a rather simple question, but all my googlefu has failed me so far. I have an nfs server with a share mounted to my local machine in dir /share/ (rw,sync,no_subtree_check) from there I want to mount bind a folder within /share/userdata to my user user directory /home/user/nfs I am able to mount /share/ just fine, however when running this command

sudo mount --bind /share/userdata /home/user/nfs

I am returned the error:

mount: /home/user/nfs: bind /share/userdata failed.

No further details are given and I can't make heads or tails of this error. Does anyone have any clue what is going on or if this is even possible?

There is a working DNS server in Windows Server 2016.
I installed and configured slave DNS server in Oracle Linux 7.
In windows server, I enabled BIND secondaries, and to Listen all ip addresses. In Oracle Linux I have these configurations: named.conf options { listen-on port 53 { any; }; listen-on-v6 port 53 { ::1; }; directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt"; memstatistics-file "/var/named/data/named_mem_stats.txt"; allow-query { any; }; allow-transfer { any; }; recursion yes; dnssec-enable yes; dnssec-validation yes; /* Path to ISC DLV key */ bindkeys-file "/etc/named.iscdlv.key"; managed-keys-directory "/var/named/dynamic"; pid-file "/run/named/named.pid"; session-keyfile "/run/named/session.key"; }; logging { channel default_debug { file "data/named.run"; severity dynamic; }; }; zone "." IN { type hint; file "named.ca"; }; zone "example.local" IN { type slave; masters { 10.1.10.2; }; allow-transfer { any; }; allow-query { any; }; file "slaves/example.local"; allow-update { any; }; }; zone "0.0.10.in-addr.arpa" IN { type slave; masters { 10.1.10.2; }; allow-query { any; }; allow-transfer { any; }; file "slaves/example.local"; allow-update { any; }; }; include "/etc/named.rfc1912.zones"; include "/etc/named.root.key"; IP address of Windows DNS server: 10.1.10.2
IP address of Linux slave DNS server: 10.1.10.217
Hostname of Windows DNS server: dc.example.local
Hostname of Linux slave DNS server: dc2.example.local I have not manually created zone files in Linux server. As I read, it takes zone files from Windows.
But it does not take zone files.
What may be the reason?
PC: nslookup dc2.example.local does not return answer.

I'm finding quite a few of these types of messages in my postfix log: 17:40:55 smtpd: warning: 34.77.82.185.b.barracudacentral.org: RBL lookup error: Host or domain name not found. Name service error for name=34.77.82.185.b.barracudacentral.org type=A: Host not found, try again 17:41:05 smtpd: warning: 34.77.82.185.hostkarma.junkemailfilter.com: RBL lookup error: Host or domain name not found. Name service error for name=34.77.82.185.hostkarma.junkemailfilter.com type=A: Host not found, try again 18:15:02 smtpd: warning: ptmail1.patrontechnology.com.dbl.spamhaus.org: RBL lookup error: Host or domain name not found. Name service error for name=ptmail1.patrontechnology.com.dbl.spamhaus.org type=A: Host not found, try again 18:40:27 smtpd: warning: 177.141.213.134.zen.spamhaus.org: RBL lookup error: Host or domain name not found. Name service error for name=177.141.213.134.zen.spamhaus.org type=A: Host not found, try again I am trying to understand if there is something wrong with my configuration or if these messages are (as I have read non-authoritatively elsewhere) merely a slightly weird way of indicating that the sender is not black-listed by the given service. Certainly some (maybe all) of the emails which generate these messages are genuine and are indeed forwarded correctly and successfully by postfix. These are the relevant lines of my smtp_recipient_restrictions: reject_rbl_client zen.spamhaus.org reject_rbl_client b.barracudacentral.org reject_rbl_client hostkarma.junkemailfilter.com=127.0.0.2 reject_rhsbl_helo dbl.spamhaus.org reject_rhsbl_sender dbl.spamhaus.org reject_rhsbl_reverse_client dbl.spamhaus.org

Is it possible to perform Split-horizon with DNSMasq? I've googled and it seems like it is only possible with Bind9, any advice would be much appericated

After upgrading a CentOS 7 server to AlmaLinux 9, and BIND along with it, I receive a new error message without changing (bind/named) configuration files: systemctl status named × named.service - Berkeley Internet Name Domain (DNS) Loaded: loaded (/usr/lib/systemd/system/named.service; enabled; preset: disabled) Active: failed (Result: exit-code) since Mon 2024-07-29 17:21:47 UTC; 19min ago Process: 948 ExecStartPre=/bin/bash -c if [ ! "$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/sbin/named-checkconf -z "$NAMEDCONF"; else echo "Checking of zone files is disabled"; fi (code=exited, status=0/SUCCESS) Process: 949 ExecStart=/usr/sbin/named -u named -c ${NAMEDCONF} $OPTIONS (code=exited, status=1/FAILURE) CPU: 33ms Jul 29 17:21:47 ns42.example.org named: directory '/var/named' is not writable Jul 29 17:21:47 ns42.example.org named: /etc/named.conf:22: parsing failed: permission denied Jul 29 17:21:47 ns42.example.org loading configuration: permission denied Jul 29 17:21:47 ns42.example.org exiting (due to fatal error) Why would (this newer version of) named need to write its zone files? This is a non-recursive secondary/backup name server and this instance of BIND/named is not to change zones. So I suppose the question could be: **How can I tell BIND not to try to write into its zone directory and not to complain about not being able to?** Bind version is bind-9.16.23-18.el9_4.1.x86_64 EDIT: Out of curiosity I temporarily made the folder writable by the named group and started the service. This is what it wrote: -rw-r--r--. 1 named named 1045 Jul 29 17:51 /var/named/localhost_resolver.mkeys.jnl -rw-r--r--. 1 named named 1045 Jul 29 17:51 /var/named/external.mkeys.jnl -rw-r--r--. 1 named named 1045 Jul 29 17:51 /var/named/internal.mkeys.jnl -rw-r--r--. 1 named named 821 Jul 29 17:52 /var/named/internal.mkeys -rw-r--r--. 1 named named 821 Jul 29 17:52 /var/named/external.mkeys -rw-r--r--. 1 named named 821 Jul 29 17:52 /var/named/localhost_resolver.mkeys So, these are some type of journal files. **How can disable writing these journal entries as the zones are read-only anyway?**

I'm working on setting up DNS and DHCP on my homelab network using BIND9 and Kea, and I'm having trouble getting my zone files to update consistently. My setup is BIND 9.18.26 and Kea 2.4.1 on the same FreeBSD 14.0 server; clients are an assortment of FreeBSD, Debian-based, Android and a couple of commercial IoT devices, with a mixture of static, reserved and dynamic addresses. Kea (so far as I can tell) is handing out all addresses, including the reserved addresses, correctly, but is not passing addresses to BIND, and since I have no idea what I'm doing, I appeal to those who do. My configuration is as follows:

// named.conf
include "/usr/local/etc/namedb/tsig.key";
include "/usr/local/etc/namedb/named.conf.options";
include "/usr/local/etc/namedb/named.conf.local";
include "/usr/local/etc/namedb/named.conf.default-zones";

acl internal-net {
        localhost;
        192.168.0.0/24;
};

server ::/0 {
        bogus yes;
};

// named.conf.options

options {
        // All file and path names are relative to the chroot directory,
        // if any, and should be fully qualified.
        directory       "/usr/local/etc/namedb/working";
        pid-file        "/var/run/named/pid";
        dump-file       "/var/dump/named_dump.db";
        statistics-file "/var/stats/named.stats";

        allow-query { internal-net; };
        allow-query-cache { internal-net; };
        allow-recursion { internal-net; };
        allow-transfer { none; };

        check-names master ignore;
        check-names slave ignore;
        check-names response ignore;

        forwarders {
                149.112.121.20;
                149.112.122.20;
        };
};

// named.conf.local
//
// Local configuration goes here
//

zone "voncorax.internal" {
        type            master;
        file            "/var/lib/named/voncorax.internal.hosts";
        allow-update    { key tsig-key; };
};

zone "0.168.192.in-addr.arpa" {
        type            master;
        file            "/var/lib/named/0.168.192.rev";
        allow-update    { key tsig-key; };
};

tsig.key:

key "tsig-key" {
        algorithm hmac-sha256;
        secret "Shh! It's a secret!";
};

kea-dhcp4.conf:

{
        "Dhcp4": {
                "valid-lifetime": 300,
                "interfaces-config": {
                        "interfaces": [ "em0" ]
                },
                "lease-database": {
                        "type": "memfile",
                        "persist": true,
                        "name": "/var/lib/kea/dhcp4.leases"
                },
                "subnet4": [
                        {
                                "id": 1,
                                "subnet": "192.168.0.0/24",
                                "pools": [
                                        {
                                                "pool": "192.168.0.100-192.168.0.254"
                                        }
                                ],
                                "option-data": [
                                        {
                                                "name": "routers",
                                                "data": "192.168.0.1"
                                        }
                                ],
                                "reservations": [
                                        {
                                                "hw-address": "dc:a6:32:12:2f:d2",
                                                "hostname": "dnsbox.voncorax.internal",
                                                "ip-address": "192.168.0.2"
                                        },
                                        {
                                                "hw-address": "b8:ca:3a:7d:69:ad",
                                                "hostname": "prometheus.voncorax.internal",
                                                "ip-address": "192.168.0.98"
                                        }
                                ]
                        }
                ],
                "option-data": [
                        {
                                "name": "domain-name-servers",
                                "data": "192.168.0.97, 192.168.0.2"
                        }
                ],
                "loggers": [
                        {
                                "name": "kea-dhcp4",
                                "output_options": [
                                        {
                                                "output": "/var/log/kea-dhcp4.log"
                                        }
                                ],
                                "severity": "INFO",
                                "debuglevel": 1
                        }
                ],
                "ddns-send-updates": true,
                "ddns-qualifying-suffix": "voncorax.internal",
                "ddns-override-no-update": true,
                "ddns-override-client-update": true,
                "dhcp-ddns": {
                        "enable-updates": true,
                        "server-ip": "127.0.0.1"
                }
        }
}

kea-dhcp-ddns.conf:

{
        "DhcpDdns":
        {
                "ip-address": "127.0.0.1",
                "port": 53001,
                "control-socket": {
                "socket-type": "unix",
                "socket-name": "/tmp/kea-ddns-ctrl-socket"
        },
        "tsig-keys": [
                {
                        "name": "tsig-key",
                        "algorithm": "hmac-sha256",
                        "secret": "Shh! It's a secret!"
                }
        ],
        "forward-ddns" : {
                "ddns-domains": [
                        {
                                "name": "voncorax.internal.",
                                "key-name": "tsig-key",
                                "dns-servers": [
                                        {
                                                "ip-address": "192.168.0.97"
                                        }
                                ]
                        }
                ]
        },
        "reverse-ddns" : {
                "ddns-domains": [
                        {
                                "name": "0.168.192.in-addr.arpa.",
                                "key-name": "tsig-key",
                                "dns-servers": [
                                        {
                                                "ip-address": "192.168.0.97"
                                        }
                                ]
                        }
                ]
        },

        "loggers": [
                {
                        "name": "kea-dhcp-ddns",
                        "output_options": [
                                {
                                        "output": "/var/log/kea-ddns.log"

                                }
                        ],
                        "severity": "INFO",
                        "debuglevel": 1
                        }
                ]
        }
}

I'm basing my work on Lee Hutchinson's Ars Technica article Doing DNS and DHCP for your LAN the old way—the way that works along with my reading of the BIND 9 and Kea documentation. Can anyone see what I'm doing wrong? EDIT: Here is the log output from kea-ddns:

2024-05-28 12:02:48.657 DEBUG [kea-dhcp-ddns.dhcpddns/10658.0xf2290c12000] DHCP_DDNS_CONFIGURE configuration update received: { "control-socket": { "socket-name": "/tmp/kea-ddns-ctrl-socket", "socket-type": "unix" }, "forward-ddns": { "ddns-domains": [ { "dns-servers": [ { "ip-address": "192.168.0.97" } ], "key-name": "tsig-key", "name": "voncorax.internal." } ] }, "ip-address": "127.0.0.1", "loggers": [ { "debuglevel": 10, "name": "kea-dhcp-ddns", "output_options": [ { "output": "/var/log/kea-ddns.log" } ], "severity": "INFO" } ], "port": 53001, "reverse-ddns": { "ddns-domains": [ { "dns-servers": [ { "ip-address": "192.168.0.97" } ], "key-name": "tsig-key", "name": "0.168.192.in-addr.arpa." } ] }, "tsig-keys": [ { "algorithm": "hmac-sha256", "name": "tsig-key", "secret": "*****" } ] }
2024-05-28 12:02:48.657 DEBUG [kea-dhcp-ddns.dctl/10658.0xf2290c12000] DCTL_CONFIG_START parsing new configuration: { "control-socket": { "socket-name": "/tmp/kea-ddns-ctrl-socket", "socket-type": "unix" }, "forward-ddns": { "ddns-domains": [ { "dns-servers": [ { "ip-address": "192.168.0.97" } ], "key-name": "tsig-key", "name": "voncorax.internal." } ] }, "ip-address": "127.0.0.1", "loggers": [ { "debuglevel": 10, "name": "kea-dhcp-ddns", "output_options": [ { "output": "/var/log/kea-ddns.log" } ], "severity": "INFO" } ], "port": 53001, "reverse-ddns": { "ddns-domains": [ { "dns-servers": [ { "ip-address": "192.168.0.97" } ], "key-name": "tsig-key", "name": "0.168.192.in-addr.arpa." } ] }, "tsig-keys": [ { "algorithm": "hmac-sha256", "name": "tsig-key", "secret": "*****" } ] }
2024-05-28 12:02:48.659 INFO  [kea-dhcp-ddns.commands/10658.0xf2290c12000] COMMAND_ACCEPTOR_START Starting to accept connections via unix domain socket bound to /tmp/kea-ddns-ctrl-socket
2024-05-28 12:02:48.660 INFO  [kea-dhcp-ddns.dctl/10658.0xf2290c12000] DCTL_CONFIG_COMPLETE server has completed configuration: listening on 127.0.0.1, port 53001, using UDP
2024-05-28 12:02:48.660 DEBUG [kea-dhcp-ddns.dctl/10658.0xf2290c12000] DCTL_RUN_PROCESS DhcpDdns starting application event loop
2024-05-28 12:02:48.660 INFO  [kea-dhcp-ddns.dhcpddns/10658.0xf2290c12000] DHCP_DDNS_STARTED Kea DHCP-DDNS server version 2.4.1 started
2024-05-28 12:02:48.660 DEBUG [kea-dhcp-ddns.commands/10658.0xf2290c12000] COMMAND_REGISTERED Command build-report registered
2024-05-28 12:02:48.660 DEBUG [kea-dhcp-ddns.commands/10658.0xf2290c12000] COMMAND_REGISTERED Command config-get registered
2024-05-28 12:02:48.660 DEBUG [kea-dhcp-ddns.commands/10658.0xf2290c12000] COMMAND_REGISTERED Command config-hash-get registered
2024-05-28 12:02:48.660 DEBUG [kea-dhcp-ddns.commands/10658.0xf2290c12000] COMMAND_REGISTERED Command config-reload registered
2024-05-28 12:02:48.660 DEBUG [kea-dhcp-ddns.commands/10658.0xf2290c12000] COMMAND_REGISTERED Command config-set registered
2024-05-28 12:02:48.660 DEBUG [kea-dhcp-ddns.commands/10658.0xf2290c12000] COMMAND_REGISTERED Command config-test registered
2024-05-28 12:02:48.660 DEBUG [kea-dhcp-ddns.commands/10658.0xf2290c12000] COMMAND_REGISTERED Command config-write registered
2024-05-28 12:02:48.660 DEBUG [kea-dhcp-ddns.commands/10658.0xf2290c12000] COMMAND_REGISTERED Command shutdown registered
2024-05-28 12:02:48.660 DEBUG [kea-dhcp-ddns.commands/10658.0xf2290c12000] COMMAND_REGISTERED Command status-get registered
2024-05-28 12:02:48.660 DEBUG [kea-dhcp-ddns.commands/10658.0xf2290c12000] COMMAND_REGISTERED Command version-get registered
2024-05-28 12:02:48.660 DEBUG [kea-dhcp-ddns.commands/10658.0xf2290c12000] COMMAND_REGISTERED Command statistic-get registered
2024-05-28 12:02:48.660 DEBUG [kea-dhcp-ddns.commands/10658.0xf2290c12000] COMMAND_REGISTERED Command statistic-get-all registered
2024-05-28 12:02:48.660 DEBUG [kea-dhcp-ddns.commands/10658.0xf2290c12000] COMMAND_REGISTERED Command statistic-reset registered
2024-05-28 12:02:48.660 DEBUG [kea-dhcp-ddns.commands/10658.0xf2290c12000] COMMAND_REGISTERED Command statistic-reset-all registered
2024-05-28 12:02:48.660 DEBUG [kea-dhcp-ddns.dhcpddns/10658.0xf2290c12000] DHCP_DDNS_QUEUE_MGR_RECONFIGURING application is reconfiguring the queue manager
2024-05-28 12:02:48.660 DEBUG [kea-dhcp-ddns.dhcpddns/10658.0xf2290c12000] DHCP_DDNS_QUEUE_MGR_STARTED application's queue manager has begun listening for requests.

This isn't an excerpt; that is literally the entirety of what's been logged since I restarted the daemon several days ago. I won't post the entire log from kea-dhcp4 because it's huge, but it appears that dhcp4 is doing its thing correctly, just not talking to d2. The following is an excerpt from kea-dhcp4.log which appears (to my inexperienced eye) to be all of a piece:

2024-05-28 17:25:55.169 DEBUG [kea-dhcp4.packets/11509.0x1a25f9c12000] DHCP4_BUFFER_RECEIVED received buffer from 192.168.0.98:68 to 192.168.0.97:67 over interface em0
2024-05-28 17:25:55.169 DEBUG [kea-dhcp4.options/11509.0x1a25f9c15f00] DHCP4_BUFFER_UNPACK parsing buffer received from 192.168.0.98 to 192.168.0.97 over interface em0
2024-05-28 17:25:55.169 DEBUG [kea-dhcp4.packets/11509.0x1a25f9c15f00] DHCP4_PACKET_RECEIVED [hwtype=1 b8:ca:3a:7d:69:ad], cid=[01:b8:ca:3a:7d:69:ad], tid=0xd3f53501: DHCPREQUEST (type 3) received from 192.168.0.98 to 192.168.0.97 on interface em0
2024-05-28 17:25:55.169 DEBUG [kea-dhcp4.packets/11509.0x1a25f9c15f00] DHCP4_QUERY_DATA [hwtype=1 b8:ca:3a:7d:69:ad], cid=[01:b8:ca:3a:7d:69:ad], tid=0xd3f53501, packet details: local_address=192.168.0.97:67, remote_address=192.168.0.98:68, msg_type=DHCPREQUEST (3), transid=0xd3f53501,
options:
  type=012, len=010: "prometheus" (string)
  type=053, len=001: 3 (uint8)
  type=055, len=010: 1(uint8) 28(uint8) 2(uint8) 121(uint8) 3(uint8) 15(uint8) 6(uint8) 12(uint8) 119(uint8) 26(uint8)
  type=061, len=007: 01:b8:ca:3a:7d:69:ad
2024-05-28 17:25:55.169 DEBUG [kea-dhcp4.dhcpsrv/11509.0x1a25f9c15f00] DHCPSRV_SUBNET4_SELECT_NO_RAI_OPTIONS No RAI options found to use for subnet selection.
2024-05-28 17:25:55.169 DEBUG [kea-dhcp4.dhcpsrv/11509.0x1a25f9c15f00] DHCPSRV_SUBNET4_SELECT_NO_RELAY_ADDRESS Relay address (giaddr) in client packet is empty.
2024-05-28 17:25:55.169 DEBUG [kea-dhcp4.dhcpsrv/11509.0x1a25f9c15f00] DHCPSRV_CFGMGR_SUBNET4_ADDR selected subnet 192.168.0.0/24 for packet received by matching address 192.168.0.98
2024-05-28 17:25:55.169 DEBUG [kea-dhcp4.packets/11509.0x1a25f9c15f00] DHCP4_SUBNET_SELECTED [hwtype=1 b8:ca:3a:7d:69:ad], cid=[01:b8:ca:3a:7d:69:ad], tid=0xd3f53501: the subnet with ID 1 was selected for client assignments
2024-05-28 17:25:55.169 DEBUG [kea-dhcp4.packets/11509.0x1a25f9c15f00] DHCP4_SUBNET_DATA [hwtype=1 b8:ca:3a:7d:69:ad], cid=[01:b8:ca:3a:7d:69:ad], tid=0xd3f53501: the selected subnet details: 192.168.0.0/24
2024-05-28 17:25:55.169 DEBUG [kea-dhcp4.hosts/11509.0x1a25f9c15f00] HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER get one host with IPv4 reservation for subnet id 1, identified by hwaddr=B8CA3A7D69AD
2024-05-28 17:25:55.169 DEBUG [kea-dhcp4.hosts/11509.0x1a25f9c15f00] HOSTS_CFG_GET_ALL_IDENTIFIER get all hosts with reservations using identifier: hwaddr=B8CA3A7D69AD
2024-05-28 17:25:55.169 DEBUG [kea-dhcp4.hosts/11509.0x1a25f9c15f00] HOSTS_CFG_GET_ALL_IDENTIFIER_HOST using identifier: hwaddr=B8CA3A7D69AD, found host: hwaddr=B8CA3A7D69AD ipv4_subnet_id=1 hostname=prometheus.voncorax.internal ipv4_reservation=192.168.0.98 siaddr=(no) sname=(empty) file=(empty) key=(empty) ipv6_reservations=(none)
2024-05-28 17:25:55.169 DEBUG [kea-dhcp4.hosts/11509.0x1a25f9c15f00] HOSTS_CFG_GET_ALL_IDENTIFIER_COUNT using identifier hwaddr=B8CA3A7D69AD, found 1 host(s)
2024-05-28 17:25:55.169 DEBUG [kea-dhcp4.hosts/11509.0x1a25f9c15f00] HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER_HOST using subnet id 1 and identifier hwaddr=B8CA3A7D69AD, found host: hwaddr=B8CA3A7D69AD ipv4_subnet_id=1 hostname=prometheus.voncorax.internal ipv4_reservation=192.168.0.98 siaddr=(no) sname=(empty) file=(empty) key=(empty) ipv6_reservations=(none)
2024-05-28 17:25:55.169 DEBUG [kea-dhcp4.dhcp4/11509.0x1a25f9c15f00] DHCP4_CLASS_ASSIGNED [hwtype=1 b8:ca:3a:7d:69:ad], cid=[01:b8:ca:3a:7d:69:ad], tid=0xd3f53501: client packet has been assigned to the following class(es): KNOWN
2024-05-28 17:25:55.169 DEBUG [kea-dhcp4.dhcp4/11509.0x1a25f9c15f00] DHCP4_CLASS_ASSIGNED [hwtype=1 b8:ca:3a:7d:69:ad], cid=[01:b8:ca:3a:7d:69:ad], tid=0xd3f53501: client packet has been assigned to the following class(es): ALL, KNOWN
2024-05-28 17:25:55.170 DEBUG [kea-dhcp4.ddns/11509.0x1a25f9c15f00] DHCP4_CLIENT_HOSTNAME_PROCESS [hwtype=1 b8:ca:3a:7d:69:ad], cid=[01:b8:ca:3a:7d:69:ad], tid=0xd3f53501: processing client's Hostname option
2024-05-28 17:25:55.170 DEBUG [kea-dhcp4.ddns/11509.0x1a25f9c15f00] DHCP4_CLIENT_HOSTNAME_DATA [hwtype=1 b8:ca:3a:7d:69:ad], cid=[01:b8:ca:3a:7d:69:ad], tid=0xd3f53501: client sent Hostname option: prometheus
2024-05-28 17:25:55.170 DEBUG [kea-dhcp4.ddns/11509.0x1a25f9c15f00] DHCP4_RESERVED_HOSTNAME_ASSIGNED [hwtype=1 b8:ca:3a:7d:69:ad], cid=[01:b8:ca:3a:7d:69:ad], tid=0xd3f53501: server assigned reserved hostname prometheus.voncorax.internal
2024-05-28 17:25:55.170 DEBUG [kea-dhcp4.dhcpsrv/11509.0x1a25f9c15f00] DHCPSRV_MEMFILE_GET_CLIENTID obtaining IPv4 leases for client ID 01:b8:ca:3a:7d:69:ad
2024-05-28 17:25:55.170 DEBUG [kea-dhcp4.hosts/11509.0x1a25f9c15f00] HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4 get one host with reservation for subnet id 1 and IPv4 address 192.168.0.98
2024-05-28 17:25:55.170 DEBUG [kea-dhcp4.hosts/11509.0x1a25f9c15f00] HOSTS_CFG_GET_ALL_ADDRESS4 get all hosts with reservations for IPv4 address 192.168.0.98
2024-05-28 17:25:55.170 DEBUG [kea-dhcp4.hosts/11509.0x1a25f9c15f00] HOSTS_CFG_GET_ALL_ADDRESS4_HOST using address 192.168.0.98 found host: hwaddr=B8CA3A7D69AD ipv4_subnet_id=1 hostname=prometheus.voncorax.internal ipv4_reservation=192.168.0.98 siaddr=(no) sname=(empty) file=(empty) key=(empty) ipv6_reservations=(none)
2024-05-28 17:25:55.170 DEBUG [kea-dhcp4.hosts/11509.0x1a25f9c15f00] HOSTS_CFG_GET_ALL_ADDRESS4_COUNT using address 192.168.0.98, found 1 host(s)
2024-05-28 17:25:55.170 DEBUG [kea-dhcp4.hosts/11509.0x1a25f9c15f00] HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4_HOST using subnet id 1 and address 192.168.0.98, found host: hwaddr=B8CA3A7D69AD ipv4_subnet_id=1 hostname=prometheus.voncorax.internal ipv4_reservation=192.168.0.98 siaddr=(no) sname=(empty) file=(empty) key=(empty) ipv6_reservations=(none)
2024-05-28 17:25:55.170 DEBUG [kea-dhcp4.dhcpsrv/11509.0x1a25f9c15f00] DHCPSRV_MEMFILE_GET_ADDR4 obtaining IPv4 lease for address 192.168.0.98
2024-05-28 17:25:55.170 DEBUG [kea-dhcp4.alloc-engine/11509.0x1a25f9c15f00] ALLOC_ENGINE_V4_REQUEST_EXTEND_LEASE [hwtype=1 b8:ca:3a:7d:69:ad], cid=[01:b8:ca:3a:7d:69:ad], tid=0xd3f53501: extending lifetime of the lease for address 192.168.0.98
2024-05-28 17:25:55.170 DEBUG [kea-dhcp4.dhcpsrv/11509.0x1a25f9c15f00] DHCPSRV_MEMFILE_UPDATE_ADDR4 updating IPv4 lease for address 192.168.0.98
2024-05-28 17:25:55.170 INFO  [kea-dhcp4.leases/11509.0x1a25f9c15f00] DHCP4_LEASE_ALLOC [hwtype=1 b8:ca:3a:7d:69:ad], cid=[01:b8:ca:3a:7d:69:ad], tid=0xd3f53501: lease 192.168.0.98 has been allocated for 300 seconds
2024-05-28 17:25:55.170 DEBUG [kea-dhcp4.options/11509.0x1a25f9c15f00] DHCP4_PACKET_PACK [hwtype=1 b8:ca:3a:7d:69:ad], cid=[01:b8:ca:3a:7d:69:ad], tid=0xd3f53501: preparing on-wire format of the packet to be sent
2024-05-28 17:25:55.170 DEBUG [kea-dhcp4.packets/11509.0x1a25f9c15f00] DHCP4_PACKET_SEND [hwtype=1 b8:ca:3a:7d:69:ad], cid=[01:b8:ca:3a:7d:69:ad], tid=0xd3f53501: trying to send packet DHCPACK (type 5) from 192.168.0.97:67 to 192.168.0.98:68 on interface em0
2024-05-28 17:25:55.170 DEBUG [kea-dhcp4.packets/11509.0x1a25f9c15f00] DHCP4_RESPONSE_DATA [hwtype=1 b8:ca:3a:7d:69:ad], cid=[01:b8:ca:3a:7d:69:ad], tid=0xd3f53501: responding with packet DHCPACK (type 5), packet details: local_address=192.168.0.97:67, remote_address=192.168.0.98:68, msg_type=DHCPACK (5), transid=0xd3f53501,
options:
  type=001, len=004: 4294967040 (uint32)
  type=003, len=004: 192.168.0.1
  type=006, len=008: 192.168.0.97 192.168.0.2
  type=012, len=028: "prometheus.voncorax.internal" (string)
  type=051, len=004: 300 (uint32)
  type=053, len=001: 5 (uint8)
  type=054, len=004: 192.168.0.97
  type=061, len=007: 01:b8:ca:3a:7d:69:ad

EDIT: I've hacked around with Wireshark a bit (from a Server Fault post ) and it appears that kea-dhcp4 is not sending anything to kea-ddns over the lo0 interface. Can anyone suggest why not, or how I can figure out why not?

I have a DNSSEC bind server. Everything works just fine - except one little issue: Why there is no automatic ZSK rollover happening? I thought the bind will generate and install new ZSK keys every 180 days. Are my expectations incorrect or are there problems with my config? I did not found any hints in the logs. How can I debug it? I'm currently running version 9.18.24: The policy in /etc/named.conf: dnssec-policy "my_policy" { keys { ksk key-directory lifetime unlimited algorithm ecdsa256; zsk key-directory lifetime P180D algorithm ecdsa256; }; nsec3param iterations 0 optout no salt-length 0; parent-ds-ttl PT1H; }; and the output of rndc dnssec -status ..... (Why is *"No rollover scheduled"*?) key: 51503 (ECDSAP256SHA256), ZSK published: yes - since Fri Dec 9 12:11:44 2022 zone signing: yes - since Fri Dec 9 12:11:44 2022 No rollover scheduled - goal: omnipresent - dnskey: omnipresent - zone rrsig: omnipresent --- Update: I could not find a way to make an automatic rollover after the configured 180 days. So I did a manual rollover: rndc dnssec -rollover -key ... and the newly generated key has the next rollover scheduled. Hopefully that solved the problem. Maybe the policy is controlling the key only during its creation and later policy changes do not affect existing keys.