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

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 servers (the recursers) are getting ba

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

Re: question about resolving of AAAA amazoses.com

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 subzone, yada yada) against F5 delegated se

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

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

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

BIND doesn't listen to other loopback addresses

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 { ... listen-on-v6 { none; }; listen-on { 127.0.0.53; 192.168.0.155;

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