Na ja, spätestens nach Ablauf der TTL sollte die Namensauflösung deiner Hosts schon überall passen.
google.com ist übrigens ein schlechtes Beispiel, die verteilen die Namensauflösung auch nach Regionen um die Last auf der Welt zu verteilen.
Hallo,
das Thema führt ja nun doch zu einigen Diskussionen. Ich habe auch das Gefühl, dass es hier auf einmal irgendwo einen „Anfragen-Stau“ gibt.
Ich verwende nslookup unter Linux (Debian) und habe als lokalen DNS AdGuard Home, der aber alle Anfragen ordnungsgemäß weiterleitet. Mit dig sehe ich, dass der DNS-Cache maximal 60 Sekunden alt ist, was weit von 15 min oder gar 3 Stunden entfernt ist.
Was ich jetzt nicht weiß, ist, ob IPV64.net auf meine Updates nicht reagiert (bzw. erst nach unzähligen Versuchen nach X Stunden) oder ob die Weitergabe an die globalen DNS nicht sauber funktioniert.
Wie gesagt, bis letzten Sonntag war alles noch in Ordnung.
Grüße
Mic.
Schreib dir doch ein kleines Skript, welches kurz nach der Zwangstrennung alle 5 Minuten oder so, alle deine Domains per nslookup über verschiedene externe DNS-Server (z.B. 1.1.1.1 / 9.9.9.9 / 8.8.8.8 /etc. abfragt und das Ergebnis in ein Logfile schreibt.
Dann siehst du ja wie lange es dauert, bis DynDNS-Updates bei den relevanten Servern ankommt.
Bau vielleicht mal ein
sleep 120
nslookup host.deinedomain.ipv64.net ns1.ipv64.netnach jeder Aktualisierung in dein Script mit ein, damit man sieht, ob der zuständige DNS-Server die Änderung zeitnah mitbekommt.
Edit: Oder so, wie von @The_eagle vorgeschlagen - jetzt erst gesehen.
Ich war eben erstaunt. Mein Counter 64/64 wurde auf einmal „mitten am Tag“ resetiert:
Wie kommt das denn?
Ich habe das genutzt, um mal eben eine Änderung der IP zu erzwingen. Das Update ging dieses Mal recht schnell. Nach ca. 3 min waren meine Webdienste wieder erreichbar.
Was komisch war: Als ich mein Skript laufen lies, hat es bei meiner dritten Domain doch wieder HTTP-Fehler 429 gebracht, allerdings mit dieser Meldung:
"info":"Update Cooldown - 10sec","status":"403 Forbidden"}
Kann es sein, dass ich nach zwei Updates eine Pause von 10 Sek. machen muss?
Ich habe nun auch ein Skript erstellt, was nslookups macht. Dieses lasse ich dann nach der DSL-Zwangstrennung (die ich nun mal eine Stunde früher eingestellt habe) alle 5 min laufen lasse.
Grüße
Mic.
Es dauere 35 Minuten bis Denis DNS die Änderung der IP bemerkt hat:
Sa 20. Jun 05:30:01 CEST 2026
Server: 192.168.102.1
Address: 192.168.102.1#53
Non-authoritative answer:
Name: nextcloud.meine.domain.de
Address: 2001:9e8:6d38:8d02::1
Server: 159.69.110.93
Address: 159.69.110.93#53
Name: nextcloud.meine.domain.de
Address: 2001:9e8:6d38:8d02::1
Server: 1.1.1.1
Address: 1.1.1.1#53
Non-authoritative answer:
Name: nextcloud.meine.domain.de
Address: 2001:9e8:6d38:8d02::1
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
Name: nextcloud.meine.domain.de
Address: 2001:9e8:6d38:8d02::1
Server: 9.9.9.9
Address: 9.9.9.9#53
Non-authoritative answer:
Name: nextcloud.meine.domain.de
Address: 2001:9e8:6d38:8d02::1
Sa 20. Jun 05:33:01 CEST 2026
Server: 192.168.102.1
Address: 192.168.102.1#53
Non-authoritative answer:
Name: nextcloud.meine.domain.de
Address: 2001:aaa:bbbb:2002::1
Server: 159.69.110.93
Address: 159.69.110.93#53
Name: nextcloud.meine.domain.de
Address: 2001:aaa:bbbb:2002::1
Server: 1.1.1.1
Address: 1.1.1.1#53
Non-authoritative answer:
Name: nextcloud.meine.domain.de
Address: 2001:aaa:bbbb:2002::1
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
Name: nextcloud.meine.domain.de
Address: 2001:aaa:bbbb:2002::1
Server: 9.9.9.9
Address: 9.9.9.9#53
Non-authoritative answer:
Name: nextcloud.meine.domain.de
Address: 2001:aaa:bbbb:2002::1
Folglich wussten auch andere DNS nichts von der Änderung.
Zwangstrennung war um 04:58 Uhr. Dennis DNS (159.69.110.93) wusste das erst um 05:33 Uhr.
@Mic2025 Ich hatte gestern auch einen außerplanmäßigen „Limit Reset“ um 21:14 Uhr. Normalerweise erfolgt er aber immer kurz nach Mitternacht.
Den Limit-Reset um 21:14:53 Uhr sehe ich in meinem Logs auch. Woher kam der? Der nächste Reset war dann 00:00:16 Uhr.
Heute Nacht habe ich die DSL-Trennung eine Stunde früher machen lassen und es hat alles funktioniert. Die neuen IP-Adressen waren laut meines DNS-Check-Skripts spätestens nach fünf Minuten online. (Das Skript lief alle fünf Minuten.)
FritzBox 02:24:06 Internetverbindung getrennt
FritzBox 02:24:12 Internetverbindung erfolgreich wiederhergestellt
DNS-Check 02:15:00 alte IPv6-Adresse dokumentiert
DnyDNS-Update 02:15:02 {"info":"good","status":"success","ip":{"ipv4":"***********","ipv6":"******************"}} (HTTP 200)
DNS-Check 02:20:00 geänderte IPv6-Adresse dokumentiert
Im Counter auf der IPV64-Webseite sehe ich nun 6/64, was plausibel ist, da mein Skript für alle drei Domains ein kombiniertes IPv4/IPv6-Update durchgeführt hat.
Evtl. hatte da Dennis seine Bastelstunde
Hallo zusammen,
für heute Nacht habe in meinem Update-Skript alles wieder „scharfgeschaltet“, d.h. zu den normalen Updates auch Präfix-Updates und Prüfung auch gegen nslookup. Hat alles soweit funktioniert und es kam auch zu keinen Verzögerungen. Mit der früheren DSL-Zwangstrennung scheint es besser zu funktionieren (oder das Problem von letzter Woche besteht so nicht mehr).
Dafür habe ich bei einem meiner Domains ein neues Phänomen entdeckt: Fünf Minuten nach der DSL-Zwangstrennung meldet nslookup das neue Präfix. Aber 05:35 Uhr meldet nslookup auf einmal wieder das alte Präfix (von vor der DSL-Zwangstrennung), was in meinem Update-Skript dafür ein Update triggert. Nach dem Update meldet dann nslookup wieder das korrekte (neue) Präfix. Da es diese Nacht keinen Wechsel in der IPv4 gab, kann ich nicht sagen, ob man dieses Phänomen da auch gesehen hätte.
[2026-06-21 02:15:01] meine-domain1.ipv64.de IPv6: *** alt ***
… DSL-Zwangstrennung …
[2026-06-21 02:20:01] meine-domain1.ipv64.de IPv6: *** neu ***
[2026-06-21 05:35:01] meine-domain1.ipv64.de IPv6: *** alt ***
[2026-06-21 05:40:01] meine-domain1.ipv64.de IPv6: *** neu ***
Spannend…
Grüße
Mic.
Doch, es besteht noch. Ich hab die Zeit für die Zwangstrennung nicht geändert. Weiterhin dauert es mehr als 30 Minuten, bis ns1.ipv64.net davon erfährt.
05:33 ist wiederum bei mir dann genau die Zeit gewesen, zu der ns1.ipv64.net erstmals die neue IP-Adresse nach Zwangstrennung kannte.
Evtl. macht Dennis genau dann Backups oder ähnliches.
PS: an meiner pfsense, kann das nun nicht liegen. Hatte gestern eigens den Cronjob, der Änderungen der DynDNS-IP prüft, von einem 30-Minuten auf ein 10-Minuten Intervall geändert. Wenn also die sense um 5:00 Uhr die Änderung verpennt hätte, dann hätte das heute Nacht aber um 5:10 und 5:20 Uhr auffallen müssen.
Aber die Logs der sense sind eindeutig. Das Update fand seitens der sense um 5;00 Uhr statt. Um 5:10, 5:20, 5:30 Uhr usw. Uhr hingegen steht im Log das nix zu tun ist, weil keine Änderung.
Wie prüfst du, ob ns1.ipv64.net deine Änderung „erfahren“ hat?
Nun:
nslookup ns1.ipv64.net
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: ns1.ipv64.net
Address: 159.69.110.93
Name: ns1.ipv64.net
Address: 2a01:4f8:1c1e:a6a8::1
ns1.ipv64.net = 159.69.110.93 und genau diesen 159.69.110.93 frage ich zwischen 5:00 und 5:57 alle drei Minuten ab. Siehe auch meinen Beitrag von gestern dazu.
Sicherlich wie immer, indem man bei nslookup auch den zu befragenden Nameserver mitgibt, also
nslookup deinedomain.ipv64.net ns1.ipv64.netDen „zuständigen“ Nameserver bekommst du mit
nslookup -q=ns deinedomain.ipv64.netheraus.
Edit: War wieder mal etwas zu langsam
Macht nix. Denn bei mir fehlte ja noch, wie man überhaupt heraus findet das ns1.ipv64.net der zuständige Nameserver ist.
Hallo,
ich hatte heute die Zeit der DSL-Trennung wieder auf 3:00 … 4:00 Uhr gestellt und das „alte“ Problem war wieder da. nslookup zeigte die neue IPv6-Adresse erst um 6:50 Uhr. Es scheint also doch etwas mit der Uhrzeit zutun haben, wann das Update bei IPV64.net getriggert wird.
Nachtrag (8:21 Uhr): Und nun läuft auch mein Updater-Skript wieder Amok. Es findet per nslookup bei jedem Lauf Abweichungen der IPv6-Adresse und triggert ein neues Update. Mein IPV64.net Update Counter steht nun schon bei 38/64.
Grüße
Mic.
Zu deinem Nachtrag:
Hast du mal auf die Antwort auf dein Update geachtet?
{„info“:„good“,„status“:„success“,„ip“:{„…“}}
oder
{„info“:„nochg“,„status“:„success“,„ip“:{„…“}}
?
Vielleicht meint ja die API, die IP wäre schon korrekt, nur nslookup liefert was anderes.
Ein „nochg“-Update lässt übrigens den Update-Counter hochlaufen, im Log steht aber nichts.
Guter Hinweis. Trotz, dass nslookup noch die falsche IPv6 rückliefert, bringt ein (Full-)Update per Link auf IPV64.net:
{"info":"nochg","status":"success","ip":{"..."}}
Irgendwas muss aber schieflaufen, wenn die IP-Änderung während der Stoßzeit (3:00 … 4:00 Uhr) stattfindet, was auch mehrere Stunden danach noch nicht „aufgeräumt“ ist.
Das es bei "nochg" keinen Eintrag im Log gibt aber den Counter hochlaufen lässt, ist m.M.n. eine Schwachstelle, die behoben werden sollte. Das würde erklären, wieso der Log und der Stand des Update-Counters bei mir meistens nicht zusammenpassen.
Jetzt wär noch gut zu wissen, welche IPs das Web-Interface in dieser Zeit anzeigt, schon die richtige aber eine andere als nslookup?
Mein Vermutung ist, dass ein Update, manuell oder über die API, zunächst mal nur in eine Datenbank und dann erst über eine andere API an den Nameserver geht. Geht im 2. Schritt etwas schief, stimmen Datenbank und DNS nicht überein. Beim nächsten Update schaut aber die API nur in die Datenbank und stellt fest, dass sich nichts ändern würde.
Ich habe noch eine andere Domain bei Netcup, da ist es ähnlich. Das Web-Interface zeigt die Datenbank an, zeigt aber auch, dass das DNS-Update noch nicht abgeschlossen ist. Das dauert dann nochmal bis zu 10 Minuten. Obendrauf kommt dann nochmal die TTL, bis auch nslookup das überall richtig auflöst.
Nicht bei ipv64. Jedenfalls nicht außerhalb der nächtlichen Update-Orgien nach Zwangstrennungen.
Musste heute morgen gegen 07:30 Uhr meine pfsense neu starten. Das bedeutet immer auch neue IP-Adressen. Schon 30 Sekunden nach der Neuverbindung war mein Nextcloud-Server wieder von extern über den FQDN erreichbar.
M.E. dauert es nur so lange, wenn eben nachts viele Updates nach Zwangstrennung ausgeführt wurden.