---
title: "DynDNS bei Doppel-NAT: ipv64.net per Windows-Aufgabenplanung aktualisieren"
url: "https://florian-puschmann.de/dyndns-bei-doppel-nat-ipv64-net-per-windows-aufgabenplanung-aktualisieren/"
type: "post"
published: "2026-11-01T11:27:44+01:00"
modified: "2026-11-01T11:32:39+01:00"
author: "Florian Puschmann"
---

Dein Router hängt hinter einer Fritzbox, also im Doppel-NAT, und dein DynDNS-Eintrag zeigt nach dem nächtlichen IP-Wechsel der Telekom auf die alte Adresse? Genau das Problem hatte ich mit meinem UniFi Cloud Gateway. Weil das Gateway den DynDNS-Eintrag bei ipv64.net in diesem Aufbau nicht selbst aktualisieren kann, erledigt das jetzt ein kleines Skript, das Windows nachts per Aufgabenplanung startet. Hier zeige ich dir das Skript, die Aufgabe, die Fehler, über die ich gestolpert bin, und warum ich ipv64.net als DynDNS-Dienst nutze.

## Auf einen Blick

- **Problem:** Im Doppel-NAT sieht das zweite Gateway nur eine private Adresse am WAN-Port und bemerkt den Wechsel der öffentlichen IP nicht.
- **Lösung:** Ein Rechner im Netz ruft die Update-URL von ipv64.net auf. ipv64 übernimmt die öffentliche IP, von der der Aufruf kommt.
- **Zeitplan:** Zwangstrennung in der Fritzbox auf 2 bis 3 Uhr, Wechsel laut meinen Logs meist gegen 2:45 Uhr, Skript täglich ab 3:00 Uhr alle 15 Minuten für eine Stunde.
- **Werkzeuge:** Batch-Datei mit dem in Windows eingebauten `curl.exe`, Windows-Aufgabenplanung (`schtasks`), Log-Datei neben dem Skript.
- **Quelle:** [ipv64.net: DynDNS2 Updater / DynDNS API](https://ipv64.net/dyndns_updater_api)

## Warum klappt DynDNS im Doppel-NAT nicht?

Bei mir hängt das UniFi Cloud Gateway (noch) hinter einer Fritzbox. Die Fritzbox hält die Internetverbindung zur Telekom und bekommt die öffentliche IPv4-Adresse. Das Gateway dahinter bekommt von der Fritzbox nur eine private Adresse aus dem Heimnetz. Das nennt man **Doppel-NAT**: Die Adressen werden zweimal übersetzt, einmal in der Fritzbox und einmal im Gateway.

Für DynDNS ist das ungünstig. Der DynDNS-Client im Gateway sieht an seinem WAN-Anschluss nur die private Adresse, die sich nie ändert. Wechselt die Telekom nachts die öffentliche IP, bekommt das Gateway davon nichts mit und meldet nichts an ipv64.net. Der DNS-Eintrag zeigt dann bis zum nächsten manuellen Update auf die alte Adresse, und alles, was von außen über den Namen erreichbar sein soll, ist weg.

## Warum nicht einfach die DynDNS-Funktion der Fritzbox?

Die Fritzbox kennt die öffentliche IP und hat selbst einen DynDNS-Client. Für mich lohnt sich der Umbau trotzdem nicht: Die Fritzbox soll demnächst ganz abgeschafft werden, danach übernimmt das UniFi Gateway allein. Bis dahin will ich nichts mehr an der Fritzbox einrichten, was ich beim Umbau wieder abbauen muss. Das Skript ist eine schnelle Brücke, die ohne Änderung an den Routern auskommt.

## Wann wechselt die IP?

In der Fritzbox lässt sich die Zwangstrennung durch den Anbieter in ein festes Zeitfenster legen. Bei mir steht sie auf **2 bis 3 Uhr**. In den Fritzbox-Ereignissen und in meinem Monitoring sehe ich, dass der Wechsel **meist gegen 2:45 Uhr** passiert.

Daraus ergibt sich der Zeitplan für das Skript: Der erste Lauf kommt um 3:00 Uhr, also nach dem Ende des Zeitfensters. Damit auch ein etwas späterer Wechsel erfasst wird, wiederholt sich der Aufruf bis kurz vor 4 Uhr alle 15 Minuten.

## Wie sieht das Update-Skript aus?

Unter Windows ist eine Batch-Datei mit dem eingebauten `curl.exe` der einfachste Weg. Das Skript ruft die Update-URL einmal auf, schreibt die Antwort von ipv64 in ein Log neben dem Skript und gibt den Exitcode von curl zurück. So sieht auch die Aufgabenplanung, ob der Aufruf geklappt hat.

Lege die Datei als `C:\Scripts\ipv64-update.bat` ab und trage deinen Key ein:

@echo off

rem IPv64 DynDNS Update – ruft die Update-URL einmal auf und schreibt ein Logset „KEY=HIER_DEIN_KEY_EINTRAGEN“set „LOGFILE=%~dp0ipv64-update.log“ echo [%date% %time%] Update gestartet>> „%LOGFILE%“curl.exe -s -S –max-time 30 „https://ipv4.ipv64.net/nic/update?key=%KEY%“ >> „%LOGFILE%“ 2>&1set „RC=%errorlevel%“echo.>> „%LOGFILE%“echo [%date% %time%] curl Exitcode: %RC%>> „%LOGFILE%“ exit /b %RC% 

Ein paar Hinweise dazu:

- Der Hostname `ipv4.ipv64.net` sorgt dafür, dass das Update über IPv4 läuft und ipv64 die IPv4-Adresse setzt. Für IPv6 gibt es entsprechend `ipv6.ipv64.net` (siehe [Updater-Doku](https://ipv64.net/dyndns_updater_api)).
- Enthält dein Key ein `%`, schreibe es im Skript als `%%`.
- Der Key steht im Klartext in der Datei. Lege sie nur dort ab, wo sie außer dir und dem Konto der Aufgabe niemand lesen kann.
- `%~dp0` ist der Ordner, in dem das Skript liegt. Das Log landet also immer neben dem Skript, egal aus welchem Verzeichnis die Aufgabenplanung es startet.

Teste das Skript zuerst direkt in der Eingabeaufforderung und schau ins Log. Steht dort eine Antwort von ipv64 und `curl Exitcode: 0`, passt der Aufruf.

## Wie richte ich die Aufgabe ein?

Öffne die Eingabeaufforderung **als Administrator** und lege die Aufgabe an:

```

```

schtasks /Create /TN „IPv64 DynDNS Update“ /TR „C:\Scripts\ipv64-update.bat“ /SC DAILY /ST 03:00 /RI 15 /DU 00:59 /F /RL HIGHEST
- `/SC DAILY /ST 03:00`: täglich um 3 Uhr
- `/RI 15`: alle 15 Minuten wiederholen
- `/DU 00:59`: Wiederholung auf knapp eine Stunde begrenzen, damit die Läufe um 3:00, 3:15, 3:30 und 3:45 Uhr kommen. Mit `/DU 01:00` kann je nach Windows-Version noch ein Lauf um 4:00 Uhr folgen.
- `/F`: eine bestehende Aufgabe gleichen Namens überschreiben
- `/RL HIGHEST`: mit höchsten Rechten ausführen

Danach einmal von Hand auslösen und das Log prüfen:

```

```

schtasks /Run /TN „IPv64 DynDNS Update“schtasks /Query /TN „IPv64 DynDNS Update“ /V /FO LIST

Ich lasse die Aufgabe unter meinem eigenen Benutzer laufen. Ohne weitere Angaben startet `schtasks` sie nur, wenn dieser Benutzer angemeldet ist. Soll sie auch ohne Anmeldung laufen, aktiviere in der Aufgabenplanung „Unabhängig von der Benutzeranmeldung ausführen“ (Windows fragt dann nach dem Passwort) oder nimm das SYSTEM-Konto (siehe Fehlersuche, Schritt 6).

Wichtig: Der Rechner muss um diese Zeit laufen. Ist er aus oder im Standby, fällt der Lauf aus. In der Aufgabenplanung kannst du unter „Einstellungen“ die Option „Aufgabe so schnell wie möglich nach einem verpassten Start ausführen“ aktivieren.

Ich lasse ihn auf meinem kleinen Server laufen, welcher 24/7 aktiv ist. 

## Die Aufgabe startet, aber nichts passiert: Was tun?

Bei mir lief die Aufgabe zuerst los, das Skript tat aber nichts. Diese Schritte grenzen den Fehler ein:

**1. Skript direkt starten.** Läuft es in der Eingabeaufforderung, liegt das Problem bei der Aufgabe, nicht beim Skript.

**2. „Letztes Ergebnis“ prüfen.** Die Ausgabe von `schtasks /Query ... /V /FO LIST` zeigt den Rückgabewert des letzten Laufs:

| Letztes Ergebnis | Bedeutung |
| --- | --- |
| 0 | alles in Ordnung |
| 1 | Aufgabe startet, Skript endet mit Fehler |
| 2 bzw. 0x80070002 | Datei nicht gefunden, Pfad falsch |
| 0x41301 | Aufgabe läuft gerade noch |

**3. Pfad prüfen.** Bei mir war genau das die Ursache: ein falscher Pfad. Vergleiche den Pfad hinter `/TR` Zeichen für Zeichen mit dem tatsächlichen Speicherort. Enthält der Pfad Leerzeichen oder startet die Aufgabe das Skript trotz richtigem Pfad nicht, starte das Skript über `cmd /c` und setze ihn in Anführungszeichen:

```

```

schtasks /Create /TN „IPv64 DynDNS Update“ /TR „cmd /c \“C:\Scripts\ipv64-update.bat\““ /SC DAILY /ST 03:00 /RI 15 /DU 00:59 /F

**4. Schreibrechte prüfen.** Darf das Konto der Aufgabe nicht in den Skriptordner schreiben, scheitert schon die erste Log-Zeile. Test: `echo test > C:\Scripts\test.txt`. Bei Bedarf Rechte vergeben (Benutzername anpassen):

icacls C:\Scripts /grant DEIN_BENUTZER:(OI)(CI)M

Alternativ das Log ins Benutzerprofil legen: `set "LOGFILE=%USERPROFILE%\ipv64-update.log"`.

**5. Zeilenenden prüfen.** Wurde die Datei auf Linux oder mit einem Editor gespeichert, der nur LF statt CRLF schreibt, verhält sich `cmd` manchmal seltsam. In PowerShell auf Windows-Zeilenenden umstellen:

```

```

(Get-Content C:\Scripts\ipv64-update.bat) | Set-Content C:\Scripts\ipv64-update.bat

**6. Als SYSTEM ausführen.** Soll die Aufgabe laufen, ohne dass jemand angemeldet ist, lege sie unter dem SYSTEM-Konto an:

```

```

schtasks /Create /TN „IPv64 DynDNS Update“ /TR „C:\Scripts\ipv64-update.bat“ /SC DAILY /ST 03:00 /RI 15 /DU 00:59 /RU SYSTEM /RL HIGHEST /F

**7. curl einzeln testen.** Ein Exitcode ungleich 0 im Log ist ein curl-Problem, etwa `6` (Name nicht auflösbar) oder `28` (Zeitüberschreitung). Zum Gegenprüfen:

curl.exe -s -S –max-time 30 „https://ipv4.ipv64.net/nic/update?key=DEIN_KEY“

## Ist ein Update alle 15 Minuten nicht übertrieben?

Ehrlich gesagt: ja, ein bisschen. Die IP wechselt in der Regel einmal pro Nacht, und eigentlich würde ein Aufruf direkt danach reichen. Die vier Läufe sind ein pragmatischer Kompromiss: Das Skript weiß nicht, ob und wann der Wechsel stattgefunden hat, es meldet einfach die aktuelle Adresse. Kommt der Wechsel etwas später als sonst, erwischt ihn einer der folgenden Läufe.

Für ipv64 ist das unkritisch. Ist die Adresse unverändert, antwortet der Dienst mit `nochg` und ändert nichts am DNS-Eintrag. Laut [Updater-Doku](https://ipv64.net/dyndns_updater_api) liegt das Standardlimit bei 48 Updates in 24 Stunden (abhängig von der Kontoklasse) und höchstens 3 Updater-Anfragen innerhalb von 10 Sekunden. Vier Aufrufe pro Nacht sind davon weit entfernt. Häufiger als nötig solltest du den Dienst trotzdem nicht aufrufen: Nach zu vielen Fehlversuchen in kurzer Zeit sperrt ipv64 den Key für 10 Minuten.

Die Grenzen dieser Lösung solltest du kennen: Wechselt die IP außerhalb des Zeitfensters, etwa nach einem Neustart der Fritzbox oder einer Störung, merkt das Skript es erst in der nächsten Nacht. Wer das vermeiden will, kann zusätzlich einen stündlichen Lauf tagsüber einplanen.

## Warum ipv64.net?

Ich nutze für DynDNS ipv64.net. Was mir daran gefällt:

- **Kostenlos:** ipv64 beschreibt sich auf der [Startseite](https://ipv64.net/) als kostenloser DynDNS-Dienst (DynDNS2), dazu kommen weitere Dienste wie Healthchecks und ein WireGuard-VPN-Gateway.
- **Aus Deutschland:** Laut eigener Angabe in Deutschland entwickelt und zu 100 % von dort betrieben.
- **Getrennte Update-Adressen für IPv4 und IPv6:** Mit `ipv4.ipv64.net` und `ipv6.ipv64.net` legst du fest, welche Adresse aktualisiert wird. Das passt gut zu Skripten wie diesem.
- **Einfache Update-URL:** Ein Aufruf mit dem Key reicht. Die Antwort lässt sich mit dem Parameter `output` von JSON auf eine kurze Form (`good`, `nochg`, `fail`) umstellen, das macht Logs übersichtlicher.
- **Standardprotokoll:** Die Schnittstelle folgt DynDNS2, damit funktionieren auch Router und Firewalls mit eingebautem DynDNS-Client.

Ich nutze ipv64.net schon seit geraumer Zeit und bin damit sehr zufrieden. Es ist ein cooles Projekt, welches technisch gut umgesetzt ist und mir viele Möglichkeiten bietet. 

## FAQ

**Warum aktualisiert mein Router im Doppel-NAT den DynDNS nicht?** Er sieht an seinem WAN-Anschluss nur die private Adresse der vorgeschalteten Fritzbox. Den Wechsel der öffentlichen IP bekommt er nicht mit.

**Woher weiß ipv64, welche IP gesetzt werden soll?** Ruft ein Rechner im Netz die Update-URL auf, nutzt ipv64 die Adresse, von der der Aufruf kommt. Das ist die öffentliche IP deines Anschlusses. Über `ipv4.ipv64.net` erzwingst du IPv4.

**Was bedeutet „Letztes Ergebnis: 1″ in der Aufgabenplanung?** Die Aufgabe startet, das Skript endet aber mit Fehler. Häufige Ursachen sind ein falscher Pfad, fehlende Schreibrechte für das Log oder ein curl-Fehler.

**Läuft die Aufgabe auch ohne angemeldeten Benutzer?** Ja, wenn du sie mit `/RU SYSTEM` anlegst.

**Ist ipv64.net kostenlos?** Laut ipv64 sind die angebotenen Dienste kostenlos nutzbar. Limits wie die Anzahl der Updates pro Tag hängen von der Kontoklasse ab.