Unbound

Unbound

#

Quelle

#

Image aus pyrox/unbound-docker, ausgerollt über das app-template von bjw-s.

Funktion

#

Der rekursive Resolver für das LAN. apps/pihole filtert und leitet hierher weiter; Unbound fragt von der Wurzel abwärts selbst und validiert DNSSEC.

Lokale Anpassung

#

zz-private-domain.conf wird per configMapGenerator zu einer ConfigMap und als /etc/unbound/unbound.conf.d/zz-private-domain.conf eingehängt. Das Image legt seine eigene Konfiguration als unbound-docker.conf im selben Verzeichnis ab; Unbound arbeitet den Glob alphabetisch ab und lässt bei skalaren Optionen den zuletzt gelesenen Wert gewinnen — der zz--Präfix sorgt also dafür, dass diese Datei nach dem Image gelesen wird.

Inhalt ist eine einzige Einstellung: private-domain: "zyria.de". Vier Namen der Zone zeigen auf RFC1918-Adressen (addc, mqtt, storage.homer, v6.addc), und private-address im Image verwirft private Adressen aus öffentlichen Zonen — ohne Ausnahme auch für die eigene. Unbound antwortete für diese Namen mit NOERROR ohne Daten. Verdeckt wurde das vom cn2pihole-Sidecar in apps/pihole, der sie aus cn.list direkt beantwortete; mit dessen Ausbau fällt diese Abdeckung weg.

subPath-Mounts bekommen Änderungen an der ConfigMap nicht mit — nach einer Änderung muss der Pod neu starten.

Warum es diese App gibt

#

Fällt der DNS-Anbieter aus, hilft kein Fallback-Resolver — auch Google fragt dieselben drei Maschinen von Core Networks und antwortet dann mit SERVFAIL. Nur zwischengespeicherte Daten helfen.

Unbound liefert in dem Fall dank serve-expired die alte, weiterhin gültige Antwort, und zwar als erfolgreiche Antwort statt als SERVFAIL. Das ist der entscheidende Punkt: die Kette davor muss kein SERVFAIL richtig deuten, sie reicht eine gültige Antwort einfach durch. Der Google-Rückfall in apps/nameserver bleibt damit für das, wofür er gedacht ist — einen kaputten Resolver — und kommt der alten Antwort nicht in die Quere.

Bewusst nicht der Unbound aus dem Mailstack: sonst hinge die Namensauflösung des ganzen Netzes am Mail-Release, und ein Redeploy dort nähme das LAN-DNS mit.

Feste ClusterIP

#

Der Service hat eine feste clusterIP, weil Pi-hole seine Upstreams als IP-Adresse braucht — FTLCONF_dns_upstreams nimmt keinen DNS-Namen, und ein Resolver, der seinen Upstream erst per DNS auflösen müsste, wäre zirkulär.

10.45.99.12 ist geprüft: kein Service hält die Adresse, und sie liegt im service-cidr 10.45.0.0/16 aus ansible/inventory.yaml.

Ein kubectl --dry-run=server taugt für diese Prüfung nicht — er lässt auch eine längst vergebene Adresse durch, weil die Vergabe erst in der Speicherschicht stattfindet. Der belastbare Weg ist der Vergleich mit der Service-Liste.

Wartung

#

Gering, weil das Image ohnehin gepflegt wird: unbound-docker baut es per Cron zweimal täglich neu, und weil der Dockerfile unbound-anchor ausführt und root.hints holt, bleiben Trust-Anchor und Root-Hints dabei ohne Zutun aktuell.

Cache-Wärmung

#

serve-expired hilft nur für Namen, die schon im Cache liegen. Der CronJob aus apps/corenetworks-dns-operator fragt deshalb regelmäßig alle Namen der eigenen Zonen hier ab.

Installation

#

Erfolgt über ArgoCD, siehe manifests.yaml.