IPv64: Aus DynDNS wurde Infrastruktur-Mikado

IPv64.

Früher:

IP ändert sich.

DynDNS aktualisiert die Domain.

Fertig.

Schön.

Ein Problem.

Eine Lösung.

Heute öffnest du IPv64 und bekommst gefühlt den halben Werkzeugkoffer eines Rechenzentrums ins Gesicht.

DynDNS.

DNS.

Healthchecks.

Statusseiten.

DNS-Failover.

Offline-Seiten.

CDN64.

Reverse Proxy.

Portmapper.

Cloud Router.

WireGuard.

Blocklisten.

API.

Node64.

Und vermutlich fehlt nur noch:

„Jetzt neu: IPv64 Waschmaschinen-Cluster.“

Aus einem simplen DynDNS-Dienst ist ein Infrastruktur-Mikado geworden.

Und je länger ich mir das ansehe, desto weniger verstehe ich, warum ich mir das freiwillig antun sollte.

IPv64 beschreibt inzwischen selbst eine ganze Kette aus Diensten: externe Healthchecks, lokale Checks über Node64, hybride Überwachung, DNS-Failover, CDN64, Cloud Router und diverse Sicherheitsfunktionen.

Das ist nicht mehr:

„Hier ist DynDNS.“

Das ist:

„Wie viele Teile deines Netzes möchtest du heute an uns hängen?“

Nein, danke.

Das Absurde daran:

Selfhosting macht man doch unter anderem deshalb, weil man Kontrolle möchte.

Eigener Server.

Eigene Dienste.

Eigene Daten.

Eigene Entscheidungen.

Und dann bauen wir uns freiwillig wieder einen zentralen Anbieter dazwischen, an dem plötzlich Erreichbarkeit, Monitoring, Tunnel, Failover und lokale Nodes hängen.

Cloud verlassen, um sich eine kleinere Cloud selbst einzubauen.

Großartig.

Und dann kommt Node64 noch dazu.

Lokales Monitoring?

Node64.

DNS-Filter?

Node64.

Reverse Proxy?

Node64.

DynDNS?

Node64.

Honeypot?

Node64.

Healthchecks vom IPv64-Portal ins Heimnetz drücken?

Natürlich Node64.

IPv64 nennt das Zusammenspiel selbst „lokal“, „online“ oder „hybrid“. Lokale und hybride Checks hängen dabei direkt an verknüpften Node64-Instanzen.

Also jetzt sitzt nicht nur außen IPv64.

Jetzt kommt IPv64 auch noch mit einem Container ins eigene Netz.

Herrlich unabhängig.

Das ist ungefähr so, als würde man aus Datenschutzgründen Google verlassen und danach sagen:

„Aber einen kleinen Google-Agenten installiere ich trotzdem auf meinem NAS. Nur für die Bequemlichkeit.“

Und dann dieses Wort:

Bequemlichkeit.

Nein.

Ich finde daran nichts bequem.

Ich finde es verkorkst.

Wenn ich Monitoring brauche, nehme ich Monitoring.

Wenn ich einen Reverse Proxy brauche, nehme ich einen Reverse Proxy.

Wenn ich DNS filtern möchte, nehme ich einen DNS-Filter.

Wenn ich DynDNS brauche, nehme ich einen DynDNS-Client.

Das sind keine exotischen Probleme.

Dafür gibt es ausgereifte Software.

Seit Jahren.

Stattdessen baut IPv64 immer mehr eigene Komponenten drumherum und Node64 versucht lokal gleich mehrere davon in einen einzigen Container zu stopfen.

Warum?

Damit ich weniger Container sehe?

Portainer ist keine Modelleisenbahn. Ich muss die Anzahl der Kästchen nicht klein halten.

Noch schöner wird es, wenn man sich anschaut, was gerade mit den alten Diensten passiert.

Healthchecks 1.0?

Wird am 22. November 2026 abgeschaltet.

Checks weg.

Verlauf weg.

Statusseiten weg.

Automatischer Umzug?

Nein.

Bitte selbst neu anlegen.

CDN 1.0?

Ebenfalls 22. November 2026 Schluss.

Reverse-Proxy-Einträge weg.

Portmapper weg.

Automatische Migration?

Natürlich nicht.

Bitte selbst zu CDN64 umziehen.

Das ist mein Lieblingsmoment.

Erst:

Alles aus einer Hand!

Dann:

Die Hand wird ausgetauscht. Bitte tragen Sie Ihren Kram selbst rüber.

Aber Hauptsache Ökosystem.

Und genau das ist die Gefahr an solchen Konstruktionen.

Wenn ich fünf unabhängige Werkzeuge benutze, kann ich eins davon ersetzen.

Caddy nervt?

Weg.

Uptime Kuma nervt?

Weg.

Pi-hole nervt?

Weg.

DynDNS-Anbieter nervt?

Update-URL ändern.

Fertig.

Wenn ich dagegen immer mehr Funktionen an denselben Anbieter kette, hängt plötzlich alles irgendwie zusammen.

Healthcheck meldet Fehler.

DNS-Failover reagiert.

CDN64 hängt davor.

Node64 misst innen.

Das Portal verwaltet die Checks.

Der Account bestimmt Limits.

Und irgendwann braucht man ein Architekturdiagramm, um herauszufinden, warum der Kühlschrank nicht mehr erreichbar ist.

Einfachheit durch zusätzliche Abhängigkeiten.

Kann man sich nicht ausdenken.

IPv64 hat inzwischen auch Kontostufen mit unterschiedlichen Limits: kostenlos, Home/Supporter für 40 Euro jährlich, Business für 100 und Company für 200 Euro. Der Cloud Router gehört zwar grundsätzlich dazu, zusätzliche öffentliche IPv4-Adressen kosten aber beispielsweise extra.

Auch das ist völlig legitim.

Server kosten Geld.

Darum geht es nicht.

Es zeigt nur endgültig, dass wir hier nicht mehr über ein kleines DynDNS-Projekt sprechen.

Wir sprechen über ein Produktportfolio.

Und Produktportfolios haben ein Interesse:

Dass du mehr vom Produktportfolio benutzt.

Deshalb passt Node64 plötzlich hervorragend hinein.

Nicht weil die Welt einen Monolithen aus DNS, Proxy, Monitoring und Honeypot gebraucht hätte.

Sondern weil so noch mehr Teile des Homelabs sauber an IPv64 angedockt werden können.

Das ist für IPv64 natürlich hervorragend.

Für mich?

Nicht.

Wenn die stärkste Begründung für Node64 lautet:

„Es arbeitet besonders eng mit IPv64 zusammen“

dann beantwortet das nicht die Frage:

Warum brauche ich Node64?

Es beantwortet:

Warum ist Node64 für IPv64 sinnvoll?

Das ist etwas anderes.

Sehr sogar.

Und dann kommt noch diese permanente Funktionsvermehrung dazu.

CDN64 wird als „Cloudflare-Alternative“ vermarktet und soll Dienste über mehrere IPv64-Edge-Server erreichbar machen, inklusive Tunnelbetrieb hinter DS-Lite und CGNAT.

Cloud Router löst wiederum Erreichbarkeit per WireGuard.

Healthchecks überwachen.

Node64 überwacht lokal.

DNS Failover schaltet um.

Alles hat seinen eigenen Platz.

Alles greift ineinander.

Alles hat Limits.

Alles hat Dokumentation.

Alles hat Migrationen.

Alles hat Fehlerquellen.

Und irgendwann frage ich mich:

Wollte ich eigentlich einen Server zuhause betreiben oder IPv64-Systemadministrator werden?

Genau deshalb nervt mich dieses Wachstum.

Nicht weil neue Funktionen grundsätzlich schlecht wären.

Sondern weil aus einer glasklaren Aufgabe immer mehr ein System wird, das seine eigene Komplexität erzeugt und anschließend weitere Produkte anbietet, um diese Komplexität wieder einzufangen.

Das ist ein Klassiker.

Problem lösen.

Neue Abhängigkeit schaffen.

Abhängigkeit verwalten.

Verwaltung als neues Feature verkaufen.

SaaS frisst seinen eigenen Schwanz.

Und jetzt bitte niemand mit:

„Aber man muss ja nicht alles benutzen.“

Natürlich nicht.

Ich muss auch nicht jede Taste auf einer Fernbedienung drücken.

Das ändert nichts daran, dass 74 davon Quatsch sein können.

IPv64 darf jeden Dienst anbieten, den es möchte.

Ich darf trotzdem fragen, warum ein DynDNS-Dienst irgendwann glaubt, auch mein Monitoring, mein CDN, mein VPN, mein DNS-Failover und meinen lokalen Infrastruktur-Container erledigen zu müssen.

Vor allem, wenn daneben längst Software existiert, deren gesamte Aufgabe seit Jahren genau eine dieser Funktionen ist.

Ich möchte keinen Anbieter, der alles kann.

Ich möchte Dienste, die eine Sache zuverlässig können.

Langweilig.

Austauschbar.

Vorhersehbar.

Wenn mein Monitoring stirbt, läuft mein DNS weiter.

Wenn mein Proxy ein Update nicht mag, interessiert das meinen Resolver nicht.

Wenn mein DynDNS-Anbieter morgen weg ist, ändere ich einen Client.

Das ist für mich Selfhosting.

Nicht ein Account, an dem immer mehr Kabel hängen.

IPv64 war einmal angenehm simpel.

Heute wirkt es auf mich wie jemand, der einen Schweizer Taschenmesser gesehen und beschlossen hat:

Da fehlt noch eine Mikrowelle.

Und genau deshalb gibt es am Sonntag den Gegenentwurf.

Keine Schaltzentrale.

Keinen Alles-Könner.

Kein „Ökosystem“.

Ein Docker-Stack.

Mehrere Container.

Jeder macht seinen Job.

Jeder einzeln austauschbar.

Und wenn einer Mist baut:

fliegt genau der eine raus.

Wie langweilig.

Wie schön.