DDNSS.de wird eingestellt: DynDNS bis 31.10.2026 migrieren

Wer Router, NAS, Kameras oder VPN-Zugänge über einen Hostnamen bei DDNSS.de erreichbar macht, muss bis Ende Oktober umstellen. Laut einer Mitteilung des Betreibers wird der kostenlose DynDNS-Dienst spätestens zum 31. Oktober 2026 eingestellt, sofern sich kein Nachfolger findet. Ab dann werden die DynDNS-Einträge nicht mehr aktualisiert. Betroffen sind alle Hostnamen unter den DDNSS-Domains, also nicht nur ddnss.de, sondern auch Varianten wie ddnss.ch, dyn-ip24.de oder home-webserver.de.

Nicht betroffen ist, wer DynDNS über einen anderen Anbieter, den Dienst des Routerherstellers oder eine eigene Domain mit DNS-API betreibt. Sofort eingreifen muss heute niemand, denn bis zum Stichtag laufen die Updates nach aktuellem Stand weiter. Die Inventur sollte aber diese Woche passieren, denn bei festen IP-Adressen fällt ein veralteter Eintrag erst beim nächsten Wechsel der öffentlichen IP auf, und dann meist nachts oder am Wochenende, wenn der VPN-Zugang eines Außendienstlers nicht mehr funktioniert.

Was ist passiert?

Der Betreiber von DDNSS.de hat Nutzer per E-Mail darüber informiert, dass der Dienst eingestellt wird. Die Mail ist auf den 22. September 2026 datiert und wurde in mehreren Quellen im Wortlaut veröffentlicht, unter anderem am 23. September im Inoffiziellen Vodafone-Kabel-Forum und am 24. September in Borns IT- und Windows-Blog. Die Kernaussagen der Mitteilung:

Der Dienst läuft seit Mai 2013 und soll zum 31. Oktober 2026 enden.
Als Grund nennt der Betreiber die laufenden Kosten für Server und Infrastruktur sowie den zeitlichen Aufwand für Betrieb, Wartung und Administration.
Vor der Abschaltung bietet er eine kostenpflichtige Übernahme an, die je nach Vereinbarung Domains, Quellcode, Daten und technische Grundlage umfassen kann.
Kommt keine Übernahme zustande, wird der Dienst spätestens am 31. Oktober 2026 eingestellt, bestehende DynDNS-Einträge werden danach nicht mehr aktualisiert.
Nutzer, die DDNSS.de für Geräte, Server, Kameras, VPNs oder andere Systeme verwenden, sollen rechtzeitig zu einem anderen Anbieter wechseln.

Zur Quellenlage gehört eine Einschränkung: Auf der Webseite von DDNSS.de selbst steht bisher kein Hinweis auf die Einstellung. Die News-Seite des Dienstes zeigte bei unserer Prüfung am 25. September 2026 als jüngsten Eintrag eine Meldung vom Januar 2025, auch die Startseite bewirbt den Dienst unverändert. In den Kommentaren bei Born wurde deshalb die Echtheit der Mail angezweifelt. Günter Born schreibt dort, er habe die im Impressum genannte Person telefonisch erreicht und diese habe die Einstellung nach 13 Jahren bestätigt. Eine offizielle Bestätigung auf ddnss.de steht damit weiterhin aus, die Meldung ist aber über die im Wortlaut gleiche Mail an mehrere Nutzer und die telefonische Rückfrage gut belegt.

Wer ist betroffen?

DDNSS.de war vor allem im deutschsprachigen Raum verbreitet, weil sich der Dienst einfach einrichten ließ und kostenlos war. Die Startseite weist mehr als 166.000 registrierte Hostnamen aus. Typische Einsatzorte in kleinen Unternehmen und Außenstellen sind:

DynDNS-Einstellungen im Router, etwa bei der FRITZ!Box mit benutzerdefiniertem Anbieter und der Update-URL upd.php von DDNSS, oder in Kabelroutern von Vodafone.
NAS-Systeme mit eingebautem DDNS-Client, über die Dateifreigaben, Fotoalben oder Backup-Ziele von außen erreichbar sind.
Linux-Server und Raspberry Pi mit ddclient, Cron-Skripten oder Container-Lösungen, die die IP per Update-URL melden.
VPN-Endpunkte: WireGuard-Peers mit Endpoint = name.ddnss.de:51820, IPsec-Gegenstellen von Site-to-Site-Verbindungen, OpenVPN-Clientprofile mit remote-Eintrag.
Portfreigaben für Kameras, Videorekorder, Fernwartungszugänge oder Smart-Home-Zentralen.
TLS-Zertifikate, deren Hostname auf einer DDNSS-Domain liegt, etwa Let's-Encrypt-Zertifikate für einen Reverse Proxy.
Eigene Domains, die per CNAME auf einen DDNSS-Hostnamen zeigen. Hier bleibt der eigene Name erhalten, das Ziel dahinter veraltet aber.

Wer eine feste öffentliche IPv4-Adresse hat und den DDNSS-Namen nur aus Gewohnheit nutzt, ist weniger akut gefährdet, sollte den Namen aber trotzdem ersetzen. Was nach dem Stichtag mit der Namensauflösung selbst passiert, ob die Zonen weiter ausgeliefert werden oder ganz verschwinden, geht aus der Mitteilung nicht hervor.

Wie kritisch ist das?

Das ist keine Sicherheitslücke, sondern ein planbares Betriebsrisiko mit festem Termin. Kritisch wird es durch den Zeitpunkt des Ausfalls: Ein DynDNS-Eintrag, der nicht mehr aktualisiert wird, zeigt nach dem nächsten IP-Wechsel auf eine fremde Adresse. VPN-Tunnel bauen sich dann nicht mehr auf, Fernzugriffe laufen ins Leere, und Zertifikatserneuerungen per HTTP-Challenge schlagen fehl.

Ein zweiter Punkt betrifft die Sicherheit indirekt. Der Betreiber bietet Domains und Daten zur Übernahme an. Wer die Domains künftig kontrolliert, bestimmt, wohin die Hostnamen auflösen. Das ist bei einem seriösen Nachfolger unproblematisch, bleibt aber ein Vertrauenswechsel, den Admins bewusst entscheiden sollten, statt Konfigurationen einfach weiterlaufen zu lassen. Clients, die sich per Hostname an einen Dienst anmelden, sollten deshalb Zertifikate oder Schlüssel prüfen und nicht allein dem Namen vertrauen. Bei WireGuard sichert der öffentliche Schlüssel des Peers die Verbindung ab, bei Web- und Fernwartungszugängen ist die Zertifikatsprüfung entscheidend.

Unsere Einschätzung: im laufenden Wartungsfenster erledigen, spätestens Mitte Oktober abschließen, damit Zeit für Tests und Nachzügler bleibt.

Was sollten Admins jetzt tun?

Inventur zuerst: Router, Firewalls, NAS und Server nach DDNSS-Hostnamen durchsuchen. Auf Linux reicht oft grep -rIl -E "ddnss|dyn-ip24|dyndns1|home-webserver|myhome-server|dynip.online" /etc /opt /home 2>/dev/null, dazu die Konfiguration von ddclient und Container-Umgebungsvariablen.
Clientseitige Konfigurationen einbeziehen: WireGuard- und OpenVPN-Profile auf Notebooks und Smartphones, IPsec-Gegenstellen, Fernwartungs-Tools, Überwachungs-Checks im Monitoring.
Eigene DNS-Zonen auf CNAME-Einträge prüfen, die auf DDNSS-Namen zeigen.
Nachfolger wählen und parallel einrichten, bevor der alte Eintrag abgeschaltet wird. Beide Namen können bis zum Stichtag gleichzeitig aktualisiert werden.
Einen eigenen, stabilen Namen einführen, zum Beispiel vpn.firma.de als CNAME auf den jeweiligen DynDNS-Namen. Bei einem späteren Anbieterwechsel ändert sich dann nur ein DNS-Eintrag statt vieler Clientprofile.
Zertifikate neu ausstellen, wenn der Hostname im Zertifikat auf einer DDNSS-Domain liegt, und Reverse-Proxy-Konfigurationen anpassen.
Clientprofile verteilen und testen, bevor der alte Name wegfällt, idealerweise bei einem erzwungenen IP-Wechsel über einen Neustart der Internetverbindung.
Den alten Update-Eintrag nach der Umstellung aus Router und Skripten entfernen und das DDNSS-Konto kündigen, damit keine Zugangsdaten in vergessenen Konfigurationen liegen bleiben.

Als Nachfolger kommen mehrere Wege in Frage, die sich in Aufwand und Abhängigkeit unterscheiden:

Der DynDNS-Dienst des Routerherstellers, bei der FRITZ!Box etwa MyFRITZ!. Das ist schnell eingerichtet, der Name ist aber an das Gerät und das Herstellerkonto gebunden.
deSEC, ein gemeinnütziger DNS-Anbieter, der laut Dokumentation DynDNS sowohl unter dedyn.io als auch für eigene Domains unterstützt, per Router-Client oder ddclient, und eine API für Let's-Encrypt-DNS-Challenges bietet.
Eine eigene Domain bei einem DNS-Anbieter mit API. Cloudflare beschreibt dafür in der Dokumentation ein Skript gegen die API oder den freien Client ddclient. Ähnliche Funktionen bieten viele Domain-Hoster, die DynDNS für eigene Domains im Paket haben.
Andere freie DynDNS-Anbieter. Hier vorher klären, ob der Account regelmäßig bestätigt werden muss und wie viele Updates pro Tag erlaubt sind.

Einordnung für Unternehmen

Die Einstellung zeigt ein bekanntes Muster: Kostenlose Einzelbetreiber-Dienste laufen jahrelang zuverlässig, bis der Betreiber aufhört. Für private Setups ist das hinnehmbar, für Firmenzugänge eigentlich nicht. Wer Mitarbeiter per VPN anbindet oder Außenstellen vernetzt, sollte Erreichbarkeit nicht von einem Dienst ohne Vertrag und ohne Ansprechpartner abhängig machen.

Die robusteste Lösung für kleine Unternehmen ist ein Hostname unter der eigenen Domain. Entweder als CNAME auf einen DynDNS-Namen oder direkt per DNS-API aktualisiert. Die Clientkonfiguration bleibt dann dauerhaft gleich, nur der Mechanismus dahinter wird getauscht. Wo der Anschluss es erlaubt, ist eine feste IP-Adresse beim Provider die einfachste Variante, weil DynDNS dann ganz entfällt. Die aktuelle Umstellung ist ein guter Anlass, diese Architektur einmal sauber aufzusetzen, statt einen kostenlosen Dienst gegen den nächsten zu tauschen.

Offen ist, ob sich ein Nachfolger für DDNSS findet. Borns Blog will darüber berichten, falls es dazu Neuigkeiten gibt. Darauf zu warten, ist für produktive Zugänge aber keine gute Strategie.

Passende Anleitungen auf S-EDV

WireGuard-VPN für Homeoffice und Standorte einrichten: Endpunkte und Peer-Konfigurationen, die nach dem Wechsel angepasst werden müssen.
DNS-Records erklärt: A, AAAA, CNAME, MX und TXT: Grundlagen für einen eigenen, stabilen Hostnamen per CNAME.
TLS-Zertifikate mit Let's Encrypt und Certbot: Zertifikate für den neuen Hostnamen ausstellen und erneuern.

Was ist passiert?

Wer ist betroffen?

Wie kritisch ist das?

Was sollten Admins jetzt tun?

Einordnung für Unternehmen

Passende Anleitungen auf S-EDV

Quellen

Weiter lesen

Technitium DNS Server mit Docker Compose: eigener DNS für das Firmennetz

VeloCloud Orchestrator: Kritische Lücke CVE-2026-93952 mit CVSS 10.0 wird aktiv ausgenutzt

Unbound und BIND 9: Kritische DNSSEC-Lücke und 14 Fehler in einem ISC-Sicherheitsupdate