AW: DNSSEC and nsupdate
Prof. Dr. Michael Schefczyk
michael at schefczyk.net
Sat Mar 3 08:32:52 UTC 2018
Thank you! Setting the .private files to 0640 does work as well and is certainly more secure.
-----Ursprüngliche Nachricht-----
Von: bind-users [mailto:bind-users-bounces at lists.isc.org] Im Auftrag von Paul Kosinski
Gesendet: Samstag, 3. März 2018 00:57
An: bind-users at lists.isc.org
Betreff: Re: DNSSEC and nsupdate
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" <michael at 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:marka at isc.org]
> Gesendet: Montag, 26. Februar 2018 01:57
> An: Prof. Dr. Michael Schefczyk <michael at schefczyk.net>
> Cc: bind-users at lists.isc.org
> Betreff: Re: DNSSEC and nsupdate
>
>
> > On 26 Feb 2018, at 8:12 am, Prof. Dr. Michael Schefczyk
> > <michael at 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
> >> <michael at 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 at lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
More information about the bind-users
mailing list