error reading private key file, ddns_update update failed not found

Ryan McGuire rmcguire at libretechconsulting.com
Mon Apr 2 13:38:04 UTC 2018


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
On Sat, 2018-03-31 at 18:25 -0400, rmcguire at libretechconsulting.com
wrote:
> 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 <w8hdkim at gmail.com>
> Sent: Friday, March 30, 2018 06:32 PM
> To: bind-users at lists.isc.org
> Subject: Re: error reading private key file, ddns_update update
> failed not found
> 
> On Fri, March 30, 2018 4:57 pm, Ryan McGuire wrote:
> 
> > 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
> 
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20180402/c811fea9/attachment.html>


More information about the bind-users mailing list