Setting the permissions of a *private* key to 0644 sounds like a bad
idea. Maybe you mean 0640?
On Fri, 2 Mar 2018 23:28:28 +
"Prof. Dr. Michael Schefczyk" wrote:
> Dear Mark,
>
> I did get the issue resolved while setting up a test environment.
>
> The issue is that normal permissions in the key-directory are
> root:bind 0644 for the public key and root:bind 0600 for the private
> key. The issue disappears when setting the private key to 0644 also
> and that must be done before starting bind - before using nsupdate is
> not enough.
>
> Do you know if these permissions are standard or a consequence of
> starting DNSSEC via webmin?
>
> Test setup - BIND 9.10.3-P4-Debian stretch:
>
> /etc/bind/named.conf
> include "/etc/bind/named.conf.options";
> include "/etc/bind/named.conf.local";
> include "/etc/bind/named.conf.default-zones";
> include "/etc/bind/named.conf.log";
> key rndc-key {
> algorithm hmac-md5;
> secret "ctHOTtudBPhdKIgaC2baPA==";
> };
> key nsupdate {
> algorithm HMAC-SHA512;
> secret
> "E0tzjpBzrcpGiZwmlqsE86hTzI2UAXNlm/pRNl2blZaze4Edn7vSHWP6
> 14gmwKKXYQPKHwnG83HTWURbqRykMQ=="; }; controls {
> inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys
> { rndc-key; }; };
>
> /etc/bind/named.conf.options
> options {
> directory "/var/cache/bind";
> dnssec-validation auto;
>
> auth-nxdomain no;# conform to RFC1035
> allow-recursion { any; };
> };
>
> /etc/bind/named.conf.local
> zone "testzone.com" {
> type master;
> file "/var/lib/bind/testzone.com.hosts";
> update-policy { grant nsupdate zonesub TXT; };
> key-directory "/var/lib/bind";
> auto-dnssec maintain;
> };
>
> Regards,
>
> Michael Schefczyk
>
> -Ursprüngliche Nachricht-
> Von: Mark Andrews [mailto:ma...@isc.org]
> Gesendet: Montag, 26. Februar 2018 01:57
> An: Prof. Dr. Michael Schefczyk
> Cc: bind-users@lists.isc.org
> Betreff: Re: DNSSEC and nsupdate
>
>
> > On 26 Feb 2018, at 8:12 am, Prof. Dr. Michael Schefczyk
> > wrote:
> >
> > Dear Mark,
> >
> > Thank you very much! No, chroot is not involved. Package
> > debootstrap (required for chroot as far as I understand) is not
> > even installed.
> >
> > It would be great to understand, what the error message:
> >
> > warning: dns_dnssec_findzonekeys2: error reading private key file
> > fqdn/ECDSAP384SHA384/41844: file not found
> >
> > really means. One does specify the key directory. Does the error
> > message imply, that the key directory should have as many levels of
> > subdirectories as the error message contains slashes? In the lowest
> > directory level, how would a key file need to be named. Not the old
> > convention of K[fqdn]+number+keyid.key or .private anymore?
>
> No that hasn’t changed.
>
> error reading private key file fqdn/ECDSAP384SHA384/41844
>
> is short hand for
>
> error reading private key file for ‘fqdn' with algorithm
> ECDSAP384SHA384 and key id 41844.
>
> At this stage I suggest that you post actual config details and
> actual command lines rather than describing what you have done as the
> error will be in the details which we can’t see without them.
>
> > Regards,
> >
> > Michael
> >
> > Technische Universität Dresden
> > Fakultät Wirtschaftswissenschaften
> > Lehrstuhl für Entrepreneurship und Innovation Prof. Dr. Michael
> > Schefczyk
> > D-01062 Dresden
> >
> > Fon: +49-3 51-4 63-3 68 81
> > Fax: +49-3 51-4 63-3 68 83
> > www.gruenderlehrstuhl.de
> >
> >
> >
> >
> > Are you running chrooted? Did you make the keys visible in the
> > chroot area?
> >
> >
> >> On 25 Feb 2018, at 2:37 am, Prof. Dr. Michael Schefczyk
> >> wrote:
> >>
> >> Dear All,
> >>
> >> For a long time already, I am using a bind master DNS server based
> >> on debian set up via webmin. It is currently Debian Stretch with
> >> bind 9.10. I am using DNSSEC.
> >>
> >> The webmin setup leads to all keys being stored in /var/lib/bind.
> >> The naming scheme is K[fqdn]+number+keyid.key or .private. There
> >> is one key-signing key and one zone-signing key for each fqdn.
> >> Resigning works via a perl srcipt / cronjob shipped by webmin.
> >>
> >> To be able to generate future letsencrypt wildcard certificates, I
> >> would like to implant acme challenges as TXT records via DNS.
> >> Using nsupdate, the dnssec signing becomes troublesome. The error
> >> message in update_debug.log is:
> >>
> >> Date/Time info: client IP#36210/key nsupdate: updating zone
> >> 'fqdn/IN': adding an RR at '_acme-challenge.fqdn' TXT "..."
> >> Date/Time error: client IP#36210/key nsupdate: updating zone
> >> 'fqdn/IN': found no active private keys, unable to generate any
> >> signatures Date/Time error: client IP#36210/key nsupdate: updating
> >> zone 'fqdn/IN': RRSIG/NSEC/NSEC3 update failed: not found
> >>
> >> Looking further, bind.log shows:
> >> Date/Time general: warning: dns_dnssec_findzonekeys2: error
>