Re: Reference to non-existent files in output from 9.18 rndc zonestatus

On 9 Jul 2025, at 14:02, Niall O'Reilly wrote: > I'm baffled by something strange I came across yesterday, and would > appreciate an injection of clue. This seems to have been a case of PEBKAB. Apologies for the noise. Niall -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscr

Re: Bind 9.18: assert in dns_cache_create() cleanup branch

On 10 Jul 2025, at 16:25, Ondřej Surý wrote: > current stable release (9.20) and the previous stable 9.18 is in the "deep > freeze" mode > where we only fix critical or security bugs Gosh, I hadn't appreciated that 9.18 was in the freezer, time does fly. - https://www.isc.org/download/ states it

Re: Bind 9.18: assert in dns_cache_create() cleanup branch

Hi Andreas, I'll also provide feedback to you here. We very much appreciate bug reports like this, where the submitter puts an effort to diagnose, describe and (possibly) fix the issue. Thank you for that. Unfortunately, this particular issue has been already fixed in the current stable release

Re: 127/8 weirdness & entertainment for fun & profit.

Crist Clark writes: > Note that is all Linux-specific behavior. BSD-derived stacks are generally > different, e.g. FreeBSD and MacOS. They do not respond to addresses that > aren’t explicitly assigned to an interface. You cannot bind an address not > assigned to an interface. I know nothing abou

Re: 127/8 weirdness & entertainment for fun & profit.

Note that is all Linux-specific behavior. BSD-derived stacks are generally different, e.g. FreeBSD and MacOS. They do not respond to addresses that aren’t explicitly assigned to an interface. You cannot bind an address not assigned to an interface. On Sun, Jul 6, 2025 at 9:23 AM Grant Taylor via

Re: BIND doesn't listen to other loopback addresses

Bagas Sanjaya writes: > Yet, the change **does not** persist on reboot (IOW, that 127.0.0.53 address > is gone or back to defaults). Hence, I have to add dummy interface. No network configuration is persistent unless you make it so. I assumed that was obvious. Bjørn -- Visit https://lists.is

Re: BIND doesn't listen to other loopback addresses

Hi, I do not know if you are using Redhat EL 9 or not but I found this article from Redhat that seems to describe how one might manage the loopback interface with NetworkManager: https://access.redhat.com/solutions/2108251 On Mon, Jul 7, 2025 at 4:48 AM Bagas Sanjaya wrote: > > On Mon, Jul 07,

Re: BIND doesn't listen to other loopback addresses

On Mon, Jul 07, 2025 at 03:28:57AM +0200, Michael De Roover wrote: > On Monday, July 7, 2025 1:54:41 AM CEST Bagas Sanjaya wrote: > > That override won't persist across reboots, though, in my case (I'm using > > NetworkManager). > > > > Thanks. > > ... That's not what I mean. As I iterate: I wo

Re: BIND doesn't listen to other loopback addresses

On Monday, July 7, 2025 1:54:41 AM CEST Bagas Sanjaya wrote: > That override won't persist across reboots, though, in my case (I'm using > NetworkManager). > > Thanks. ...-- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this

Re: BIND doesn't listen to other loopback addresses

On Sun, Jul 06, 2025 at 08:10:58PM +0200, Bjørn Mork via bind-users wrote: > Bagas Sanjaya writes: > > > Here in my case, I was expecting BIND to listen to 127.0.0.53 as > > separate address, just like in similar applications (systemd-resolved, > > dnsdist, etc). > > You do need to add the addre

Re: BIND doesn't listen to other loopback addresses

Bagas Sanjaya writes: > Here in my case, I was expecting BIND to listen to 127.0.0.53 as > separate address, just like in similar applications (systemd-resolved, > dnsdist, etc). You do need to add the address to an interface, but you don't need to add a new dummy interface. This will make your

Re: 127/8 weirdness & entertainment for fun & profit.

New-Subject: host vs subnet routes Old-Subject: BIND doesn't listen to other loopback addresses On 7/6/25 1:02 AM, Ondřej Surý wrote: The IPv4 loopback is actually quite weird in this regard that 127.0.0.1/8 is assigned by everything in 127/8 automagically works without explicit address assig

Re: BIND doesn't listen to other loopback addresses

On 7/6/25 12:48, Michael De Roover wrote: On Sunday, July 6, 2025 4:40:37 AM CEST Michael De Roover wrote: Omit 127.0.0.53, like so: options { listen-on { 192.168.0.155; }; }; Works fine for me using IP addresses 192.168.10.{4-6}, on Alpine edge. You can keep v6

Re: BIND doesn't listen to other loopback addresses

On Sunday, July 6, 2025 2:34:58 AM CEST Bagas Sanjaya wrote: > Hi, > > I notice BIND's address binding behavior (bug?). I'm running BIND from > git (9.21.10-dev (Development Release) ). > > My named.conf specifies listen-address to both loopback and WiFi devices: > > ``` > options { > ...

Re: BIND doesn't listen to other loopback addresses

On 7/6/25 12:30, Greg Choules wrote: https://bind9.readthedocs.io/en/stable/reference.html#namedconf- statement-automatic-interface-scan Note the phrase "...and supported by the operating syst

Re: BIND doesn't listen to other loopback addresses

On 7/6/25 13:02, Ondřej Surý wrote: On 6. 7. 2025, at 2:35, Bagas Sanjaya wrote: It seems like BIND only listen to addresses that are assigned to existing network devices, no? The thread got little bit muddled, but basically the answer is: yes, that’s right. The IPv4 loopback is actually qu

Re: BIND doesn't listen to other loopback addresses

> On 6. 7. 2025, at 2:35, Bagas Sanjaya wrote: > > It seems like BIND only listen to addresses that are assigned to existing > network devices, no? The thread got little bit muddled, but basically the answer is: yes, that’s right. The IPv4 loopback is actually quite weird in this regard that 1

Re: BIND doesn't listen to other loopback addresses

On Sunday, July 6, 2025 4:40:37 AM CEST Michael De Roover wrote: > Omit 127.0.0.53, like so: > > options { > listen-on { > 192.168.0.155; > }; > }; > > Works fine for me using IP addresses 192.168.10.{4-6}, on Alpine edge. You > can keep v6 none. One of the more basic op

Re: BIND doesn't listen to other loopback addresses

On Sunday, July 6, 2025 7:21:19 AM CEST Bagas Sanjaya wrote: > On Sun, Jul 06, 2025 at 11:52:35AM +1000, Mark Andrews wrote: > > Listen-on is an acl. The interface table is scanned for matches which are > > then bound to. This is documented behaviour. > in ARM? Common practice really. Don't consi

Re: BIND doesn't listen to other loopback addresses

https://bind9.readthedocs.io/en/stable/reference.html#namedconf-statement-automatic-interface-scan Note the phrase "...and supported by the operating system...". Linux capabilities must also be enabled (i.e. not *disabled* at build time) for BIND to be able to keep scanning as addresses come and g

Re: BIND doesn't listen to other loopback addresses

On Sun, Jul 06, 2025 at 11:52:35AM +1000, Mark Andrews wrote: > Listen-on is an acl. The interface table is scanned for matches which are > then bound to. This is documented behaviour. in ARM? -- An old man doll... just what I always wanted! - Clara signature.asc Description: PGP signature

Re: BIND doesn't listen to other loopback addresses

On Sunday, July 6, 2025 2:34:58 AM CEST Bagas Sanjaya wrote: > options { > ... > listen-on-v6 { none; }; > listen-on { 127.0.0.53; 192.168.0.155; }; > ... > }; Omit 127.0.0.53, like so: options { listen-on { 192.168.0.155; }; }; Works fine

Re: BIND doesn't listen to other loopback addresses

Listen-on is an acl. The interface table is scanned for matches which are then bound to. This is documented behaviour. -- Mark Andrews > On 6 Jul 2025, at 10:35, Bagas Sanjaya wrote: > > Hi, > > I notice BIND's address binding behavior (bug?). I'm running BIND from > git (9.21.10-dev (Deve

Re: question about resolving of AAAA amazoses.com

Another operational impact of these broken servers, broken DNS64. BIND wants to verify no records exist for a QNAME before synthesizing records, but since it can’t get a valid denial of existence, it won’t return synthesized s. On Sat, Jul 5, 2025 at 6:44 AM Bagas Sanjaya wrote: > On 7

Re: question about resolving of AAAA amazoses.com

On 7/5/25 19:17, Jeff Sumner wrote: Apologies for the lack of clarity. We performed a major F5 upgrade recently – for which we were delegating some zones from our ISC BIND servers (just Plain Old NS record delegation) and ever since then, clients using nslookup and host, which query the BIND

Re: question about resolving of AAAA amazoses.com

in the sniffer – so the BIND servers are acting correctly – the F5s are not. We’re working that through. J From: Bagas Sanjaya Date: Saturday, July 5, 2025 at 8:12 AM To: Jeff Sumner , bind-users@lists.isc.org Subject: Re: question about resolving of amazoses.com On 7/5/25 18:55, Jeff

Re: question about resolving of AAAA amazoses.com

On 7/5/25 18:55, Jeff Sumner wrote: Doing battle with the exact same problem – from an over-the-weekend F5 upgrade. So funny this is coming up now. We’re not considering a code upgrade yet, but users are complaining about the Real ISC-BIND servers returning SERVFAIL for queries (not subz

Re: question about resolving of AAAA amazoses.com

“Not considering a code reversion on the F5’s yet” (not upgrade) J From: Jeff Sumner Date: Saturday, July 5, 2025 at 7:55 AM To: bind-users@lists.isc.org Subject: Re: question about resolving of amazoses.com Doing battle with the exact same problem – from an over-the-weekend F5 upgrade

Re: question about resolving of AAAA amazoses.com

servers. J From: bind-users on behalf of Ondřej Surý Date: Saturday, July 5, 2025 at 12:03 AM To: Florian Piekert Cc: bind-users@lists.isc.org Subject: Re: question about resolving of amazoses.com Specifically in this case the incorrect chain starts here: > $ dig IN feedback-smtp

Re: question about resolving of AAAA amazoses.com

Specifically in this case the incorrect chain starts here: > $ dig IN feedback-smtp.us-east-1.amazonses.com @ns-265.awsdns-33.com. > > ; <<>> DiG 9.21.8-1+0~20250521.138+debian12~1.gbpefbbeb-Debian <<>> IN > feedback-smtp.us-east-1.amazonses.com @ns-265.awsdns-33.com. > ;; global optio

Re: question about resolving of AAAA amazoses.com

Hello and many thanks for the quick all-answering response! Thanks for Greg as well, I leave it to Petr's answer then :-) Am 04.07.2025 um 10:13 schrieb Petr Špaček: On 04. 07. 25 9:56, Florian Piekert via bind-users wrote: Hello all, I frequently have this in my logs May  4 14:29:16 sonne

Re: question about resolving of AAAA amazoses.com

On 04. 07. 25 9:56, Florian Piekert via bind-users wrote: Hello all, I frequently have this in my logs May  4 14:29:16 sonne named[4035767]: DNS format error from 2600:9000:5303:c800::1#53 resolving feedback-smtp.us- east-1.amazonses.com/ for 127.0.0.1#44099: Name us- east-1.amazonses.co

Re: question about resolving of AAAA amazoses.com

Hi Florian. Well since you mention it, may we see your BIND configuration? Also "named -V", please and, if you can, a packet capture (preferably binary pcap, not just a few lines of tcpdump output) showing what your server is doing at the time you see these messages in the logs. Cheers, Greg On F

Re: Significant memory usage

Am 02.07.2025 um 09:46 schrieb Doug Freed: You are correct; the syntax of response-policy is very unique. response-policy {   zone "foo" ; } ; It is the semicolon which ends a statement, not the closing curly bracket of a block, which is why all blocks have to end in a semicolon too. thank

Re: Significant memory usage

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

Re: Significant memory usage

On 7/1/25 23:55, Lee wrote: On Tue, Jul 1, 2025 at 11:14 PM Matthias Fechner wrote: Am 01.07.2025 um 22:23 schrieb Lee: response-policy { zone "rpz.foo"; zone "rpz.bar"; zone "rpz.pgl"; } break-dnssec yes recursive-only no qname-wait-recurse no; should these 3 line

Re: Significant memory usage

On Tue, Jul 1, 2025 at 11:14 PM Matthias Fechner wrote: > > Am 01.07.2025 um 22:23 schrieb Lee: > >response-policy { zone "rpz.foo"; zone "rpz.bar"; zone "rpz.pgl"; } > > break-dnssec yes > > recursive-only no > > qname-wait-recurse no; > > should these 3 lines (break-dnssec

Re: Significant memory usage

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

Re: Significant memory usage

Am 01.07.2025 um 22:23 schrieb Lee: response-policy { zone "rpz.foo"; zone "rpz.bar"; zone "rpz.pgl"; } break-dnssec yes recursive-only no qname-wait-recurse no; should these 3 lines (break-dnssec , ...) not inside the response-policy block? Otherwise it is applied to the

Re: Server crash on receiving query

Looks like current betas of Tahoe and Sonoma fix this kernel bug! On 7 Nov 2024, at 12:18 am, Ondřej Surý wrote: Since the libuv bug is in the open, I’ll link it here as well: https://github.com/libuv/libuv/issues/4594

Re: Significant memory usage

Thank you Ondrej! I changed my scripts to apply the hosts in this manner moving forward. Everything appears to be working as before, with significantly less memory usage, which is awesome! Still, I think the memory usage for the way I had it setup before shouldn't drastically increase in new ver

Re: Significant memory usage

Good point. As this is local setup, it makes much sense to use qname-wait-recurse no; this saves both time and bandwidth as this is of no concern (from documentation): > No DNS records are needed for a QNAME or Client-IP trigger; the name or IP > address itself is sufficient, so in principle the

Re: Significant memory usage

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 tha

Re: Significant memory usage

On Tue, Jul 1, 2025 at 2:33 PM OwN-3m-All wrote: > > No, I'm not asking you to prioritize anything. I'm just saying that > previously valid and memory performant setups are not performing well on the > newest versions of bind (using too much memory). c'est la vie > I created this setup based o

Re: Significant memory usage

Also, 127.0.0.1 (localhost) needs to be returned for these hosts, not a NXDOMAIN response. Would that impact 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 ht

Re: Significant memory usage

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

Re: Significant memory usage

No, I'm not asking you to prioritize anything. I'm just saying that previously valid and memory performant setups are not performing well on the newest versions of bind (using too much memory). I created this setup based on guides I found online. So, if this is not the proper way to do it, what

Re: Significant memory usage

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 0

Re: Significant memory usage

Hi, thanks for providing a reproducer. Just to give some rough numbers for the various branches we have (9.18, 9.20 and development): BIND 9.18 (bind-9.18 branch HEAD) $ smem -P name[d] PID User Command Swap USS PSS RSS 450020 ondrej named0 3233560 3234515

Re: Significant memory usage

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

Re: Significant memory usage

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

Re: Significant memory usage

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

Re: Is there any method/config to pass through rcode refused

On 01/07/2025 10:05, Neil Nie (NSB) wrote: Hi Neil, I found that bind9 (as forwarder) always overwrite rcode refused to rcode servfail. For one use-case, the dns client wants to get original rcode (like refused). Please advise if there is any config or method to achieve that. A resolver tries

Re: Is there any method/config to pass through rcode refused

Hi Neil. Think about what a resolver is doing. A client asks it a question, usually with the RD bit set, meaning essentially, do whatever you have to do to get me my answer. So the resolver attempts to find that answer, somehow. If it already has it in cache, great. If it doesn't it may recurse,

Re: stray conflict marker on ARM docs

On Mon, Jun 23, 2025 at 12:32:10PM +0200, Petr Špaček wrote: > On 23. 06. 25 12:23, Bagas Sanjaya wrote: > > Hi Aydın, > > > > When I look at ARM docs (`doc/arm/build.inc.rst`) since your Meson > > build conversion in 5cd6c173ff74 (replace the build system with meson, > > 2024-04-16), > > I see s

Re: stray conflict marker on ARM docs

On 23. 06. 25 12:23, Bagas Sanjaya wrote: Hi Aydın, When I look at ARM docs (`doc/arm/build.inc.rst`) since your Meson build conversion in 5cd6c173ff74 (replace the build system with meson, 2024-04-16), I see stray conflict marker remains: <<< HEAD For line editing in :iscman:`nsupdate` a

Re: Problem with latest Docker image

Hi Randy, I've not used the docker images or "geoip-directory", but the error message you found sounds like support for this is a compile time option that was not enabled. Perhaps check your configuration. Does it contain "geoip-directory"? Do you need this support? If not, I suggest disabling

Re: Problem with latest Docker image

Hey Randy, you haven’t specified previous version you’ve been using, but nothing expect the version has changed between 9.20.8 and 9.20.9 and between 9.20.9 and 9.20.10: https://gitlab.isc.org/isc-projects/bind9-docker/-/commits/v9.20?ref_type=heads You can change the command like of named fro

Re: dnssec/obsolete dns keys removal - how to?

On 21/06/2025 05:16, Florian Piekert via bind-users wrote: Hello, wow, that did the trick. I didn't think of this at all. It -after all- appeared to be VERY obvious. I don't know why I overlooked this possibilty. THANK YOU! Am 20.06.2025 um 19:03 schrieb Crist Clark: Do you have a .signed f

Re: dnssec/obsolete dns keys removal - how to?

Hello, wow, that did the trick. I didn't think of this at all. It -after all- appeared to be VERY obvious. I don't know why I overlooked this possibilty. THANK YOU! Am 20.06.2025 um 19:03 schrieb Crist Clark: Do you have a .signed file that BIND created? To be 100%, shutdown named, kill that

Re: Significant memory usage

Ok. And what are your observations? Or do you expect us to debug your issue and interpret the outputs you send here for you? As a side note, the rndc outputs you are pasting into your emails are mostly useless to debug memory issues. Ondrej -- Ondřej Surý — ISC (He/Him) My working hours and y

Re: Significant memory usage

I’ve been running for 12+ hours with a max-cache-size of 256M (since I’m on a machine with 2GB that does a lot of data reduction as it’s a honeypot firewall). This is what I’ve collected. +++ Statistics Dump +++ (1749514002) ++ Incoming Requests ++ 203077 QUERY 12014

Re: Significant memory usage

I take it back, it does at the beginning of the manual. It would be helpful if all references to had links back to the explanation. Odd that when you specify a percentage the effective amount is logged by named, but when you specify an absolute amount it’s not. > On Jun 8, 2025, at 10:46 P

Re: Significant memory usage

Actually it does https://bind9.readthedocs.io/en/v9.20.9/reference.html#term-sizeval -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" > On 9 Jun 2025, at 06.47, Philip Prindeville via bind-users > wrote: > > I read: > > https://bind9.readthedocs.io/en

Re: Significant memory usage

I read: https://bind9.readthedocs.io/en/v9.20.9/reference.html#namedconf-statement-max-cache-size and it doesn’t explain the notation for . > On Jun 8, 2025, at 10:39 PM, Ondřej Surý wrote: > > What If you actually read the manual that I sent you - syntax of sizeval is > explained there. >

Re: Significant memory usage

What If you actually read the manual that I sent you - syntax of sizeval is explained there. -- 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 9. 6. 2025, at 6:34, Philip Prindevi

Re: Significant memory usage

Maybe GB is the only unit it groks. Jun 8 22:31:52 OpenWrt named[19145]: /etc/bind/named.conf:42: expected integer and optional unit or percent near ‘1536MB’ Nope: Jun 8 22:32:48 OpenWrt named[19609]: /etc/bind/named.conf:43: expected integer and optional unit or percent near ‘2GB' > On

Re: Significant memory usage

It does have the effect. Also there’s BIND 9 ARM at https://bind9.readthedocs.io/en/v9.20.9/ -- Ondřej Surý — ISC (He/Him) My working hours and your working hours may be differentw . Please do not feel obligated to reply outside your normal working hours. > On 9. 6. 2025, at 6:20, Philip Prinde

Re: Significant memory usage

Jun 8 22:22:10 OpenWrt named[15142]: /etc/bind/named.conf:42: expected integer and optional unit or percent near '1638MB' > On Jun 8, 2025, at 10:17 PM, Ondřej Surý wrote: > > Yes, there's no math involved, it just honors the limit. > > FTR you can also say: > > max-cache-size 2GB; > > You

Re: Significant memory usage

I’ll try to get a smoking gun. How do you configure an explicit number of bytes with max-cache-size? The manpage says: max-cache-size ( default | unlimited | | ); but doesn’t explain the syntax of “sizeval”. I tried “1638M” but that doesn’t seem to have an effect. > On Jun 8, 2025, at 10

Re: Significant memory usage

Yes, there's no math involved, it just honors the limit. FTR you can also say: max-cache-size 2GB; You don't have to specify it to the last byte. 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 outsi

Re: Significant memory usage

I don't see anything wrong with the memory in the attached file - 13MB doesn't seem to be causing any havoc. And it roughly matches what I am seeing here with fresh named instance on 64-bit machine: $ smem -P name[d] PID User Command Swap USS PSS RSS

Re: Significant memory usage

Odd. I tried: max-cache-size 1717986918; and restarted and I don’t see anything in the logs about it. But I did when I used a percentage. > On Jun 8, 2025, at 10:02 PM, Ondřej Surý wrote: > > The 1.7GB is what the system is reporting. That’s why I asked as I’ve seen > OpenWRT repo

Re: Significant memory usage

The 1.7GB is what the system is reporting. That’s why I asked as I’ve seen OpenWRT reporting weird or no values before. 171MB cache is little on a low side and negative effects from overmem LRU cleaning will going to hurt the performance. I would suggest to set a fixed size for the cache - 1.6G

Re: Significant memory usage

This is on an embedded system, i.e. a 4-core AMD64 low-power machine with 16GB of memory, that uses 2GB of that as a tmpfs. 90% would cripple the system. I’m going to try 10% (after all, it’s only doing name service for 200 machines, maybe 450 RRs, and more than have of the machines are IoTs t

Re: Significant memory usage

Working on it: https://github.com/openwrt/packages/pull/26721 Here’s my statistics-channel output: named-stats.xml Description: XML document > On May 18, 2025, at 10:30 PM, Ondřej Surý wrote: > > Well, you’ve provided basically nothing as leads, so it is hard to tell > what’s going on w

Re: Significant memory usage

Does the named report proper max-cache-size into the log when starting? Something like: 'max-cache- size 90%' - setting to 86522MB (out of 96136MB) 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

Re: Significant memory usage

> On Jun 8, 2025, at 3:07 PM, Philip Prindeville via bind-users > wrote: > > > >> On May 21, 2025, at 3:38 PM, Ben Scott wrote: >> >> - Original Message - >>> From: "Philip Prindeville via bind-users" >>> To: "bind-users" >>> Sent: Sunday, May 18, 2025 5:20:59 PM >>> Subject: Sig

Re: Significant memory usage

> On May 21, 2025, at 3:38 PM, Ben Scott wrote: > > - Original Message - >> From: "Philip Prindeville via bind-users" >> To: "bind-users" >> Sent: Sunday, May 18, 2025 5:20:59 PM >> Subject: Significant memory usage > >> What I’ve noticed is that at startup I’m using about 33K pages

Re: Significant memory usage

> On May 21, 2025, at 3:38 PM, Ben Scott wrote: > > - Original Message - >> From: "Philip Prindeville via bind-users" >> To: "bind-users" >> Sent: Sunday, May 18, 2025 5:20:59 PM >> Subject: Significant memory usage > >> What I’ve noticed is that at startup I’m using about 33K pages

Re: DNSSEC Validation not working

Hi Luca, This is correct: dnssec-validation auto; If you use "yes" there, then you must supply a trust anchor. Auto is the default. The only idea I have is this: zone "." IN { type hint; file "named.ca"; }; You don't need this anymore. BIND 9.18 will automatically find the root zones starting

Re: QNAME minimisation question

On 04/06/2025 18:50, Greg Choules wrote: The help text for delv says you can specify a source using -b, the same as you can with dig: Usage:  delv [@server] {q-opt} {d-opt} [domain] [q-type] [q-class] Where:  domain  is in the Domain Name System         q-class  is one of (in,hs,ch,...) [defaul

Re: Significant Throughput Drop in BIND 9.20.8 for Batch DNS Updates – Seeking Community Insights and Solutions

On 6/5/25 06:50, Sahil Sharma D via bind-users wrote: *_Use case :_*// Trying to load 120M identifier of length 15 digit which will load in zone using nsupdate in a batch of 1000. A file created having 120M identifier and sent to nsupdate in a batch of 1000 to add identifier in bind. _Befo

Re: QNAME minimisation question

The help text for delv says you can specify a source using -b, the same as you can with dig: Usage: delv [@server] {q-opt} {d-opt} [domain] [q-type] [q-class] Where: domain is in the Domain Name System q-class is one of (in,hs,ch,...) [default: in] q-type is one of (a,any,mx,

Re: QNAME minimisation question

Hi Stace. The transport protocol used to ask the question is (or should be) independent of the question being asked. So in this case asking for a PTR record for an IPv6 address wouldn't change whether IPv4 or IPv6 is used to make the recursive queries. I've done a bit more testing on this, a

Re: QNAME minimisation question

On 03/06/2025 22:06, Petr Špaček wrote: I've created https://gitlab.isc.org/isc-projects/bind9/-/issues/5351 so we can improve logging. Your input on what sort of information is useful would be much appreciated. Thanks very much for that. I've added a comment. :-) -- Visit https://lists.isc.or

Re: QNAME minimisation question

On 6/3/25 11:29, Nick Tait wrote: On 02/06/2025 23:30, Petr Špaček wrote: In short, with an empty cache, BIND will exceed pre-configured limit on number of queries it can do. This is protection from various attacks which misuse DNS to attack itself. Thanks for the explanation! This particula

Re: QNAME minimisation question

On 6/3/25 12:06, Petr Špaček wrote: On 6/3/25 11:29, Nick Tait wrote: On 02/06/2025 23:30, Petr Špaček wrote: In short, with an empty cache, BIND will exceed pre-configured limit on number of queries it can do. This is protection from various attacks which misuse DNS to attack itself. Thanks

Re: QNAME minimisation question

On 3 Jun 2025, at 10:29, Nick Tait via bind-users wrote: > But I also noticed that delv only makes A queries (not ), and even if I > specify "-6" on the command-line it makes no difference? Have yo tried using an IPv6 address with the -x option? delv -x :::45.90.5.195 +ns +qmin +maxque

Re: QNAME minimisation question

On 02/06/2025 23:30, Petr Špaček wrote: In short, with an empty cache, BIND will exceed pre-configured limit on number of queries it can do. This is protection from various attacks which misuse DNS to attack itself. Thanks for the explanation! This particular recursive query doesn't seem espe

Re: QNAME minimisation question

On 6/2/25 12:01, Nick Tait via bind-users wrote: I can reproduce the issue by clearing the BIND cache, and then running the following DIG command, to attempt a reverse DNS lookup of 45.90.5.195 On 6/2/25 12:54, Carlos Horowicz via bind-users wrote: The problem seems related to "No zone cut at

Re: QNAME minimisation question

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

Re: Limit the number of Additional RR in an Answer

Hi Jeremy Thanks for the Link > Can you share an example here of the NAPTR or SRV query resulting in > Additional section records? The additional sections make sense to me, they avoid further A/ lookups but I suspect they might be the cause for the crashed of small memory CPE's. I have one

Re: Limit the number of Additional RR in an Answer

> To further dig into that direction, I was asking Google if there is a > bind setting to limit or disable the sending of additional RR with an > answer but could not find such a setting. > > * Is there such a setting? See minimal-responses in the ARM https://bind9.readthedocs.io/en/stable/refere

Re: Dns tunnel detection/prevention

On Saturday, May 24, 2025 3:53:57 AM CEST Fred Morris wrote: > On Fri, 23 May 2025, Grant Taylor via bind-users wrote: > > I don't think there is anything that I would describe that way. But there > > may be some rate limiting option(s) that you could use to at least cripple > > using DNS queries

Re: Dns tunnel detection/prevention

On 5/23/25 8:53 PM, Fred Morris wrote: If you fail in an outright, reproducible, measurable fashion you give your opponent predictability and confidence. As a defender you want to undermine that and look like an under-resourced, poorly administered network that somehow, we don't know exactly ho

Re: Dns tunnel detection/prevention

On Fri, 23 May 2025, Grant Taylor via bind-users wrote: On 5/22/25 9:23 AM, Karol Nowicki via bind-users wrote: Does ISC Bind software by native has any dns tunneling prevention embedded ? I don't think there is anything that I would describe that way. But there may be some rate limiting

Re: Dns tunnel detection/prevention

On 5/22/25 9:23 AM, Karol Nowicki via bind-users wrote: Does ISC Bind software by native has any dns tunneling prevention embedded ? I don't think there is anything that I would describe that way. But there may be some rate limiting option(s) that you could use to at least cripple using DNS

Re: Migration to inline-signing

an you tell me the error message? I would not expect the zone stopping > from loading, but it's hard to tell without full configuration. > > Note that when switching, signatures and NSEC records from the dynamic > zone would be removed and moving to inline-signing requires a full >

Re: Dns tunnel detection/prevention

On Thursday, May 22, 2025 4:23:05 PM CEST Karol Nowicki via bind-users wrote: > Does ISC Bind software by native has any dns tunneling prevention embedded? > Thanks BIND on its own does not do this. Assuming that you are running it on a LAN as a resolver meanwhile, you can make it the only thing

  1   2   3   4   5   6   7   8   9   10   >