AW: AW: Problem resolving a host wenn TTL of NS-Servers runs out
TLP:AMBER Hi I can confirm, on my test containers running 9.20.20 and 9.18.46, the problem is solved. Thanks a lot for your help! Regards, Christian -Ursprüngliche Nachricht- Von: Colin Vidal Gesendet: Mittwoch, 28. Jänner 2026 23:24 An: Melbinger Christian Cc: bind-users ; Ondřej Surý Betreff: Re: AW: Problem resolving a host wenn TTL of NS-Servers runs out Hi, Thanks for those precision. As the resolver detects a loop while attempting the resolution using IPv4 servers it bails off from there. I think this is the reason why `dual-stack-servers` is not helping. I was able to reproduce the problem locally and have full log of it, I'll investigate more tomorrow. While there is a misconfiguration on the authoritative side (the TTL of the name servers at the delegation should be the same as in the child zone), this sounds like something's wrong in the resolver anyway. -- Colin Vidal -- [email protected] Internet Systems Consortium WienIT GmbH, Thomas-Klestil-Platz 13, 1030 Wien, FN 255649 f, Handelsgericht Wien, DVR: 2109667, UID-Nr. ATU61296118 -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list.
Re: AW: Problem resolving a host wenn TTL of NS-Servers runs out
Hi,
>> Back to the problem, you can give a try to `dual-stack-servers`
> Hm, sadly, that did not work. It sounds like a workaround that I could
> implement, and the description sounds exactly like what I need, but even after
> completely stopping and starting the container, the named didn't try to query
> the upstream server.
>
> I created a test-instance and modified the named.conf to include the statement
> # docker exec -ti named-test named-checkconf -px
> [...]
> options {
>directory "/var/cache/bind";
>hostname "unknown";
>listen-on {
>"any";
>};
>version "unknown";
>allow-recursion {
>"rec-queries";
>};
>dnssec-validation no;
>dual-stack-servers {
>9.9.9.9;
>149.112.112.112;
>};
>allow-transfer {
>};
>notify no;
> };
> [...]
>
>
> But the named never asked one of those quad9 server. I even checked with a
> tcpdump on the physical-interface, no traffic.
> (When issuing a dig from within a container shell, directly to quad9, I can
> successfully contact both IPs. At least not a network issue)
>
>
> Here are the logs with level 5 set.
>
> 27-Jan-2026 14:58:08.021 client @0x7f5953b18000 198.18.1.1#46760: UDP request
> 27-Jan-2026 14:58:08.022 client @0x7f5953b18000 198.18.1.1#46760: using view
> '_default'
> 27-Jan-2026 14:58:08.022 client @0x7f5953b18000 198.18.1.1#46760: request is
> not
> signed
> 27-Jan-2026 14:58:08.022 client @0x7f5953b18000 198.18.1.1#46760: recursion
> available
> 27-Jan-2026 14:58:08.022 client @0x7f5953b18000 198.18.1.1#46760
> (www.semigator.de): query (cache) 'www.semigator.de/A/IN' approved
> 27-Jan-2026 14:58:08.022 fetch: www.semigator.de/A
> 27-Jan-2026 14:58:08.022 QNAME minimization - not minimized, qmintype 1
> qminname
> www.semigator.de
> 27-Jan-2026 14:58:08.022 expiring v4 for name 0x7f59521a7000
> 27-Jan-2026 14:58:08.022 fetch: ns1.haufegroup.de/A
> 27-Jan-2026 14:58:08.022 QNAME minimization - not minimized, qmintype 1
> qminname
> ns1.haufegroup.de
> 27-Jan-2026 14:58:08.022 dns_adb_createfind: started A fetch for name
> ns1.haufegroup.de (0x7f59521a7000)
> 27-Jan-2026 14:58:08.022 createfind: attaching find 0x7f595408cc40 to adbname
> 0x7f59521a7000 1
> 27-Jan-2026 14:58:08.022 fctx 0x7f59540e(www.semigator.de/A): createfind
> for
> 198.18.1.1#46760 - success
> 27-Jan-2026 14:58:08.022 expiring v4 for name 0x7f59521a7380
> 27-Jan-2026 14:58:08.022 fetch: ns2.haufegroup.com/A
> 27-Jan-2026 14:58:08.022 QNAME minimization - not minimized, qmintype 1
> qminname
> ns2.haufegroup.com
> 27-Jan-2026 14:58:08.022 dns_adb_createfind: started A fetch for name
> ns2.haufegroup.com (0x7f59521a7380)
> 27-Jan-2026 14:58:08.022 createfind: attaching find 0x7f595408cd00 to adbname
> 0x7f59521a7380 1
> 27-Jan-2026 14:58:08.022 fctx 0x7f59540e(www.semigator.de/A): createfind
> for
> 198.18.1.1#46760 - success
> 27-Jan-2026 14:58:08.022 fetch: ns1.haufegroup.de/A
> 27-Jan-2026 14:58:08.022 fetch loop detected resolving 'ns1.haufegroup.de/A'
> 27-Jan-2026 14:58:08.022 fctx 0x7f59540e1400(ns1.haufegroup.de/A): createfind
> for - success
> 27-Jan-2026 14:58:08.022 dns_adb_destroyfind on find 0x7f595408cdc0
> 27-Jan-2026 14:58:08.022 createfind: attaching find 0x7f595408cdc0 to adbname
> 0x7f59521a7380 0
> 27-Jan-2026 14:58:08.022 fctx 0x7f59540e1400(ns1.haufegroup.de/A): createfind
> for - success
> 27-Jan-2026 14:58:08.022 createfind: attaching find 0x7f595408ce80 to adbname
> 0x7f59521a7000 0
> 27-Jan-2026 14:58:08.022 fctx 0x7f5954119c00(ns2.haufegroup.com/A): createfind
> for - success
> 27-Jan-2026 14:58:08.022 fetch: ns2.haufegroup.com/A
> 27-Jan-2026 14:58:08.022 fetch loop detected resolving 'ns2.haufegroup.com/A'
> 27-Jan-2026 14:58:08.022 fctx 0x7f5954119c00(ns2.haufegroup.com/A): createfind
> for - success
> 27-Jan-2026 14:58:08.022 dns_adb_destroyfind on find 0x7f595408cf40
> 27-Jan-2026 14:58:09.021 client @0x7f5953013000 198.18.1.1#53774: UDP request
> 27-Jan-2026 14:58:09.021 client @0x7f5953013000 198.18.1.1#53774: using view
> '_default'
> 27-Jan-2026 14:58:09.021 client @0x7f5953013000 198.18.1.1#53774: request is
> not
> signed
> 27-Jan-2026 14:58:09.021 client @0x7f5953013000 198.18.1.1#53774: recursion
> available
> 27-Jan-2026 14:58:09.021 client @0x7f5953013000 198.18.1.1#53774
> (www.semigator.de): query (cache) 'www.semigator.de/A/IN' approved
> 27-Jan-2026 14:58:09.021 fetch: www.semigator.de/A
> 27-Jan-2026 14:58:14.021 client @0x7f5953b19c00 (no-peer): allocate new client
> 27-Jan-2026 14:58:14.021 client @0x7f5953b19c00 198.18.1.1#46760: UDP request
> 27-Jan-2026 14:58:14.021 client @0x7f5953b19c00 198.18.1.1#46760: using view
> '_default'
> 27-Jan-2026 14:58:14.021 client @0x7f5953b19c00 198.18.1.1#46760: request is
> not
> signed
> 27-Jan-2026 14:58:14.021 client @0x7f5953b19c00 198.18.1.1#46760: recursion
> available
> 27-Jan-2026 14:58:14.021 client @0x7f
AW: Problem resolving a host wenn TTL of NS-Servers runs out
Hi
> Also, the ACL `FE80::` suggested you would except the resolver to listen to
> IPv6 locally
You're right, FE80:: and ::1 make no sense with all ipv6 disabled. It can never
receive a query on those ranges.
> Back to the problem, you can give a try to `dual-stack-servers`
Hm, sadly, that did not work. It sounds like a workaround that I could
implement, and the description sounds exactly like what I need, but even after
completely stopping and starting the container, the named didn't try to query
the upstream server.
I created a test-instance and modified the named.conf to include the statement
# docker exec -ti named-test named-checkconf -px
[...]
options {
directory "/var/cache/bind";
hostname "unknown";
listen-on {
"any";
};
version "unknown";
allow-recursion {
"rec-queries";
};
dnssec-validation no;
dual-stack-servers {
9.9.9.9;
149.112.112.112;
};
allow-transfer {
};
notify no;
};
[...]
But the named never asked one of those quad9 server. I even checked with a
tcpdump on the physical-interface, no traffic.
(When issuing a dig from within a container shell, directly to quad9, I can
successfully contact both IPs. At least not a network issue)
Here are the logs with level 5 set.
27-Jan-2026 14:58:08.021 client @0x7f5953b18000 198.18.1.1#46760: UDP request
27-Jan-2026 14:58:08.022 client @0x7f5953b18000 198.18.1.1#46760: using view
'_default'
27-Jan-2026 14:58:08.022 client @0x7f5953b18000 198.18.1.1#46760: request is
not signed
27-Jan-2026 14:58:08.022 client @0x7f5953b18000 198.18.1.1#46760: recursion
available
27-Jan-2026 14:58:08.022 client @0x7f5953b18000 198.18.1.1#46760
(www.semigator.de): query (cache) 'www.semigator.de/A/IN' approved
27-Jan-2026 14:58:08.022 fetch: www.semigator.de/A
27-Jan-2026 14:58:08.022 QNAME minimization - not minimized, qmintype 1
qminname www.semigator.de
27-Jan-2026 14:58:08.022 expiring v4 for name 0x7f59521a7000
27-Jan-2026 14:58:08.022 fetch: ns1.haufegroup.de/A
27-Jan-2026 14:58:08.022 QNAME minimization - not minimized, qmintype 1
qminname ns1.haufegroup.de
27-Jan-2026 14:58:08.022 dns_adb_createfind: started A fetch for name
ns1.haufegroup.de (0x7f59521a7000)
27-Jan-2026 14:58:08.022 createfind: attaching find 0x7f595408cc40 to adbname
0x7f59521a7000 1
27-Jan-2026 14:58:08.022 fctx 0x7f59540e(www.semigator.de/A): createfind
for 198.18.1.1#46760 - success
27-Jan-2026 14:58:08.022 expiring v4 for name 0x7f59521a7380
27-Jan-2026 14:58:08.022 fetch: ns2.haufegroup.com/A
27-Jan-2026 14:58:08.022 QNAME minimization - not minimized, qmintype 1
qminname ns2.haufegroup.com
27-Jan-2026 14:58:08.022 dns_adb_createfind: started A fetch for name
ns2.haufegroup.com (0x7f59521a7380)
27-Jan-2026 14:58:08.022 createfind: attaching find 0x7f595408cd00 to adbname
0x7f59521a7380 1
27-Jan-2026 14:58:08.022 fctx 0x7f59540e(www.semigator.de/A): createfind
for 198.18.1.1#46760 - success
27-Jan-2026 14:58:08.022 fetch: ns1.haufegroup.de/A
27-Jan-2026 14:58:08.022 fetch loop detected resolving 'ns1.haufegroup.de/A'
27-Jan-2026 14:58:08.022 fctx 0x7f59540e1400(ns1.haufegroup.de/A): createfind
for - success
27-Jan-2026 14:58:08.022 dns_adb_destroyfind on find 0x7f595408cdc0
27-Jan-2026 14:58:08.022 createfind: attaching find 0x7f595408cdc0 to adbname
0x7f59521a7380 0
27-Jan-2026 14:58:08.022 fctx 0x7f59540e1400(ns1.haufegroup.de/A): createfind
for - success
27-Jan-2026 14:58:08.022 createfind: attaching find 0x7f595408ce80 to adbname
0x7f59521a7000 0
27-Jan-2026 14:58:08.022 fctx 0x7f5954119c00(ns2.haufegroup.com/A): createfind
for - success
27-Jan-2026 14:58:08.022 fetch: ns2.haufegroup.com/A
27-Jan-2026 14:58:08.022 fetch loop detected resolving 'ns2.haufegroup.com/A'
27-Jan-2026 14:58:08.022 fctx 0x7f5954119c00(ns2.haufegroup.com/A): createfind
for - success
27-Jan-2026 14:58:08.022 dns_adb_destroyfind on find 0x7f595408cf40
27-Jan-2026 14:58:09.021 client @0x7f5953013000 198.18.1.1#53774: UDP request
27-Jan-2026 14:58:09.021 client @0x7f5953013000 198.18.1.1#53774: using view
'_default'
27-Jan-2026 14:58:09.021 client @0x7f5953013000 198.18.1.1#53774: request is
not signed
27-Jan-2026 14:58:09.021 client @0x7f5953013000 198.18.1.1#53774: recursion
available
27-Jan-2026 14:58:09.021 client @0x7f5953013000 198.18.1.1#53774
(www.semigator.de): query (cache) 'www.semigator.de/A/IN' approved
27-Jan-2026 14:58:09.021 fetch: www.semigator.de/A
27-Jan-2026 14:58:14.021 client @0x7f5953b19c00 (no-peer): allocate new client
27-Jan-2026 14:58:14.021 client @0x7f5953b19c00 198.18.1.1#46760: UDP request
27-Jan-2026 14:58:14.021 client @0x7f5953b19c00 198.18.1.1#46760: using view
'_default'
27-Jan-2026 14:58:14.021 client @0x7f5953b19c00 198.18.1.1#46760: request is
not signed
27-Jan-2026 14:58:14.021 client @0x7f5953b19c00 198.18.1.1#46760: recursion
available
27-Jan-2026 14:58:14
AW: Problem resolving a host wenn TTL of NS-Servers runs out
Hi
In case I offended anyone, I'm sorry, that was not my intention. Writing
"strongly disagree" was a bit too much.
I will gladly show my setup in more detail. I've spun up a test instance to
eliminate background noise and reduce the config even more.
Here's the docker container config:
# cat docker-compose.yml
services:
named-test:
container_name: named-test
hostname: named-test
image: internetsystemsconsortium/bind9:9.20
# Overruling the entrypoint with "-4" to disable all ipv6, and "-d 5 -g" to
enable debugging and sending it to stderr (thus docker logs)
entrypoint: /usr/sbin/named -f -c /etc/bind/named.conf -u bind -4 -d 5 -g
ports:
- "3053:53/udp" # Exposing to a custom port
- "3053:53/tcp" # Exposing to a custom port
volumes:
- etc-bind:/etc/bind
- cache:/var/cache/bind
- lib:/var/lib/bind
- log:/var/log
volumes:
etc-bind:
cache:
lib:
log:
My server uses a non standard docker config - nothing fancy, most notably a
custom bridge domain
# cat /etc/docker/daemon.json
{
"log-driver": "json-file",
"log-opts": {
"max-size": "10m",
"max-file": "3"
},
"bip": "198.18.0.1/24",
"default-address-pools": [
{
"base": "198.18.0.0/15",
"size": 24
}
],
"default-ulimits": {
"memlock": {
"name": "memlock",
"soft": -1,
"hard": -1
},
"nofile": {
"Hard": 1048576,
"Name": "nofile",
"Soft": 1048576
}
}
}
Here's the output of the running bind config. 198.18.0.0/15 is said bridge
domain.
# docker exec -ti named-test named-checkconf -px
acl "rec-queries" {
10.0.0.0/8;
192.168.0.0/16;
127.0.0.0/8;
172.16.0.0/12;
::1/128;
fe80::/128;
198.18.0.0/15;
};
controls {
inet 127.0.0.1 allow {
"localhost";
} keys {
"rndc-key";
};
};
logging {
channel "default_syslog" {
stderr ;
severity dynamic;
print-time yes;
};
category "default" {
"default_syslog";
};
};
options {
directory "/var/cache/bind";
hostname "unknown";
listen-on {
"any";
};
version "unknown";
allow-recursion {
"rec-queries";
};
dnssec-validation no;
allow-transfer {
};
notify no;
};
key "rndc-key" {
algorithm "hmac-sha256";
secret "";
};
zone "localhost" {
type master;
file "/etc/bind/db.local";
};
zone "0.in-addr.arpa" {
type master;
file "/etc/bind/db.0";
};
zone "255.in-addr.arpa" {
type master;
file "/etc/bind/db.255";
};
Like before, the first lookup of www.semigator.de works. After an hour, the
A-Records get removed and only the are left.
haufegroup.com. 108454 NS ns1.haufegroup.de.
108454 NS ns2.haufegroup.com.
ns2.haufegroup.com. 108454 2001:67c:10b8::103
haufegroup.de. 22054 NS ns1.haufegroup.de.
22054 NS ns2.haufegroup.com.
ns1.haufegroup.de. 22054 2001:67c:1bc::103
semigator.de. 22054 NS ns1.haufegroup.de.
22054 NS ns2.haufegroup.com.
; ns2.haufegroup.com. [v4 TTL 10] [v4 failure] [v6 unexpected]
; ns1.haufegroup.de. [v4 TTL 10] [v4 failure] [v6 unexpected]
; www.semigator.de/A [ttl 1]
So now when I look up semigator, it fails as expected.
I just realized the named even sends back "EDE: 22 (No Reachable Authority)"
# dig @localhost -p 3053 www.semigator.de
; <<>> DiG 9.16.23-RH <<>> @localhost -p 3053 www.semigator.de
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 45743
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 03805b17f3711725010069788d61252030504cce4759 (good)
; EDE: 22 (No Reachable Authority)
;; QUESTION SECTION:
;www.semigator.de. IN A
;; Query time: 2 msec
;; SERVER: ::1#3053(::1)
;; WHEN: Tue Jan 27 11:03:13 CET 2026
;; MSG SIZE rcvd: 79
With debug level 5, the logfile spills out a lot of information
27-Jan-2026 10:03:01.279 client @0x7fee5d6dd000 198.18.1.1#37717: UDP request
27-Jan-2026 10:03:01.279 client @0x7fee5d6dd000 198.18.1.1#37717: using view
'_default'
27-Jan-2026 10:03:01.279 client @0x7fee5d6dd000 198.18.1.1#37717: request is
not signed
27-Jan-2026 10:03:01.279 clien
AW: Problem resolving a host wenn TTL of NS-Servers runs out
Hi I strongly disagree, as I already start the daemon with the -4 option. It should never user IPv6. -4 This option tells named to use only IPv4, even if the host machine is capable of IPv6. -4 and -6 are mutually exclusive. https://bind9.readthedocs.io/en/v9.18.14/manpages.html#named-internet-domain-name-server And also I just tried it, I added the line under options and reloaded the daemon with docker exec -ti named-prod /usr/sbin/rndc reload It's still not working. there's only the IP in the cache, and it can never reach it... Regards, Christian -Ursprüngliche Nachricht- Von: Colin Vidal Gesendet: Montag, 26. Jänner 2026 16:48 An: Melbinger Christian Cc: bind-users Betreff: Re: Problem resolving a host wenn TTL of NS-Servers runs out [You don't often get email from [email protected]. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] Hi, > Short version: When a NS has A and Records with different TTLs, a > bind with only IPv4 fails to resolve an address once the A-Record > expires and only the is left. I think `query-source-v6 none;` in `options` should solve your problem. https://bind9.readthedocs.io/en/v9.20.18/reference.html#namedconf-statement-query-source-v6 -- Colin Vidal -- [email protected] Internet Systems Consortium WienIT GmbH, Thomas-Klestil-Platz 13, 1030 Wien, FN 255649 f, Handelsgericht Wien, DVR: 2109667, UID-Nr. ATU61296118 -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list.
