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

dinsdag 21 juli 2026 13:31

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 ]

Ryzen 7 7800X3D ,MSI PRO X670-P WIFI, 2x16GB DDR5 6000Mhz, Nvidia RTX2070 Super

Acties:

dinsdag 21 juli 2026 13:35

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

Ryzen 7 7800X3D ,MSI PRO X670-P WIFI, 2x16GB DDR5 6000Mhz, Nvidia RTX2070 Super

Acties:

RobertMe

Development tools
Docker
Docker

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 ]

dinsdag 21 juli 2026 13:49

Acties:

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.

dinsdag 21 juli 2026 13:54

Acties:

dinsdag 21 juli 2026 14:31

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.

Ryzen 7 7800X3D ,MSI PRO X670-P WIFI, 2x16GB DDR5 6000Mhz, Nvidia RTX2070 Super

Acties:

RobertMe

Development tools
Docker
Docker

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.

dinsdag 21 juli 2026 14:55

Acties:

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.

dinsdag 21 juli 2026 15:03

Acties:

dinsdag 21 juli 2026 16:43

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.

Prima.

Acties:

dinsdag 21 juli 2026 20:59

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.

Ryzen 7 7800X3D ,MSI PRO X670-P WIFI, 2x16GB DDR5 6000Mhz, Nvidia RTX2070 Super

Acties:

dinsdag 21 juli 2026 21:45

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.

Prima.

Acties:

dinsdag 21 juli 2026 23:15

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

makes it run like clockwork

Acties:

woensdag 22 juli 2026 07:32

tikkietrugjaap schreef op dinsdag 21 juli 2026 @ 20:59:
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:

[...]

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.

[...]

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.

[...]

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.

[...]

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

[...]

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.

Ah top dat resultaat, hier zie je direct dat inderdaad glibc het niets boeit dat die op ipv6 een error terug krijgt maar dat de musl libc volledig kapot gaat daarop.

Gelukkig is de oplossing erg simpel, je hoeft niet je hele keten om te gooien en Dnsmasq als forwarder voor unbound te zetten, dit kan uiteraard maar is imho beetje overkill. Wat je beter kan doen is gewoon in de custom.d folder van unbound een .conf bestand aan te maken met het volgende:

server: 
     local-zone: "home.internal." transparent 
     local-zone: "servers.internal." transparent 
     local-zone: "iot.internal." transparent

Standaard behandelt unbound een lokaal domein vaak namelijk heel strikt of static of deny. Zodra Alpine dan om een AAAA record vraagt wat niet in Unbound staat denk denkt unbound dat het niet bestaat en geeft die een serverfail. Zodra je dit instelt op transparant dan verander je dit gedrag door aan te geven dat als de AAAA record niet bestaat hij gewoon een noerror teruggeeft.

Hoop dat het nu duidelijk is!

Ryzen 7 7800X3D ,MSI PRO X670-P WIFI, 2x16GB DDR5 6000Mhz, Nvidia RTX2070 Super

Acties:

woensdag 22 juli 2026 08:06

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

Gelukkig is de oplossing erg simpel, je hoeft niet je hele keten om te gooien en Dnsmasq als forwarder voor unbound te zetten, dit kan uiteraard maar is imho beetje overkill.

Hoop dat het nu duidelijk is!

Voor mij in ieder geval wel - dank je!

Kan je dan ook volstaan met één regel: local-zone: "internal." transparent? Met het idee dat dan alles wat eindigt op internal op die manier wordt afgehandeld?

Wat ik me ook nog afvraag is hoe unbound weet gaat krijgen van de door dnsmasq uitgegeven ip adressen en bijbehorende, geregistreerde systeemnamen? Hoe zou dat moeten werken?

[ Voor 20% gewijzigd door Airw0lf op 22-07-2026 07:47 ]

makes it run like clockwork

Acties:

woensdag 22 juli 2026 20:49

Airw0lf schreef op dinsdag 21 juli 2026 @ 21:45:
@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.

Ik heb dat zo ingesteld nadat ik had gezocht naar oplossingen om hostnames van verschillende apparaten die via DNSMasq een IP krijgen vindbaar te maken. Dit om te voorkomen dat ik IP adressen moest gaan onthouden of teveel DHCP adressen static moest maken.

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

Ah top dat resultaat, hier zie je direct dat inderdaad glibc het niets boeit dat die op ipv6 een error terug krijgt maar dat de musl libc volledig kapot gaat daarop.

Gelukkig is de oplossing erg simpel, je hoeft niet je hele keten om te gooien en Dnsmasq als forwarder voor unbound te zetten, dit kan uiteraard maar is imho beetje overkill. Wat je beter kan doen is gewoon in de custom.d folder van unbound een .conf bestand aan te maken met het volgende:
server: 
     local-zone: "home.internal." transparent 
     local-zone: "servers.internal." transparent 
     local-zone: "iot.internal." transparent
Standaard behandelt unbound een lokaal domein vaak namelijk heel strikt of static of deny. Zodra Alpine dan om een AAAA record vraagt wat niet in Unbound staat denk denkt unbound dat het niet bestaat en geeft die een serverfail. Zodra je dit instelt op transparant dan verander je dit gedrag door aan te geven dat als de AAAA record niet bestaat hij gewoon een noerror teruggeeft.

Hoop dat het nu duidelijk is!

Ik ga hier mee aan de slag. De gedachte erachter is mij helaas nog onduidelijk maar dat komt omdat ik simpelweg geen kaas heb gegeten van DNS. Ik zou niet eens weten wat het verschil is tussen een transparent local-zone en de andere opties. Moet toch maar eens op zoek naar wat meer achterliggende informatie m.b.t. dit onderwerp. Ik vind het wel opmerkelijk dat dit niet in de GUI van Unbound kan worden ingesteld. Maar wellicht is dat een keuze geweest van het Opnsense-team.
In ieder geval bedankt voor de informatie.

Prima.

Acties:

woensdag 22 juli 2026 22:59

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

Ah top dat resultaat, hier zie je direct dat inderdaad glibc het niets boeit dat die op ipv6 een error terug krijgt maar dat de musl libc volledig kapot gaat daarop.

Gelukkig is de oplossing erg simpel, je hoeft niet je hele keten om te gooien en Dnsmasq als forwarder voor unbound te zetten, dit kan uiteraard maar is imho beetje overkill. Wat je beter kan doen is gewoon in de custom.d folder van unbound een .conf bestand aan te maken met het volgende:
server: 
     local-zone: "home.internal." transparent 
     local-zone: "servers.internal." transparent 
     local-zone: "iot.internal." transparent
Standaard behandelt unbound een lokaal domein vaak namelijk heel strikt of static of deny. Zodra Alpine dan om een AAAA record vraagt wat niet in Unbound staat denk denkt unbound dat het niet bestaat en geeft die een serverfail. Zodra je dit instelt op transparant dan verander je dit gedrag door aan te geven dat als de AAAA record niet bestaat hij gewoon een noerror teruggeeft.

Hoop dat het nu duidelijk is!

Terugkoppeling over het bovenstaande.

Ik moest even opzoeken hoe het .conf bestand moest heten en dat was blijkbaar "custom-local-zones.conf". Ik heb dit gemaakt en de regels die jij aangaf erin gezet. Daarna zowel DNSMasq als Unbound opnieuw gestart. Het resultaat was helaas precies als voorheen.

Wat ik daarna heb gedaan is bij Query forwarding de regel voor het domein servers.internal, die naar server IP 127.0.0.1 port 53053 (wat DNSMasq is) verwees, gedisabled. Dat resulteerde in dezelfde foutmelding (Bad Address) maar die foutmelding kwam wel veel sneller. Dat deed me vermoeden dat de foutmelding voornamelijk vanuit DNSMasq kwam. Ik ben toen nog eens in de instelling van DNSMasq gaan zoeken en kwam de optie "DHCP local domain" tegen. De uitleg bij die optie is "Sets all DHCP domains as local. This will configure this DNS server as authoritative; it will not forward queries to any upstream servers for these domains". Dat leek mij een goede om te proberen en inderdaad, nadat ik die optie had aangevinkt, zowel DNSMasq als Unbound opnieuw had opgestart kon in normaal pingen vanuit mijn Docker containers.

Ik vermoed dat er mensen zullen zijn met kennis van DNS die nu vrij luid "duh" roepen maar ik ben vrij content met het resultaat.

Waar ik nog wel een beetje mee zit is dat ik niet uit kan leggen wat er voorheen fout ging en waarom het nu wel werkt. Voor zover ik het begrijp krijgt DNSMasq een DNS verzoek van Unbound voor een host op één van de lokale domeinen. Ik zou toch vermoeden dat hij daar dan gewoon een resultaat voor geeft zoals hij dat ook doet voor alle andere verzoeken maar blijkbaar werkt dat anders.
Ik ben online gaan zoeken naar lesmateriaal om meer over DNS te leren maar dat is een rabbit hole op zichzelf.

Anyway, iedereen bedankt voor het meedenken.

Prima.

Acties:

donderdag 23 juli 2026 13:20

@tikkietrugjaap - mijn 0,500 Euro:

De oorzaak ligt in beiden - unbound en dnsmasq.

Allereerst unbound - die lijkt vooral te zijn gebouwd rondom external DNS resolving bij de bron van het DNS domein. Waarbij af fabriek local resolving niet (goed) werkt. Om dit in goede banen te leiden heb ik in unbound onderstaande settings in een custom config bestand gestoken.

De twee server settings zorgen er voor dat reverse dns lookups goed werken - ook als er geen dnssec actief is (wat in de meeste thuis netwerkjes het geval is).

De eerste forward-zone vertellen unbound waar die terecht kan voor alle domains die eindigen op .lan - in mijn geval dus alle vlans. De tweede forward-zone doet hetzelfde voor alle reverse DNS lookups voor alle vlans. De derde forward-zone is voor external DNS lookups - die worden afgehandeld door bepaalde DNS servers van Cloudflare en KPN.

code:

server:
    insecure-lan-zones: yes
    local-zone: "168.192.in-addr.arpa." nodefault

forward-zone:
    name: "lan."
    forward-addr: 192.168.230.235

forward-zone:
    name: "168.192.in-addr.arpa."
    forward-addr: 192.168.230.235

forward-zone:
    name: "."
    forward-addr: 1.1.1.2
    forward-addr: 1.0.0.2
    forward-addr: 195.121.97.203
    forward-addr: 195.121.97.202

Dan dnsmasq - dat ligt wat ingewikkelder als je met vlans werkt.

Hieronder allereerst mijn aanpak voor vlans.

Via systemd-networkd heb ik de nodige vlan interfaces aangemaakt; waaronder eth0.210, eth0.220 en eth0.230. Het management "vlan" is bij mij altijd eth0. Vervolgens via een dnsmasq-config bestandje de vlans voorzien van dhcp en dns - hieronder een paar van die vlans. Je ziet dat elk vlan/domain aangemerkt is als local domain. Hierdoor blijven alle dns aanvragen lokaal.

code:

# Wired - vlan 210
domain=wired.lan,192.168.210.0/24,local
dhcp-range=set:vlan-210,192.168.210.11,192.168.210.99,168h
dhcp-option=tag:vlan-210,option:router,192.168.210.241
dhcp-option=tag:vlan-210,option:dns-server,192.168.210.235,192.168.100.234
dhcp-option=tag:vlan-210,option:ntp-server,192.168.210.235

# Binnenkant WiFi - vlan 220
domain=wifi.lan,192.168.220.0/24,local
dhcp-range=set:vlan-220,192.168.220.11,192.168.220.99,168h
dhcp-option=tag:vlan-220,option:router,192.168.220.241
dhcp-option=tag:vlan-220,option:dns-server,192.168.220.235,192.168.100.234
dhcp-option=tag:vlan-220,option:ntp-server,192.168.220.235

# Domotica & IoT - vlan 230 - dns forwarder is dnsmasq on homey-be
domain=domotica.lan,192.168.230.0/24,local
dhcp-range=set:vlan-230,192.168.230.11,192.168.230.99,168h
dhcp-option=tag:vlan-230,option:router,192.168.230.241
dhcp-option=tag:vlan-230,option:dns-server,192.168.230.209
dhcp-option=tag:vlan-230,option:ntp-server,192.168.230.235

Om het gedrag zo voorspelbaar mogelijk te krijgen zijn in een apart dnsmasq config bestandje onderstaande parameters opgenomen. Met bind-interfaces zorg je er voor dat dnsmasq alleen actief wordt op daadwerkelijk vooraf bepaalde, bestaande interfaces (versus 0.0.0.0). De no-dhcp zorgt er voor dnsmasq niks doet met dhcp aanvragen via docker.

De laatste 3 zorgen er voor het betreffende systeem gezien wordt als enige dhcp server die altijd zorgt voor een fqdn op basis van het mac-adres - dit laatste wordt afgedwongen via dhcp-ignore-clid.

code:

bind-interfaces
no-dhcp-interface=docker0

dhcp-fqdn
dhcp-authoritative
dhcp-ignore-clid

Er zijn ook nog een paar dns parameters die hier kunnen helpen - maar het voert te ver om die ook allemaal hier op te nemen en uit te leggen. Dit omdat ik dnsmasq gebruik op basis van pihole waardoor een aantal dingen automagically ingesteld worden.

Aangezien dit alles behoorlijk off-topic is wil ik voorstellen om vervolg vragen via een PM te doen.

[ Voor 3% gewijzigd door Airw0lf op 22-07-2026 23:28 ]

makes it run like clockwork

Acties:

donderdag 23 juli 2026 13:35

Gekke vraag misschien maar toch want ik zie vast ergens iets over het hoofd.....

Ik draai op een Pi 5 met veel tevredenheid OpenMediaVault. Nu staat OMV geen desktopomgeving toe op het basis OS, hun keuze en eigenlijk ook wel prima. Op OMV draai ik Docker dus mijn denken is: Waarom geen Raspi OS desktop in Docker, zeg maar: een Raspi in een VM achtige oplossing.

Zoeken heeft me nog niks opgeleverd en dus hier de vraag: Is dit een mogelijkheid en waar kan ik meer info vinden?

Acties:

donderdag 23 juli 2026 14:15

DjoeC schreef op donderdag 23 juli 2026 @ 13:20:
Gekke vraag misschien maar toch want ik zie vast ergens iets over het hoofd.....

Ik draai op een Pi 5 met veel tevredenheid OpenMediaVault. Nu staat OMV geen desktopomgeving toe op het basis OS, hun keuze en eigenlijk ook wel prima. Op OMV draai ik Docker dus mijn denken is: Waarom geen Raspi OS desktop in Docker, zeg maar: een Raspi in een VM achtige oplossing.

Zoeken heeft me nog niks opgeleverd en dus hier de vraag: Is dit een mogelijkheid en waar kan ik meer info vinden?

Je kan in OMV - naast de Docker plugin - ook de KVM-plugin installeren. En dan een VM aanmaken met een RPI-OS-plus-desktop. Als ik vragen mag: waarom zou je dat willen doen?

[ Voor 5% gewijzigd door Airw0lf op 23-07-2026 13:38 ]

makes it run like clockwork

Acties:

donderdag 23 juli 2026 15:55

Airw0lf schreef op donderdag 23 juli 2026 @ 13:35:
[...]

Je kan in OMV - naast de Docker plugin - ook de KVM-plugin installeren. En dan een VM aanmaken met een RPI-OS-plus-desktop. Als ik vragen mag: waarom zou je dat willen doen?

Dank je, ik ga die optie eens goed doorlezen. Waarom? Ik wil continue een browserapplicatie met wat automatische acties op de achtergrond laten draaien en die remote kunnen benaderen. En nu bedenk ik me (...) de vraag had dus ook kunnen zijn: Een browser (FF, Chromium, whatever) in Docker. En ik zie nu dat er een Firefox container is voor ARM64, zie je wel: je hebt me getriggerd dat ik de simpele oplossing over t hoofd heb gezien.

Maar, ik ga me ook eens verdiepen in de KVM optie.

Acties:

vrijdag 24 juli 2026 10:44

DjoeC schreef op donderdag 23 juli 2026 @ 14:15:
[...]

Dank je, ik ga die optie eens goed doorlezen. Waarom? Ik wil continue een browserapplicatie met wat automatische acties op de achtergrond laten draaien en die remote kunnen benaderen. En nu bedenk ik me (...) de vraag had dus ook kunnen zijn: Een browser (FF, Chromium, whatever) in Docker. En ik zie nu dat er een Firefox container is voor ARM64, zie je wel: je hebt me getriggerd dat ik de simpele oplossing over t hoofd heb gezien.

Maar, ik ga me ook eens verdiepen in de KVM optie.

Ok - maar nog steeds... misschien mis ik iets... maar hoe zie je dat met die remote toegang? Want of je een browser gebruikt in een Docker container of in een VM maakt eigenlijk niet uit - remote toegang is nog steeds beperkt tot een CLI/SSH login - toch?

makes it run like clockwork

Acties:

zaterdag 25 juli 2026 11:13

Airw0lf schreef op donderdag 23 juli 2026 @ 15:55:
[...]

Ok - maar nog steeds... misschien mis ik iets... maar hoe zie je dat met die remote toegang? Want of je een browser gebruikt in een Docker container of in een VM maakt eigenlijk niet uit - remote toegang is nog steeds beperkt tot een CLI/SSH login - toch?

Ik hoopte op browser in browser waarbij de onderliggende doorloopt als de wrapper afsluit (hopelijk snap je wat ik probeer te zeggen), en ik weer verder kan zodra ik de onderliggende opnieuw benader.

Vergelijk het met een duurtest van de onderliggende browser alleen moet er af en toe wat gewijzigd worden terwijl het draait. Ik kan natuurlijk een losse Pi inrichten, maar dat is nou net niet de bedoeling. Ik wil dus een browser draaien/kunnen benaderen op een headless machine zonder grafische interface omdat OMV dat niet geweldig vind maar mijn Pi5 nog meer dan voldoende capaciteit heeft.

[ Voor 26% gewijzigd door DjoeC op 24-07-2026 10:48 ]

Acties:

LEDfan

Een browser in een Docker container wordt vaak gebruikt voor front-end testen of om automatisch screenshots te nemen. Dit is dan vaak een headless versie van Chrome aangestuurd met https://playwright.dev/ , https://www.selenium.dev/ etc.
Als je echt de browser UI wilt kunnen gebruiken, kan je X en VNC in een Docker container draaien. Bv met https://github.com/fcwu/docker-ubuntu-vnc-desktop , maar misschien zijn er wel meer up to date projecten.

zaterdag 25 juli 2026 12:04

Acties:

synoniem

LEDfan schreef op zaterdag 25 juli 2026 @ 11:13:
Een browser in een Docker container wordt vaak gebruikt voor front-end testen of om automatisch screenshots te nemen. Dit is dan vaak een headless versie van Chrome aangestuurd met https://playwright.dev/ , https://www.selenium.dev/ etc.
Als je echt de browser UI wilt kunnen gebruiken, kan je X en VNC in een Docker container draaien. Bv met https://github.com/fcwu/docker-ubuntu-vnc-desktop , maar misschien zijn er wel meer up to date projecten.

Een meer recent voorbeeld is https://github.com/jlesage/docker-baseimage-gui.

zaterdag 25 juli 2026 13:01

Acties: