Hab’s jetzt nicht bei anderen Apps ausprobiert aber unter Antenna Podcast auf Android scheint der ldn Feed leider kaputt? Oder ist das ein Problem was nur bei mir Auftritt?
Ich nutze den AudioBookShelf Server + App, aber der hat seit 2 Tagen auch ein Problem, den Feed zu laden.
#TL/DR: Technisches Bla Bla
So wie es aussieht, macht der Provider für die Feeds (cdn.kicks-apps.com) irgendetwas nicht komformes, weswegen alle Docker container auf Alpine Basis die URL „feeds.lagedernation.org“ und die kicks-app.com nicht auflösen können.
#TL/DR ende
Bei meinem Audiobookshelf Server konnte ich das beheben, in dem ich IPv6 dafür ausgeschaltet habe.
Evtl. könnte es dir also helfen ein WLAN ohne IPv6 zu verwenden (oder irgendein VPN mit reinem IPv4)…
Ich habe das gleiche Problem. Ich nutze auch Audiobookshelf (als Docker-Compose in einem LXC auf einem Proxmox-Server) und kann seit ner Weile keine neue Episoden runterladen.
Deaktivierung von IPv6 hat das Problem nicht behoben.
Kleine Ergänzung: Es liegt weder am DNS noch an IPv4 oder IPv6.
Die Resolution von cdn.kicks-apps.com geht unabhängig vom DNS-Anbieter wegen fehelnder dnssec seitens kick-apps nicht: Link zur DNSSEC-Visualisierung.
Wir können den Fehler nicht reproduzieren.
Trotzdem haben wir mal unseren Dienstleister gefragt. Die sagen, das liegt an der fehlerhaften Implementierung einiger Clients. Wenn es gar keinen DS Record gibt, sollte der Client die Verbindung zulassen und nicht blockieren („fail gracefully“). Finde ich plausibel.
Mit den üblichen Linux-Instanzen lässt sich die Adresse unabhängig von DNS-Resolver (mit oder ohne DOH oder DOS) nicht auflösen.
Ich habe das Problem jetzt mit statischen Hosts lösen können (direkt so in die docker-compose.yml, für die Audiobookshelf-Nutzer):
extra_hosts:
- "cdn.kicks-apps.com:139.162.176.235"
- "feeds.lagedernation.org:139.162.176.235"
Und fürs Debugging folgende Fehlermeldung mit nslookup:
root@audiobookshelf:/opt# nslookup feeds.lagedernation.org
Server: 10.0.0.1
Address: 10.0.0.1#53
Non-authoritative answer:
feeds.lagedernation.org canonical name = cdn.kicks-apps.com.
Name: cdn.kicks-apps.com
Address: 139.162.176.235
;; Got SERVFAIL reply from 10.0.0.1
** server can't find cdn.kicks-apps.com: SERVFAIL
1 „Gefällt mir“
Kleine Ergänzung:
Für LagePlus-Abonnenten braucht man auch eine Auflösung von cdn.lagedernation.org, also folgende Hosts:
extra_hosts:
- "cdn.lagedernation.org:139.162.176.235"
- "cdn.kicks-apps.com:139.162.176.235"
- "feeds.lagedernation.org:139.162.176.235"
1 „Gefällt mir“
Danke! Tatsächlich kann ich bei meiner Audiobookshelf Instanz mit diesen extra_hosts endlich wieder Lage der Nation hören. Danke für den Hinweis!
1 „Gefällt mir“
Hi @vieuxrenard,
Könntet ihr eventuell bei eurem Dienstleister (ich bin mir nicht sicher ob derselbe oder ein anderer?) mal nachfragen warum die Nameserver von cdn.lagedernation.org keine AAAA records (IPv6) auflösen bzw. diesen Typ aktiv zurückweisen? Das wird nämlich das Problem von einigen Leuten hier im Thread sein, zumindest ist es meins (und deshalb hat IPv6 abschalten auch für einige funktioniert).
Man sieht das ganz schön wenn man auf DNS-Abfragen | heise Netze versucht, den AAAA Eintrag für cdn.lagedernation.org auflösen zu lassen. Da kriegt man nämlich ein „SERVFAIL“. Das scheint daran zu liegen dass die cdn.lagedernation.org Nameserver bei AAAA Records die Verbindung zurückweisen:
$ dig @ns1.lagedernation.org. AAAA cdn.lagedernation.org
; <<>> DiG 9.18.37 <<>> @ns1.lagedernation.org. AAAA cdn.lagedernation.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 8 # <----------------------------
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;cdn.lagedernation.org. IN AAAA
;; Query time: 40 msec
;; SERVER: 139.162.176.235#53(ns1.lagedernation.org.) (UDP)
;; WHEN: Sun Jul 13 21:48:03 CEST 2025
;; MSG SIZE rcvd: 50
Das erscheint mir aber das falsche Verhalten hier (und ich habe auch noch keinen DNS Server gesehen der das macht; frage mich was da in Nutzung ist) - REFUSED ist RCODE 5 (siehe zugehörigen RTF: RFC 1035 - Domain names - implementation and specification, Seite 27) und wird genutzt wenn sich der DNS Server aktiv weigert etwas zu tun. Da ns1.lagedernation.org aber autoritativer Nameserver für eure CDN Domain ist, sollte er sich nicht weigern.
Wenn das CDN nicht über IPv6 angeboten wird ist das okay, der DNS Server sollte mMn aber einfach eine leere Liste zurückgeben. Gibt halt keine AAAA Einträge für IPv6. Das ganze mit REFUSED abzusägen ist aber ziemlich Brechstange und sorgt für die SERVFAILs die man unter anderem bei heise sieht. SERVFAIL verwirrt dann einige Clients. Das auf die Clients zu schieben ist aber nicht so ganz korrekt.
1 „Gefällt mir“
Danke für die Erläuterung, einen leeren Record zurückzugeben sollte ja tatsächlich möglich sein, wenn das das standardkonforme Verhalten ist. Das hab ich jetzt ehrlich gesagt nicht geprüft, aber ich gebe die Idee mal an den Dienstleister weiter.
1 „Gefällt mir“
Hat jemand einen Fix für die TrueNAS Version von Audiobookshelf? Leider gibt es hier keine extra_hosts Option 
Habe eine Lösung gefunden, falls es jemand braucht.
Da die TrueNAS Implementierung by default kein extra_hosts Feld anbietet, muss man die App zu einer Custom App konvertieren, und dann in der yaml Datei das reinkopieren, was @dfadfjelfld oben angegeben hat:
extra_hosts:
- "cdn.lagedernation.org:139.162.176.235"
- "cdn.kicks-apps.com:139.162.176.235"
- "feeds.lagedernation.org:139.162.176.235"
Update: ich denke der Nameserver arbeitet jetzt wie er soll.
; <<>> DiG 9.10.6 <<>> @ns1.lagedernation.org AAAA cdn.lagedernation.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25673
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;cdn.lagedernation.org. IN AAAA
;; Query time: 2 msec
;; SERVER: 139.162.176.235#53(139.162.176.235)
;; WHEN: Thu Sep 25 19:57:33 CEST 2025
;; MSG SIZE rcvd: 50
Das kann ich übrigens weiterhin nicht reproduzieren … und wir haben diverse Systeme unter MacOS, Debian, Ubuntu und Raspian im Einsatz. Ich würde eher von einem DNS-Filter im Upstream ausgehen.
Ich habe die extra hosts jetzt raus genommen und es funktioniert mittlerweile auch ohne 
Danke für den Fix!
Am DNS kann es (eigentlich) nicht liegen, da ich beim Debuggen direkt Cloudflare und Quad9 unfiltered genutzt habe. Könnte mir eher vorstellen, dass es an der ipv6-Geschichte lag.
Ich hatte seit Monaten das Problem, dass ich die Folgen der Lage nur im heimischen WLAN, aber nicht über mobile Daten runterladen konnte (und ich konnte auch cdn.lagedernation.org im Browser nicht öffnen). Das war für mich bisher nicht schlimm, aber heute hab ichs dann unterwegs doch mal versucht zu debuggen. Tatsächlich war die quick’n’dirty Lösung, in den Android-Einstellungen den voreingestellten IPv6-nutzenden Access-Point der Telekom auf den legacy IPv4-Access-Point der Telekom zu ändern. D.h. zumindest (bis?) heute war immer noch irgendwas fishy, fürchte ich? Daheim hab ich jetzt mal hier im Forum geschaut und diesen Thread gefunden und dachte mir, ich reporte das mal auch kurz, falls das nützlich sein könnte.
(Aber eigentlich kann ich mir wirklich nicht vorstellen, dass ich der einzige Lage-Hörer bin, der über den IPv6-Telekom-Access-Point versucht, die Lage runterzuladen …)
IPv6 ist offenbar für viele immer noch Neuland 
Wenn man direkt mit unserem NS spricht, funktioniert alles, aber es passiert leider tatsächlich gelegentlich, dass bei unseren Usern irritierende Fehlermeldung ankommen.
Wir schauen uns das noch mal an.
1 „Gefällt mir“
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
1 „Gefällt mir“