Ich bin über das gleiche Problem in Audiobookshelf gestolpert. Habe mal ein bisschen tiefer gegraben, und eine Lösung für ABS gebastelt.
Das eigentliche Problem:
@vieuxrenard Würde mich freuen wenn du hier nochmal einen Blick drauf wirfst.
TLDR:
Die Authoritativen Nameservers ns[1-4].lagedernation.org beantworten A queries ohne Probleme. Allerdings geben sie explizit REFUSED zurück wenn man AAAA records queried. Das führt bei recursiven Nameservern (z.B. Google’s 8.8.8.8) wiederum zu einem SERVFAIL.
Falls der webserver keine IPv6 addressen hat, dann sollte der Authoritative Nameserver trotzdem mit NOERROR (und einer leeren payload) antworten, anstatt REFUSED zurückzugeben. Der REFUSED r-code ist für access policy Zwecke gedacht, nicht für diesen use case!
Das problem besteht definitiv für die domains feeds.lagedernation.org und cdn.lagedernation.org - nicht sicher ob weitere domains betroffen sind.
Hier die technischen details...
1. Beobachtung bei einen öffentlichen Resolver
- Resolver:
8.8.8.8(google public DNS) - Query:
cdn.lagedernation.org - Record:
AAAA(IPv6)
$ dig @8.8.8.8 cdn.lagedernation.org AAAA
[...]
status: SERVFAIL
[...]
; EDE: 23 (Network Error): ([139.162.176.53] rcode=REFUSED for cdn.lagedernation.org/aaaa)
; EDE: 23 (Network Error): ([139.162.176.235] rcode=REFUSED for cdn.lagedernation.org/aaaa)
; EDE: 22 (No Reachable Authority): (At delegation cdn.lagedernation.org for cdn.lagedernation.org/aaaa)
[...]
→ Google’s Resolver meldet, dass die authotitativen Nameserver 139.162.176.235 (ns1.lagedernation.org) und 139.162.176.53 (ns4.lagedernation.org) die query für AAAA records explizit als REFUSED beantworten.
2. Verifikation direkt bei den authoritativen Nameservern
- Resolver:
ns1.lagedernation.org - Query:
cdn.lagedernation.org - Record:
AAAA(IPv6)
$ dig @ns1.lagedernation.org cdn.lagedernation.org AAAA
[...]
status: REFUSED
[...]
Zum Vergleich, hier die Query für den A record:
$ dig @8.8.8.8 cdn.lagedernation.org AAAA
[...]
status: NOERROR
[...]
cdn.lagedernation.org. 0 IN A 139.162.176.235
[...]
→ A queries funktionieren, aber AAAA queries werden aktiv abgelehnt.
3. Einordnung
Anstatt queries für IPv6 mit REFUSED abzulehnen, sollten eure Nameservers einfach eine leere Antwort (oder eben passende IPv6 addressen) zurückgeben. - Eure Nameserver sind leider definitiv falsch konfiguriert.
Meine Lösung für AudioBookShelf:
Problem innerhalb ABS:
Durch den parziellen NS resolution Fehler (A records funktionieren, AAAA liefert SERVFAIL) hängt sich audiobookshelf schon bei der domain name resolution auf. Interessanterweise passiert das aber übrigens nicht in allen Umgebungen, aber eben in dem Alpine basierten container. - Den genauen Grund hierfür habe ich noch nicht herausgefunden, vermute aber dass der zugrundeliegende getaddrinfo syscall in Alpine anders imlpementiert (oder konfiguriert) ist.
Mein Fix:
Ich habe einen fix in AudioBookShelf implementiert, der domain names explizit mit Node’s dns Modul resolved, und dabei A records und AAAA records seperat behandelt. Dabei werden Probleme in der NS resolution abgefangen, ohne dass der Fehler geworfen wird.
Audiobookshelf PR #4885 - Implement experimental DNS Resolution
Call to action:
Der PR ist aktuell noch nicht gemerged - Ich würde mich sehr freuen wenn mehr Menschen den fix ausprobieren könnten und auf dem github PR einen „daumen hoch“, oder einen positiven Kommentar da lassen könnten, damit der merge demnächst vielleicht prioriziert wird.
Meinen Fix ausprobieren:
So lange der PR nicht in den offiziellen release gemerged ist, werde ich aktuelle Versionen des Audiobookshelf docker image mit meinem fix selbst bereitstellen. Das gepatchte image gibt es auf dockerhub.
Das aktuelle image ist:
docker.io/passionatebytessolutions/audiobookshelf:2.32.1-pr4885
Wichtig: Um das experimentelle DNS resolution feature zu aktiviern muss noch eine environment variable gesetzt werden - Hierzu also eure docker-compose.yaml, oder helm chart values.yaml, oder sonstige config entsprechend anpassen:
EXP_DNS_RESOLUTION=1