[Docker] [alle OS] Het grote Docker ervaringen en tips topic

[Dracoz]

RobertMe schreef op dinsdag 21 juli 2026 @ 13:09:
[...]

Als je IPv6 uit zet hoort de lokale DNS resolver dat natuurlijk gewoon te weten en geen AAAA queries af te vuren. De DNS server aan de andere kant kan immers al helemaal niet weten of de client wel of geen IPv6 doet. Immers weet de DNS server al helemaal niks van het netwerk af. Die kan immers ook op een ander systeem dan de router draaien etc etc etc. Het is toch echt de verantwoordelijkheid van de lokale resolver / OS om de juiste queries te doen. En grote kans dat dat zelfs uit het OS komt en niet zozeer uit de lokale resolver. De applicatie zal immers zelf moeten kiezen of die een A, AAAA, TXT, MX, SOA, DS, ... wilt doen. En ja, applicaties kunnen ook zowel A als AAAA tegelijkertijd doen en de voorkeur geven aan het soort dat als eerste een werkende verbinding levert.

Zoals ik zei, Alpine gebruikt de musl libc en die blijft op dns niveau altijd AAAA records opvragen. OPNsense geeft een servfail en daardoor geeft de musl libc bad adress terug.

Een OS zoals bijvoorbeeld Ubuntu zal dit negeren omdat glibc de ipv6 foutmelding negeert en de ipv4 gewoon teruggeeft.

Dit komt dus allemaal omdat die zonetype binnen unbound niet op transparent staat en dus altijd een servfail op ipv6 teruggeeft.

[ Voor 5% gewijzigd door Dracoz op 21-07-2026 13:32 ]

[Dracoz]

tikkietrugjaap schreef op dinsdag 21 juli 2026 @ 13:04:
[...]

Momenteel heb ik al een override voor mijn reverse-proxy dus het override scherm ken ik wel een beetje. Waar ik nu nog mee zit is dat ik niet goed begrijp wat ik zou moeten invullen om binnen Docker containers ook goede DNS te hebben. Ik merk dat ik nog niet helemaal begrijp waarom dit op deze manier gebeurt waardoor het zoeken naar een werkende oplossing een uitdaging is. Hopelijk dat een avondje online speuren mij daar verder in brengt.

Wederom bedankt.

Zet eens een test vm op met bijvoorbeeld ubuntu. Grote kans dat het dan wel werkt omdat die dus glibc gebruiken. Wat je eigenlijk moet doen is zorgen dat je zonetype binnen unbound op transparent staat, dan werkt het ook gewoon binnen alpine etc. Die kun je doen via een .conf bestand

[RobertMe]

Dracoz schreef op dinsdag 21 juli 2026 @ 13:23:
[...]

Zoals ik zei, Alpine gebruikt de musl libc en die blijft op dns niveau altijd AAAA records opvragen. OPNsense geeft een servfail en daardoor geeft de musl libc bad adress terug.

Een OS zoals bijvoorbeeld Ubuntu zal dit negeren omdat glibc de ipv6 foutmelding negeert en de ipv4 gewoon teruggeeft.

Dat lijkt mij gewoon heel sterk. Zou immers betekenen dat Alpine nooit bruikbaar is in een IPv4 only netwerk. En nouja, Alpine is een "vrij populair" base image voor Docker containers en Docker ondersteund pas vrij recent IPv6 (by default). Dus als Alpine zich niks aantrekt van of het OS (/omgeving / container) IPv6 geschikt is dan zou je nooit Alpine als base image hebben kunnen gebruiken (en kan dat nog steeds niet) in een IPv4 omgeving. Waarbij een DNS resolver in het netwerk nog steeds prima op AAAA requests zal antwoorden ook al is die DNS resolver zelf niet via IPv6 met het internet verbonden.

Edit:

$ docker network create --ipv6=false noipv6
9026ff4a7819fcf904732a5a7e80a32b1886e79b3ef8087876ffc2d53ab9426b
$ docker run --rm --network noipv6 -it alpine ash
Unable to find image 'alpine:latest' locally
latest: Pulling from library/alpine
55afa1ecc21d: Already exists
Digest: sha256:28bd5fe8b56d1bd048e5babf5b10710ebe0bae67db86916198a6eec434943f8b
Status: Downloaded newer image for alpine:latest
/ # ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0@if255: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP
    link/ether 02:91:ac:5b:ca:58 brd ff:ff:ff:ff:ff:ff
    inet 172.19.0.2/16 brd 172.19.255.255 scope global eth0
       valid_lft forever preferred_lft forever
/ # ping google.com
PING google.com (172.217.171.110): 56 data bytes
^C
--- google.com ping statistics ---
6 packets transmitted, 0 packets received, 100% packet loss

Werkt dus prima. Ping gaat naar het IPv4 adres. Doe ik ping -6 google.com laat die wel het IP zien maar "Network unreachable". (Er komt geen antwoord omdat de boel in de firewall is dicht getimmerd. Containers mogen niet naar buiten babbelen tenzij expliciet toegestaan).

[ Voor 41% gewijzigd door RobertMe op 21-07-2026 13:42 ]

[synoniem]

RobertMe schreef op dinsdag 21 juli 2026 @ 13:35:
[...]

Dat lijkt mij gewoon heel sterk. Zou immers betekenen dat Alpine nooit bruikbaar is in een IPv4 only netwerk. En nouja, Alpine is een "vrij populair" base image voor Docker containers en Docker ondersteund pas vrij recent IPv6 (by default). Dus als Alpine zich niks aantrekt van of het OS (/omgeving / container) IPv6 geschikt is dan zou je nooit Alpine als base image hebben kunnen gebruiken (en kan dat nog steeds niet) in een IPv4 omgeving. Waarbij een DNS resolver in het netwerk nog steeds prima op AAAA requests zal antwoorden ook al is die DNS resolver zelf niet via IPv6 met het internet verbonden.

Edit:

$ docker network create --ipv6=false noipv6
9026ff4a7819fcf904732a5a7e80a32b1886e79b3ef8087876ffc2d53ab9426b
$ docker run --rm --network noipv6 -it alpine ash
Unable to find image 'alpine:latest' locally
latest: Pulling from library/alpine
55afa1ecc21d: Already exists
Digest: sha256:28bd5fe8b56d1bd048e5babf5b10710ebe0bae67db86916198a6eec434943f8b
Status: Downloaded newer image for alpine:latest
/ # ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0@if255: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP
    link/ether 02:91:ac:5b:ca:58 brd ff:ff:ff:ff:ff:ff
    inet 172.19.0.2/16 brd 172.19.255.255 scope global eth0
       valid_lft forever preferred_lft forever
/ # ping google.com
PING google.com (172.217.171.110): 56 data bytes
^C
--- google.com ping statistics ---
6 packets transmitted, 0 packets received, 100% packet loss

Werkt dus prima. Ping gaat naar het IPv4 adres. Doe ik ping -6 google.com laat die wel het IP zien maar "Network unreachable". (Er komt geen antwoord omdat de boel in de firewall is dicht getimmerd. Containers mogen niet naar buiten babbelen tenzij expliciet toegestaan).

Het ligt iets genuanceerder. Bij Alpine vuurt een nslookup voor tegelijkertijd ipv4 en ipv6 af en sommige DNS-servers reageren dan inderdaad met een SERVFAIL (waaronder kennelijk unbound zonder transparent zone). Je kunt dit mitigeren door aan resolv.conf (in de container) dit toe te voegen:

options single-request-reopen

Dan gebruikt nslookup 1 vraag per keer.

[Dracoz]

synoniem schreef op dinsdag 21 juli 2026 @ 13:49:
[...]


Het ligt iets genuanceerder. Bij Alpine vuurt een nslookup voor tegelijkertijd ipv4 en ipv6 af en sommige DNS-servers reageren dan inderdaad met een SERVFAIL (waaronder kennelijk unbound zonder transparent zone). Je kunt dit mitigeren door aan resolv.conf (in de container) dit toe te voegen:

options single-request-reopen

Dan gebruikt nslookup 1 vraag per keer.

Slimme oplossing, nog niet eens aan gedacht om dat toe te voegen. Dat scheelt weer sleutelen in OPNsense inderdaad. Uiteraard is op netwerkniveau de "mooiste" oplossing wel om het op de OPNsense goed in te stellen, dan is het overal in het vervolg opgelost.

[RobertMe]

synoniem schreef op dinsdag 21 juli 2026 @ 13:49:
[...]


Het ligt iets genuanceerder. Bij Alpine vuurt een nslookup voor tegelijkertijd ipv4 en ipv6 af en sommige DNS-servers reageren dan inderdaad met een SERVFAIL (waaronder kennelijk unbound zonder transparent zone). Je kunt dit mitigeren door aan resolv.conf (in de container) dit toe te voegen:

options single-request-reopen

Dan gebruikt nslookup 1 vraag per keer.

Ik draai Unbound, rechtstreeks als mijn DNS (als in: in het voorbeeld verbind de Alpine container direct met Unbound). Alleen heb ik mijn lokale DNS met RPZ gedaan, en niet met Unbounds custom format. Dan zou het issue echt al een niche in een niche in een niche moeten zijn wil je er tegenaan lopen. En ja, ook als ik een lokale naam laat resolven, met of zonder bestaand record van een ander type, krijg ik gewoon een NOERROR terug en geen SERVFAIL.

[synoniem]

RobertMe schreef op dinsdag 21 juli 2026 @ 14:31:
[...]

Ik draai Unbound, rechtstreeks als mijn DNS (als in: in het voorbeeld verbind de Alpine container direct met Unbound). Alleen heb ik mijn lokale DNS met RPZ gedaan, en niet met Unbounds custom format. Dan zou het issue echt al een niche in een niche in een niche moeten zijn wil je er tegenaan lopen. En ja, ook als ik een lokale naam laat resolven, met of zonder bestaand record van een ander type, krijg ik gewoon een NOERROR terug en geen SERVFAIL.

Ja ik zou verwachten dat de optie dns=unbound-ip het probleem ook zou oplossen. De vraagsteller geeft echter aan dat hij dat al geprobeerd heeft en ik heb geen idee hoe zijn verdere configuratie er uit ziet en hoe niche die configuratie is

Ik gebruik zelf pfSense en dat is tegenwoordig steeds minder goed te vergelijken met OPNsense. En het inregelen van ipv6 was nog een aardig klusje om het goed te doen i.c.m. PPPOE.

Maar het probleem dat niet alle dns-servers en m.n. bij consumentenhardware tegen een dubbele nslookup kan komt meer voor.

[tikkietrugjaap]

Even een bericht tussendoor. Ik zie allemaal hele goede informatie voorbij komen. Ik heb vanavond weer tijd om dit op te pakken en zal dan reageren op alles. Mits dit is toegestaan binnen deze thread want het lijkt erop dat dit niet aan Docker ligt.

[Dracoz]

RobertMe schreef op dinsdag 21 juli 2026 @ 14:31:
[...]

Ik draai Unbound, rechtstreeks als mijn DNS (als in: in het voorbeeld verbind de Alpine container direct met Unbound). Alleen heb ik mijn lokale DNS met RPZ gedaan, en niet met Unbounds custom format. Dan zou het issue echt al een niche in een niche in een niche moeten zijn wil je er tegenaan lopen. En ja, ook als ik een lokale naam laat resolven, met of zonder bestaand record van een ander type, krijg ik gewoon een NOERROR terug en geen SERVFAIL.

RPZ is bij jou exact de reden dat dit gedrag voorkomen wordt. ​Als je OPNsense gewoon standaard draait met 'register DHCP leases' in Unbound, krijg je precies die strikte local-zones. Combineer dat met Alpine-containers (die parallel A en AAAA-queries vuren) en je loopt hier dus direct tegenaan.

[tikkietrugjaap]

Ok. Ik heb de berichten gelezen en het lijkt er steeds meer op dat ik iets niet goed heb ingesteld bij DNSMasq en Unbound. Eens kijken of ik zoveel mogelijk antwoorden kan geven zonder een chaotische post te maken:

Mars Warrior schreef op dinsdag 21 juli 2026 @ 13:06:

getent ahosts desk9800.home.internal binnen de container levert niets op. Hij doet wel iets maar vervolgens zie ik gewoon weer de command prompt. Als ik het binnen de VM doe krijg ik:

192.168.10.103  STREAM desk9800.home.internal
192.168.10.103  DGRAM
192.168.10.103  RAW

dig desk9800.home.internal A binnen de container levert op:

; <<>> DiG 9.20.23 <<>> desk9800.home.internal A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45044
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;desk9800.home.internal.                IN      A

;; ANSWER SECTION:
desk9800.home.internal. 1       IN      A       192.168.10.103

;; Query time: 0 msec
;; SERVER: 127.0.0.11#53(127.0.0.11) (UDP)
;; WHEN: Tue Jul 21 20:08:13 CEST 2026
;; MSG SIZE  rcvd: 67

dig desk9800.home.internal A binnen de container levert op:

; <<>> DiG 9.20.23 <<>> desk9800.home.internal AAAA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 5375
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;desk9800.home.internal.                IN      AAAA

;; Query time: 0 msec
;; SERVER: 127.0.0.11#53(127.0.0.11) (UDP)
;; WHEN: Tue Jul 21 20:08:07 CEST 2026
;; MSG SIZE  rcvd: 40

In beide gevallen wordt de Docker DNS aangesproken (127.0.0.11) maar alleen bij ipv4 gaat het goed.

Dracoz schreef op dinsdag 21 juli 2026 @ 13:31:

Mijn VM's zijn allemaal Ubuntu Server (op Home Assistant na). Je bedoelde waarschijnlijk een docker container op basis van ubuntu dus die heb ik opgestart met "sudo docker run --rm --network noipv6 -it ubuntu". Daarna iputils geïnstalleerd en een ping naar desk9800 verliep inderdaad vlekkeloos.

RobertMe schreef op dinsdag 21 juli 2026 @ 13:35:

In jouw voorbeeld ping je google.com. Dat lukt bij mij, vanuit de container, wel. Hij pingt dan automatisch een ipv4 adres. Probeer ik echter jouw stappen maar ping ik mijn eigen host (desk9800) dan krijg ik hetzelfde resultaat.

synoniem schreef op dinsdag 21 juli 2026 @ 13:49:

Ik heb die regel nog niet geprobeerd, bedankt daarvoor. Echter ben ik het wel met @Dracoz eens dat dit beter geregeld kan worden op netwerkniveau. Ik heb iets niet goed ingesteld binnen Opnsense, lijkt het op. Mijn configuratie is, denk ik, niet heel niche. Opnsense router op een kleine PC, daarop DNSMasq voor DHCP en Unbound voor DNS zodat alle hosts middels FQDN kunnen worden gevonden. Een aantal VLANs maar op dit moment hebben die allemaal nog een allow all regel. Elke VLAN zijn eigen domain (home.internal, servers.internal, iot.internal, etc.).

Dracoz schreef op dinsdag 21 juli 2026 @ 16:43:

Ik heb inderdaad 'register DHCP leases' aanstaan binnen Unbound. Ook heb ik, bij Query Forwarding regels aangemaakt per DHCP range in de vorm van "10.168.192.in-addr.arpa" met een server IP van 127.0.0.1. Ook heb ik dergelijke regels per domain dus "servers.internal" met een server IP van 127.0.0.1. Dit scheen te moeten om DNSMasq en Unbound met elkaar te laten praten.

Zoals gezegd lijkt er iets niet goed te gaan binnen Opnsense. Maar waar is mij op dit moment nog niet duidelijk.

[Airw0lf]

@tikkietrugjaap - wat is de nood om met unbound te gaan werken?

Mijn inschatting is dat je er niet aan gaat ontkomen om dnsmasq ook in te zetten voor dns resolving. Waarbij dnsmasq de forwarder is voor unbound - zo heb ik het in ieder geval opgelost.