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 +0000 "Prof. Dr. Michael Schefczyk" <mich...@schefczyk.net> 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 <mich...@schefczyk.net> > Cc: bind-users@lists.isc.org > Betreff: Re: DNSSEC and nsupdate > > > > On 26 Feb 2018, at 8:12 am, Prof. Dr. Michael Schefczyk > > <mich...@schefczyk.net> 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 > >> <mich...@schefczyk.net> 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 > >> reading private key file fqdn/ECDSAP384SHA384/41844: file not > >> found Date/Time general: warning: dns_dnssec_findzonekeys2: error > >> reading private key file fqdn/ECDSAP384SHA384/55203: file not found > >> > >> The numbers 41844 and 55203 are the very key IDs for which keys do > >> exist in the traditional K... format /var/lib/bind. Of > >> course, /var/lib/bind is also set as the key directory. The keys > >> are certainly readable without permissions problems. The error > >> does not go away even if you make them 777. > >> > >> Please inform me what the issue is and what to do. Is there a > >> change in the key naming scheme? How would the new names look > >> like? I can certainly create one directory per fqdn > >> under /var/lib/bind/ and then one subdirectory ECDSAP384SHA384 but > >> what would be the (two?) files in 41844 and 55203? Is there a way > >> to convert? > >> > >> Thank you very much for your efforts! > >> > >> Michael Schefczyk _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users