RE: "Hiding" version.bind in /etc/bind/named.conf.options doesn't work

[Bob McDonald]

Personally, I leave the version statement alone. I like having my
"internal" servers return the current running version when queried. I
disable chaos queries on my internet facing servers via views thus
effectively not answering any queries for the version or hostname  from
folks I don't know. I agree that today's attackers really don't care, they
just try to exploit everything known.

The other thing I do is code server-id=hostname; on my "internal" servers
and server-id=; on my internet facing servers. This
returns the actual hostname for "internal" servers when queried for the
chaos hostname.bind or id.server or  when repomding to a +nsid request. It
will not return an answer for chaos queries on the internet facing servers
(because of the previously mentioned view restriction) while the response
to a +nsid request will be a meaningful name. This is especially handy on
the "inside" for HA clusters and anycast cloud member servers as it returns
the actual server name the response came from. For internet facing queries
it will simply return the meaningful name you specified when responding to
a +nsid request. Depending on the name chosen, this can be useful for
troubleshooting. Choose wisely.

YMMV,

Bob
___
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

AW: DNSSEC and nsupdate

[Prof. Dr. Michael Schefczyk]

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-boun...@lists.isc.org] Im Auftrag von Paul 
Kosinski
Gesendet: Samstag, 3. März 2018 00:57
An: bind-users@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 +
"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':