DYNDNS anbieter kostenlos

Zuletzt bearbeitet:
Und das geht nicht, schrieb ich ja auch schon Posting zuvor.

Würde nur für Abfrage via http gehen, keine Namensauflösung via DNS.
 
Zuletzt bearbeitet von einem Moderator:
Moins

Es sei denn, der 1und1 Webspace ist ein "Proxy" für einen echten DynDNS.
...und leitet die UpdateURLs entsprechend weiter.

Was natürlich nur bei denen funktionieren kann, die die Public IP (dann) nicht beachten.
 
Zuletzt bearbeitet:
Es sei denn, der 1und1 Webspace ist ein "Proxy" für einen echten DynDNS.
Anwendungsbeispiel? Jenseits von "mehrere Accounts aktualisieren" meine ich aber nur ... den Fall sehe ich schon, verstehe ihn aber nur eingeschränkt (weil ich persönlich es so niemals machen würde).

Warum dann nicht gleich den "richtigen" DynDNS-Service mit einem Update-Request aktualisieren? Selbst mit aktueller Firmware ist das auch problemlos noch für mehrere DynDNS-Accounts möglich (editiert man eben die ar7.cfg, dafür reicht der FBEditor und es braucht nicht einmal einen Telnet-Zugang), nimmt aber den (zusätzlichen) "single point of failure" am eigenen Webspace aus dem Spiel und bietet mit dem ddnsd von AVM auch bessere Möglichkeiten (die man nicht immer haben will, steht aber auf einem anderen Blatt) fehlgeschlagene Updates zu wiederholen und zwar selektiv für den einzelnen Account ... was bei so einem "Proxy" dann schon wieder eine "more sophisticated logic" erfordern würde (wenn so ein Webspace überhaupt die Pakete beeinhaltet, um aus einem PHP- oder Perl-Skript heraus die aktuellen DNS-Einstellungen abzufragen) und die meisten DynDNS-Anbieter haben eine Policy mit einer beschränkten Anzahl von Updates pro Zeiteinheit.

EDIT:
@eisbaerin:
Treiben es die Haseaten auch wie die Karnickel?
 
was bei so einem "Proxy" dann schon wieder eine "more sophisticated logic" erfordern würde
Und genau darin würde bei mir der Reiz liegen.
Zum Beispiel, im Falle einer Fernwartung auf "https://fritzbox.spdns.eu/jason_boxinfo.xml" testen*, ob Update nötig wäre.
...wenn nicht dann nicht.

Und wenn eine andere Serial zurückkommt weiss ich: Aha, eine andere (fremde) Fritz!Box auf meiner alten IP :mrgreen:


* <j:Serial>ABCDEF123456</j:Serial>
 
Zuletzt bearbeitet:
Zuletzt bearbeitet:
Und wenn eine andere Serial zurückkommz weiss ich: Aha, eine andere Fritz!Box auf meiner alten IP
Das sollte gar nicht erst passieren ... der externe Abruf der jason_boxinfo.xml (warum der überhaupt funktioniert, ist mir immer noch ein Rätsel, IMHO ein Security-Problem und die Angaben könnte man über TR-064 auch abfragen, dann hat der User wenigstens noch die Möglichkeit, es gesondert abzuschalten) erfordert schon noch den Benutzernamen und das Kennwort, oder? Damit solltest Du von einer fremden Box (mit den eigenen Credentials) an dieser Stelle nur eine Fehlermeldung erhalten und der Besitzer der fremden Box eine Warnung für einen unautorisierten Zugriffsversuch.

Wobei diese Zusätze ja auch mit DynDNS nicht mehr so sehr viel zu tun haben ... man könnte höchstens den AVM-DynDNS-Client als Trigger für solche Aktionen verwenden, aber auch das wäre m.E. mit einem zusätzlichen DynDNS-Service in der Box besser geregelt.

Es bleibt ja dabei, daß der DynDNS-Client von AVM für jeden Service einen Domain-Namen wissen will, diesen Namen abfragt und das Ergebnis mit der aktuellen IP-Adresse vergleicht (das regelmäßige Erneuern lassen wir bei der Betrachtung jetzt mal außen vor, um es nicht zu verkomplizieren) und nur wenn das nicht übereinstimmt, sendet die Box ein Update an den entsprechenden Service. Wenn man also für so einen "Proxy" einen einzelnen Domain-Namen verwendet, dann kommt kein Update, solange dieser Name auf die FRITZ!Box-Adresse auflöst oder es kommen immer wieder neue Updates, wenn die Auflösung nicht mit der aktuellen Adresse übereinstimmt.

So etwas wie einen "Heartbeat"-Service, der in regelmäßigen Abständen bereits von der FRITZ!Box selbst aus einen HTTP-Request startet, bei dessen Ausbleiben über mehrere Intervalle man dann die Schlußfolgerung "FRITZ!Box tot" ziehen könnte, gibt es bei der FRITZ!Box ja leider nicht. Man könnte zwar den (Firmware-)Update-Check auf eine eigene Adresse umleiten, das gibt aber andere Probleme, da die Antworten dieses Dienstes seitens AVM signiert werden und das kann ein eigener Dienst nur schwer nachahmen, selbst als Proxy nicht.

Noch viel schlimmer! Warst du noch nie auf der Reeperbahn oder in der Herbertstraße? ;)
Dat is Hamburg ... Hanse is ook annerwerts. :D
 
... der externe Abruf der jason_boxinfo.xml erfordert schon noch den Benutzernamen und das Kennwort, oder?
Bei meinen Test nicht. Bei HTTPS kommt intern/extern nur: "Dieser Verbindung wird nicht vertraut"
Bei den externen Aufrufen auch keine Credentials nötig, meine Hostnamen/Domains hab ich im DNS Rebind Schutz als Ausnahmen eingetragen.

EDIT: Nach entfernen der Hostnamen/Domains aus dem DNS Rebind Schutz werden die Credentials abgefragt.
...beim externen Zugriff via HTTPS, lokaler Zugriff (XSS) benötigt keine Credentials.

Box: Die 7360SL wie in Signatur angegeben (nicht modifiziert)
 
Zuletzt bearbeitet:
@koy:
Wie sehen die Einstellungen zur Anmeldung an der Box aus dem LAN aus?

Ich hatte es mit einer 7390 / 06.30 probiert (nur um mich zu vergewissern, bevor ich so etwas schreibe/frage) und da ging ohne Credentials nichts ... wenn das tatsächlich so wäre, daß sich diese Seite ohne Credentials auch von extern abrufen läßt, solange die lokale Anmeldung nicht auf "Benutzername + Kennwort" steht, dann ist das nicht nur eine theoretische Sicherheitslücke ... das macht die "Fahndung" nach potentiell verwundbaren FRITZ!Boxen dann zum Kinderspiel und sollte asap an AVM gemeldet (und spätestens mit dem nächsten Release, ggf. sogar dringender) gefixt werden. Auch die Kenntnis von 50% der "Ausgangsdaten" für individuelle Verschlüsselung in der Box ist sicherlich nicht zu verachten.

Daß man eine Box ohnehin mit Benutzername/Kennwort sichern sollte, versteht sich von alleine ... und auch nicht jede Box hat den Fernzugriff aktiviert. Aber ein externer Abruf dieser Infos ohne Credentials wäre trotzdem eine heikle Angelegenheit, die garantiert nicht unter die Kategorie "it's not a bug, it's a feature" fallen sollte.

EDIT: Das "extern" meint auch tatsächlich den externen Abruf, nicht nur den Abruf aus dem LAN mit der externen Adresse ... der wäre harmlos.
 
Natürlich so...
(o) Anmeldung mit FRITZ!Box-Benutzernamen und Kennwort
...wobei der Benutzer selbstverständlich Konfigurationsrechte hat.

Haste mein EDIT gelesen?

Zu deinem EDIT, ja, da muss ich erstmal Mobilfunkinternet anwerfen, moment...
Dann werden Benutzername/Kennwort abgefragt.
 
Zuletzt bearbeitet:
EDIT habe ich jetzt erst gelesen, der Zusammenhang zwischen Rebind-Schutz und Notwendigkeit der Authentifizierung ist mir aber nicht klar ... solange da nicht irgendein Name auf eine private Adresse aufgelöst wird, spielt der Rebind-Schutz doch gar nicht mit. Das wäre ja ein noch viel größerer Patzer, wenn dieser Rebind-Schutz bei der für das GUI entscheidenden Frage "is_internet" bei der Zugriffsprüfung irgendwelche Auswirkungen hätte. Im Moment würde ich eher darauf tippen, daß da bei Dir dann der externe Name durch irgendwelche Zusatzserver in die interne Adresse aufgelöst wurde/wird und dann ist das Ergebnis wieder plausibel. Von intern läßt sich die Box-Info immer ohne Credentials abfragen ... da ist das auch als potentielle Lücke wenig relevant, weil sich der "footprint" so einer FRITZ!Box im LAN auch auf einigen anderen Wegen ermitteln läßt (vielleicht nicht gerade mit der konkreten Firmware-Version für "tailored access", aber prinzipiell schon).

Wir driften immer weiter vom DynDNS weg ... wollte ich eigentlich nicht unbedingt. Ich hätte ja am liebsten ein Unterforum "FRITZ!Box-Sicherheit", wo man dann solche Fragen in aller Ruhe diskutieren und testen kann ... ansonsten spielt so etwas eben überall hinein - von WLAN bis Telefonie und GUI - und ist damit immer schwer zu lokalisieren oder gar an einem vorhandenen passenden Unterforum festzumachen.
 
Zuletzt bearbeitet:
Ja Genau. Ich dachte ich habe da auf dem Webspace statt einer Seite einen dyndns Server laufen zu lassen. Und das nicht als Proxy sondern als eigenen Dienst. Mit dem Webspace hätte ich ja auch eine öffentliche Adresse.

Die Überlegung ist einfach wenn alles dezentral ist wird das abschnorcheln auch schwieriger.

Ich habe aber bisher keine Erfahrung mit einer eigener Seite Server etc. Ist wohlö doch schwieriger als ich dachte wenn es nichts kosten soll. Dann wohl doch warten auf IPv6
 
Mit einem Webserver kommst da nicht weit, der ist nur für Webseiten. Und klar hat der ne öffentliche IP, sonst macht eine Internet Seite keinen Sinn.

Wenn nichts von verstehst, verwende einen existierenden Dienst. Sonst halt ggf. eigenes Thema mit deinem eigentlichen Problem, dann kann man dort ggf. andere Lösungen nennen.
 
Danke aber es läuft ja bei mir seid Jahren. Erst dyndns bis ich dann wechseln musste. Ich mach mir halt nur Gedanken wie man es schwieriger für die Überwachung machen kann. Ich kann hier wechseln auf 10000 synchron, allerdings mit Glasfaser was mir zum einen Probleme mit den Diensten meiner Fritzbox macht (dyndns, VoIP, FTP etc. pp).
Zum anderen bekomme ich keine sicheren Infos ob ich eine öffentlich IP bekomme und/oder ein Shared-Connection. Wenn ich da wirklcih volles Internet bekomme baue ich meine eigene Cloud.

Mein Nachbar hat einen 50000 Anschluss mit einem Huawei Router/Modem. Wenn ja wenn er ihn hat. Er nutzt meinen 6000er DSL-Anschluss weil da auch 6000 ankommen, kontinuierlich.
Genau wegen solchen Problemen und der Rechtslage hier zögere ich. Never change a running System. Zurück zu Kupfer geht nicht.
 
Zuletzt bearbeitet:
Ein DDNS Anbieter bringt dir nichts, wenn über IPv4 nicht erreichbar bist. Da brauchst andere Wege. Dazu gibt es aber auch Themen.
 
ertsen bin ich über IPv4 erreichbar und nutze auch seid Jahren DDNS. Und alles weitere was ich eben geschrieben habe liebt wohl nahe das ich zumindest soweit im Thema bin. Genau deswegen habe ich auch immer noch ADSL 6000 obwohl ich 10000 synchron FTTH zum gleichen Preis haben könnte.
 
Gemeint ist wohl eher (a)symmetrisch.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.