DynDNS meldet success ober updated nicht

IPv64.net - Services DynDNS2
1

ich habe das Problem das mein Dyndns update nicht funktioniert.
Ich verwende: curl -sSL „https://ipv64.net/nic/update?key=MEINKEY&domain=MEINESUBDOMAIN.ipv64.net“ und bekomme auch eine Antwort: {„status“:„success“}
Allerdings wird die IP nicht geupdatet und der „DynDNS Update Limit / 24h“ counter zählt auch nicht hoch. Wenn ich über die Webseite manuell ein update mache geht es.
Ich update nur die IPv4 Adresse. (Ignore IPv6)

Hat jemand eine Idee woran es liegen könnte?

Edit: Bis heute früh, der Zwangstrennung, funktionierte es.

2

Hallo Treerunner,

vor wenigen tagen hatte ich ein aehnliches Problem, ging wie bei Dir laaaange gut, irgendwann nicht mehr.

Was mit z.Z. nicht klar ist, wenn Du ein manuelles update ueber die Webseite machst, ob dann auch in der Welt der Name zur IP richtig aufgeloest wird (war bei mir nicht der Fall) oder nur eine Veraenderung in der WebGUI zu sehen ist (und trotzdem keine Namensaufloesung statt findet?).

Da bei meinem Problem auf meiner Seite, weder FBox, noch am Anschluss, oder an den Skripten was veraendert wurde, denke ich (spekulativ), dass bie ipv64 irgendwas klemmt(e).

Ich konnte es nur loesen, in dem ich den dysfunktionalen Namen auf einer neuen Anmeldung (neue Email etc) bei ipv64 neu konfiguriert habe, hat dann sofort funktioniert.

Evtl., wenn Du nicht zu viele andere DNS Erweiterungen (CAA/TXT etc) auf dem alten Namen hast, kannst Du vllt. durch einfaches Loeschen des dysfunktionalen Namen (ohne neues Anmeldungkonto) und einer Neuanlage des Namens das Problem loesen(?).

Wenn auch das nicht hilft, dann neues Konto und den alten Namen dort neukonfigurieren, vllt. gar kannst Du die API Keys mitnehmen(?) und musst dann an den Skripten nichts anpassen.

Ist keine grosse tech. Hilfe nur ein Weg, doch bei mir war die DynDNS Aufloesung bei ipv64 von einem auf den anderen Tag wech (die anden DynDNS funkten weiterhin), bei einer anderen Maschine (anderes Netzwerk) funkte es weiterhin einwandfrei.
Technisch (ausser reboot tut gut, galvanische Entkopplung des Routers/FBox + paar min Warten) wirst Du auf deiner Seite mit keiner Veraenderung etwas bewirken, denn ich gehe davon aus, dass alles beim alten Status geblieben ist; welche technische Schraube will man da (rueck)drehen? :frowning: :slight_smile:

Viel Erfolg.
ELindeman

3

Ich hatte auch das Gefühl das die IP die ich manuell aktualisiert hatte nicht richtig funktionierte. Ich bekam Zertifikatsfehler (war von Dennis Schröder) wenn ich meine Domain aufrief. Ich habe dann erstmal auf einen anderen DynDNS Dienst umgestellt, es sollte ja schnell wieder laufen. Solange ich per script nicht updaten kann bleibe ich erstmal bei dem anderen. Ich werde mal versuchen die Domain neu anzulegen und schauen ob es dann wieder funktioniert.

4

Ich habe eine neue Dyndns Domain angelegt.
Habe diese mit dem curl -sSL „https://ipv64.net/nic/update?key=MEINKEYNEU&domain=MEINESUBDOMAINNEU.ipv64.net“ geupdated.

Dabei wurde nur die ipv6 Adresse eingetragen. Es wurde keine IPv4 eingetragen. (Einstellung stand auf „IPv4 & IPv6 accepted“) abdaterückmeldung war „good“
Danach habe ich auf „IPv6 ignore“ gestellt (ich brauche nur die IPv4). Jetzt besteht das gleiche Problem mit der neuen Dyndns Adresse wie mit der alten. Es wird beim Update {„status“:„success“} zurückgemeldet und keine IPv4 wird upgedated.

5

@treerunner da du ein curl -sSL-Script verwendest und nicht verrätst auf welchem Device du das laufen lässt, ist Support nur schwerlich möglich.

Mutmaßlich nutzt du dieses curl -sSL-Script aber nicht direkt auf dem Router/der Firewall, die die öffentlich IPv4-Adresse vom ISP erhält. Das könnte Ursache des Problems sein, dass bei dir zwar eine IPv6-Adresse, aber keine IPv4-Adresse aktualisiert wird, denn ein Device im LAN deines Routers/Firewall hat ja per Definition nur eine private IPv4-Adresse.

6

das ganze lauft auf einem Linux server hinter dem router. Bisher wurde dadurch auch die öffentliche IPv4 Adresse richtig upgedatet. (Steht ja auch so in der Anleitung, das man das o von einem Linux server aus machen soll)
Es wurde immer die Aufrufende öffentliche IPv4 eingetragen (nicht die Private von meinem Linux Server).
Wenn das jetzt geändert wurde sollte das aber irgendwo stehen.

7

Ich glaub nicht dass das geändert wurde. Fakt ist aber: der Linux-Server im LAN kennt seine öffentliche IPv4-Adresse nicht. Folglich kann der die nicht direkt updaten. Das geht nur mit der IPv6-Adresse, Die öffentliche IPv4-Adresse wird also „geschätzt/erraten“. Das birgt Fehlerquellen.

Anders ist es wenn z.B. eine FritzBox die IPv4-Adresse updatet. Die bekommt diese ja vom ISP zugewiesen, kennt sie daher und kann diese direkt dem DynDNS-Dienst mitteilen. Das wäre somit der zuverlässigere und daher zu bevorzugende Weg.

8

Es wird aber keine ipv4 adresse übernommen auch nicht meine private. und es wird mit success geantwortet. Da passt was nicht.

9

Die frage ist nur wo etwas nicht passt. Bei dir oder bei ipv64. Ich tippe ja auf bei dir. Bei mir gibt es diese Probleme nämlich nicht und wenn es bei ipv64 nict passen würde, müssten ja viel mehr betroffen sein und nicht nur zwei oder drei.

10

Wenn ich im curl aufruf die öffentliche ip als parameter mit übergebe scheint es upzudaten.
Die Frage ist nur warum es plötzlich nicht mehr funktionierte ohne das ich auf meiner Seite etwas geändert habe. Und warum ein success zurück gemeldet wird obwohl das Update ja schief geht.

11

Hallo The_eagle,

Du unterstuetz hier im Forum viel, dein Equipment ist mehr als eine FBox und ipv6 ist fuer Dich auch kein grosses Problem. Respekt, ehrlich gemeint.

Ich finde die Aussage oben trotzdem leicht :slight_smile: problematisch, denn wie ansonst koennen Windows-Maschinen mit einer EXE von anderen DynDNS-Provider ihre IP4-Adresse erfahren (gar updaten) und/oder ein Browserplugin (z.B. fuer FF) diese (zumindest bei mir die vielen Jahre) korrekt erfahren?
Ich nutze dieses Plugin fuer Tor, was mein Browser meldet (wenn ueber TorProxy im LAN), ebenso was eine Webseite fuer Ip-Detection meldet.

Nicht nur das, sondern auch die vielen Skripte, Codeschnipsel/Einzeiler, die man findet, oder sich selbst bastelt, die aus dem hinteren Ring die akt. IP4 abfragen, per Umgebungsvariable im Skript weiter verarbeiten wuerden so nicht funktionieren. Sie funktionieren sehr zuverlaessig.

@treerunner
Ich gehe davon aus, wenn Du von der linux-Maschine die oeffentlich IP abfragst, dass Du mit den nachfolgen Zeilen klar kommst, cave wegen backticks.
So kannst Du die FBox vs. aus hinter der FBox abgefragte IP4 abgleichen.

CURLBIN=which curl
echo „dyndns: "$CURLBIN" -s http://checkip.dyndns.org/ | grep -o "[[:digit:].]\+"“
echo „monip: w3m -dump http://www.monip.org/ | awk -F': ' '/IP/ { print $2 }'“
echo „icanhazip: "$CURLBIN" -s -4 http://icanhazip.com/“
echo „cloudflareip4: "$CURLBIN" -4 -s https://cloudflare.com/cdn-cgi/trace | grep "ip="“

Zur Not ersetzt Du bitte die CURLBIN-Variable mit /usr/bin/curl oder wo auch curl bei Dir ist.

Hast Du die neue Domain unter dem alten ipv64-Benutzer angelegt?
Oder hast Du Dich neu angemeldet und dort die neue (evtl. gar die alte) konfiguriert?

Ich bin auch leicht skeptisch, weil z.Z. unsere IP fix scheint, trotz der 24h Trennung, warum auch immer. Mal sehen, ob - wenn eine neue IP am Anschluss liegt - dann bei uns ipv64 mit geht, oder wieder kein Update auf ip4 kriege.
Da ich als konservativer alter Sack (always never touch a running system) meine Skripte nicht taeglich aendere, denke ich, dass (weil auch die anderen DynDNS-Provider noch ok funktionieren) irgendwas auf ipv64 (auf meinem alten Benutzer) klemmte.

Was ipv64 so sexy macht, dass man den CAA Eintrag fuer DNS-Challange fuer LECerts modifizieren kann, dann muss man keinen 80er Port aufmachen (CAA… 0 issue letsencrypt.org).

Schoene Feiertage.
ELindemann

12

Naja, das du nichts geändert hast ist leicht gesagt, aber nicht unbedingt glaubwürdig. Damit meine ich jedoch nicht dass du lügst !!!

Ich meine, dass das curl -sSL-Script ja auf einem System mit einem Betriebssystem läuft. Welches kann ich grade nirgends in deinem Supportanfragen hier finden. Betriebssysteme wie Ubuntu/Debian/Whatever bekommen aber mehr oder weniger häufig Upgrades. Schon das kann eine relevante Veränderung bedeuten. Router wie eine Fritte bekommen diese deutlich seltener. Aber auch im Zusammenhang mit Updates des Fritten OS gab es schon Probleme.

Klar, du kannst die öffentliche IP-v4-Adresse ja lesen. Der Server des es updaten soll nicht. Wie ich bereits an andere Stelle ausführte; die öffentliche IP-v4-Adresse muss in deiner Konfiguration mehr oder weniger zuverlässig „erraten“ werden.

Es ist daher suboptimal die IPv4-Adresse nicht vom Router selbst, der diese vom ISP zugewiesen bekommt und daher kennt, updaten zu lassen. Bei mir erledigt das Update einer IPv4-Adresse darum IMMER der Router oder die Firewall die diese vom ISP zugewiesen bekommt.

13

Ich hole mir die öffentliche IPv4 über:
ipv4=$(curl -4 -s ifconfig.co)

Der Server sieht auch nur meine öffentliche IPv4 als aufrufender Client. Das sollte ipv64.net auch können. (konnte es ja auch bisher)
Ich habe an meinem System auch kein update gefahren. An meinem Script wurde auch nix verändert.
Es scheint ja jetzt zu gehen. Ich muss halt meine IPv4 vorher selber auslesen und mit geben, da ip64 das jetzt anscheint verlernt hat.

Und der Server der die IP Updaten soll (ip64.net) sieht sehr wohl die IP Adresse des aufrufenden Clienten.

@ELindemann:
ja ich habe eine neue Domain unter dem alten Benutzer angelegt.

14

Versuche mal bitte einen NEUEN Benutzer anzulegen, dort eine andere Domain zu konfigurieren, dann siehst Du sogleich, ob der neue Benutzer kann (und auch deine Skripte fuer ipv64 [angepasst] OK sind).

Wenn so, schiebe (loeschen/neu anlegen) deine alte Domain auf den neuen Benutzer, spaeter den alten Benutze -wenn nicht massiv andere Sachen da gebunden sind - loeschen.

@The_eagle
Du hast Recht, wenn Updates hintenrum ohne, dass man es mitbekommt eingespielt werden, dann ist dieses Szenario absolut moeglich. Dann aber springen die anderen Skripte auch raus, updaten nix und /oder man hat dann mehrere Baustellen aus seiner eigenen Seite.
So aber, wenn alle anderen funktional sind, updaten wuerde das immer noch auf ipv64 zeigen, ohne jegliche Schuldzuweisung, really not.

Geht ja nur darum wieder stabile Zustaende zu erhalten, was DS dort aufgebaut hat ist gigantisch, sowohl fuer 0 EUR, als auch fuer wenig Geld. Und wenn da der Wurm drin ist, koennten solche Meldungen vllt. bei der Fehleranalyse, besser bei der Instandsetzung helfen.

Da mein Problem mit einem neuen Benutzer vaporisiert ist, und auch alles andere funktional ist, kann ich hoffen, dass den anderen - erstmal - auch so geholfen wird. :-).
Wenn so, dann haette man vllt. doch ein Signifikanz(?).

Gruss
ELindemann