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
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
>
>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________
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
