Dein Anschluss bekommt regelmäßig eine neue IP-Adresse, deine Domains sollen trotzdem auf ihn zeigen. Bisher heißt das: pro Anbieter eine eigene App oder ein Skript, jedes mit eigener Konfiguration. DNSmith ersetzt das durch einen Hub — einmal installieren, Anbieter aus einer Liste wählen, Zugangsdaten eintragen, fertig. Beliebig viele Einträge über beliebig viele Anbieter, alles über die Oberfläche, keine YAML-Datei.
Stand: läuft, der Katalog umfasst 64 Anbieter. Auf echter Hardware erprobt sind die einfachen Anbieter; die Signatur- und Zwei-Schritt-APIs sind gegen aufgezeichnete Antworten getestet, nicht gegen echte Konten.
- 🗂️ 64 Anbieter – von DuckDNS und Dynu bis Cloudflare, Route 53, Google
Cloud DNS und Aliyun. Je eine erzeugte Anbieterseite unter
docs/providers/. - 🧩 Zwei generische Einträge – Generisches DynDNS2 für jeden Dienst, der das klassische Protokoll spricht, und ein eigener HTTP-Provider, bei dem Methode, Authentifizierung, Parameternamen und Erfolgskriterium frei einstellbar sind. Damit lässt sich auch anbinden, was nicht in der Liste steht.
- 📄 Ein Anbieter ist eine Datei, kein Programm – was ein Dienst technisch verlangt, steht als Daten in einem Manifest. Daraus entstehen das Formular in der Oberfläche, die Anbieterseite in der Dokumentation und der Aufruf selbst. 54 der 64 Anbieter brauchen keine Zeile Python.
- 🌐 IPv4 und IPv6 gleichberechtigt – ein Eintrag pflegt A, AAAA oder beides. Bei anbieterseitig getrennten Aufrufen erfolgt je Adressfamilie einer.
- 📡 Vier IP-Quellen je Adressfamilie – automatisch übers Internet, aus einer Home-Assistant-Entität (der Regelfall bei DS-Lite), feste Adresse, oder gar nicht. Liefert eine Entität keinen brauchbaren Wert, bleibt der Eintrag unangetastet statt falsch gesetzt zu werden.
- 🩺 CGNAT- und DS-Lite-Erkennung – die Oberfläche sagt, warum der Anschluss trotz erfolgreichem Update nicht erreichbar ist, statt dich Ports prüfen zu lassen.
- 🔌 Verbindung testen – wo die API es zulässt, ein echter lesender Aufruf gegen den Anbieter; wo nicht, steht ausdrücklich „nur Einstellungen geprüft".
- 💬 Fehler mit nächstem Schritt – statt „HTTP 401" steht dort, was abgelehnt wurde und was zu prüfen ist. Die Originalmeldung bleibt aufklappbar.
- ⏱️ Schonender Umgang mit Anbietern – aktualisiert nur bei tatsächlicher IP-Änderung, mit Abklingzeit und Backoff. Sperren werden erkannt und abgewartet.
- 🔒 Kein offener Port – die Oberfläche läuft ausschließlich über Ingress.
- 🛡️ Kein Sprungbrett ins Heimnetz – jede vom Nutzer angegebene Adresse wird vor dem Aufruf aufgelöst und geprüft; Weiterleitungen werden nicht verfolgt.
| Home Assistant | eine Installation mit Supervisor (Home Assistant OS oder Supervised) — nur dort gibt es Apps |
| Architektur | aarch64 oder amd64. 32-Bit (armv7, armhf) unterstützt die Home-Assistant-Basis nicht mehr |
| Konto beim DDNS-Anbieter | mindestens eines, mit den jeweiligen Zugangsdaten |
| Für IPv6 | Docker in Home Assistant muss IPv6 haben — ab Mitte 2025 voreingestellt, sonst einmalig ha docker options --enable-ipv6=true und Host-Neustart |
Es gibt kein veröffentlichtes Image: die App wird beim Installieren auf deinem Gerät gebaut. Das dauert beim ersten Mal einige Minuten.
- Einstellungen → Add-ons → Add-on Store → ⋮ → Repositories
https://github.com/duczz/ha-dnsmithhinzufügen- DNSmith in der Liste suchen, Installieren, dann Starten
- Öffnen — die Oberfläche erscheint in der Seitenleiste
Der Knopf oben in dieser Datei erledigt Schritt 1 und 2 auf einmal.
- Den Ordner
dnsmithnach/addons/dnsmithauf dem Home-Assistant-Gerät legen (Samba, SSH oder Studio Code Server) - Einstellungen → Add-ons → Add-on Store → ⋮ → Nach Updates suchen
- DNSmith unter „Lokale Add-ons" installieren und starten
Warning
Beim Aktualisieren den Ordner ersetzen, nicht überkopieren. Warum das einen Unterschied macht, steht im Handbuch.
Öffnen → + Anbieter hinzufügen → Zugangsdaten eintragen → Verbindung testen → Eintrag anlegen.
Es gibt keine App-Konfiguration im Supervisor-Reiter und keine YAML-Datei — alles steht in der Oberfläche. Wie die einzelnen Schritte aussehen, woher die IP-Adressen kommen und was bei IPv6 zu beachten ist, steht im Handbuch.
engine:
adapter: native
protocol: dyndns2
request:
url: https://api.dynu.com/nic/update
params:
hostname: "{hostname}"
myip: "{ipv4}"
myipv6: "{ipv6}"
success:
vocabulary: dyndns2Das ist der vollständige Dynu-Anbieter. Kein Python dazu.
Zehn der 64 brauchen ein Modul, weil ihre API etwas verlangt, das sich nicht als ein Aufruf hinschreiben lässt — eine Sitzung, eine Signatur, ein Warten auf eine Aktion. Warum, steht jeweils im Kopf des Moduls; ein Modul ohne gültigen Grund gehört zurück ins Manifest.
Auch zwei Schritte bleiben Daten: lookup: bindet Zone- und Record-IDs, bevor
request: schreibt. Das ist der Unterschied zwischen einem Projekt mit zwanzig
fast gleichen Modulen und einem mit zehn verschiedenen.
Genau eine Abhängigkeit geht auf einen einzelnen Anbieter zurück:
cryptography, weil Google Cloud DNS einen RS256-signierten JWT verlangt und
RSA nicht in der Standardbibliothek steht. Route 53 und Aliyun signieren mit
hmac und hashlib und brauchen nichts.
Zugangsdaten liegen getrennt von der Konfiguration, erscheinen in keiner
Antwort der Oberfläche und in keinem Protokoll, und sind im Export
standardmäßig nicht enthalten. Kein host_network, kein privileged, kein
veröffentlichter Port, eigenes AppArmor-Profil. Keine vom Nutzer angegebene
Adresse darf ins lokale Netz zeigen.
Wo was liegt, warum nichts verschlüsselt ist und was das für Sicherungen bedeutet: Handbuch → Zugangsdaten. Schwachstellen bitte nicht als öffentliches Issue melden, sondern über GitHub Security Advisories.
| Dokument | Zielgruppe |
|---|---|
| Handbuch | Nutzer: Einrichten, IP-Quellen, IPv6, Fehlersuche — erscheint auch im App-Reiter „Dokumentation" |
| Anbieterseiten | Nutzer: was ein bestimmter Anbieter verlangt (erzeugt) |
| Anbieter beitragen | Entwickler: Aufbau eines Manifests |
| Testsuiten | Entwickler: was womit abgesichert ist |
| CHANGELOG.md | alle Versionen |
bash tests/run.sh # alle Suiten
bash scripts/test-build.sh # baut das Image und prüft es (Docker/WSL)Kein pytest: die Suiten sollen auf einem nackten Python laufen. Drei der fünf brauchen nur PyYAML und jsonschema und sichern genau den Teil ab, den man beim Hinzufügen eines Anbieters anfasst; die beiden übrigen fahren den Hub hoch und überspringen sich, wenn seine Abhängigkeiten fehlen.
Kein Test spricht mit einem echten Anbieter.
dnsmith/providers/src/<id>.yamlschreiben — das ist die Quellepython3 tools/manifest_merge.pyerzeugt das Manifest und prüft es. Jeder Platzhalter imrequest-Block muss von einem Formularfeld, einem Laufzeitwert oder einerlookup-Bindung gedeckt sein; sonst schlägt es fehlpython3 tools/gen_docs.pyerzeugt die Anbieterseite- Den Endpunkt in
tests/test_provider_requests.pyeintragen — die Tabelle dort ist absichtlich eine zweite Kopie von Host und Pfad
dnsmith/ was auf das Gerät kommt
hub/ Python: Oberfläche, Konfiguration, Zugangsdaten, Updates
providers/ Manifeste (erzeugt) und src/ (Quelle)
frontend/ die Ingress-Oberfläche
docs/providers/ Anbieterseiten (erzeugt)
schemas/ das Manifest-Schema
tools/ Erzeuger und Prüfwerkzeug
tests/ die Testsuiten
Ein Prozess, ein Container. Schlägt ein Update fehl, betrifft das nur den einen Eintrag: die Oberfläche bleibt erreichbar und zeigt den Grund.
- Fehlersuche: die häufigen Fälle stehen in
dnsmith/DOCS.md - Protokoll: Einstellungen → Add-ons → DNSmith → Protokoll. Für mehr
Details die Protokollstufe in den DNSmith-Einstellungen auf
debugstellen — Zugangsdaten werden auch dort herausgefiltert - Fehler melden: Issue anlegen
- Sicherheitslücke: GitHub Security Advisories, nicht als öffentliches Issue
MIT — siehe LICENSE. Hinweise zu Anbieter-Icons und Marken stehen in NOTICE.