leider hat der neue Link auch nicht funktioniert. Es wurde über Nacht kein Update durch die FritzBox getriggert. Ich bin mir aber mittlerweile unsicher, ob es echt am Link liegt oder ob es nicht an der FritzBox selbst liegt, die einfach nichts macht.
Die HealthChecks sehe ich auf der Nutzer-Webseite von IPV64.net. Sie machen aber keine IP-Updates… oder?
Wenn das Docker-Tool nicht von IPV64.net veröffentlicht wurde, von wem ist es denn dann? Wurde es evtl. blockiert, dass es nicht mehr funktioniert?
Danke und Grüße Mic.
PS.: Beim Versuch diesen Post zu verfassen, brachte mir die Webseite immer wieder Fehlermeldungen (angeblich enthält er Werbung). Daher poste ich nun nur eine Kurzfassung.
Probiere deine Update-Prefix-URL doch einfach mal im Browser deines PCs. Ich habe das heute morgen mal gemacht. Zuerst habe ich mir eine URL zusammengebastelt in der Form https://ipv64.net/nic/update?key=...&domain=meinedomain.ipv64.net&ip6lanprefix=2001:16b8:bb33:xxxx::/64&onlyprefix
mit dem Prefix, den mir meine Fritte unter Verbindungsdetails anzeigte, und achte auf die Rückmeldung.
Auffällig war, dass ein Prefix-Update im Vergleich zu einem Domain-Update doch relativ lange dauert (könnte zu einem Timeout führen). Ohne den Zusatz „&onlyprefix“ wird auch der AAAA-Record für die Domain selbst aktualisiert, warum auch immer, was natürlich kontraproduktiv ist, wenn der PC mit seiner temporären IPv6 rausgeht. Keine Ahnung, warum Dennis das so macht. Das hat aber so ganz gut geklappt.
Mit einem kombinierten Update-URL für IPv4, IPv6 und Prefix in einer URL kämpfe ich noch. Das ging früher mal prima, aber nach all den Maßnahmen nach der DDOS-Attacke mit Mai nicht mehr zuverlässig.
Also ich verwende seit mehr als einem Jahr an einer an einem entfernten Standort befindlichen 7490 die kombinierte Update-URL für IPv4, IPv6 und Prefix in einer URL. Das klappt (bis auf wenige Tage während der DDOS-Attacken) jetzt exakt so zuverlässig wie vor der DDOS-Attacke.
Einen Zusammenhang zwischen vor und nach der DDOS-Attacke kann es somit eher nicht geben. Sehr viel wahrscheinlicher schon mit unterschiedlichen Versionen des FrittenOS. Die 7490 verharrt bei 7.60 während andere Modelle bereits bei 8.03 angekommen sind.
Auch auf meiner pfsense nutze ich https://ipv6.ipv64.net/nic/update?key=1234567890abcdefgh&ipv6prefix=auto&onlyprefix als Update-URL nur für den IPv6-Prefix eines meiner 4 LAN-Segmente. Klappt vor und nach der DDOS-Attacke gleichermaßen gut.
Nachtrag:
Guckst du hier: Healthcheck Ping // Healthcheck API. Dachte du brauchst was zum auswerten ob die URL noch auf die richtige IP verweist. Ist die IP-Adesse nicht die richtige scheitert der Healthcheck. Dann Updaten.
@The_eagle, dann schau dir mal bitte das Verhalten der einzelnen Varianten der Update-URL direkt im Browser an. Da gibt es eklatante Unterschiede von ratzfatz bis hin zu Timeouts insbesondere bei Prefix-Updates. Der Zusammenhang mit den Maßnahmen zur Abwehr der DDOS-Attacken ist offensichtlich. Ich verwende weiterhin getrennt Update-URLs fürs IPv4, IPv6 und eine fürs Prefix-Update, damit es wenigstens so halbwegs funktioniert. Der Update-Counter pro Tag ist mittlerweile bei 1 angekommen, nach bis zu 30 Versuchen/Tag anfangs.
Liebe Admins hier. Was soll das, dass meine Post immer mit dem Hinweis: „Ein Fehler ist aufgetreten: Entschuldige, leider kannst du keinen Link zu diesem Host posten.“ geblockt werden. Das nervt,
die meisten Links habe ich auch im Browser ausprobiert, um zu sehen, ob es eine Reaktion gibt. Die gibt es meistens auch. Auch der „vierte Link“ erzeugt eine Reaktion, wenn ich ihn im Browser anwende. Wobei die Rückmeldung nichts von „update success“ sagt. In der FritzBox scheint er nichts zu bewirken… oder nur manchmal. Ich sehe da noch kein Muster drin, wann es in der FritzBox funktioniert und wann nicht.
Irgendwie ist das alles nicht so recht zuverlässig. Meinem Update-Skript vertraue ich da mehr, da es bisher problemlos alle Updates gemacht hat, die nötig waren. Wenn das Docker-Tool von IPV64.net funktionieren würde, wäre es natürlich noch besser.
Ich habe auf meiner FritzBox FritzOS 8.02 drauf. Ich habe in letzter Zeit aber auch Tests für AVM mit neuen (teilweise inoffiziellen) Labor-Versionen für FritzOS 8.10 gemacht.
Momentan haben die zwei, drei Nutzer meiner NextCloud auch Performance-Probleme und Probleme mit Verbindungsabbrüchen. Das hat wohl aber nichts mit IPV64.net zutun?
@Benares Nein, der Zusammenhang mit den Maßnahmen zur Abwehr der DDOS-Attacken existiert nicht. Jedenfalls nicht bei einer 7490 mit OS 7.60.
Ich nutze zu Überwachung der Updates auch die IPV64-Android-APP. Jeden Abend wenn ich bereits im Bett liege, also meist so 22:30 bis 23:00 Uhr, Überprüfe ich in der App unter Account → Account Status → DynDNS Update Limit / 24h die Anzahl der im Laufe des Tages durchgeführten Updates.
Sowohl bei der überwachten Fritte 7490 wie auch bei meiner pfsense steht der auch so spät am Abend noch zumeist bei 2 (je ein Update am Morgen nach Zwangstrennung für IPv4 und IPv6). Das Prefix-Update wird von ipv64 offenbar nicht als Update gewertet. Nur in sehr seltenen Fällen und zumeist auch nur, wenn ich manuell etngegriffen habe, steht der Zähler mal bei 4, 6 oder 8. Zweistellig war der noch nie (außer direkt während der DDOS-Attacken).
Der von dir konstruierte Zusammenhang existiert also nur bei bestimmten Fritten mit bestimmten Versionen von deren Betriebssystem. Ältere Versionen (vor OS8) des Fritten-OS und andere Software, wie meine pfsense haben Null Komma Null Probleme.
Vielleicht sollten Fritten OS8 Nutzende mal den AVM-Support bemühen und nachfragen, was die so alles in ihrem ja nicht quelloffenen OS geändert haben und die auffordern ipv64 vernünftig zu supporten.
Wenn es nicht geht, warum führst du dann auf dem Docker-Host (je nach Linux-Host OS) entweder APT Debian DDNS IPv64 Package oder die Update URL per CURL aus? Ich meine deinen Docker Container werden doch wohl hoffentlich auf einem Host mit einem richtigen OS, also Linux, laufen und nicht auf einem dieser OS’s aus Redmond oder Cupertino.
@The_eagle, da ist nichts konstruiert. Ich habe meine 7690 seit Anfang des Jahres, zuvor hatte ich eine 7590. Die letzte Änderung an der 7690 war ein Update von 8.01 auf 8.02 am 31.01.25. Bis ~19.05.2025 lief es immer problemlos mit einer gemeinsamen Update-URL für IPv4, IPv6 und Prefix (bis auf die Zeit mit den DDOS-Attacken. Das war ungefähr die Zeit als Dennis begann sein System zu schärfen. Ich trennte daraufhin die URLs damit es wenigsten so halbwegs lief. Inzwischen geht auch wieder eine gemeinsame URL, aber lange nicht so zuverlässig wie die getrennten.
Mag sein, dass Fritz!OS 8 andere Timeout-Zeiten als die älteren Versionen. Deshalb habe ich eben nochmal mit curl auf meiner Diskstation probiert, um zu sehen, von welchen Antwortzeiten wir das sprechen.
root@DS1522:~# time curl "https://ipv64.net/nic/update?key=...&domain=meinedomain.ipv64.net&ip6lanprefix=2001:16b8:bb3b:xxx0::/64&onlyprefix"
{"info":"","ipv6prefix":"2001:16b8:bb3b:xxx0::\/64"}
real 0m20.672s
user 0m0.043s
sys 0m0.006s
root@DS1522:~# time curl "https://ipv64.net/nic/update?key=....&domain=meinedomain.ipv64.net&ip6lanprefix=2001:16b8:bb3b:xxx1::/64&onlyprefix"
{"info":"","ipv6prefix":"2001:16b8:bb3b:xxx1::\/64"}
real 0m8.738s
user 0m0.044s
sys 0m0.006s
root@DS1522:~# time curl "https://ipv64.net/nic/update?key=...&domain=meinedomain.ipv64.net&ip6lanprefix=2001:16b8:bb3b:xxx0::/64&onlyprefix"
{"info":"","ipv6prefix":"2001:16b8:bb3b:xxx0::\/64"}
real 0m11.579s
user 0m0.043s
sys 0m0.006s
Du siehst, wie lange die Prefix-Updates dauern und wie sehr die Zeiten schwanken. Ein einfacher IPv6-Update geht dagegen ratzfatz.
root@DS1522:~# time curl "https://ipv64.net/nic/update?key=....&domain=meinedomain.ipv64.net&ip6=2001:16b8:a035:449e:e208:55ff:fe0e:xxxx" {"info":"good","status":"success","ip":{"ipv6":"2001:16b8:a035:449e:e208:55ff:fe0e:xxxx"}}
real 0m0.121s
user 0m0.042s
sys 0m0.006s
root@DS1522:~# time curl "https://ipv64.net/nic/update?key=...&domain=meinedomain.ipv64.net&ip6=2001:16b8:a035:449e:e208:55ff:fe0e:xxxx"
{"info":"nochg","status":"success","ip":{"ipv6":"2001:16b8:a035:449e:e208:55ff:fe0e:xxxx"}}
real 0m0.126s
user 0m0.046s
sys 0m0.004s
Ja und? Ich verstehe nicht was die Dauer eines Updates damit zu tun haben soll, dass deine Fritte bis zu 30 Updates/Tag macht. Vor allem sehe ich keinen Zusammenhang, wenn diese bis zu 30 Updates/Tag nicht schon gleich nach der Zwangstrennung erfolgen, sondern erst im Laufe des Tages.
Hat die Fritte erst einmal ein erfolgreiches Update gemacht, so gibt es doch für die Fritte gar keinen Grund im Laufe des Tages weitere Updates anzustoßen, es sei denn es gab eine weitere Zwangstrennung oder sonst eine Anlass zum Bezug einer neuen IPv6- und/oder IPv4-Adresse,
Bei einer stabilen Leitung und einer Fritte ohne Fehler (als Ursache für Verbindungsverlust) wird es aber nicht passieren, dass sich IP-Adressen ändern, es sein denn du sagt dem Ding es soll manuell eine Neuverbindung anstoßen.
Du verstehst mich einfach nicht. Es geht um Meldungen wie DynDNS-Fehler: Der DynDNS-Anbieter meldet Fehler 0
im Log, die eindeutig auf ein Timeout beim Update-Versuch hindeuten. Dadurch wird dieser halt wiederholt. Und 30 Versuche sind es auch schon lange nicht mehr, aber 2-3/Tag schon noch. Da hat Dennis wohl bereits nachgebessert.
Ich bin bei 1&1 mit DSL, da gibt es noch eine tägliche Zwangstrennung, der ich in der Nacht „zuvor komme“. Die IPv4 ändert sich meist nicht, aber der Prefix immer. Deshalb wäre 1 Update/Tag normal, aber nicht 2-3.
Ich dachte, gerade du müsstest das eigentlich verstehen, aber das ist wohl vergebene Liebesmüh. Und zu den extremen Laufzeiten/-Unterschieden beim Prefix-Update hast du auch noch nichts gesagt, ich meine das Timeout bei Fritz!OS läge bei ~3s und nicht bei 8-20s. Vermutlich hast du das bisher noch nicht mal selbst getestet.
Was soll ich da testen wenn es perfekt läuft. FB 7490, o2 DSL, jede Nacht zwischen 3 und 4 Uhr die Zwangstrennung, neue IPv4- und IPv6-Adresse. 2 (in Worten zwei) Updates bis 23 Uhr, (eines für IPv4, das andere für Ipv6). KEINE DynDNS-Fehler-Meldungen. Und wenn man keine hat kann man auch keine aufspüren, auch nicht durch noch so viele Tests.
Was mir aber sofort auffällt:
1&1 hat doch nur noch DS-Lite und kein Dual Stack wie o2. Liegt da das Problem?
Du irrst, 1&1 DSL ist weiterhin Dual-Stack. Was deine olle 7490 da so treibt, interessiert mich nicht. Es geht einzig und allein um das geänderte Update-Verhalten bei IPv64 selbst seit der DDOS-Attacke. Ich verstehe einfach nicht, dass dich das nicht interessiert, und was du noch noch in der Sache beitragen könntest. Threads dazu gibt es ja mittlerweile zur Genüge.
Es gibt einfach kein geändertes Update-Verhalten bei IPv64 selbst. Weder mit meiner pfsense noch mit der „ollen“ 7490. Offenbar gibt es das nur bei wenigen Leuten in Kombination mit irgendwelchen Fritten und deren obskuren OS ab Version 8. Und so ein fragwürdiges Gedöns werde ich mir nun bestimmt nicht für eine zudem noch vollkommen überteuerten Verkaufspreis beschaffen, um deine Probleme nachvollziehen zu können.
Sollte eines Tages die 7490 den Dienst quittieren, kommt da als Ersatz ganz bestimmt nix aus dem Hause AVM hin.
Bisher nur welche von NACH DDOS. Um zu erkennen ob es den von der behaupteten Zusammenhang tatsächlich gibt müsstest du schon auch noch Vergleichswerte von vor DDOS liefern.
Ich vermute aber:
Kannst du nicht weil hast du nicht.
Warum sehe ich da keinen Zusammenhang?
Weil es mir nicht einleuchtet, wie man mit Anti-DDOS Maßnahmen ganz gezielt nur die Antwortzeiten für Updates der IPv6-Präfixe erhöhen kann, nicht aber dann auch die für IPv4- und IPv6-Adressen. Wenn dann müsste doch alles drei gleichermaßen langsamer geworden sein durch die Maßnahmen und zu längeren Antwortzeiten für alle Updates führen,
Für Test habe ich
time curl -sSL "https://ipv64.net/nic/update?key=1234567890abcdefgh&ipv6prefix=auto&onlyprefix"
und zum Vergleich
time curl -sSL "https://ipv64.net/nic/update?key=1234567890abcdefgh"
genutzt. Ersteres aktualisiert nur den IPv6-Prefix, letzteres die IPv4 und IPv6-Adresse. Richtig ist auch, dass die Antwortzeiten beim NUR Prefix-Update deutlich länger sind als beim Update von IPv4- und IPv6-Adresse.
Aber m.E. muss das andere Gründe haben als DDOS-Abwehrmaßnahmen.
Durchgeführt habe ich diese Tests alternierend direkt im Terminal eines Debian-Servers und eine Ubuntu-Desktops in unterschiedlichen LAN-Segmenten meiner pfsense, so dass der zu updatende IPv6-Prefix auch anders war und jedes Mal ein Update gemacht wurde. Denn wegen IPv6-Prefix-Delegation hat jedes LAN-Segment der pfsense ja einen anderen, eigenen IPv6-Prefix.
