error reading private key file, ddns_update update failed not found

[Ryan McGuire]

Good Afternoon,

I have a newly configured bind9 server with two dynamic zones that I
cannot seem to get working. I've ensured I have a key-directory
configured and I've confirmed that the keys exist and are readable by
bind but I'm unable to resolve the issue. The zones themselves work
fine, but dynamic updates are failing. If it's relevant, bind is
running inside an LXD container.

Logs:

Mar 29 15:50:39 bind named[99]: client 192.168.0.3#2093/key
ddns_update: signer "ddns_update" approved
Mar 29 15:50:39 bind named[99]: client 192.168.0.3#2093/key
ddns_update: updating zone 'mcguire.local/IN': adding an RR at 'am335x-
opt.mcguire.local' A 192.168.0.165
Mar 29 15:50:39 bind named[99]: client 192.168.0.3#2093/key
ddns_update: updating zone 'mcguire.local/IN': adding an RR at 'am335x-
opt.mcguire.local' TXT "3154a902d1b045a4064274c0d6b5
Mar 29 15:50:39 bind named[99]: dns_dnssec_findzonekeys2: error reading
private key file mcguire.local/RSASHA256/43356: file not found
Mar 29 15:50:39 bind named[99]: dns_dnssec_findzonekeys2: error reading
private key file mcguire.local/RSASHA256/43345: file not found
Mar 29 15:50:39 bind named[99]: client 192.168.0.3#2093/key
ddns_update: updating zone 'mcguire.local/IN': found no active private
keys, unable to generate any signatures
Mar 29 15:50:39 bind named[99]: client 192.168.0.3#2093/key
ddns_update: updating zone 'mcguire.local/IN': RRSIG/NSEC/NSEC3 update
failed: not found

Zone config:

zone "0.168.192.in-addr.arpa" IN {
  type master;
  file "/etc/bind/zones/db.0.168.192.in-addr.arpa.signed";
  auto-dnssec maintain;
  key-directory "/etc/bind/keys";
  inline-signing yes;
  allow-update { key DDNS_UPDATE; };
};
zone "mcguire.local" IN {
  type master;
  file "/etc/bind/zones/db.mcguire.local.signed";
  auto-dnssec maintain;
  key-directory "/etc/bind/keys";
  inline-signing yes;
  allow-update { key DDNS_UPDATE; };
};

Key directory and relevant keys:

File: /etc/bind/keys/
[...]
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid:
(  112/    bind)

-rw-r--r-- 1 bind bind  627 Mar 28 12:11 K0.168.192.in-
addr.arpa.+008+04239.key
-rw-r----- 1 bind bind 1776 Mar 28 12:11 K0.168.192.in-
addr.arpa.+008+04239.private
-rw-r--r-- 1 bind bind  972 Mar 28 12:12 K0.168.192.in-
addr.arpa.+008+05959.key
-rw-r----- 1 bind bind 3316 Mar 28 12:12 K0.168.192.in-
addr.arpa.+008+05959.private
-rw-r--r-- 1 bind bind  955 Mar 28 12:11 Kmcguire.local.+008+43345.key
-rw-r----- 1 bind bind 3316 Mar 28 12:11
Kmcguire.local.+008+43345.private
-rw-r--r-- 1 bind bind  610 Mar 28 12:11 Kmcguire.local.+008+43356.key
-rw-r----- 1 bind bind 1776 Mar 28 12:11
Kmcguire.local.+008+43356.private

Any ideas?

Regards,

-Ryan

[Kim Culhan]

Mar 29 15:50:39 bind named[99]: dns_dnssec_findzonekeys2: error > reading

private key file mcguire.local/RSASHA256/43356: file not > > found

Mar 29 15:50:39 bind named[99]: dns_dnssec_findzonekeys2: error > reading

private key file mcguire.local/RSASHA256/43345: file not >found

Recent experience has been that the 'key file not found' problem an result
from
replacing the key files in the key directory.

When the zone is signed, bind retains the key files which existed at that
time
by including them in the signed zone files.

There may be a better way to fix this, but I found it necessary to re-sign
the zone
after removing the existing signed zones files:

As in: rm domain.zone.* then resign the zone.

In the process of Googling for a solution to this problem for days I found
only one
more 'sophisticated' approach to this problem.

This is probably not the best way to do this, but it gets the server up and
running
again in a few minutes.

Maybe someone will followup to this 'solution' with the correct way and it
may be
you didn't make the mistake I did and re-generate the keys.

thanks
-kim

[r***@libretechconsulting.com]

Hi Kim,

Thank you for your email. I'll give this a shot. I did run dns-signzone on both zones again but I didn't remove the signed zones first.

Regards,

-Ryan

-------- Original Message --------
From: Kim Culhan <***@gmail.com>
Sent: Friday, March 30, 2018 06:32 PM
To: bind-***@lists.isc.org
Subject: Re: error reading private key file, ddns_update update failed not found

Post by Kim Culhan

Mar 29 15:50:39 bind named[99]: dns_dnssec_findzonekeys2: error > reading

private key file mcguire.local/RSASHA256/43356: file not > > found

Mar 29 15:50:39 bind named[99]: dns_dnssec_findzonekeys2: error > reading

private key file mcguire.local/RSASHA256/43345: file not >found
Recent experience has been that the 'key file not found' problem an result
from
replacing the key files in the key directory.
When the zone is signed, bind retains the key files which existed at that
time
by including them in the signed zone files.
There may be a better way to fix this, but I found it necessary to re-sign
the zone
As in: rm domain.zone.* then resign the zone.
In the process of Googling for a solution to this problem for days I found
only one
more 'sophisticated' approach to this problem.
This is probably not the best way to do this, but it gets the server up and
running
again in a few minutes.
Maybe someone will followup to this 'solution' with the correct way and it
may be
you didn't make the mistake I did and re-generate the keys.
thanks
-kim
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users

[Ryan McGuire]

Good Morning,
No surprise I'm sure, but this was user error. I had enabled inline
signing but was manually running dns-signzone as I always had.
Admittedly I didn't understand how inline signing worked, but this KB
article made it obvious: https://kb.isc.org/article/AA-00626/0/Inline-S
igning-in-ISC-BIND-9.9.0-Examples.html. Updates are working perfectly
now. 
I'm not sure if there is a way to implement a log message if inline
signing is enabled for a zone but a manually signed zone file is
referenced or present, but it would be very helpful should someone
stuck [very far] in the past like I was run into this scenario. There
is no end to the outdated and inaccurate blogs and tutorials for bind
that can cause this to happen.
Regards,
-Ryan

Post by r***@libretechconsulting.com
Hi Kim,
Thank you for your email. I'll give this a shot. I did run dns-
signzone on both zones again but I didn't remove the signed zones
first.
Regards,
-Ryan
-------- Original Message --------
Sent: Friday, March 30, 2018 06:32 PM
Subject: Re: error reading private key file, ddns_update update failed not found

Mar 29 15:50:39 bind named[99]: dns_dnssec_findzonekeys2: error >

reading private key file mcguire.local/RSASHA256/43356: file not > >
found

Mar 29 15:50:39 bind named[99]: dns_dnssec_findzonekeys2: error >

reading private key file mcguire.local/RSASHA256/43345: file not

found

Recent experience has been that the 'key file not found' problem an
result from
replacing the key files in the key directory.
When the zone is signed, bind retains the key files which existed at
that time
by including them in the signed zone files.
There may be a better way to fix this, but I found it necessary to
re-sign the zone
As in:  rm domain.zone.* then resign the zone.
In the process of Googling for a solution to this problem for days I
found only one
more 'sophisticated' approach to this problem.
This is probably not the best way to do this, but it gets the server
up and running
again in a few minutes.
Maybe someone will followup to this 'solution' with the correct way
and it may be
you didn't make the mistake I did and re-generate the keys.
thanks
-kim
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users

[Tony Finch]

If it's relevant, bind is running inside an LXD container.

Did you run the diagnostic commands inside the container or in a normal
host shell?

Tony.
--
f.anthony.n.finch <***@dotat.at> http://dotat.at/
Rockall: East 4 or 5, increasing 6 or 7, perhaps gale 8 later. Slight or
moderate, becoming moderate or rough, becoming very rough later in far
southwest. Showers. Good.
_______________________________________________
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/listinfo/bind-users

[r***@libretechconsulting.com]

Hi Tony,

From within the container.

Regards,

-Ryan



-------- Original Message --------
From: Tony Finch <***@dotat.at>
Sent: Saturday, March 31, 2018 06:17 PM
To: ***@libretechconsulting.com
Subject: Re: error reading private key file, ddns_update update failed not found

Post by Tony Finch

If it's relevant, bind is running inside an LXD container.

Did you run the diagnostic commands inside the container or in a normal
host shell?
Tony.
--
Rockall: East 4 or 5, increasing 6 or 7, perhaps gale 8 later. Slight or
moderate, becoming moderate or rough, becoming very rough later in far
southwest. Showers. Good.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users

[Tony Finch]

Post by r***@libretechconsulting.com
From within the container.

Is named chrooting itself inside the container? :-)

(Is the networking setup for LXD less of a disaster area than for Docker?
https://www.percona.com/blog/2016/08/03/testing-docker-multi-host-network-performance/
https://www.percona.com/blog/2016/02/05/measuring-docker-cpu-network-overhead/
Not DNS benchmarks but I bet they have paid more attention to TCP
performance than UDP...)

Tony.
--
f.anthony.n.finch <***@dotat.at> http://dotat.at/
Fisher, German Bight: East backing northwest, 4 or 5. Slight, occasionally
moderate for a time. Occasional sleet. Good, occasionally poor.
_______________________________________________
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/listinfo/bind-users