Hallo zusammen, ich habe immer wieder bei manchen meiner Subdomains das Problem, dass im ipv64.net Portal zwar die richtig IP drin steht und aktualisiert wird, aber dann noch immer die alte Adresse im DNS aufgelöst wird. Auch nach mehreren Stunden.
Konkret habe ich die checkmk-cssit.ipv64.net mit diversen Subdomains. Momentan hat die 10126.checkmk-cssit.ipv64.net das Problem, das im Portal als AAAA die 2003:e6:7711:8400:5054:ff:fed6:a404 hinterlegt ist, aber per DNS und MXtoolbox die 2003:e6:7733:a00:5054:ff:fed6:a404 dazu aufgelöst wird, welche die IP zuvor war. Update war vor 4 Stunden. Bisher hatte ich das dann immer gelöst, indem ich die Subdomain gelöscht, neu angelegt und den Update CURL angepasst hatte. Ich sehe da auch kein Muster drin, das betrifft immer mal wieder eine andere Subdomain und hat sich bisher noch nie von selbst gelöst immer nur durch löschen und neu anlegen.
alles klar, ich habe die 2 problematischen Einträge nochmal bearbeitet und dann updaten lassen. Ich melde mich hier erneut wenn das Problem wieder wo auftritt.
Hallo, habe seit heute morgen wieder das Problem, wieder bei einem anderen Eintrag: 10278.checkmk-cssit.ipv64.net steht im Portal auf 2003:e6:770c:8a00:5054:ff:fed3:45b2 (was auch die richtige Adresse des Systems ist) aber wird öffentlich mit der (vermutlich alten) aufgelöst: 2003:e6:772d:d700:5054:ff:fed3:45b2
Ich denke, dass ich dasselbe Problem habe. Habe jetzt auch schon ein paar mal festgestellt, dass ich über die DDNS von IPv64 nicht per Wireguard auf mein Netzwerk kam. Über den Dienst von myfritz ging es aber sehr wohl. Meine IPv6 ist ebenfalls korrekt in IPv64 eingetragen.
Bislang hat sich die Angelegenheit bei mir allerdings von selbst erledigt. Ob die IPv6 korrekt aufgelöst wurde, habe ich bis dahin nicht geprüft, auf den Gedanken bin ich noch nicht gekommen. Werde ich beim nächsten Mal machen.
Hi, am besten mal mit der Network Tools: DNS,IP,Email testen. Deinen IPV64 DNS Eintrag und deine myfritz Adresse vergleichen bzw. wenn du die V6 der Fritzbox extern kennst kannst du es ja ablesen.
Gerade jetzt habe ich wieder das Phänomen, dass ich über IPv64 nicht auf mein Netzwerk zu Hause komme. Über den myfritz-Dienst aber sehr wohl. Wie ich es sehe, wird die IPv6 aber korrekt aufgelöst.
Aktuell bin ich ratlos, wie es dazu kommen kann und wie ich es lösen soll. In der Vergangenheit war es dann nach einiger Zeit wieder in Ordnung.
Ich vermute das Problem eher im Proxy des CDN. Kann es sein, dass sich die IPv4 geändert hat und nicht korrekt auf meine private IPv6 aufgelöst wird? Oder die IPv4 ist korrekt, aber vllt. hängt im CDN irgendwas?! Wenn ich einen Healthcheck mache, klappt dieser mit IPv6 korrekt, wenn ich aber „Prefer IPv4“ aktiviere, klappt er nicht.
Jetzt läuft es bei mir wieder.
Ich lasse den Healthcheck über IPv4 mal weiter laufen. Dann werde ich ja zukünftig informiert, wenn es wieder hakt und habe einen ganz guten Überblick, wie lange das Problem anhält.
//edit
Der Healthcheck über IPv4 schlägt weiterhin fehl. Da hatte ich wohl einen Gedankenfehler, da die IPv4 ja nicht exklusiv meine ist, sondern nur der Port zu mir weitergeleitet wird. Ist es möglich, einen Healthcheck über IPv4 an einen bestimmten Port der DynDNS zu schick, also sowas wie subdomain.ipv64.net:55000 ?
Oder gibt es eine andere Möglichkeit, mit IPv4 einen Healthcheck einer DynDNS zu machen?
ich kann das auch bestätigen. Die Hauptdomain ist nur über IPv6 erreichbar und ich wollte über das CDN noch eine Erreichbarkeit mit IPv4 erreichen. Das Problem ist das die Domain nicht bekannt gemacht wird. Es wird nicht die CDN IP (IPv4) bekannt gemacht und bei IPv6 haben viele DNS Server entweder die Hauptipadresse oder die CDN Adresse. Subdomains werden gar nicht bekannt gemacht.
Auch das Ausschalten und Einschalten vom CDN brachte keine Besserung.
Ich habe eine interessante Entdeckung eben gemacht. Wenn ich die problematischen Einträge in der Weboberfläche einmal editiere und dann exakt so wieder speichere, wird auch im DNS das ganze korrekt eingetragen. Ist das vielleicht ein Problem, dass meine Cronjobs immer zur gleichen Uhrzeit laufen von allen Subdomains?
Konnte damit heute alle 4 kaputten DNS Einträge fixen ohne nochmal neu die CURLS vom Contab durchlaufen zu lassen. DNS war dann auch schnell geupdatet nach der Aktion.
Konnte heute wieder die gleiche Problematik genau so lösen. Wie als wenn der DNS Server dahinter nicht alle Änderungen mitbekommt die man an die API schickt, diese und das Frontend jedoch schon. @Dennis_Admin soll ich mal die Conjob Zeiten verteilen oder wie siehst du das?
Also eigentlich sollten die Daten schon da ankommen wo sie hin sollen und zwar sofort. Ich frage mich nur warum das nur bei 2 Leuten passiert und nicht bei X hunderten.
Das macht mich noch etwas stutzig.
Hey also bei mir ist das gleiche heute wieder gewesen mit ipv4 Adresse, geht um 2 Domains, eine hat die aktuelle Adresse bekommen die andere wurde nicht Aktualisiert obwohl die Daten gesendet wurden. Keine Ahnung was das sein soll.
Also die IP wird wohl anscheinend richtig zu IPV64 gesendet aber am ende beim DNS Server steht bei der einen Domain noch die IPv4 Adresse vom Vortag drin. Das heißt für mich das dieses Problem bei der Übermittlung von IPv64 liegt zum DNS Server…
