AdGuard Cloudflare-Fallback nachgezogen

02-AdGuard-CT100.md

@@ -189,6 +189,37 @@ Ressourcen-Ausreißer bei AdGuard muss nicht an AdGuard selbst liegen — erst p
 des Query-Logs den tatsächlichen Verursacher finden (`python3` über die JSON-Zeilen, `Counter` nach
 Client und Domain), bevor an CPU/RAM-Zuteilung gedreht wird.
 
+## 10. Fallback-Upstream: Cloudflare
+
+**Anlass:** In der Nacht war der primäre Upstream (Quad9 DoH) in zwei Fenstern stark
+degradiert — ~25 % der Anfragen ohne Antwort, teils 10–15s Latenz, ein Ausreißer 235s. Der
+Internetanschluss selbst lief laut Router-Ereignisprotokoll durchgehend stabil (kein Reconnect),
+das Problem lag isoliert am Quad9-Pfad. Root-Cause per Query-Log-Auswertung (`Upstream`-Feld
+leer = keine Antwort) und Router-Ereignisprotokoll verifiziert, nicht vermutet.
+
+```yaml
+# /opt/AdGuardHome/AdGuardHome.yaml
+dns:
+  fallback_dns:
+    - https://1.1.1.1/dns-query
+    - https://1.0.0.1/dns-query
+```
+
+**Bewusst `fallback_dns`, nicht ein zweiter `upstream_dns`-Eintrag.** AdGuard behandelt
+`upstream_dns` je nach `upstream_mode` als Load-Balancing-/Parallel-Pool — ein zweiter Eintrag
+dort hätte Cloudflare gleichberechtigt mitbefragt, nicht nur bei Ausfall. `fallback_dns` springt
+dagegen ausschließlich ein, wenn keiner der primären Upstreams rechtzeitig antwortet — genau das
+Verhalten, das in der Nacht gefehlt hat.
+
+Cloudflares DoH-Endpunkt bewusst per **IP-Literal** (`1.1.1.1`/`1.0.0.1`) statt Hostname
+eingetragen — vermeidet eine zusätzliche Abhängigkeit von `bootstrap_dns`, um den
+Fallback-Endpunkt selbst aufzulösen (der bestehende `bootstrap_dns`-Block ist ohnehin nur für
+Quad9s Hostname-Endpunkt nötig).
+
+Übliche stop/edit/start-Reihenfolge (Abschnitt 2) eingehalten. **Verifiziert:** nach Neustart
+normale Auflösung, Conditional Forwarding, DNS-Rewrite und Ad-Blocking alle unverändert korrekt
+(`dig`-Vierfachtest, siehe unten).
+
 ## Verifikation
 
 ```bash