Re: Whitelisting sites using RPZ

[Blason R]

Oh thats great...in that case general practice would be always whitelist
the zones first then blacklist?

On Thu, Apr 26, 2018 at 11:53 AM, Daniel Stirnimann <
daniel.stirnim...@switch.ch> wrote:

> > response-policy { zone "malware.trap"; zone "whitelist.allow"  policy
> > passthru; };
>
> ...
>
> > So which one will take precendence in this case?
>
> Policy processing will search the zone files in the order in which they
> appear in the response-policy statement.
>
> So, you need to change the order in your example to achieve the desired
> result.
>
> Daniel
> ___
> 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
>
___
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: Whitelisting sites using RPZ

[Daniel Stirnimann]

On 26.04.18 09:46, Blason R wrote:
> Oh thats great...in that case general practice would be always whitelist
> the zones first then blacklist?

I'm using:

whitelist with "policy passthru log no"
test zones with "policy passthru"
blacklists with "policy cname LANDINGPAGE"

Note, "[ log yes_or_no ]" has been added in BIND 9.12.

Daniel
___
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: Whitelisting sites using RPZ

[Blason R]

9.12 is not yet stable; i believe?

On Thu, Apr 26, 2018 at 1:23 PM, Daniel Stirnimann <
daniel.stirnim...@switch.ch> wrote:

> On 26.04.18 09:46, Blason R wrote:
> > Oh thats great...in that case general practice would be always whitelist
> > the zones first then blacklist?
>
> I'm using:
>
> whitelist with "policy passthru log no"
> test zones with "policy passthru"
> blacklists with "policy cname LANDINGPAGE"
>
> Note, "[ log yes_or_no ]" has been added in BIND 9.12.
>
> Daniel
>
___
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: Whitelisting sites using RPZ

[Daniel Stirnimann]

On 26.04.18 10:10, Blason R wrote:
> 9.12 is not yet stable; i believe?

9.12 is stable. 9.13 is current development. 9.11 is the current
Extended Support Version (ESV).

You may want to read this:
https://www.isc.org/blogs/bind-release-strategy-updated/
https://kb.isc.org/article/AA-01540

Daniel
___
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: Whitelisting sites using RPZ

[Daniel Stirnimann]

> Note, "[ log yes_or_no ]" has been added in BIND 9.12.

Sorry, this has been added in BIND 9.11 already.

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

Release Strategy Clarification

[Matthew Pounsett]

This is a question for ISC about the new BIND release plan which I thought
might be a useful clarification for others as well.

I didn't notice this when the new plan was first presented in March, but
the key text in the legend of the Example Release Plan[0] for the red
blocks is "a release that is no longer supported."  This implies that 9.12
will go from being the most recent supported stable version of BIND to
unsupported literally overnight.  It doesn't appear there is a period where
9.12 and 9.14 are both supported, as 9.12 approaches end of life.

Is this an oversight, where the legend text needs updating to "a release
that is approaching end of life," or do we really all have to plan to do
our upgrades on January 1st every year?

Thanks,
   Matt


[0]: 
___
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

problems changing NS records

[Lucio Crusca]

Until a few hours ago, I had several domains and 3 nameservers for them:

ns1.virtualbit.it (master, 136.243.232.142)
ns11.virtualbit.it (slave, 158.69.210.19)
ns2.virtualbit.it (slave, 136.243.232.143)

Then I tried to migrate to a new master, names.virtualbit.it (46.4.38.130).
Here is the migration steps I followed:

1) I configured Bind on the new server as master for all domains
2) I added the master IP address to the two slaves with:

masters vbitdnsmasters { 136.243.232.142; 46.4.38.130; };

zone "acquaritalia.it" {
type slave;
masters { vbitdnsmasters; };
file "/var/lib/bind/acquaritalia.it.db";
};

and so on for all other zones.

3) I updated the NS records in the zone files, and in the control panel of
the domain registrar

Now all the domains have problems. IntoDNS reports:

"
Nameservers A recordsERROR: Some of your DNS servers do not have A
records at all. I could not find any A records for the following DNS
servers:
ns2.virtualbit.it

You must have A records for all of your nameservers.
"

However:

dig @136.243.232.143 -t ns acquaritalia.it
dig @136.243.232.143 acquaritalia.it
dig @136.243.232.143 www.acquaritalia.it
dig @136.243.232.143 -t mx acquaritalia.it

all work as expected. Meanwhile, the same queries against 8.8.8.8 sometime
work, sometime reply SERVFAIL.

I don't know what I did wrong. Please help.
___
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: problems changing NS records

[Alberto Colosi]

have you changed zone registration?

there is DNS FQDN reference


if you change dns fqdn you have to update zone on your NIC


as it on NIC it or where you registered the domain





From: bind-users  on behalf of Lucio Crusca 

Sent: Thursday, April 26, 2018 3:18 PM
To: bind-users@lists.isc.org
Subject: problems changing NS records

Until a few hours ago, I had several domains and 3 nameservers for them:

ns1.virtualbit.it (master, 136.243.232.142)
ns11.virtualbit.it (slave, 158.69.210.19)
ns2.virtualbit.it (slave, 136.243.232.143)

Then I tried to migrate to a new master, 
names.virtualbit.it (46.4.38.130). Here is the 
migration steps I followed:

1) I configured Bind on the new server as master for all domains
2) I added the master IP address to the two slaves with:

masters vbitdnsmasters { 136.243.232.142; 46.4.38.130; };

zone "acquaritalia.it" {
type slave;
masters { vbitdnsmasters; };
file "/var/lib/bind/acquaritalia.it.db";
};

and so on for all other zones.

3) I updated the NS records in the zone files, and in the control panel of the 
domain registrar

Now all the domains have problems. IntoDNS reports:

"
Nameservers A recordsERROR: Some of your DNS servers do not have A records 
at all. I could not find any A records for the following DNS servers:
ns2.virtualbit.it

You must have A records for all of your nameservers.
"

However:

dig @136.243.232.143 -t ns 
acquaritalia.it
dig @136.243.232.143 
acquaritalia.it
dig @136.243.232.143 
www.acquaritalia.it
dig @136.243.232.143 -t mx 
acquaritalia.it

all work as expected. Meanwhile, the same queries against 8.8.8.8 sometime 
work, sometime reply SERVFAIL.

I don't know what I did wrong. Please help.

___
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: problems changing NS records

[Tony Finch]

Lucio Crusca  wrote:

> Until a few hours ago, I had several domains and 3 nameservers for them:
>
> ns1.virtualbit.it (master, 136.243.232.142)
> ns11.virtualbit.it (slave, 158.69.210.19)
> ns2.virtualbit.it (slave, 136.243.232.143)

Oh dear, this is a bit of a rabbit hole.

I can't resolve any of those names you listed, so let's try to find out
why...

$ dig +noall +authority ns virtualbit.it @dns.nic.it.
virtualbit.it.  10800   IN  NS  names.sulweb.org.
virtualbit.it.  10800   IN  NS  ns2.sulweb.org.
virtualbit.it.  10800   IN  NS  ns11.sulweb.org.

$ dig +noall +authority ns sulweb.org. @a0.org.afilias-nst.info.
sulweb.org. 86400   IN  NS  dns2.seflow.net.
sulweb.org. 86400   IN  NS  dns3.seflow.net.
sulweb.org. 86400   IN  NS  dns1.seflow.net.

$ dig +noall +answer dns1.seflow.net. dns2.seflow.net. dns3.seflow.net.
dns1.seflow.net.14314   IN  A   94.198.98.168
dns2.seflow.net.14330   IN  A   193.70.56.6
dns3.seflow.net.14365   IN  A   144.217.99.49

$ dig +short dns1.seflow.net. dns2.seflow.net. dns3.seflow.net. |
  while read a; do dig ns sulweb.org @$a; done | grep status:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 14143
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 41727
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 19805

OK, so seflow.net is no longer hosting sulweb.org, which means domains
like virtualbit.it that depend on sulweb.org are offline.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
reject all prejudice and discrimination based upon race, colour,
religion, age, disability, gender, or sexual orientation
___
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: problems changing NS records

[Iván García]

Hi. I think the problem is this:

*dig NS +noadditional +noquestion +nocomments +nocmd +nostats +trace
virtualbit.it. @208.67.222.222*

.   518400  IN  NS
   a.root-servers.net..
518400  IN  NS
   b.root-servers.net..
518400  IN  NS
   c.root-servers.net..
518400  IN  NS
   d.root-servers.net..
518400  IN  NS
   e.root-servers.net..
518400  IN  NS
   f.root-servers.net..
518400  IN  NS
   g.root-servers.net..
518400  IN  NS
   h.root-servers.net..
518400  IN  NS
   i.root-servers.net..
518400  IN  NS
   j.root-servers.net..
518400  IN  NS
   k.root-servers.net..
518400  IN  NS
   l.root-servers.net..
518400  IN  NS
   m.root-servers.net.
;; Received 228 bytes from 208.67.222.222#53(208.67.222.222) in 4 ms
it. 172800  IN  NS
   nameserver.cnr.it.it.   
172800  IN  NS
   s.dns.it.it.172800  
IN  NS
   dns.nic.it.it.  172800  
IN  NS
   a.dns.it.it.172800  
IN  NS
   r.dns.it.it.172800  
IN  NS
   m.dns.it.
;; Received 414 bytes from 192.112.36.4#53(192.112.36.4) in 19 ms
virtualbit.it.  10800   IN  NS
   ns11.sulweb.org.virtualbit.it.  
10800   IN  NS
   names.sulweb.org.virtualbit.it. 
10800   IN  NS
   ns2.sulweb.org.
/usr/bin/dig: couldn't get address for 'ns11.sulweb.org': no more


---


*www.virtualbit...@names.sulweb.org.:*
*dig A +noadditional +noquestion +nocomments +nocmd +nostats +trace
www.virtualbit.it. @names.sulweb.org.*

/usr/bin/dig: couldn't get address for 'names.sulweb.org.': failure

*www.virtualbit...@ns11.sulweb.org.:*
*dig A +noadditional +noquestion +nocomments +nocmd +nostats +trace
www.virtualbit.it. @ns11.sulweb.org.*

/usr/bin/dig: couldn't get address for 'ns11.sulweb.org.': failure

*www.virtualbit...@ns2.sulweb.org.:*
*dig A +noadditional +noquestion +nocomments +nocmd +nostats +trace
www.virtualbit.it. @ns2.sulweb.org.*

/usr/bin/dig: couldn't get address for 'ns2.sulweb.org.': failure

Regards,

Iván.




2018-04-26 15:35 GMT+02:00 Alberto Colosi :

> have you changed zone registration?
>
> there is DNS FQDN reference
>
>
> if you change dns fqdn you have to update zone on your NIC
>
>
> as it on NIC it or where you registered the domain
>
>
>
>
>
> --
> *From:* bind-users  on behalf of Lucio
> Crusca 
> *Sent:* Thursday, April 26, 2018 3:18 PM
> *To:* bind-users@lists.isc.org
> *Subject:* problems changing NS records
>
> Until a few hours ago, I had several domains and 3 nameservers for them:
>
> ns1.virtualbit.it (master, 136.243.232.142)
> ns11.virtualbit.it (slave, 158.69.210.19)
> ns2.virtualbit.it (slave, 136.243.232.143)
>
> Then I tried to migrate to a new master, names.virtualbit.it
> (46.4.38.130). Here is the migration steps I followed:
>
> 1) I configured Bind on the new server as master for all domains
> 2) I added the master IP address to the two slaves with:
>
> masters vbitdnsmasters { 136.243.232.142; 46.4.38.130; };
>
> zone "acquaritalia.it" {
> type slave;
> masters { vbitdnsmasters; };
> file "/var/lib/bind/acquaritalia.it.db";
> };
>
> and so on for all other zones.
>
> 3) I updated the NS records in the zone files, and in the control panel of
> the domain registrar
>
> Now all the domains have problems. IntoDNS reports:
>
> "
> Nameservers A recordsERROR: Some of your DNS servers do not have A
> records at all. I could not find any A records for the following DNS
> servers:
> ns2.virtualbit.it
>
> You must have A records for all of your nameservers.
> "
>
> However:
>
> dig @136.243.232.143 -t ns acquaritalia.it
> dig @136.243.232.143 acquaritalia.it
> dig @136.243.232.143 www.acquaritalia.it
> dig @136.243.232.143 -t mx acquaritalia.it
>
> all work as expected. Meanwhile, the same queries against 8.8.8.8 sometime
> 

Re: problems changing NS records

[Matus UHLAR - fantomas]

On 26.04.18 15:18, Lucio Crusca wrote:

Until a few hours ago, I had several domains and 3 nameservers for them:

ns1.virtualbit.it (master, 136.243.232.142)
ns11.virtualbit.it (slave, 158.69.210.19)
ns2.virtualbit.it (slave, 136.243.232.143)




Nameservers A recordsERROR: Some of your DNS servers do not have A
records at all. I could not find any A records for the following DNS
servers:
ns2.virtualbit.it

You must have A records for all of your nameservers.


this says it precisely: ns2.virtualbit.it does not exist.


However:

dig @136.243.232.143 -t ns acquaritalia.it
dig @136.243.232.143 acquaritalia.it
dig @136.243.232.143 www.acquaritalia.it
dig @136.243.232.143 -t mx acquaritalia.it


I have no idea where did you get the information that it has IP
136.243.232.143, the IP mey answer, but it is not ns2.virtualbit.it because
ns2.virtualbit.it simply does not exist.

note that domain virtualbit.it is registered to sulweb.org nameservers,
which already makes it inapt for using NS record and it also has problems:

"
ERROR: Some of your DNS servers do not have A records at all. I could not
find any A records for the following DNS servers:
ns11.sulweb.org
ns2.sulweb.org
names.sulweb.org

You must have A records for all of your nameservers. 
"


...not mentioning that sulweb.org itself is hosted by seflow.net which makes
it inapt too...

find better nameservers for your domain.


--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Boost your system's speed by 500% - DEL C:\WINDOWS\*.*
___
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: Fwd: Facing weird issue with DNS-RPZ

[Carl Byington]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Wed, 2018-04-25 at 19:30 +0530, Blason R wrote:
> I tried that couple of times on CentOS and it fails :(.

http://www.five-ten-sg.com/mapper/bind

I just updated the instructions. It looks like the built-in tests (that
are normally run as part of the build) require some IPv6. If you
disabled IPv6, you should be able to build with "--define 'test 0'"

Was there any other failure?


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEAREKAAYFAlrgzpYACgkQL6j7milTFsGMiQCgijHwoOI9VMhatAhuI/sOarmy
izcAoIssuYMdqgGbsTit5crgq8SrKSWf
=jvJE
-END PGP 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

Question about upgrade the version of BIND

[koji.matsumoto]

Hello All,

I am using BIND 9.10.2-P1.
I have a question.

[Situation]
In order to upgrade the version of BIND, I uninstalled BIND 9.10.2-P1 and 
installed BIND 9.11.3.
I started the service, but the startup of the service failed.
? Error code
1067
? Application event log
managed-keys-directory 'D: \ Program Files \ ISC BIND 9 \ var \ managed-keys' 
is not writable.

[A question]
Is the recovery procedure correct?
Added write permission of named user to 'D: \ Program Files \ ISC BIND 9 \ var 
\ managed-keys' directory.

Warm Regards,
matsumoto
___
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: Release Strategy Clarification

[Victoria Risk]

> On Apr 26, 2018, at 5:53 AM, Matthew Pounsett  wrote:
> 
> This is a question for ISC about the new BIND release plan which I thought 
> might be a useful clarification for others as well.
> 
> I didn't notice this when the new plan was first presented in March, but the 
> key text in the legend of the Example Release Plan[0] for the red blocks is 
> "a release that is no longer supported."  This implies that 9.12 will go from 
> being the most recent supported stable version of BIND to unsupported 
> literally overnight.  It doesn't appear there is a period where 9.12 and 9.14 
> are both supported, as 9.12 approaches end of life.
> 
> Is this an oversight, where the legend text needs updating to "a release that 
> is approaching end of life," or do we really all have to plan to do our 
> upgrades on January 1st every year?

Hi Matt,

You have correctly interpreted the chart in the blog post, but you don’t have 
to update in January, just when there is a bug you need a fix for.  If that bug 
is a security bug, the red block means, we will issue a security patch even 
though we are no longer issuing regular maintenance on that branch. So, 
effectively there is a quarter, 3 months, of overlap.

We want to do much more frequent releases, with new branches every year. We 
can’t create more branches AND support all of them for years like we used to. 
We believe that if the delta from one version to another is smaller, because 
the releases are closer together, then if you are say, running 9.12.3, and you 
want a bug fix, and we put that bug fix into 9.14.0, that will not be a big 
leap to upgrade to that.

Not everyone wants to update every year though, and that is why we also have 
the Extended Support Version. We are committed to supporting 9.11.x through the 
end of 2021. That will allow people to stay on that branch for something like 5 
years, which seems like plenty.  

It is true that you have to make a choice about whether to hang out with the 
ESV or follow the annual stable releases.

Vicky

> 
> Thanks,
>Matt
> 
> 
> [0]:  >
> ___
> 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

Victoria Risk
Product Manager
Internet Systems Consortium
vi...@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

what's wrong with recent bind-utils against dnsmasq

[Reindl Harald]

when the server is dnsmasq you get all sort of funny results from
SERVFAIL to REFUSED combined with the right answer

that now even goes so far that named is no longer able to resolve
zone-delegations pointing to a dnsmasq

[root@testserver:~]$ nslookup rhsoft.testserver.example.com 127.0.0.1
Server: 127.0.0.1
Address:127.0.0.1#53

Name:   rhsoft.testserver.example.com
Address: 127.0.0.1
** server can't find rhsoft.testserver.example.com: REFUSED
___

[root@flow-home:~]$ nslookup contentlounge.flow-home.example.net
Server: 127.0.0.1
Address:127.0.0.1#53

Name:   contentlounge.flow-home.example.net
Address: 10.0.0.244
** server can't find contentlounge.flow-home.example.net: SERVFAIL
___

[root@testserver:~]$ host rhsoft.testserver.example.com 127.0.0.1
Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases:

rhsoft.testserver.example.com has address 127.0.0.1
Host rhsoft.testserver.example.com not found: 5(REFUSED)
Host rhsoft.testserver.example.com not found: 5(REFUSED)
___

[root@testserver:~]$ dig rhsoft.testserver.example.com @127.0.0.1

; <<>> DiG 9.11.3-RedHat-9.11.3-4.fc27 <<>>
rhsoft.testserver.example.com @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42729
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;rhsoft.testserver.example.com.  IN  A

;; ANSWER SECTION:
rhsoft.testserver.example.com. 30 IN A   127.0.0.1

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Do Apr 26 10:40:44 CEST 2018
;; MSG SIZE  rcvd: 73

-- 

Reindl Harald
the lounge interactive design GmbH
A-1060 Vienna, Hofmühlgasse 17
CTO / CISO / Software-Development
m: +43 676 40 221 40
p: +43 1 595 3999 33
http://www.thelounge.net/

GPG-Public-Key:
https://arrakis-tls.thelounge.net/gpg/h.reindl_thelounge.net.pub.txt
___
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