--- title: "DDNSS.de läuft weiter: Betreiber nimmt Schlusstermin 31. Oktober 2026 zurück, Übernahme offen" date: 2026-09-25T02:12:54+02:00 modified: 2026-10-31T19:49:06+01:00 category: netzwerk type: news author: Marcel Schönfelder canonical: https://s-edv.com/news/ddnss-de-dyndns-eingestellt-31-oktober-2026-migration keywords: - DynDNS - DDNSS - DNS - FRITZ!Box - WireGuard - VPN - Netzwerk reading_time: 8 --- # DDNSS.de läuft weiter: Betreiber nimmt Schlusstermin 31. Oktober 2026 zurück, Übernahme offen **Stand 31.10.2026:** DDNSS.de wird vorerst nicht eingestellt. Laut einer Mail des Betreibers an die Nutzer vom 29. Oktober 2026 ist der 31. Oktober kein Schlusstermin mehr, der Dienst läuft unverändert weiter. Über eine Übernahme wird noch verhandelt, ein Ergebnis gibt es nicht. Wer Router, NAS, Kameras oder VPN-Zugänge über einen Hostnamen bei DDNSS.de erreichbar macht, muss damit nicht mehr bis Ende Oktober umstellen. Der Betreiber hatte die Einstellung des kostenlosen DynDNS-Dienstes zunächst für spätestens 31. Oktober 2026 angekündigt und diesen Termin am 29. Oktober zurückgenommen. Bis zum Abschluss der Übernahmeverhandlungen soll sich nichts ändern, einen festen Endtermin gibt es nicht. Das gilt für 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 niemand. Eine Inventur lohnt sich trotzdem, denn die Zukunft des Dienstes bleibt offen, und 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 hatte Nutzer zunächst 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](https://borncity.com/blog/2026/09/24/ddnss-de-wird-zum-31-oktober-2026-eingestellt/). Die Kernaussagen dieser ersten 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. Am 9. Oktober 2026 meldete der Betreiber per Rundmail Gespräche über eine mögliche Übernahme, [wie Born berichtet](https://borncity.com/blog/2026/10/10/gespraeche-zur-uebernahme-von-ddnss-de-laufen/). Am 29. Oktober folgte die Entwarnung per Mail, die [Dennis Schröder im Wortlaut veröffentlicht hat](https://schroederdennis.de/ipv64-net/ddnss-de-eingestellt-uebernahme-ipv64/). Darin heißt es: „Der 31. Oktober 2026 ist ausdrücklich kein Schlusstermin.“ Die Kernaussagen: - Bestehende DynDNS-Einträge laufen unverändert weiter. - Es gibt keine Abschaltung und keinen festen Endtermin. - Bis zum Abschluss der Übernahmeverhandlungen ändert sich nichts. - Der Betreiber will informieren, sobald eine Entscheidung gefallen ist. Wer den Dienst übernehmen könnte, nennt die Mail nicht. Öffentlich gemeldet haben sich Dennis Schröder von IPv64.net und dnsHome.de, die nach eigenen Angaben in Kontakt mit dem Betreiber stehen. Schröder schrieb am 29. Oktober, er habe trotz Nachfrage nichts gehört. Bei seinem Angebot müssten Router und Skripte laut seiner Aussage kaum angepasst werden, die Nutzer aber auf die IPv64-Plattform wechseln. Zur Quellenlage gehört eine Einschränkung: Auf der Webseite von DDNSS.de selbst steht weder etwas zur Einstellung noch zur Entwarnung. Die [News-Seite des Dienstes](https://ddnss.de/sitenews.php) zeigte bei unserer Prüfung am 31. Oktober 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 ersten 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. Die Entwarnung ist über die im Wortlaut gleiche Mail an mehrere Nutzer belegt, eine Bestätigung auf ddnss.de steht weiterhin aus. ## Wer ist betroffen? DDNSS.de ist vor allem im deutschsprachigen Raum verbreitet, weil sich der Dienst einfach einrichten lässt und kostenlos ist. 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 abhängig vom Dienst, sollte den Namen aber mittelfristig ersetzen. Was bei einem Betreiberwechsel oder einem späteren Ende mit der Namensauflösung selbst passiert, ob die Zonen weiter ausgeliefert werden oder ganz verschwinden, geht aus den Mitteilungen nicht hervor. ## Wie kritisch ist das? Das ist keine Sicherheitslücke und nach der Entwarnung auch kein Fall mit festem Termin mehr, aber weiterhin ein Betriebsrisiko. Sollte der Dienst später doch enden, wäre der Zeitpunkt des Ausfalls das Problem: 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 verhandelt über eine Übernahme, die nach seiner ersten Mitteilung Domains und Daten umfassen kann. 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: kein Notfall mehr. Begonnene Umstellungen können zu Ende geführt werden, die übrigen Zugänge gehören in die normale Wartungsplanung, mit einem vorbereiteten Ausweichweg bis zur Entscheidung über die Übernahme. ## 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. - Für produktive Zugänge einen Ausweichweg wählen und parallel einrichten. Beide Namen können 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. - Wer bei DDNSS bleibt: die im Konto hinterlegte E-Mail-Adresse prüfen, denn der Betreiber informiert bisher per Rundmail und nicht auf der Webseite. Sobald die Entscheidung fällt, neu bewerten, wer die Domains künftig kontrolliert und ob bestehende Konten erhalten bleiben. Als Ausweichweg kommen mehrere Lösungen 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](https://desec.readthedocs.io/en/latest/dyndns/configure.html) 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](https://developers.cloudflare.com/dns/manage-dns-records/how-to/managing-dynamic-ip-addresses/) ein Skript gegen die API oder den freien Client [ddclient](https://ddclient.net/). Ä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 Ankündigung zeigt ein bekanntes Muster, auch wenn sie vorerst zurückgenommen ist: 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 Ankündigung bleibt ein guter Anlass, diese Architektur einmal sauber aufzusetzen, statt einen kostenlosen Dienst gegen den nächsten zu tauschen. Offen bleibt, ob und an wen DDNSS übergeben wird. Der Betreiber will informieren, sobald eine Entscheidung gefallen ist. 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](https://s-edv.com/anleitungen/wireguard-vpn-homeoffice-standort-einrichten): Endpunkte und Peer-Konfigurationen, die nach dem Wechsel angepasst werden müssen. - [DNS-Records erklärt: A, AAAA, CNAME, MX und TXT](https://s-edv.com/anleitungen/dns-records-erklaert-a-aaaa-cname-mx-txt): Grundlagen für einen eigenen, stabilen Hostnamen per CNAME. - [TLS-Zertifikate mit Let's Encrypt und Certbot](https://s-edv.com/anleitungen/lets-encrypt-certbot-tls-zertifikate): Zertifikate für den neuen Hostnamen ausstellen und erneuern. ## Quellen - [Borns IT- und Windows-Blog: DDNSS.de wird zum 31. Oktober 2026 eingestellt (24.09.2026)](https://borncity.com/blog/2026/09/24/ddnss-de-wird-zum-31-oktober-2026-eingestellt/) - [Borns IT- und Windows-Blog: Gespräche zur Übernahme von DDNSS.de laufen (10.10.2026)](https://borncity.com/blog/2026/10/10/gespraeche-zur-uebernahme-von-ddnss-de-laufen/) - [schroederdennis.de: ddnss.de wird eingestellt, mit Mail vom 29.10.2026 im Wortlaut in den Kommentaren (30.10.2026)](https://schroederdennis.de/ipv64-net/ddnss-de-eingestellt-uebernahme-ipv64/) - [Inoffizielles Vodafone-Kabel-Forum: Mitteilung des Betreibers im Wortlaut (23.09.2026)](https://www.vodafonekabelforum.de/viewtopic.php?t=48415) - [DDNSS.de: Startseite mit Domainliste und Funktionsumfang](https://ddnss.de/) - [DDNSS.de: News-Seite, geprüft am 31.10.2026 ohne Hinweis auf Einstellung oder Entwarnung](https://ddnss.de/sitenews.php) - [deSEC: Configuring your dynDNS Client](https://desec.readthedocs.io/en/latest/dyndns/configure.html) - [Cloudflare Docs: Managing dynamic IP addresses](https://developers.cloudflare.com/dns/manage-dns-records/how-to/managing-dynamic-ip-addresses/)