FYI: Unbound und Deutsche Glasfaser (DG) - SERVERFAIL

[GerdRuetten]

Hallo Community,

da sicher einige von euch Kunde der Deutschen Glasfaser sind und pihole in Kombination mit unbound einsetzen, folgendes zur Information:

Ich bin selber Kunde der DG und konnte mich plötzlich nicht mehr im Kundenportal der DG anmelden.
Auch waren die Seiten der DG nicht mehr erreichbar.

Im Query Log von pihole erhielt ich massenhaft Einträge wie:

Ein dig auf deutsche-glasfaser.de führte zu:

root@ProxmoxCT-pihole:/etc/unbound/unbound.conf.d# dig deutsche-glasfaser.de @127.0.0.1 -p 5335

; <<>> DiG 9.18.24-1-Debian <<>> deutsche-glasfaser.de @127.0.0.1 -p 5335
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 4816
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;deutsche-glasfaser.de. IN A
;; Query time: 0 msec
;; SERVER: 127.0.0.1#5335(127.0.0.1) (UDP)
;; WHEN: Wed Mar 13 07:41:00 CET 2024
;; MSG SIZE rcvd: 50

Wenn ich in pihole den "Custom DNS Server"-Eintrag 127.0.0.1#5335 raus genommen und auf einen der "Upstream DNS Servers " (Google, Quad9, etc.) umgestellt habe, waren die Seiten der DG problemlos erreichbar.

Meine Fehlersuche beschränkte sich daher auf Unbound und DG.

Dies führte mich schlussendlich zu folgendem, sehr aktuellem (20.02.2024) Beitrag:

Unbound am Deutsche Glasfaser Anschluss

der exakt die Lösung beschreibt.

Danke an @StephanKlein von nerdig.es

Systemumgebung:

• Core vDev (development-v6, 71b17294)
• FTL vDev (development-v6, 2f38061f)
• Web interface vDev (development-v6, 8e246431)

[Bucking_Horn]

Danke, das bestätigt nochmals das Verhalten der autoritativen IPv4-DNS-Server von Deutsche Glasfaser, das hier schon öfters beobachtet wurde (z.B. SERVFAIL with deutsche-glasfaser.de).

Und potentiell könnte das auch für alle interessant sein, die an einem DSLite-Anschluss hängen, bei dem die direkte Verbindung ins Internet nur über IPv6 erfolgt, d.h. IPv4-Adressen werden vom ISP netzintern umgesetzt. Dabei erhält der Router für gewöhnlich eine CGNAT-IPv4-Adresse (aus dem Bereich 100.64.0.0/10).

unbound stellt nun in der Standard-Konfiguration DNS-Anfragen nur über IPv4, mithin von der IPv4 Deines Routers. Nehmen wir hier einmal an, das wäre die 100.64.gerd.1.

Für das erfolgreiche Auflösen von deutsche-glasfaser.de wird unbound folglich auch die IPv4-Adressen der autoritativen DNS-Server für deutsche-glasfaser.de befragen wollen, also z.B. dnsauth002.dg-w.de via 185.22.45.49.

Dieser DNS-Server scheint allerdings DNS-Anfragen nicht zu bearbeiten, wenn sie nicht aus dem öffentlichen Adressraum kommen, siehe z.B. SERVFAIL with deutsche-glasfaser.de - #19 by Bucking_Horn.

Wenn Dein ISP also die Anfrage von 100.64.gerd.1 direkt an 185.22.45.49 durchleitet, verarbeitet dieser die Anfrage nicht.

Dieser Umstand müsste eigentlich vom ISP behoben werden, entweder durch entsprechende Konfiguration des DNS-Servers oder Anpassung des Routings, d.h. Ausleiten von 100.64.gerd.1 an eine öffentliche IPv4-Adresse, die dann mit 185.22.45.49 kommuniziert.

Solange dies nicht der Fall ist, bleiben zwei lokale Strategien zur Vermeidung des Fehlers:

1. Aktivieren von ausschließlich IPv6 in unbound

Das geht einfach durch Hinein-Kommentieren der entsprechenden IPv6-Optionen und Heraus-Kommentieren von IPv4 in /etc/unbound/unbound.conf.d/pi-hole.conf und einen anschließenden Neustart von unbound.
In dieser Konfiguration sollte der unbound-Rechner möglichst über eine temporäre IPv6-Adresse (vormals Privacy Extension-Adresse) oder zumindest eine stabile private IPv6 nach RFC7217 verfügen.

2. Benutzerspezifisches Conditional Forwarding für die betroffenen Domänen in a) Pi-hole oder b) unbound.

Für 2a) wäre das z.B. über folgende benutzerspezifische Konfiguration möglich:

sudo nano /etc/dnsmasq.d/42-forward-dg.conf
# DNS-Anfragen für Deutsche Glasfaser an öffentliche DNS-Server senden
server=/deutsche-glasfaser.de/dg-w.de/dg-ao.de/9.9.9.9

(siehe auch dnsmasq's Dokumentation zu server)

(Für andere ISPs sind hier natürlich entsprechend andere Domänen einzutragen.)

Im Unterschied zur von Dir verlinkten Lösung muss Pi-hole hier die Anfrage nicht erst an unbound weiterleiten, aber die Kommunikation erfolgt über normales DNS, nicht über DoH.

Bei einem DSLite-Anschluss wäre 1) das bevorzugte Mittel, da der öffentliche Verkehr hier über IPv6 potentiell schneller abgewickelt werden kann als über IPv4, dass ja erst über das ISP-interne CGNAT auf eine öffentliche IPv4 geleitet wird - davon würden also alle DNS-Anfragen von unbound profitieren.