masters directive in NZF file

[Chuck Musser]

Hi,

We've got a set of slaves running BIND 9.9.9-P5 that have dynamically managed 
zones (via rndc addzone and delzone). The master server's IP was hardcoded into 
the options sent to addzone, resulting in NZF files with lines like so:

zone "foo.com" { type slave; file "foo.com"; masters { 1.2.3.4; }; };

We want to change the master server, so in retrospect, the above doesn't seem 
ideal. Could we define a masters statement in the main named.conf file, then 
reference it in addzone requests? For example:

// In named.conf
masters our-masters { 1.2.3.4; };

// In NZF/addzone requests:
zone "foo.com" { type slave; file "foo.com"; masters { our-masters; }; };

To make the transition, I'd imagine we'd make the changes to the two files, 
then do an "rndc reconfig". Then, when we wanted to change the master, we'd 
just change the "our-master" entry and do "rndc reconfig".

Is all this a valid way to do it?

Thanks,

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

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

[sthaug]

> >> Good morning, I'm trying to make it more difficult for an attacker to
> >> get my DNS server version.
> > 
> > Waste of time.  The attacks are automated, and will be mounted anyway.
> > 
> 
> Indeed. At least one of my legacy servers returns "4.9.4-P1-Would you 
> believe Win98SE?", which was an in-joke at the time but I like it well 
> enough that it is still here 10+ years later.

Irrelevant aside: I have an Apache server which returns

Server: Apache/2.4 (Sintran III)

Don't know Sintran III? https://en.wikipedia.org/wiki/Sintran_III :-)

Steinar Haug, Nethelp consulting, sth...@nethelp.no
___
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

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

[Warren Kumari]

On Wed, Feb 28, 2018 at 12:57 PM, G.W. Haywood via bind-users
 wrote:
> Hi there,
>
> On Wed, 28 Feb 2018, (Ing. Pedro Pablo Delgado Martell) wrote:
>
>> Good morning, I'm trying to make it more difficult for an attacker to
>> get my DNS server version.
>
>
> Waste of time.  The attacks are automated, and will be mounted anyway.

Thank you - this has long been a position that I've held/espoused.

It is easier / cheaper / faster for an attacker to simply assume that
a machine is running vulnerable software and try all exploits on it,
instead of carefully checking to see what services / versions a server
advertises and restricting to those.
Also, if you are *not* running a vulnerable version of , it
doesn't matter if the attacker knocks on the door, and if you *are*
running a vulnerable version, having the attacker not know that
doesn't provide you any protection.

I realize that this sounds somewhat ranty, but I've recently had to
deal with some checklist-style security audits / certifications which
require things like hiding version information (and pointing at the
"firewall") while completely ignoring actual security issues (like
"are the versions known vulnerable", "are the firewalls / ACLS /
whatever sane", "do your users know not to click on
unpaid_invoice.doc", "do you use 2FA", "are all your credential
'Hunter2'" ?)


W


>
> --
>
> 73,
> Ged.
> ___
> 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



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf
___
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

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

[Dave Warren]

On 2018-02-28 10:57, G.W. Haywood via bind-users wrote:

Hi there,

On Wed, 28 Feb 2018, (Ing. Pedro Pablo Delgado Martell) wrote:


Good morning, I'm trying to make it more difficult for an attacker to
get my DNS server version.


Waste of time.  The attacks are automated, and will be mounted anyway.



Indeed. At least one of my legacy servers returns "4.9.4-P1-Would you 
believe Win98SE?", which was an in-joke at the time but I like it well 
enough that it is still here 10+ years later.


I've still seen modern attacks. As you say, the attacks are automated 
and there is no real advantage in checking versions first, it is easier 
to just throw everything at everyone.


___
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

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

[G.W. Haywood via bind-users]

Hi there,

On Wed, 28 Feb 2018, (Ing. Pedro Pablo Delgado Martell) wrote:


Good morning, I'm trying to make it more difficult for an attacker to
get my DNS server version.


Waste of time.  The attacks are automated, and will be mounted anyway.

--

73,
Ged.
___
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

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

[Alan Clegg]

On 2/28/18 10:57 AM, Bob Harold wrote:

> Those instructions assume that the  /etc/bind/named.conf.options file
> is 'included' in the main named.conf file.
> Just add the "version" line to your named.conf file options section.

[...]

> So my config file is at:
> /replicated/jail/named/etc/named.conf

Beware, however of modifying "base" files that were installed by the
package management system.  If you change /etc/named.conf and it gets
overwritten by your next package based upgrade (or the modified file
causes your automated upgrade system to stop upgrading that package),
you will be badly surprised.

(been there, done that, have the scrapes and bruises)



signature.asc
Description: OpenPGP digital signature
___
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

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

[Bob Harold]

On Wed, Feb 28, 2018 at 8:55 AM, Ing. Pedro Pablo Delgado Martell <
ppmart...@eleka.co.cu> wrote:

> Good morning, I'm trying to make it more difficult for an attacker to get
> my DNS server version. I have been following several posts about doing this
> and mostrly all of them suggest to modify the
> */etc/bind/named.conf.options* file and add the lines:
>
> options {
>
> version "Not available"; // Or any bogus info or
> just none without quotes
>
> }
>
> Then restart the service (*service bind9 restart*) and the version will
> not be shown, only the defined text, in this case "Not available". However,
> after doing this and restarting the service I'm still getting my server
> version. Am I placing this lines in the wrong file? Thanks in advance!
>
> 
>
> Bind version:   9.10.2-P3
>
> OS:Debian GNU/Linux 8 (jessie)
>
> Those instructions assume that the  */etc/bind/named.conf.options* file
is 'included' in the main named.conf file.
Just add the "version" line to your named.conf file options section.

If you don't know where your named.conf file is, try this command:
ps -ef | grep named

which should get some result, like maybe:
named 1728 1  0 Feb11 ?01:55:51 /usr/local/sbin/named -t
/replicated/jail/named -u named -n 2 -U 2 -S 16384

If there was a "-c" option, it would tell you the name of the config file.
If not, like this example, the default is "/etc/named.conf".

Note the "-t" option, which says we are doing chroot to
/replicated/jail/named
So my config file is at:
/replicated/jail/named/etc/named.conf

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

RE: Issue running "dig txt rs.dns-oarc.net" on 9.12

[NNEX Support]

Thanks for the information Cathy. I've always run the Red Hat provided packages 
in the past, this is the first time I've ever tried running the newest release 
direct. Mostly I'm just feeling extra cautious since this is something I've 
never done before and admittedly I don't know as much about DNS as I should so 
I really appreciate you taking the time to break down what is happening.

Based on your explanation it sounds like this isn't something I'll ever run 
into other than this one special case so I'll stop worrying about it.

Thank you!

-Nick

-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Cathy 
Almond
Sent: Tuesday, February 27, 2018 4:29 AM
To: bind-users@lists.isc.org
Subject: Re: Issue running "dig txt rs.dns-oarc.net" on 9.12

On 22/02/2018 16:44, NNEX Support wrote:
> I'm sorry to keep replying to myself but I believe I've found the line of 
> code that is causing this issue. Looking at validator.c, in the 
> check_deadlock function, 9.12.0rc1 says:
> 
> ...
> 
> if (parent->event != NULL &&
> parent->event->type == type &&
> dns_name_equal(parent->event->name, name) &&
> 
> ...
> 
> 9.12.0rc3 and above says:
> 
> ...
> 
> if (parent->event != NULL &&
> (parent->event->type == type ||
>  parent->event->type == dns_rdatatype_cname) &&
> dns_name_equal(parent->event->name, name) &&
> 
> ...
> 
> By removing  "parent->event->type == dns_rdatatype_cname)" (and adjusting the 
> rest of the if statement appropriately) the query "dig ns rs.dns-oarc.net" 
> works.
> 
> I see this commit related to this line of code: 
> https://gitlab.isc.org/isc-projects/bind9/commit/2b51d5874c49ac823890b
> 88824290fbf1c18f2cc
> 
> I'm sure this line of code is important, otherwise it wouldn't be there and I 
> don't know enough to be removing random bits of code, so of course I'd never 
> run this in production. Still I want to understand why this is happening and 
> if it’s a bug or me not understanding DNS properly. 

Good sleuthing - though apart from understanding why the query now fails, I 
don't think there's any code defect that needs to be addressed.
 This line of code belongs with these changes between RC1 and RC3.  They are 
kinda important (note the CVE reference):

4859.   [bug]   A loop was possible when attempting to validate
unsigned CNAME responses from secure zones;
this caused a delay in returning SERVFAIL and
also increased the chances of encountering
CVE-2017-3145. [RT #46839]

4858.   [security]  Addresses could be referenced after being freed
in resolver.c, causing an assertion failure.
(CVE-2017-3145) [RT #46839]

The debug log you pointed to was also specific about why the validation
stopped:

validating rs.dns-oarc.net/CNAME: checking existence of DS at 'rs.dns-oarc.net'
validating rs.dns-oarc.net/CNAME: continuing validation would lead to
deadlock: aborting validation
validating rs.dns-oarc.net/CNAME: deadlock found (create_fetch)

The rs.dns-oarc.net zone is broken because it returns a CNAME for queries at 
the apex.

Observe the delegation (I'm querying one of the servers auth for
dns-oarc.net):

; <<>> DiG 9.11.2 <<>> +norec +dnssec @64.191.0.65 rs.dns-oarc.net NS ; (1 
server found) ;; global options: +cmd ;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43571 ;; flags: qr; QUERY: 
1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096 ; COOKIE: 
47d4eddbbbde6fd18616a25b5a952d35767788ad0b03038f (good) ;; QUESTION SECTION:
;rs.dns-oarc.net.   IN  NS

;; AUTHORITY SECTION:
rs.dns-oarc.net.3600IN  NS  ns00.rs.dns-oarc.net.
rs.dns-oarc.net.3600IN  NSECrs4.dns-oarc.net. NS RRSIG NSEC
rs.dns-oarc.net.3600IN  RRSIG   NSEC 8 3 3600 20180328101103
20180226091103 12093 dns-oarc.net.
floDmByYaxmh+QQWou7PtICj4tnpW6/ea1WzatUfAEMvPOSmm54CJ467
KWpnf5XADFgFrcHOr0gYLlbFVJrwEB5n6R+SvXOTx9zwgva3SY37Vgq8
ZMwdNPdGxmVLOz1Ou5tByfZV2ZLpueF+hBB12wft+wNCysjMuwtx4U2D a64=

;; ADDITIONAL SECTION:
ns00.rs.dns-oarc.net.   3600IN  A   64.191.0.133
ns00.rs.dns-oarc.net.   3600IN  2620:ff:c000:0:2::133

Then look at the query response for a DS RRset that the BIND validator is 
receiving from ns00.rs.dns-oarc.net:

; <<>> DiG 9.11.2 <<>> +norec +dnssec @64.191.0.133 rs.dns-oarc.net DS ; (1 
server found) ;; global options: +cmd ;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61119 ;; flags: qr aa; 
QUERY: 1, ANSWER: 1, AUTHORITY: 27, ADDITIONAL: 28

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;rs.dns-oarc.net.   IN  DS

;; ANSWER SECTION:

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

[Ing. Pedro Pablo Delgado Martell]

Good morning, I'm trying to make it more difficult for an attacker to 
get my DNS server version. I have been following several posts about 
doing this and mostrly all of them suggest to modify the 
*/etc/bind/named.conf.options* file and add the lines:


options {

version "Not available";                         // Or any bogus info or 
just none without quotes


}

Then restart the service (*service bind9 restart*) and the version will 
not be shown, only the defined text, in this case "Not available". 
However, after doing this and restarting the service I'm still getting 
my server version. Am I placing this lines in the wrong file? Thanks in 
advance!




Bind version:       9.10.2-P3

OS:                    Debian GNU/Linux 8 (jessie)

___
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