views-based RPZ

[Carlos Horowicz via bind-users]

Hello List,

an ISP has brought a case where several customers do not agree with our 
web interface portal that lets select different RPZ zones to be 
activated for a set of resolvers that are common to all customers. They 
even belong to different countries where some domains are banned.


Given the case that I start treating provisioned CIDRs from customers as 
a base for views, does bind9.18.* support a huge number of views with 
different rpz zones activated per view ?


I recall having read in the documentation about a limitation of 64 rpz 
zones in total, is this a number that can be configured, or even be set 
to "unlimited"  ?


Thanks in advance

Carlos Horowicz
Planisys

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

views-based RPZ

[Carlos Horowicz via bind-users]

Hello List,

an ISP has brought a case where several customers do not agree with our web 
interface portal that lets select different RPZ zones to be activated for a set 
of resolvers that are common to all customers. They even belong to different 
countries where some domains are banned.

Given the case that I start treating provisioned CIDRs from customers as a base 
for views, does bind9.18.* support a huge number of views with different rpz 
zones activated per view ?

I recall having read in the documentation about a limitation of 64 rpz zones in total, is 
this a number that can be configured, or even be set to "unlimited"  ?

Thanks in advance

Carlos Horowicz
Planisys

--
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: views-based RPZ

[Carlos Horowicz via bind-users]

Hi Greg,

thanks for your insights.

Ok so the limit of 64 response policy zones applies to one view.

I wonder, assuming the views are orthogonal (no overlapping of CIDRs, as 
in an ISP assigning CIDRs to local loops):


1. is there an algorithm in bind9 or out there that quickly maps a 
client IP address to a CIDR, e.g. a something like a binary tree 
quicksearch ? or balanced red-black tree ? top-down sequential 
processing sounds very inefficient.


2. if RPZ records are held in memory, why would an RPZ zone need to be 
stored n times if there are n orthogonal views ? That is, why the more 
views the more memory needed. Maybe you meant the qpcache, to store 
different answers, though I don't understand how that works.


Best regards

Carlos

On 24/08/2024 08:36, Greg Choules wrote:

Hi Carlos.
If you have enough RAM it should be possible to create multiple views, 
each with a zone (primary or secondary, up to you) that contains the 
RPZ data for that view and a response-policy that uses that zone.


The limit on number of zones is per response-policy block. But if 
you're using separate blocks inside each view, each r-p block 
referring to only one zone, then that limit is not relevant.


Bear in mind that views are processed top down, so if you have a lot 
of them it can take a (relatively) long time to match clients to the 
ones at the bottom. Also, by default, each view has its own cache, 
hence the need for a lot of RAM.


I would try it out on a lab server first.

Hope that helps.
Cheers, Greg

On Fri, 23 Aug 2024 at 20:43, Carlos Horowicz via bind-users 
 wrote:


Hello List,

an ISP has brought a case where several customers do not agree
with our web interface portal that lets select different RPZ zones
to be activated for a set of resolvers that are common to all
customers. They even belong to different countries where some
domains are banned.

Given the case that I start treating provisioned CIDRs from
customers as a base for views, does bind9.18.* support a huge
number of views with different rpz zones activated per view ?

I recall having read in the documentation about a limitation of 64
rpz zones in total, is this a number that can be configured, or
even be set to "unlimited"  ?

Thanks in advance

Carlos Horowicz
Planisys

-- 
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: views-based RPZ

[Carlos Horowicz via bind-users]

Hi Petr,

great that you mention where to look into the code, I'm not familiar 
with it yet. This is certainly what I'm looking for, the search 
algorithm for a client IP to find its view. The lab test depends on an 
investment in a Supernic (and the appropriate chassis/Motherboard/PCI 
architecture for it) , thus I prefer to look into the code first and see 
if it deserves hardware-based acceleration.


@Greg we have a bunch of rpz resolvers for ISPs ranging from 4 to 
15MQueries/5 min. But bigger ISPs with 10 fold more traffic have 
manifested the rpz policies should be as flexible as possible for 
individual corporate customers. Nowadays loading zones with millions of 
rpz domains with ixfr takes a long time on platinum-xeon on a single 
view where bind 9.18* is not very responsive. Yes this deserves a single 
lab test for e.g. 2 or 3 views and see if loading time varies.


Thank you all for your insights,

Carlos

On 26/08/2024 10:20, Petr Špaček wrote:

On 25. 08. 24 9:20, Greg Choules via bind-users wrote:
Regarding view selection, I don't know exactly how the code works or 
how efficient it is. But certainly I have seen some configs with a 
lot of views and they seem to function OK.


Views are matched one by one, you can have a look at function 
get_matching_view() in file bin/named/server.c.


Having said that, the matching can be fast enough or not depending on 
the configuration. Typically it's better to do a test in lab than 
theorize.


Petr Špaček
Internet Systems Consortium



What sort of QPS are each of your servers handling?

Cheers, Greg

On Sun, 25 Aug 2024 at 05:27, Grant Taylor via bind-users 
mailto:bind-users@lists.isc.org>> wrote:


    On 8/24/24 07:37, Carlos Horowicz via bind-users wrote:
 > 2. if RPZ records are held in memory, why would an RPZ zone need
    to be
 > stored n times if there are n orthogonal views ? That is, why the
    more
 > views the more memory needed. Maybe you meant the qpcache, to 
store

 > different answers, though I don't understand how that works.

    I believe that some newer versions of BIND can share zone 
information

    across multiple views.  Check out the "in-view" statement that goes
    in a
    zone {...} clause.

    Link - Chapter 7 BIND zone clause
   - https://www.zytrax.com/books/dns/ch7/zone.html#in-view
<https://www.zytrax.com/books/dns/ch7/zone.html#in-view>

--
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: Executive Order 14144 - encrypted DNS

[Carlos Horowicz via bind-users]

IMHO this has nothing to do with DNSSEC, it sounds more like the urge to 
encrypt resolver traffic (I guess they're referring to DoT)


On 27/01/2025 13:55, Marc wrote:

FYI - EO 14144 has the following provision related to encrypting DNS:

(c) Encrypting Domain Name System (DNS) traffic in transit is a critical
step to protecting both the confidentiality of the information being
transmitted to, and the integrity of the communication with, the DNS
resolver.
   (i) Within 90 days of the date of this order, the Secretary of
Homeland Security, acting through the Director of CISA, shall publish
template contract language requiring that any product that acts as a DNS
resolver (whether client or server) for the Federal Government support
encrypted DNS and shall recommend that language to the FAR Council.
Within 120 days of receiving the recommended language, the FAR Council
shall review it, and, as appropriate and consistent with applicable law,
the agency members of the FAR Council shall jointly take steps to amend
the FAR. (ii) Within 180 days of the date of this order, FCEB agencies
shall enable encrypted DNS protocols wherever their existing clients and
servers support those protocols. FCEB agencies shall also enable such
protocols within 180 days of any additional clients and servers
supporting such protocols.


Disclaimer, not really an dns expert

What is this referring to DNSSEC? Afaik is just signing traffic not? What is 
the point of encrypting data with the current implementation of certificates. 
Even google does not trust CA's with it's certificate pinning.



--
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: Executive Order 14144 - encrypted DNS

[Carlos Horowicz via bind-users]

I found this RFC https://www.rfc-editor.org/info/rfc9076 pretty 
interesting as it covers all topics related to DNS privacy, including 
the need to prepare for quantum-resistant algorithms and encrypting DNS 
traffic ... I guess the author is not only referring to resolver traffic 
that should use DoT instead of plaintext UDP/53 , but also zone 
transfers over the Internet encrypted with TLS (thus the reference to 
certificates).


-Carlos

On 27/01/2025 14:02, Carlos Horowicz via bind-users wrote:
IMHO this has nothing to do with DNSSEC, it sounds more like the urge 
to encrypt resolver traffic (I guess they're referring to DoT)


On 27/01/2025 13:55, Marc wrote:

FYI - EO 14144 has the following provision related to encrypting DNS:

(c) Encrypting Domain Name System (DNS) traffic in transit is a 
critical

step to protecting both the confidentiality of the information being
transmitted to, and the integrity of the communication with, the DNS
resolver.
   (i) Within 90 days of the date of this order, the Secretary of
Homeland Security, acting through the Director of CISA, shall publish
template contract language requiring that any product that acts as a 
DNS

resolver (whether client or server) for the Federal Government support
encrypted DNS and shall recommend that language to the FAR Council.
Within 120 days of receiving the recommended language, the FAR Council
shall review it, and, as appropriate and consistent with applicable 
law,

the agency members of the FAR Council shall jointly take steps to amend
the FAR. (ii) Within 180 days of the date of this order, FCEB agencies
shall enable encrypted DNS protocols wherever their existing clients 
and

servers support those protocols. FCEB agencies shall also enable such
protocols within 180 days of any additional clients and servers
supporting such protocols.


Disclaimer, not really an dns expert

What is this referring to DNSSEC? Afaik is just signing traffic not? 
What is the point of encrypting data with the current implementation 
of certificates. Even google does not trust CA's with it's 
certificate pinning.


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

Question about post-quantum X25519Kyber768

[Carlos Horowicz via bind-users]

Hi there,

does anyone know of the bind developers thinking of incorporating 
post-quantum cryptography into bind9 , like Cloudflare with 
X25519Kyber768 on BoringSSL ?


I'm just curious about if there are thoughts or ongoing work, or if this 
is in the near roadmap at all.


Thank you,

Carlos Horowicz
Avascloud/Planisys

--
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: Question about post-quantum X25519Kyber768

[Carlos Horowicz via bind-users]

Yes , when any changes concerning DS records would drag willing of 
support by registries, it sounds reasonable that there should be an RFC 
for it.



Thanks,

Carlos


On 02/01/2025 13:45, Robert Wagner wrote:


From my poke a few months back - stuff like PQC and NSA's Commercial 
Solutions for Classified settings need to go through the RFC process. 
Since both the DNS server and DNS client need to be on the same page 
as to which cipher suites they agree on.


Around 10/16:

Robert, if you'd like to propose standardizing SHA-512 for use in DS 
records please propose this in an Internet Draft — there is a helpful 
page here: https://authors.ietf.org/en/home 
<https://authors.ietf.org/en/home> .


W


Robert Wagner



*From:* bind-users  on behalf of 
Carlos Horowicz via bind-users 

*Sent:* Thursday, January 2, 2025 7:32 AM
*To:* bind-users@lists.isc.org 
*Subject:* Question about post-quantum X25519Kyber768
This email originated from outside of TESLA

Do not click links or open attachments unless you recognize the sender 
and know the content is safe.


Hi there,

does anyone know of the bind developers thinking of incorporating
post-quantum cryptography into bind9 , like Cloudflare with
X25519Kyber768 on BoringSSL ?

I'm just curious about if there are thoughts or ongoing work, or if this
is in the near roadmap at all.

Thank you,

Carlos Horowicz
Avascloud/Planisys

--
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: Massive increase of SERVFAIL after April 28th 2025.

[Carlos Horowicz via bind-users]

Hi Vincent

using a conventional resolver (no rpz, no forwards, no forward zones) 
from our Miami cloud:



Tracing to ftp.lip6.fr[a] via 190.185.104.10, maximum of 3 retries
190.185.104.10 (190.185.104.10)
 |\___ g.ext.nic.fr [fr] (2001:0678:004c:::::0001)
 | |\___ soleil.uvsq.fr [lip6.fr] (193.51.24.1) Got authoritative 
answer [received type is cname]
 | |\___ isis.lip6.fr [lip6.fr] (132.227.60.2) Got authoritative 
answer [received type is cname]
 |  \___ osiris.lip6.fr [lip6.fr] (132.227.60.30) Got authoritative 
answer [received type is cname]

 |\___ g.ext.nic.fr [fr] (194.0.36.1)
 | |\___ osiris.lip6.fr [lip6.fr] (132.227.60.30) (cached)
 | |\___ soleil.uvsq.fr [lip6.fr] (193.51.24.1) (cached)
 |  \___ isis.lip6.fr [lip6.fr] (132.227.60.2) (cached)
 |\___ d.nic.fr [fr] (2001:0678:000c:::::0001)
 | |\___ isis.lip6.fr [lip6.fr] (132.227.60.2) (cached)
 | |\___ osiris.lip6.fr [lip6.fr] (132.227.60.30) (cached)
 |  \___ soleil.uvsq.fr [lip6.fr] (193.51.24.1) (cached)
 |\___ d.nic.fr [fr] (194.0.9.1)
 | |\___ isis.lip6.fr [lip6.fr] (132.227.60.2) (cached)
 | |\___ soleil.uvsq.fr [lip6.fr] (193.51.24.1) (cached)
 |  \___ osiris.lip6.fr [lip6.fr] (132.227.60.30) (cached)
 |\___ f.ext.nic.fr [fr] (2001:067c:1010:0011::::0053)
 | |\___ osiris.lip6.fr [lip6.fr] (132.227.60.30) (cached)
 | |\___ soleil.uvsq.fr [lip6.fr] (193.51.24.1) (cached)
 |  \___ isis.lip6.fr [lip6.fr] (132.227.60.2) (cached)
  \___ f.ext.nic.fr [fr] (194.146.106.46)
   |\___ osiris.lip6.fr [lip6.fr] (132.227.60.30) (cached)
   |\___ isis.lip6.fr [lip6.fr] (132.227.60.2) (cached)
    \___ soleil.uvsq.fr [lip6.fr] (193.51.24.1) (cached)

osiris.lip6.fr (132.227.60.30)  ftp.lip6.fr -> nephtys.lip6.fr
osiris.lip6.fr (132.227.60.30)  nephtys.lip6.fr -> 132.227.74.17
isis.lip6.fr (132.227.60.2) ftp.lip6.fr -> nephtys.lip6.fr
isis.lip6.fr (132.227.60.2) nephtys.lip6.fr -> 132.227.74.17
soleil.uvsq.fr (193.51.24.1)    ftp.lip6.fr -> nephtys.lip6.fr
soleil.uvsq.fr (193.51.24.1)    nephtys.lip6.fr -> 132.227.74.17

HTH

Carlos Horowicz
Planisys


On 01/05/2025 18:07, vinc...@cojot.name wrote:


Hi Carlos,

First of all, I'd like to say how sorry I was for those affected, as I 
was watching the events unfold down south.


I've rebuilt dnstracer for RHEL9 and I don't really understand what's 
going on here.. Here's the output for ftp.lip6.fr:


# dnstracer -q cname -s M.GTLD-SERVERS.NET  ftp.lip6.fr
Tracing to ftp.lip6.fr[cname] via M.GTLD-SERVERS.NET, maximum of 3 
retries
M.GTLD-SERVERS.NET (2001:0501:b1f9:::::0030) Refers 
backwards


Same output from any of my bind hosts:

# dnstracer -q cname -s 127.0.01  ftp.lip6.fr
Tracing to ftp.lip6.fr[cname] via 127.0.01, maximum of 3 retries
127.0.01 (127.0.0.1) Refers backwards

But interestingly, doing this with www.google.com instead of 
ftp.lip6.fr -only- works on the bind servers with forwarders 
configured. On a test bind host without the forwarders, I get this:


# dnstracer -q cname -s 127.0.01  www.google.com
Tracing to www.google.com[cname] via 127.0.01, maximum of 3 retries
127.0.01 (127.0.0.1) Refers backwards

Vincent

On Thu, 1 May 2025, Carlos Horowicz via bind-users wrote:



Hi,

For SERVFAIL to happen, ALL authoritative for the affected domains 
must have been in Datacenters in Spain, Portugal or southern France.


I live in Spain, and as 12:33 CET I lost not only power but basic 
telephony, cellular telephony and cellular data. Everything. Power 
generators were only good for keeping power
locally at Datacenters or Hospitals, but they were isolated from each 
other.


The mitigation began at around 2-3pm CET , as they were turning up 
different power plants one at a time and connecting it to the power 
network, and it took them more than 12

hours to turn everything up.

So may be that was the reason, if it coincides with your perception 
... dnstracer has eventually helped me find lame delegations.


Carlos Horowicz
Planisys

On 01/05/2025 17:23, Rob McEwen via bind-users wrote:
  From vinc...@cojot.name
  until a few days ago (April 28th?) when the amount of SERVFAIL 
started going ballistic and started preventing the resolution of a 
lot of DNS names on the

  internet to the point where DNS was unusable


I strongly suspect that this was caused (even if indirectly?) by the 
MASSIVE and many-hours-long power outages in Europe, mainly in Spain 
and Portugal. That started on
April 28, 2025, at approximately 6:33 a.m. Eastern Time (ET) - and 
the majority of it lasted almot 24 hours.


https://www.france24.com/en/europe/20250430-what-we-know-so-far-about-the-massive-blackout-that-hit-spain-and-portugal 



Hopefully, you're not seeing any more of these errors now?

Rob McEwen, invaluement





--
Visit https://lists.isc.org/mailman/listinf

Re: Massive increase of SERVFAIL after April 28th 2025.

[Carlos Horowicz via bind-users]

Hi,

For SERVFAIL to happen, ALL authoritative for the affected domains must 
have been in Datacenters in Spain, Portugal or southern France.


I live in Spain, and as 12:33 CET I lost not only power but basic 
telephony, cellular telephony and cellular data. Everything. Power 
generators were only good for keeping power locally at Datacenters or 
Hospitals, but they were isolated from each other.


The mitigation began at around 2-3pm CET , as they were turning up 
different power plants one at a time and connecting it to the power 
network, and it took them more than 12 hours to turn everything up.


So may be that was the reason, if it coincides with your perception ... 
dnstracer has eventually helped me find lame delegations.


Carlos Horowicz
Planisys

On 01/05/2025 17:23, Rob McEwen via bind-users wrote:

From vinc...@cojot.name
until a few days ago (April 28th?) when the amount of SERVFAIL 
started going ballistic and started preventing the resolution of a 
lot of DNS names on the internet to the point where DNS was unusable


I strongly suspect that this was caused (even if indirectly?) by the 
MASSIVE and many-hours-long power outages in Europe, mainly in Spain 
and Portugal. That started on April 28, 2025, at approximately 6:33 
a.m. Eastern Time (ET) - and the majority of it lasted almot 24 hours.


https://www.france24.com/en/europe/20250430-what-we-know-so-far-about-the-massive-blackout-that-hit-spain-and-portugal

Hopefully, you're not seeing any more of these errors now?

Rob McEwen, invaluement

-- 
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: ECS subnet

[Carlos Horowicz via bind-users]

Hi,

you mean "edns-client-subnet yes;" in opensource bind9.18 right ?  
("unknown option 'edns-client-subnet'")


-Carlos

On 17/02/2025 18:00, Petr Špaček wrote:

On 14. 02. 25 17:41, Rainer Duffner wrote:
Am 14.02.2025 um 17:39 schrieb Greg Choules 
:


Hi.
Is this a question about BIND, or Unbound?
Note the name of the list.




No, it’s a question about BIND.

If an upstream resolver sends an ECS subnet (it’s in the packet 
header somewhere, from what I understand) - how can BIND show this in 
the logs?


ECS is not supported in the open source version of BIND so I guess it 
might not get logged. What you can do is enable PROXYv2 support, 
assuming Unbound supports it.



--
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: QNAME minimisation question

[Carlos Horowicz via bind-users]

Hi

The problem seems related to "No zone cut at 90.45.in-addr.arpa." , 
shouldn't trigger a SERVFAIL with qname-minimisation relaxed


This is strange, because the intermediate response has a SOA , and NSEC 
seems enough to fail-over to qname-minimisation off .. it seems you're 
force to set the value off or disabled, because bind finds something 
"strange" in the zone cut response.


dig ns +dnssec 90.45.in-addr.arpa @127.0.0.1

; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> ns +dnssec 90.45.in-addr.arpa 
@127.0.0.1

;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3483
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; COOKIE: 47e896cf6ccfda110100683d80f19d2be46647905c35 (good)
;; QUESTION SECTION:
;90.45.in-addr.arpa.    IN    NS

;; AUTHORITY SECTION:
45.in-addr.arpa.    739    IN    SOA    z.arin.net. dns-ops.arin.net. 
2017040515 1800 900 691200 10800
45.in-addr.arpa.    739    IN    RRSIG    SOA 8 3 86400 20250616082821 
20250602072821 19875 45.in-addr.arpa. 
P4IRK/zZI0PrSiEfGMY+aFC7ipvCDuxAf4qKU72PUrIXT34tRg/ILXN1 
xSu28ASQovyGVJavy09N9NWog+PUD4CTwLPLIzrYLSlQYSeSb74Lh0i2 
Y3CVe9d4OfRPmng1enj/CbhzYOe/PG/qJ159DoDlBg41gdhSzQyLSsdj Ffo=
99.9.45.in-addr.arpa.    739    IN    RRSIG    NSEC 8 5 10800 
20250616082821 20250602072821 19875 45.in-addr.arpa. 
nneoox/GsQsIPH1WfouCcqjpXzw1yd2S4km+jWPI7Ow6mDZkhpZEOr8L 
S5/osv5Dmu0HmadjUucHwpTFHALqJVR/BeCDl54w0/0pLaYX4BxSPzPN 
8a7AvmA/qpu/M5deTy4egDFX7qV2DJo17DvykLbBmeAGkN3R5k4olLha dbU=
99.9.45.in-addr.arpa.    739    IN    NSEC 0.90.45.in-addr.arpa. NS 
RRSIG NSEC


;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Mon Jun 02 07:46:09 -03 2025
;; MSG SIZE  rcvd: 541

-Carlos


On 02/06/2025 12:01, Nick Tait via bind-users wrote:

No zone cut at 90.45.in-addr.arpa.

--
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: Significant memory usage

[Carlos Horowicz via bind-users]

Apparently you have 295108 zones, maybe you can try one single rpz zone 
with all 295108 fqdn's like


.

12724[.]xyz IN CNAME .
21736[.[xyz IN CNAME .

.

instead of one zone per fqdn, and see if the memory footprint changes 
(both VMEM and RES)


Good luck!

Carlos Horowicz
Planisys

On 01/07/2025 19:27, OwN-3m-All wrote:
>>  Apologies if I misunderstood your setup. I’ve also encountered 
memory issues in recent BIND versions — BIND 9.18.33 on Debian 12 is a 
tremendous beast, capable of handling millions of QPS — but after 
reducing logging (including DNSTAP) and disabling serve-stale, I saw a 
significant improvement in both performance and memory usage.


Sorry, there's 295,108 hosts I'm serving up as 127.0.0.1 (for ad 
blocking).


I zipped my entire /etc/bind directory (which includes all configs).  
It's available to download here:


https://dinofly.com/files/linux/bind/bind_config_9.20_out_of_memory_bind_9.18_fine.zip



--
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: Significant memory usage

[Carlos Horowicz via bind-users]

Hello there,

I’m not a BIND developer either, but I was intrigued when you mentioned 
/millions of zone entries/. Are you referring to millions of individual 
zones, rather than consolidating entries into a single RPZ zone?


Apologies if I misunderstood your setup. I’ve also encountered memory 
issues in recent BIND versions — BIND 9.18.33 on Debian 12 is a 
tremendous beast, capable of handling millions of QPS — but after 
reducing logging (including DNSTAP) and disabling serve-stale, I saw a 
significant improvement in both performance and memory usage.


Best regards,

*Carlos Horowicz***

Planisys

On 01/07/2025 19:03, OwN-3m-All wrote:
Can we quit pretending that the newest versions of bind aren't memory 
hogs?  We shouldn't have to provide the technical details as to why 
the newest versions of bind use so much ram.  We don't know.  We're 
just end users.  However, with millions of zone entries (used as an ad 
blocking DNS server) like:


zone ad-assets.futurecdn.net  { type 
master; notify no; file "/etc/bind/null.zone.file"; };


with /etc/bind/null.zone.file containing:

; BIND db file for ad servers - point all addresses to localhost
;
; This file comes from:
;
; https://pgl.yoyo.org/adservers/
;
; A site with a list of ad servers and details on how to use it to
; block ads on the Internet. Plus some BIND stuff and other bits.
;
;  - p...@yoyo.org
;

$TTL    86400   ; one day

@       IN      SOA ns0.example.net . 
hostmaster.example.net . (

                        2002061000       ; serial number YYMMDDNN
                        28800   ; refresh  8 hours
                        7200    ; retry    2 hours
                        864000  ; expire  10 days
                        86400 ) ; min ttl  1 day
                NS ns0.example.net .
                NS ns1.example.net .

                A       127.0.0.1
                       ::1

*               IN      A       127.0.0.1
*               IN             ::1

Bind 1:9.20.10-1+ubuntu20.04.1+deb.sury.org +1 
amd64 runs out of memory and crashes on a 4GB virtual machine with 1 
vCPU.


I downgraded to 9.18 (and am using the same bind configs as before) 
and that "fixed" the issue:


apt-get install bind9=1:9.18.30-0ubuntu0.20.04.2 
bind9-utils=1:9.18.30-0ubuntu0.20.04.2 
bind9-libs=1:9.18.30-0ubuntu0.20.04.2


So, rather than pretending that the new version of bind is better, 
maybe the developers of bind should figure out how to make the newer 
versions of bind more memory efficient than the older versions as 
opposed to making them significantly worse in regards to memory usage.


There have been countless threads in bind-users complaining about 
memory usage in the newest versions.  It's time that these reports 
were taken seriously.  They're legit.  Newer versions of bind use more 
memory.  Why?  I don't know... I'm not a bind developer.
-- 
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: Significant memory usage

[Carlos Horowicz via bind-users]

Ondřej,

I usually include *qname-wait-recurse no* after the *response-policy { 
... } *block, hoping to avoid issues where SERVFAILs, lame delegations, 
or firewalled authoritative servers might interfere with RPZ responses. 
I’m not entirely sure if I’m just being a bit /superstitious/ about that 
— but I wanted to mention it in the context of the setup you described, 
which uses A and  RRs (rather than CNAMEs or RPZ-SUFFIX rules). 
Perhaps qname-wait-recurse has a different impact in this case.


I’ve always found it puzzling when a SERVFAIL appears in the logs just 
/before/ a “CNAME .” redirection is applied, which makes me wonder if 
using A/ redirection to 127.0.0.1 is ultimately more robust.


Apologies if this adds noise to the thread — feel free to disregard if 
not relevant.


Best regards,

Carlos Horowicz

Planisys

On 01/07/2025 21:00, Ondřej Surý wrote:

You'll have to experiment a bit (and I mean read the documentation[1]) as I am 
writing this from top of my head,

1. You need to create RPZ zone like this:

$TTL 604800
$ORIGIN adaway.rpz.
@ IN SOA localhost. root.localhost. (1 604800 86400 2419200 604800 )
@ IN NS localhost.
ad-assets.futurecdn.net A 127.0.0.1
ad-assets.futurecdn.net  ::1
[...]

I've used this command:

( echo "@ IN SOA localhost. root.localhost. (1 604800 86400 2419200 604800 )"; echo "@ IN NS localhost." ; cat 
named_adaway.conf  | cut -f 2 -d ' ' | while read D; do echo "$D IN A 127.0.0.1"; echo "$D IN  ::1"; echo "*.$D 
IN A 127.0.0.1"; echo "*.$D IN  ::1"; done ) > adaway.rpz.db

2. Add the RPZ zone to your named.conf

zone adaway.rpz {
type primary;
file "//adaway.rpz.db";
allow-query { localhost; };
};

3. Add the response-policy to your options {} in named.conf

options {
[...]
response-policy { zone adaway.rpz; } break-dnssec yes;
[...]
};

And the memory usage on 9.20 is now mere 450MB:
   PID User Command Swap  USS  PSS  RSS
514700 ondrej   /home/ondrej/Projects/bind90   451684   452652   461872

$ dig +short -p 12345 @::1 ad-assets.futurecdn.net.
127.0.0.1
$ dig +short -p 12345 @::1 foo.ad-assets.futurecdn.net.
127.0.0.1

1.https://bind9.readthedocs.io/en/v9.20.10/reference.html#response-policy-zone-rpz-rewriting
--
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.


On 1. 7. 2025, at 20:40, OwN-3m-All wrote:

Also, 127.0.0.1 (localhost) needs to be returned for these hosts, not a 
NXDOMAIN response.  Would that impact it?
--
Visithttps://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 athttps://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: Significant memory usage

[Carlos Horowicz via bind-users]

   Ondřej


   By the way, have you ever considered using Redis as an in-memory
   cache database? I’ve been thinking about offloading some of the TTL
   expiry and cache management to Redis.


   In some customer environments, the query volume is extremely high —
   we’re using Mellanox CX-6 25G interfaces, which already handle a lot
   of offloading and fair IRQ distribution at the NIC level — so I
   wonder if you ever ran into performance limitations with Redis under
   similar loads, or decided against it for architectural reasons.

   Just curious

Thank you

Carlos Horowicz
Planisys


On 02/07/2025 06:53, Ondřej Surý wrote:

On 2. 7. 2025, at 0:14, OwN-3m-All wrote:

I wonder if other memory issues users are complaining about are related.

I don’t know. You were the first one to actually provided a reproducer and a 
usable test case. Despite your exaggeration about “countless” reports there 
were not that many of them actually.


How many zones can a bind instance handle realistically?

Internally, we are testing BIND 9 with 1M small zones and it works just fine.

What happened was that 9.20 introduced a new database backend called QP that 
replaced venerable custom red-black tree implementation we had. The side effect 
of that was 12K memory chunk overhead per zone. Under normal conditions, this 
would not manifest as that 12K would get filled with the zone data, but in the 
case of almost empty zone, the memory chunk would be mostly empty and it just 
blew up the memory requirements.

BIND 9.22 will contain an optimization that gradually increases the memory 
chunk size and that allows “auto tuning” for both small zones, large zones and 
the cache.

Ondrej
--
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.-- 
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