stale answer und keine Verbindung

Help Deutschsprachige Hilfe
1

Bitte beachte diese Vorlage, damit wir dir bestmöglich helfen können!

Beobachtetes und erwartetes Verhalten

Wenn der localhost die DNS Auflösung macht kommt bei der Adresse http://dispatcher.rdnfk.com/ eine stale answer und die Verbindung schlägt fehl. Wenn die Auflösung über z.b. Cloudflare kommt geht es. Das ist in sofern ärgerlich weil es gefühlt zufällig ist. In der Regel ruft Alexa die Adresse zum Radiohören ab (ARD Audiothek). Alles andere wird wunderbar aufgelöst. Wenn ich in den Einstellungen alle anderen DNS Server deaktivieren und nur den localhost auflösen lasse geht auch alles bis auf diese Adresse. Hat vielleicht jemand eine Idee?

Grüße

Debug Token:

https://tricorder.pi-hole.net/jdVoszei/

2

Bist Du sicher, dass es sich um diese Domäne handelt?

Diese Domäne existiert nicht:

~ $ nslookup dispatcher.rdnfk.com 1.1.1.1
Server:		1.1.1.1
Address:	1.1.1.1#53

** server can't find dispatcher.rdnfk.com: NXDOMAIN
3

sorry Tippfehler dispatcher.rndfnk.com

4

Diese Domäne existiert und wird von Pi-hole auch aufgelöst; allerdings wird ein Aufruf der von Dir vorgegebenen URL http://dispatcher.rndfnk.com in jedem Browser bei mir vom zuständigen Webserver zuverlässig mit der Anzeige von 404 Not Found quittiert.

Falls das bei Dir anders ist, was hätte da stattdessen eigentlich auftauchen sollen? Und wo wird bei Dir 'stale answer' angezeigt?

5

Moin,

die Adresse stammt von der ARD Audiothek, linkt dann weiter zu den Audiostreams. Die Adresse steht so im Query log.

image

Die Adresse stammt aus einer m3u playlist, dass ist die gesamte Adresse: http://dispatcher.rndfnk.com/rbb/fritz/live/mp3/mid

Die Alexa verwendet wahrscheinlich den selben Link (zumindest entsteht dann der selbe Eintrag) , kann dann nicht Verbinden und mäkelt rum. Andere Radiosender die nicht zur ARD Audiothek gehören funktionieren natürlich.

6

Ok, stale answer wird also nicht ständig beim Aufruf der URL http://dispatcher.rndfnk.com/ im Browser angezeigt, sondern sporadisch bei der Anfrage der Domain dispatcher.rndfnk.com in der Antwort von Pi-holes Upstream geliefert und entsprechend im Query Log dargestellt.

Ich vermute mal, es handelt sich bei diesem Upstream um unbound?
Wie sieht denn die Konfiguration dafür aus?

sudo grep -v '^\s*#\|^$' -R /etc/unbound/unbound.conf*
7

ja ist ein unbound

server:
cache-max-ttl: 86400
cache-min-ttl: 300
directory: "/opt/unbound/etc/unbound"
ede: yes
ede-serve-expired: yes
edns-buffer-size: 1232
interface: 0.0.0.0@5335
rrset-roundrobin: yes
username: "\_unbound"
log-local-actions: no
log-queries: no
log-replies: no
log-servfail: yes
logfile: /opt/unbound/etc/unbound/unbound.log
verbosity: 1
aggressive-nsec: yes
delay-close: 10000
do-daemonize: no
do-not-query-localhost: no
neg-cache-size: 4M
qname-minimisation: yes
access-control: 127.0.0.1/32 allow
access-control: 192.168.0.0/16 allow
access-control: 172.16.0.0/12 allow
access-control: 10.0.0.0/8 allow
auto-trust-anchor-file: "var/root.key"
root-hints: "/opt/unbound/etc/unbound/var/root.hints"
chroot: "/opt/unbound/etc/unbound"
deny-any: yes
harden-algo-downgrade: yes
harden-unknown-additional: yes
harden-below-nxdomain: yes
harden-dnssec-stripped: yes
harden-glue: yes
harden-large-queries: yes
harden-referral-path: no
harden-short-bufsize: yes
hide-http-user-agent: no
hide-identity: yes
hide-version: yes
http-user-agent: "DNS"
identity: "DNS"
private-address: 10.0.0.0/8
private-address: 172.16.0.0/12
private-address: 192.168.0.0/16
private-address: 169.254.0.0/16
private-domain: "plex.direct"
ratelimit: 1000
tls-cert-bundle: /etc/ssl/certs/ca-certificates.crt
unwanted-reply-threshold: 10000
use-caps-for-id: no
val-clean-additional: yes
infra-cache-slabs: 8
incoming-num-tcp: 10
key-cache-slabs: 8
msg-cache-size: 396926293
msg-cache-slabs: 8
num-queries-per-thread: 4096
num-threads: 5
outgoing-range: 8192
rrset-cache-size: 793852586
rrset-cache-slabs: 8
minimal-responses: yes
prefetch: yes
prefetch-key: yes
serve-expired: yes
sock-queue-timeout: 3
so-reuseport: yes
include: /opt/unbound/etc/unbound/a-records.conf
include: /opt/unbound/etc/unbound/srv-records.conf
remote-control:
control-enable: no
8

Diese Zeilen deuten darauf hin, dass unbound bei Dir als Docker-Container mvance/unbound läuft.

Das von mir angegebene grep-Kommando ist so konzipiert, dass es die vollständige Konfiguration von unbound zurückgeben würde, wenn unbound gemäß unserer Anleitung eingerichtet wurde.

mvance/unbound verwendet allerdings ein eigenes Layout für unbound-Konfigurationsdateien, so dass wir hier nur Teile Deiner Konfiguration sehen.

Wie bereits erläutert, liefert unbound die von Dir beobachtete stale answer.

Dein unbound ist so konfiguriert, dass er auch abgelaufene DNS-Antworten ausliefern darf:

Entsprechend markiert unbound veraltete DNS-Antworten als abgelaufen (stale) und liefert diese mit einer TTL von 30 Sekunden aus. Das erlaubt eine sofortige Antwort aus dem Cache, ohne auf die (u.U. wesentlich) langsamere Antwort von öffentlichen DNS-Servern warten zu müssen.

Du müsstest also serve-expired: yes aus Deiner unbound-Konfiguration entfernen, damit Pi-hole seinerseits nicht 30 Sekunden lang veraltete Informationen ausliefert.

Pi-hole selbst verwendet seit Version 6 übrigens einen ähnlichen Mechanismus (klicken für Details)

Pi-holes Cache Optimiser kann weiterhin DNS-Antworten aus dem Cache sofort ausliefern, auch wenn deren TTL bereits abgelaufen sein sollte.
Gleichzeitig leitet Pi-hole die DNS-Anfrage im Hintergrund an die Upstream-DNS-Server weiter und aktualisiert den zugehörigen Cache-Eintrag, sobald eine Antwort vorliegt.

Allerdings setzt Pi-hole dabei eine TTL von 0, so dass ein Client seine DNS-Anfrage sofort wiederholen kann.

Ein Client würde damit also höchstens so lange veraltete Daten verwenden, bis die aktuelle DNS-Antwort von Pi-holes Upstream eingetroffen ist (und ist damit also in etwa vergleichbar mit dem Verhalten ohne Cache Optimiser).

Durch das Abschalten von serve-expired in unbound verlierst Du also nichts.

Außerdem sollte Dir bewusst sein, dass mvance/unbound unbound nicht als rekursiven Resolver konfiguriert, sondern als DoT-Forwarder:

By default, this image forwards queries Cloudflare DNS server over TLS. In other words, it does not act as a recursive server.

9

Sehr schön danke, das teste ich mal aus. Ja Unbound läuft zusammen mit pihole als docker.

10

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.