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

[Dracoz]

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!

[Airw0lf]

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 ]

[tikkietrugjaap]

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.

[tikkietrugjaap]

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.

[Airw0lf]

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

[DjoeC]

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?

[Airw0lf]

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 ]

[DjoeC]

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.

[Airw0lf]

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?

[DjoeC]

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 ]

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

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

[DjoeC]

@LEDfan @synoniem Komende week wordt t te heet voor de tuin dus ene moment om eens wat te stoeien.
En ja, ik wil echt de UI vanaf de voorgrond (andere browser) kunnen gebruiken en op de achtergrond als (pseudo full-screen) actief houden.

Selenium heb ik van gehoord als testtool. Dat zou voordelen kunnen hebben maar ik weet niet of je daar tijdens een run kunt wijzigen, extra klikken/invullen/etc. En da's geen docker discussie

[daily.data.inj]

Iemand ervaring met docker logs & syslog als remote logging driver? https://docs.docker.com/engine/logging/dual-logging/.

Hiervoor werd de logging via de docker-compose files geregeld. Werkte perfect op 1 groot minpunt na, de logs werden weggeschreven naar een andere docker container (splunk) waardoor ik eerst moest wachten tot de splunk container up was.

Ik heb nu tijd om dit om te gooien, maar dat loopt niet zoals verwacht.
Het zou moeten werken door dit via de daemon te doen: https://docs.docker.com/engine/logging/configure/#configure-the-default-logging-driver.
De logs komen aan op de remote syslog locatie, dus geen network issues. Alleen bij het parsen van de timestamp krijg ik continue errors via deze syslog stroom vanuit docker. Wat er op lijkt dat de timestamp die vanuit de docker logs komt niet volgens rfc5424 is of de configuratie in daemon.json niet meeneemt, zie hieronder wat voorbeelden.

De ontvangende kant (fluent-bit) is redelijk flexibel dus kan daar ik in de config best e.e.a. compenseren. Maar so far heeft dat nog niet voor succes gezorgd.
Deze route werkt overigens voor het ontvangen van andere syslog events perfect. Het lijkt dus echt om deze combinatie te gaan.

code: Foutmeldingen remote syslog

telemetry-layer-fluentbit | [2026/08/19 15:51:21.423] [ warn] [parser:syslog-rfc5424] invalid time format %Y-%m-%dT%H:%M:%S.%L%z for '2026-08-19T13:51:21+00:00'
telemetry-layer-fluentbit | [2026/08/19 15:51:21.424] [error] [parser] cannot parse '2026-08-19T13:51:21+00:00'
telemetry-layer-fluentbit | [2026/08/19 15:51:21.424] [ warn] [parser:syslog-rfc5424] invalid time format %Y-%m-%dT%H:%M:%S.%L%z for '2026-08-19T13:51:21+00:00'
telemetry-layer-fluentbit | [2026/08/19 15:51:29.606] [ warn] [input:syslog:syslog.0] error parsing log message with parser 'syslog-rfc5424'

JSON: daemon.json

{
  "insecure-registries" : ["xxxx"],
  "log-driver": "syslog",
  "log-opts": {
    "syslog-format": "rfc5424",
    "syslog-address": "xxx",
    "tag": "{{.Name}}"
  }
}

code: fluentbit-config.yaml

parsers:
  - name: syslog-rfc5424
    format: regex
    regex: '^\<(?<pri>[0-9]{1,5})\>1 (?<time>[^ ]+) (?<host>[^ ]+) (?<ident>[^ ]+) (?<pid>[-0-9]+) (?<msgid>[^ ]+) (?<extradata>(\[(.*?)\]|-)) (?<message>.+)$'
    time_key: time
    time_format: '%Y-%m-%dT%H:%M:%S.%L%z'
    time_keep: On


pipeline:
  inputs:
    - name: syslog
      tag: docker.syslog.udp
      parser: syslog-rfc5424
      listen: 0.0.0.0
      port: 5140
      mode: udp
      receive_buffer_size: 65535
  outputs:
    - name: opensearch
      match: docker.syslog.udp
      host: telemetry-log-opensearch
      port: 9200
      aws_auth: off
      tls: off
      suppress_type_name: on

[babbelbox]

Ik ben absoluut geen expert, maar qua tijdsnotatie zie ik wel iets geks. Je verwacht lijkt het milliseconden, maar die krijg je niet en je tijdzone is in hh:mm notatie, en dat lijkt me geen combi met de Z, die verwacht +of- HHMM, dus zonder :

[daily.data.inj]

babbelbox schreef op woensdag 19 augustus 2026 @ 20:12:
Ik ben absoluut geen expert, maar qua tijdsnotatie zie ik wel iets geks. Je verwacht lijkt het milliseconden, maar die krijg je niet en je tijdzone is in hh:mm notatie, en dat lijkt me geen combi met de Z, die verwacht +of- HHMM, dus zonder :

Ja klopt, schijnbaar een ISO8601 formaat. Alleen config van de docker deamon staat de log driver staat op RFC5424 en daarnaast hebben de compose files geen logging sectie meer.

In ieder geval van het weekend nog even verder gepuzzeld en uiteindelijk, na ook expliciet verwijderen van 'dangling' volumes, kwamen de logs grotendeels door op de remote syslog. Voor nu helemaal goed en weer een mooie stap verder.
Helaas komen er nog genoeg parsing errors voorbij, dus dat wordt een andere keer troubleshooten. Wellicht docker containers 1 voor 1 starten om te kijken of ik wat schuldige containers kan aanwijzen.

[Mars Warrior]

daily.data.inj schreef op maandag 24 augustus 2026 @ 20:22:
[...]

Ja klopt, schijnbaar een ISO8601 formaat. Alleen config van de docker deamon staat de log driver staat op RFC5424 en daarnaast hebben de compose files geen logging sectie meer.

In ieder geval van het weekend nog even verder gepuzzeld en uiteindelijk, na ook expliciet verwijderen van 'dangling' volumes, kwamen de logs grotendeels door op de remote syslog. Voor nu helemaal goed en weer een mooie stap verder.
Helaas komen er nog genoeg parsing errors voorbij, dus dat wordt een andere keer troubleshooten. Wellicht docker containers 1 voor 1 starten om te kijken of ik wat schuldige containers kan aanwijzen.

Enig idee wat die foutmeldingen zijn dan? Want elke container heeft toch gewoon zijn eigen formaat qua output of in ieder geval wat er in de log regel staat?

Dus hoe krijg je Spunk ooit zover dat deze dit fatsoenlijk kan decoderen?

[Dennis]

Gisteren mijn Docker met Traefik, lldap en Authelia werkend gekregen maar met betrekking tot die laatste is er wel heeel erg weinig aanpasbaar. Ik kan niet eens een eigen logo'tje op het inlogscherm zetten of bijvoorbeeld de achtergrondkleur veranderen. Dat vind ik voor mezelf niet zo erg, maar ik wil ook familieleden hier gebruik van laten maken en ik zou het toch wel fijn vinden als ze iets herkennen aan de interface zodat ze ook zien wáár ze inloggen (behalve de url).

[ Voor 0% gewijzigd door Dennis op 27-08-2026 18:49 . Reden: Geen Authentik, maar Authelia. ]

[Ghoulli]

Dennis schreef op donderdag 27 augustus 2026 @ 09:00:
Gisteren mijn Docker met Traefik, lldap en Authentik werkend gekregen maar met betrekking tot die laatste is er wel heeel erg weinig aanpasbaar. Ik kan niet eens een eigen logo'tje op het inlogscherm zetten of bijvoorbeeld de achtergrondkleur veranderen. Dat vind ik voor mezelf niet zo erg, maar ik wil ook familieleden hier gebruik van laten maken en ik zou het toch wel fijn vinden als ze iets herkennen aan de interface zodat ze ook zien wáár ze inloggen (behalve de url).

Keycloak zou dit eventueel wel kunnen, werkt voor het inloggen eigenlijk hetzelfde als Authentik maar is toch wel degelijk anders met opzetten. Zou je eens kunnen proberen als je wil.

[ahbart]

Dennis schreef op donderdag 27 augustus 2026 @ 09:00:
Gisteren mijn Docker met Traefik, lldap en Authentik werkend gekregen maar met betrekking tot die laatste is er wel heeel erg weinig aanpasbaar. Ik kan niet eens een eigen logo'tje op het inlogscherm zetten of bijvoorbeeld de achtergrondkleur veranderen. Dat vind ik voor mezelf niet zo erg, maar ik wil ook familieleden hier gebruik van laten maken en ik zou het toch wel fijn vinden als ze iets herkennen aan de interface zodat ze ook zien wáár ze inloggen (behalve de url).

uhh. In Authentik kun je het logo aanpassen.

In de beheer omgeving: Systeem - Brands en een nieuwe brand aanmaken. Onder Instellingen en merkinstellingen kun je dan van alles aanpassen.

[Dennis]

ahbart schreef op donderdag 27 augustus 2026 @ 17:49:
uhh. In Authentik kun je het logo aanpassen.

In de beheer omgeving: Systeem - Brands en een nieuwe brand aanmaken. Onder Instellingen en merkinstellingen kun je dan van alles aanpassen.

Ik verwar het altijd... ik bedoelde Authelia. Die namen haal ik steeds door elkaar .

[ahbart]

Dennis schreef op donderdag 27 augustus 2026 @ 18:49:
[...]

Ik verwar het altijd... ik bedoelde Authelia. Die namen haal ik steeds door elkaar .

Aah ja. Authelia heb ik ook gebruikt. Die is vrij beperkt. Kun je geen logo mounten als volume of zo?

[Mars Warrior]

Dennis schreef op donderdag 27 augustus 2026 @ 18:49:
[...]

Ik verwar het altijd... ik bedoelde Authelia. Die namen haal ik steeds door elkaar .

https://www.authelia.com/reference/guides/server-asset-overrides/

Is allemaal aanpasbaar hoor in Authelia.

[Dennis]

Ah dank @Mars Warrior, dat heb ik dan gemist. Dat logo is in ieder geval al één ding . En ik zal de feature request voor custom themes eens even een zetje geven.

[daily.data.inj]

Mars Warrior schreef op maandag 24 augustus 2026 @ 21:18:
[...]

Enig idee wat die foutmeldingen zijn dan? Want elke container heeft toch gewoon zijn eigen formaat qua output of in ieder geval wat er in de log regel staat?

Dus hoe krijg je Spunk ooit zover dat deze dit fatsoenlijk kan decoderen?

Daar zijn die docker logging drivers dus voor, het format van de messages kun je configureren.
https://docs.docker.com/engine/logging/drivers/splunk/#message-formats.
Gewoon inline embedded als string was voor mij voldoende, ter illustratie 2 weken geleden:


Nu met een andere logging driver (syslog), komen er parsing errors naar voren omdat ik vermoed dat niet alle messages (en/of containers) zich aan het RFC5424 syslog format houden. Eens kijken of ik wat wijzer wordt vanavond.

[Dennis]

Aangezien hier (denk ik) de meeste kennis zit m.b.t. Traefik even de volgende vraag:

Ik heb vanavond mijn Navidrome met succes gedeployed met een mount van Hetzner Storage Box. Werkt allemaal prima (in de browser), ook netjes met Authelia ervoor.

Maar nu komt de uitdaging: de clients die ik wil gebruiken ondersteunen geen OAuth2. Begrijpelijk want dat moet eigenlijk server side geïmplementeerd worden in Navidrome. Nu lijkt daar wel een discussie over te worden gevoerd maar ik verwacht niet dat dat morgen klaar is .

Dan het alternatief: client side certificates (mutual TLS). Dat ondersteunen de clients die ik wil gebruiken wél. Traefik kan dat in beginsel ook dus dat zal vast configureerbaar zijn. Maar ik wil dan graag die extra stap dat de Subject Common Name (CN) wordt doorgegeven als Remote-User header. Zodat je in Navidrome niet meer in hoeft te loggen.

Wat ik nodig heb lijkt deze plugin ongeveer te doen (andere header, maar principe is gelijk). Heeft iemand dit toevallig in gebruik of iets vergelijkbaars geïmplementeerd hier? Of misschien een andere creatieve oplossing om dit probleem te omzeilen?

[Dennis]

Dit zou trouwens ook een optie kunnen zijn: mTLS met een fallback. Voor mijn use-case met Navidrome zou dat ideaal zijn. Hoewel dan liever met Oauth2.

[Dennis]

Bijna 24 uur later is het gelukt. Heb Claude aan het werk gezet . Die maakte wel een paar fouten maar met wat debuggen konden we dat oplossen.

Ik heb nu dubbele authenticatie, wat werkt via wat middleware die al bestond (passtlsclientcert) en zelfgemaakte (python scriptje dat de common name van het certificaat in de remote-user header stopt). Dus als ik naar mijn Navidrome surf krijg ik eerst de optie mezelf te authenticeren met een certificaat. Bied ik die niet aan, dan kan ik met Authelia inloggen.

Certificaat gebruik ik vanuit Symfonium en werkt prima. De Authelia inlog is handig voor als ik bijvoorbeeld op kantoor ben.

Conclusie: Traefik is cool (en Claude ook).