date:20230322

Re: RPZ answer me NXDOMAIN for some domain

2023-03-22 Thread Mark Andrews

'break-dnssec no' looks at the DO flag and whether the data to be returned is 
signed.  If DO is 1 and the data is signed
then the answer is not modified.  If DO is 0 then it is modified as the client 
cannot be performing DNSSEC validation on
the response and be expecting it to succeed for responses from signed zones.

‘break-dnssec yes’ ignores the DO flag and whether the data is signed.

This is designed to allow forwarded requests to get DNSSEC protection as you 
can have the policy on multiple servers in
the chain to server plain clients.

> On 23 Mar 2023, at 00:28, Ondřej Surý  wrote:
> 
> 
>> On 22. 3. 2023, at 14:26, BONIN Nathanael  wrote:
>> 
>> If I add break-dnssec yes ; in my bind conf, it seems to works like I wanted 
>> to !!! Thanks.
> 
> +1
> 
>> But what I don’t understand is why, when I use directly SrvA (server that 
>> have RPZ zone), it works ?
> 
> That's something that's impossible to answer without seeing the full 
> configuration (named-checkconf -px).
> 
> Ondrej
> --
> Ondřej Surý (He/Him)
> ond...@isc.org
> 
> My working hours and your working hours may be different. Please do not feel 
> obligated to reply outside your normal working hours.
> 
> -- 
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
> this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> 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

-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Patch provided, please review!: Re: DNSTAP doesn't purge old dnstap files

2023-03-22 Thread Jesus Cea


On 21/3/23 23:38, Jesus Cea wrote:

Hi everybody.

Bind 9.16 here.

I have this configuration for DNSTAP:

"""
   dnstap {auth; client; resolver; forwarder;};
   dnstap-output file "/var/cache/bind/dnstap.tap" size 100M versions 
100 suffix timestamp;

"""

The "dnstap.tap" is correctly moved to "dnstap.tap.TIMESTAMP" a new 
"dnstap.tap" file is created when the old one reaches 100MB in size, but 
bind is not purging old "dnstap.tap.TIMESTAMP" files when their count 
goes over 100. It doesn't delete all files at all.


I have invested an afternoon debugging this and I have a diagnostic and 
a trivial patch: Please, review: 
https://gitlab.isc.org/isc-projects/bind9/-/issues/3959


--
Jesús Cea Avión _/_/  _/_/_/_/_/_/
j...@jcea.es - https://www.jcea.es/_/_/_/_/  _/_/_/_/  _/_/
Twitter: @jcea_/_/_/_/  _/_/_/_/_/
jabber / xmpp:j...@jabber.org  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RPZ answer me NXDOMAIN for some domain

2023-03-22 Thread BONIN Nathanael

Hi there,

We are using RPZ zone for some times now, but recently we found a weird 
behavior from some domains. Let me explain !

We have 2 NS server : Recursive one (let's call him SrvA) and one bebind (let's 
call him SrvB, with global forwarder : SrvA ). My RPZ zone is on SrvA.

If we took a little diagram, we have :

User = > SrvB = > SrvA = > Internet

If we create an A record tatata.google.com / 2.3.4.5 (that doesn't exist at 
google.com) on RPZ zone :


  *   On SrvA with : dig @localhost tatata.google.com we got IP : 2.3.4.5 => 
GREAT !
  *   On SrvB with : dig @localhost tatata.google.com (that point on SrvA), we 
got IP : 2.3.4.5 => WONDERFUL !

BUT

If we create another A record sri.biopyrenees.net / 3.4.5.6 (that doesn't exist 
at biopyrenees.net) on RPZ zone :


  *   On SrvA with : dig @localhost sri.biopyrenees.net, we got IP : 3.4.5.6 => 
YOUPI !
  *   On SrvB with : dig @localhost sri.biopyrenees.net, we got : NXDOMAIN => 
WHA ?

Why for some domain, the RPZ isn't working ?

An exemple of what I wrote on my RPZ zone :

tatata.google.com   A   2.3.4.5
sri.biopyrenees.net A  3.4.5.6

Is it normal ? Is there a way to have the good answer on my SrvB ?

With tcpdump, I see the same behavior with a record that works and with the 
record that doesn't work...

Thanks for your help.

Nath.





-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: RPZ answer me NXDOMAIN for some domain

2023-03-22 Thread Greg Choules via bind-users

Hi Nath.
What have you got on SrvB for biopyrenees.net, or net?
On SrvB, please do "dig @127.0.0.1 sri.biopyrenees.net" (please use the
actual address rather than "localhost") and paste the full result here. I
am interested in flags and the query time right now.

Cheers, Greg

On Wed, 22 Mar 2023 at 11:52, BONIN Nathanael  wrote:

> Hi there,
>
>
>
> We are using RPZ zone for some times now, but recently we found a weird
> behavior from some domains. Let me explain !
>
>
>
> We have 2 NS server : Recursive one (let’s call him SrvA) and one bebind
> (let’s call him SrvB, with global forwarder : SrvA ). My RPZ zone is on
> SrvA.
>
>
>
> If we took a little diagram, we have :
>
>
>
> User = > SrvB = > SrvA = > Internet
>
>
>
> If we create an A record tatata.google.com / 2.3.4.5 (that doesn’t exist
> at google.com) on RPZ zone :
>
>
>
>- On SrvA with : dig @localhost tatata.google.com we got IP : 2.3.4.5
>=> GREAT !
>- On SrvB with : dig @localhost tatata.google.com (that point on
>SrvA), we got IP : 2.3.4.5 => WONDERFUL !
>
>
>
> BUT
>
>
>
> If we create another A record sri.biopyrenees.net / 3.4.5.6 (that doesn’t
> exist at biopyrenees.net) on RPZ zone :
>
>
>
>- On SrvA with : dig @localhost sri.biopyrenees.net, we got IP :
>3.4.5.6 => YOUPI !
>- On SrvB with : dig @localhost sri.biopyrenees.net, we got : NXDOMAIN
>=> WHA ?
>
>
>
> Why for some domain, the RPZ isn’t working ?
>
>
>
> An exemple of what I wrote on my RPZ zone :
>
>
>
> tatata.google.com   A   2.3.4.5
>
> sri.biopyrenees.net A  3.4.5.6
>
>
>
> Is it normal ? Is there a way to have the good answer on my SrvB ?
>
>
>
> With tcpdump, I see the same behavior with a record that works and with
> the record that doesn’t work…
>
>
>
> Thanks for your help.
>
>
>
> Nath.
>
>
>
>
>
>
>
>
>
>
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: RPZ answer me NXDOMAIN for some domain

2023-03-22 Thread Ondřej Surý

Hi,

look for break-dnssec in 
https://bind9.readthedocs.io/en/stable/reference.html#response-policy-zone-rpz-rewriting

--
Ondřej Surý — ISC (He/Him)

My working hours and your working hours may be different. Please do not feel 
obligated to reply outside your normal working hours.

> On 22. 3. 2023, at 12:52, BONIN Nathanael  wrote:
> 
> 
> Hi there,
>  
> We are using RPZ zone for some times now, but recently we found a weird 
> behavior from some domains. Let me explain !
>  
> We have 2 NS server : Recursive one (let’s call him SrvA) and one bebind 
> (let’s call him SrvB, with global forwarder : SrvA ). My RPZ zone is on SrvA.
>  
> If we took a little diagram, we have :
>  
> User = > SrvB = > SrvA = > Internet
>  
> If we create an A record tatata.google.com / 2.3.4.5 (that doesn’t exist at 
> google.com) on RPZ zone :
>  
> On SrvA with : dig @localhost tatata.google.com we got IP : 2.3.4.5 => GREAT !
> On SrvB with : dig @localhost tatata.google.com (that point on SrvA), we got 
> IP : 2.3.4.5 => WONDERFUL !
>  
> BUT
>  
> If we create another A record sri.biopyrenees.net / 3.4.5.6 (that doesn’t 
> exist at biopyrenees.net) on RPZ zone :
>  
> On SrvA with : dig @localhost sri.biopyrenees.net, we got IP : 3.4.5.6 => 
> YOUPI !
> On SrvB with : dig @localhost sri.biopyrenees.net, we got : NXDOMAIN => 
> WHA ?
>  
> Why for some domain, the RPZ isn’t working ?
>  
> An exemple of what I wrote on my RPZ zone :
>  
> tatata.google.com   A   2.3.4.5
> sri.biopyrenees.net A  3.4.5.6
>  
> Is it normal ? Is there a way to have the good answer on my SrvB ?
>  
> With tcpdump, I see the same behavior with a record that works and with the 
> record that doesn’t work…
>  
> Thanks for your help.
>  
> Nath. 
>  
>  
>  
>  
>  
> -- 
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
> this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

BIND Process failed during logrotate

2023-03-22 Thread White, Peter

I had the named process fail this past weekend on two secondaries running BIND 
9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.13. It seems that logrotate.d is calling 
the following script at the time of the failure.

/var/named/data/named.run {
missingok
su named named
create 0644 named named
postrotate
/usr/bin/systemctl reload named.service > /dev/null 2>&1 || true
/usr/bin/systemctl reload named-chroot.service > /dev/null 2>&1 || true
/usr/bin/systemctl reload named-sdb.service > /dev/null 2>&1 || true
/usr/bin/systemctl reload named-sdb-chroot.service > /dev/null 2>&1 || 
true
/usr/bin/systemctl reload named-pkcs11.service > /dev/null 2>&1 || true
endscript
}

First of all, is this script part of the normal BIND distribution, or is it 
part of the RHEL 7 distribution? From what I can tell, it is called weekly.

Poring through the BIND logs for the cause of the failure, I came across this. 
Note the server.c:2948 error message and subsequent failure.
19-Mar-2023 03:46:01.908 received control channel command 'reload'
19-Mar-2023 03:46:01.908 loading configuration from '/etc/named.conf'
19-Mar-2023 03:46:01.909 reading built-in trust anchors from file 
'/etc/named.root.key'
19-Mar-2023 03:46:01.909 GeoIP Country (IPv4) (type 1) DB not available
19-Mar-2023 03:46:01.909 GeoIP Country (IPv6) (type 12) DB not available
19-Mar-2023 03:46:01.909 GeoIP City (IPv4) (type 2) DB not available
19-Mar-2023 03:46:01.909 GeoIP City (IPv4) (type 6) DB not available
19-Mar-2023 03:46:01.909 GeoIP City (IPv6) (type 30) DB not available
19-Mar-2023 03:46:01.909 GeoIP City (IPv6) (type 31) DB not available
19-Mar-2023 03:46:01.909 GeoIP Region (type 3) DB not available
19-Mar-2023 03:46:01.909 GeoIP Region (type 7) DB not available
19-Mar-2023 03:46:01.909 GeoIP ISP (type 4) DB not available
19-Mar-2023 03:46:01.909 GeoIP Org (type 5) DB not available
19-Mar-2023 03:46:01.909 GeoIP AS (type 9) DB not available
19-Mar-2023 03:46:01.909 GeoIP Domain (type 11) DB not available
19-Mar-2023 03:46:01.909 GeoIP NetSpeed (type 10) DB not available
19-Mar-2023 03:46:01.909 using default UDP/IPv4 port range: [1024, 65535]
19-Mar-2023 03:46:01.909 using default UDP/IPv6 port range: [1024, 65535]
19-Mar-2023 03:46:01.910 sizing zone task pool based on 2 zones
19-Mar-2023 03:46:01.911 ../../../bin/named/server.c:2498: fatal error:
19-Mar-2023 03:46:01.911 RUNTIME_CHECK(tresult == 0) failed
19-Mar-2023 03:46:01.911 exiting (due to fatal error in library)
Looking back a week earlier when the script last run, that server.c error was 
not there.

Any thoughts on what could have caused this on two secondaries? The primary 
reloaded around the same time without incident.

Thanks for your assistance.
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: RPZ answer me NXDOMAIN for some domain

2023-03-22 Thread Ondřej Surý

> On 22. 3. 2023, at 14:26, BONIN Nathanael  wrote:
> 
> If I add break-dnssec yes ; in my bind conf, it seems to works like I wanted 
> to !!! Thanks.

+1

> But what I don’t understand is why, when I use directly SrvA (server that 
> have RPZ zone), it works ?

That's something that's impossible to answer without seeing the full 
configuration (named-checkconf -px).

Ondrej
--
Ondřej Surý (He/Him)
ond...@isc.org

My working hours and your working hours may be different. Please do not feel 
obligated to reply outside your normal working hours.

-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: BIND Process failed during logrotate

2023-03-22 Thread Ondřej Surý

Peter,

> On 22. 3. 2023, at 14:40, White, Peter  wrote:
> 
>  First of all, is this script part of the normal BIND distribution, or is it 
> part of the RHEL 7 distribution? From what I can tell, it is called weekly.

This is RH's script

>  Any thoughts on what could have caused this on two secondaries? The primary 
> reloaded around the same time without incident.

This is ancient version patches with multiple security patches:

> running BIND 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.13

My advices would be either to talk to RedHat (if you have a support contract) 
or use ISC BIND 9 packages,
I would recommend upgrading straight to the latest BIND 9.18 (with proper 
testing, etc..).

The packages are available from:

https://www.isc.org/download/

(See the paragraph just above the table.)

Ondrej
--
Ondřej Surý (He/Him)
ond...@isc.org

My working hours and your working hours may be different. Please do not feel 
obligated to reply outside your normal working hours.

-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: RPZ answer me NXDOMAIN for some domain

2023-03-22 Thread BONIN Nathanael

Hi Ondrej !

I think you found the answer !!! It seems that the problem is DNSSEC. The 
biopyrenees.net seems to have a dnssec sig :

dig @127.0.0.1 biopyrenees.net +dnssec +short
213.186.33.5
A 8 2 3600 20230414114926 20230315114926 1266 biopyrenees.net. 
uUm5BxSqUJFyBhFCkT20zcqD+VkxCOJ47KxDqzvLoaMLMPPwTLtxtseM 
/CW3hCeEAMGgxyGO/10N97jPLSTKZXlfrqC2DTgKbu27U7fE6gJtArRC 
LgIAv17ivw/mIyQT4WQzOLtJnCLc0wL/Ak3nHYG+eXV4CWmPVSPe9AXE JFY=

If I add break-dnssec yes ; in my bind conf, it seems to works like I wanted to 
!!! Thanks. But what I don’t understand is why, when I use directly SrvA 
(server that have RPZ zone), it works ?

Thanks for your time 

Nath.


[cid:image002.png@01D7D25A.A81420E0]

Nathanaël BONIN
Ingénieur système Linux et supervision
DO-HDS
Tél. 05.67.69.72.95
boni...@mipih.fr

2 Impasse Michel Labrousse, 31100 Toulouse







De : Ondřej Surý 
Envoyé : mercredi 22 mars 2023 14:12
À : BONIN Nathanael 
Cc : bind-users@lists.isc.org
Objet : Re: RPZ answer me NXDOMAIN for some domain

Hi,

look for break-dnssec in 
https://bind9.readthedocs.io/en/stable/reference.html#response-policy-zone-rpz-rewriting

--
Ondřej Surý — ISC (He/Him)

My working hours and your working hours may be different. Please do not feel 
obligated to reply outside your normal working hours.


On 22. 3. 2023, at 12:52, BONIN Nathanael 
mailto:boni...@mipih.fr>> wrote:

Hi there,

We are using RPZ zone for some times now, but recently we found a weird 
behavior from some domains. Let me explain !

We have 2 NS server : Recursive one (let’s call him SrvA) and one bebind (let’s 
call him SrvB, with global forwarder : SrvA ). My RPZ zone is on SrvA.

If we took a little diagram, we have :

User = > SrvB = > SrvA = > Internet

If we create an A record tatata.google.com / 2.3.4.5 (that doesn’t exist at 
google.com) on RPZ zone :


  1.  On SrvA with : dig @localhost tatata.google.com we got IP : 2.3.4.5 => 
GREAT !
  2.  On SrvB with : dig @localhost tatata.google.com (that point on SrvA), we 
got IP : 2.3.4.5 => WONDERFUL !

BUT

If we create another A record sri.biopyrenees.net / 3.4.5.6 (that doesn’t exist 
at biopyrenees.net) on RPZ zone :


  1.  On SrvA with : dig @localhost sri.biopyrenees.net, we got IP : 3.4.5.6 => 
YOUPI !
  2.  On SrvB with : dig @localhost sri.biopyrenees.net, we got : NXDOMAIN => 
WHA ?

Why for some domain, the RPZ isn’t working ?

An exemple of what I wrote on my RPZ zone :

tatata.google.com   A   2.3.4.5
sri.biopyrenees.net A  3.4.5.6

Is it normal ? Is there a way to have the good answer on my SrvB ?

With tcpdump, I see the same behavior with a record that works and with the 
record that doesn’t work…

Thanks for your help.

Nath.





--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: RPZ answer me NXDOMAIN for some domain

2023-03-22 Thread BONIN Nathanael

> That's something that's impossible to answer without seeing the full 
> configuration (named-checkconf -px).

The full config here : https://pastebin.com/CwWFq73G

Thanks.

Ondrej
--
Ondřej Surý (He/Him)
ond...@isc.org

My working hours and your working hours may be different. Please do not feel 
obligated to reply outside your normal working hours.

-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Deprecation notice for BIND 9.18: (root-)delegation-only option

2023-03-22 Thread Ondřej Surý

Hi,

in line with our deprecation policy, I am notifying the mailing list about our
intent
to deprecated the delegation-only and root-delegation-only options. This is
again
adept for expedited deprecation - it will be removed in BIND 9.20 and deprecated
in BIND 9.18.

The (root-)delegation-options were introduced as a countermeasure for the
infamous
Site Finder by Verisign[1]. With the controversy around this and introduction
of DNSSEC,
the likelihood of this happening is infinitesimal.

If you don't even know what those options does, the TL;DR is that it disables
the non-delegation records for configured domains (TLD), this in turns might
break legitimate TLDs like .de, .fr, .museum and others [2][3].

If you know a legitimate reason to keep those options, please describe the use
case
here or in the issue mention below.

This is tracked under https://gitlab.isc.org/isc-projects/bind9/-/issues/3953

1. https://en.wikipedia.org/wiki/Site_Finder
2. https://circleid.com/posts/the_name_domain_disrupted_by_site_finder_patch
3.
https://www.afnic.fr/en/observatory-and-resources/news/warning-for-bind-and-delegation-only-users/

Ondřej
--
Ondřej Surý (He/Him)
ond...@isc.org

My working hours and your working hours may be different. Please do not feel
obligated to reply outside your normal working hours.

--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list

ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: RPZ answer me NXDOMAIN for some domain

Patch provided, please review!: Re: DNSTAP doesn't purge old dnstap files

RPZ answer me NXDOMAIN for some domain

Re: RPZ answer me NXDOMAIN for some domain

Re: RPZ answer me NXDOMAIN for some domain

BIND Process failed during logrotate

Re: RPZ answer me NXDOMAIN for some domain

Re: BIND Process failed during logrotate

RE: RPZ answer me NXDOMAIN for some domain

RE: RPZ answer me NXDOMAIN for some domain

Deprecation notice for BIND 9.18: (root-)delegation-only option

11 matches

Site Navigation

Mail list logo

Footer information