7490 - DynDNS mit einem zweiten Host

[trulli]

Mein Provider unterstützt kein CNAME.
Ausserdem löst das nicht mein Problem, da der zweite Host auch schon einmal eine IP eines anderen Routers benötigt, den ich dann über die Web-Oberfläche des Providers ändere.
Die IP des zweiten Host wird als Sicherheits-Abfrage für den Zugriff auf einen externen Rechner genutzt. Da ich meist von zu Hause arbeite, sollte diese IP auch die von zu Hause sein.
Manchmal brauche ich aber auch Zugriff von einem anderen Standort aus. In diesem Fall muss ich die DynDns auf den anderen Standort stellen.
Deshalb nützt mir auch kein CNAME, da diese Dyndns-Adresse ja dann grundsätzlich auf meine Heim-Adresse zugreift.

 

[Benares]

da der zweite Host auch schon einmal eine IP eines anderen Routers benötigt

Ich verstehe dich immer weniger. Lass den 2. Router halt das DDNS-Update für den 2. Host machen.

Was will man denn mit DDNS erreichen? Richtig, man will einfach einen festen Namen für eine sich ggf. ständig ändernde IP.
Und wenn man dann noch weitere Namen pro IP braucht, braucht man halt einen DDNS-Provider, der CNAMES unterstützt. Gibt's doch für kleines Geld.

 

[PeterPawn]

@trulli:
Entgegen Deiner offensichtlichen Erwartungen ist das hier aber ein öffentliches Forum, in dem man auch durch passives Lesen die Lösung für Probleme finden kann. Und das, was ich meinerseits da schildere (vielleicht sogar "erneut", denn einen Link auf den "riesigen Thread" gibt es ja immer noch nicht), gehört nun mal zu den möglichen (und hier auch "sauberen") Lösungen ... wenn andere diesen Thread also per Suche finden, dann erhalten sie auch die Chance, DIESE Lösung kennenzulernen und selbst zu entscheiden, ob das eine für sie ggf. gangbare Alternative ist. Auch wenn Du diesen Thread hier vielleicht eröffnet hast, ist das noch lange nicht "Deiner" und Antworten, die zum Thema gehören und passen, sind hier auch dann noch zugelassen, wenn sie Dir nicht in den Kram passen mögen.

Vielleicht wundern die künftigen Lesern sich dann aber genauso, daß Du offenbar nicht akzeptieren willst, daß genau die Lösung, die Dir nun (aus welchem Grund auch immer) vorschwebt, so nicht möglich ist - oder sie wäre zumindest "nicht bekannt" bzw. hier noch nie aufgeführt worden. Du hast offenbar irgendwo einen (geheimen?) Thread gefunden, wo zwar Lösungen für Dein Problem vorgeschlagen wurden (offenbar auch von einigen der Leute, die sich hier schon wieder bemühen, zu helfen - was ich da (älteres) finde, wäre z.B. das hier: https://www.ip-phone-forum.de/threads/mehrere-dyndns-domains-accounts-in-7490.277134/), aber diese Lösungen sagen Dir halt nicht zu ... nun gut, das ist Deine Entscheidung. Aber Dein "Problem" ist nun mal auch nicht so einzigartig, daß anzunehmen wäre, es hätte sich sonst niemand damit befaßt - offenbar waren die alle bisher nur zu blöd, eine auch für Dich akzeptable Lösung zu finden ... wobei man ja gar nicht genau weiß, welche Vorschläge Du nun tatsächlich schon kennst und welche vielleicht nicht.

Aber Du hast ja festgestellt, daß Dein Anliegen bei AVM offenbar nicht beschrieben ist ... auch das sollte einem ja irgendwie zu denken geben, wenn man damit schon zwei "Quellen" hat, die feststellen, daß es so nicht funktioniert und das hat sich nun mal auch in den letzten sechs Jahren im GUI nicht geändert. Nur bei der Behandlung solcher Accounts durch ctlmgr_ctl hat AVM da vor nicht allzu langer Zeit noch einmal nachgelegt, intern kann man da jetzt mit mehr als einem Account arbeiten. Wobei "zwei Quellen" ja auch untertrieben ist - das Problem läßt sich mit einer Suchmaschine ja auch auf anderen Sites nachlesen ... und auch da gibt es keine Lösungen, die Deinen "Anforderungen" genügen (wenn man die aus dem bisher Geschriebenen ableitet).

---

Da wird dann die Feststellung:

So etwas muss ganz einfach über die Web-Oberfläche machbar sein und natürlich sauber erklärt sein (Immerhin ist ja zumindest nicht mehr "dyndns.org" fest eingestellt ...).

auch schon fast albern ... wer hat das denn festgelegt? Und warum müssen es (mind.?) zwei "Standard-Dienste" für DynDNS sein (um den "Backup"-Gedanken aufzugreifen), wenn AVM als Backup doch den MyFRITZ!-Service anbietet? Auch da darf natürlich jeder selbst entscheiden, ob er ihn nutzt ... aber woran macht sich denn eine "Standard-Vorgehensweise" für ein DynDNS-Backup fest?`Kann man das irgendwo nachlesen? Gibt es irgendwelche Konventionen, welchen Provider oder sogar wieviele davon eine Firmware "anbieten" muß? Welche anderen Router-Hersteller halten sich denn in ihrer Firmware an dieses "Standard-Vorgehen"? Vielleicht braucht das ja mal jemand, wenn er von einer FRITZ!Box zu einem anderen Hersteller wechseln will - also hab keine Scheu, das hier auch einfach mal zu hinterlassen.

Ohne eine Antwort auf diese Fragen ist das aber einfach nur Stuss (vor allem, wenn da "muß" steht und nicht "sollte") - erst recht der Teil in der Klammer am Ende. Ich weiß gar nicht mehr, wie lange genau da im FRITZ!OS schon eine Wahl aus mehreren Providern und auch ein "benutzerdefinierter" Eintrag möglich ist ... aber das ist seit mind. 06.0x so (und das sind mind. 6,5 Jahre), wenn nicht sogar noch deutlich(!) länger (nur mein Firmware-Archiv ist "endlich"). Da stellt man sich dann schon die Frage, wann Du diesen "fest eingestellten" Provider dyndns.org wohl zuletzt in einer FRITZ!Box gesehen haben könntest.

 

[trulli]

@Benares
Kurze Erklärung:
Ich greife von zu Hause auf einen Firmen-PC zu, der anhand einer Dyndns überprüft, ob ich von zu Hause zugreife.
Bin ich auf Dienstreise muss ich vom Hotel aus zugreifen. Also muss ich auf der Seite des Providers die Dyndns ändern in die IP des Hotels. Da nützt mir CNAME nun einmal gar nichts.
Auf dem Firmen-PC kann ich nur eine Dyndns für die Überprüfung hinterlegen ... bevor einer einen Tipp hat ...

So, jetzt zu meinen Tests:
Box ist eine 7490 mit 7.21
DynDNS-Provider ist Securepoint (kostenlose Variante)
Standard-Update-URL: https://update.spdyn.de/nic/update?hostname=<domain>&myip=<ipaddr>
Standard-Domain-Name: Name1.spdns.de

1) Update-URL ohne &myip=<ipaddr> geht nicht

Update-URL: https://update.spdyn.de/nic/update?hostname=<domain>&myip=<ipaddr>
2) Domain-Name: Name1.spdns.de Name2.spdns.de geht nicht (also getrennt durch Blank)
3) Domain-Name: Name1.spdns.de,Name2.spdns.de geht (also getrennt durch Komma)

Domain-Name: Name1.spdns.de
4) Update-URL: https://update.spdyn.de/nic/update?hostname=<domain> Name2.spdns.de&myip=<ipaddr> geht nicht (also getrennt durch Blank)
5) Update-URL: https://update.spdyn.de/nic/update?hostname=<domain>,Name2.spdns.de&myip=<ipaddr> geht (also getrennt durch Komma)

6) Update-URL: https://update.spdyn.de/nic/update?hostname=<domain>&myip=<ipaddr> https://update.spdyn.de/nic/update?hostname=Name2.spdns.de&myip=<ipaddr> geht nicht (also getrennt durch Blank)
7) Update-URL: https://update.spdyn.de/nic/update?hostname=<domain>&myip=<ipaddr>,https://update.spdyn.de/nic/update?hostname=Name2.spdns.de&myip=<ipaddr> geht nicht (also getrennt durch Komma)

Ich habe mich jetzt erst einmal für die Version 3) entschieden. Sollte das auf Dauer zu Fehlern führen, nehme ich Version 5)

Vielen Dank an Alle für die Unterstützung.

Sollte es gar nicht laufen, werde ich hier weiter berichten.

Nächste Aktion ist dann das Update auf 7.27 - mal schauen, ob es damit dann auch noch läuft.

 

[Benares]

Nimm besser Variante 5. Irgendwie muss die FB ja auch prüfen, ob ein Update notwendig ist. Das macht sie m.W. über den bei Domain eingetragenen Namen.
Das Variante 6 nicht geht, wundert mich allerdings.

 

[trulli]

Woher weißt Du eigentlich schon vorher, welche Probleme ich habe ...
Also mit der Version 3) werde ich auch nicht glücklich.
Alle 30 Minuten habe ich einen LogFile-Eintrag bei der 7490 (DynDNS-Fehler: Der angegebene Domainname kann trotz erfolgreicher Aktualisierung nicht aufgelöst werden).
Und zusätzlich versucht er alle 30 Minuten den zweiten Host zu ändern, obwohl gar nicht nötig (da wird mir dann irgendwann der Provider aufs Dach steigen ...)
Ich probiere jetzt mal Version 5.
Übrigens geht nicht nur 6 nicht, 7 geht auch nicht.
Aber egal ... jetzt probiere ich 5 - und wenn das auch nicht sauber funktioniert, muss halt das Skript wieder herhalten.

 

[kleinkariert]

Danke für den umfangreichen Test!
Erwähnen könnte man noch, dass "https://" beim AVM nie notwendig ist, das wird offensichtlich ergänzt.

 

[AraldoL]

Trägt jetzt nicht zur Lösung bei aber wenn ich #25 lese: Entweder dein Arbeitgeber will und erlaubt daß du dich auch von einem (ggf. sehr unsicheren) Hotel aus verbindest, dann hat er gefälligst für eine technische Lösung zu sorgen. Kann doch nicht sein daß sich Mitarbeiter da selber über öffentliche Foren wie dieses was zurechtfrickeln müssen was 98% gar nicht können.

Oder er will es nicht oder soll es nicht wissen, dann sägst du da evtl. auf dem Ast auf dem du sitzt. Ich kenne selber zwei Leute die auch dem Firmenserver vorgaukeln wollten sie wären woanders, beide brauchen sich da jetzt keine Gedanken mehr zu machen seit der Kündigung.

Nicht falsch verstehen, will da jetzt nicht als Miesmacher auftreten sondern wegen der Fälle die ich kenne und die da sehr blauäugig waren einfach drauf hinweisen daß das nach hinten losgehen kann. Wenn das so abgesegnet ist will ich nichts gesagt haben ...

 

[kleinkariert]

Wenn jetzt jetzt zum entspannten off-topic-Teil kommen:

der anhand einer Dyndns überprüft, ob ich von ... zugreife

Das ist möglicherweise nicht so ernst gemeint von der Firmenleitung, sondern einfach nur eine von vielen aktivierten Policies des Securepoint-"Kastens".
Könnte man dann nicht einfach auf dem Firmennotebook einen DynDNS-Refresh machen und fertig. Die IP läst sich später immer noch nachweisen und grob geolokalisieren.

 

[HabNeFritzbox]

Wenn es nur darum geht dass IP vom Standort des Notebooks bekannt ist, wäre es ggf. sinnvoller einfach Update auf dem Notebook auszuführen, die IP muss man selbst nicht angeben, die Anbieter nehmen normal die IP von wo Anfrage kommt.

So bräuchte man weder in FB werkeln, noch im Portal was manuell ändern.

 

[trulli]

Ich versuch es mal zu erklären:
Es gibt eine Dyndns mit Namen "Kontrolle.dns.de". Die wird von meiner Fritzbox zu Hause gesetzt.
Ich greife jetzt mit meinem PC auf das Firmennetz zu.
Dort wird jetzt geprüft, ob die Anfrage von der IP kommt, die abgebildet ist auf der DynDNS-Adresse "Kontrolle.dns.de".
Das heisst, nur die PC's, die hinter meiner Fritzbox sind, können zugreifen.
Bin ich jetzt auf Dienstreise, ändere ich auf der Seite des Providers manuell die DynDNS-Adresse von "Kontrolle.dns.de" auf die IP des Hotels (des Routers vom Hotel, nicht vom Notebook).
Von zu Hause kann jetzt niemand mehr zugreifen. Das alles geschützt auch noch mit Username und Passwort ist eine recht gute Absicherung.

Und abschliessend: Es sieht so aus, als wenn die Version 5 fehlerfrei läuft.
Update-URL: https://update.spdyn.de/nic/update?hostname=<domain>,Name2.spdns.de&myip=<ipaddr>

 

[PeterPawn]

Für spätere Leser, die ähnliche Probleme haben und beim Suchen nach dem DynDNS-Update mit mehr als einem Konto dann hier landen:

Das von mir weiter vorne angerissene Problem, daß die Updates bei den "vordefinierten" Provider-Einträgen nur ohne TLS erfolgen würden (das hat mit dem benutzerdefinierten Eintrag nichts zu tun), hat sich mittlerweile erledigt oder so nie richtig bestanden und basierte nur auf einem Irrtum bzw. "Unkenntnis" meinerseits. Der DynDNS-Client versteht wohl doch eine Portangabe (seit wann genau, weiß ich nicht - aber es ist mind. bis 06.35 zurückverfolgbar für den Provider Dyndnsfree.de, der aber als einziger eine solche Angabe enthält und in der 06.05 noch nicht enthalten war ... weitere Versionen dazwischen habe ich nicht geprüft) hinter dem Servernamen und wenn das Port 443 ist, wird auch HTTPS verwendet. Die Angabe eines Protokolls VOR dem Servernamen ist bei den vordefinierten Einträgen NICHT möglich - dann findet gar kein Traffic zum Server statt, vermutlich wird die Angabe vorher als ungültiger Name/ungültige Adresse aussortiert, denn es erfolgt auch kein Versuch einer DNS-Auflösung bei Angabe eines Namens.

Die ganzen vordefinierten Accounts stehen auch nirgendwo in der Firmware in irgendwelchen Textdateien ... sie sind als komplette Einträge in der libar7cfg.so hinterlegt und werden beim ersten Speichern einer "frischen" ar7.cfg dann hinzugefügt. Von den derzeit acht Providern (wenn ich mich nicht verzählt habe - die älteren Vorgaben für namemaster.de (zuletzt in der 06.6x vorhanden) und TZO.com, sowie zwei ältere dyndns.org-Spezialaccounts, wurden offenbar wieder entfernt, können aber bei Leuten, die ihre Konfiguration schon länger durch die Gegend schleppen, auch weiterhin existieren) verwendet aber auch nur ein einzelner tatsächlich TLS-Verschlüsselung beim Request (eben der erwähnte Dyndnsfree.de) ... der ganze Rest (inkl. No-IP, wo das Update auf Port 8245 und mit Base64-kodierten Parametern erfolgt - aber ohne TLS) nutzt einen "stinknormalen" HTTP-Request, wobei sogar die Credentials schon direkt im Request als "Basic Auth" angegeben werden - also praktisch im Klartext, denn das ist lediglich eine simple Base64-Kodierung für diese Credentials. Von einer - wie auch immer gearteten - "Digest Auth" ist da nichts zu sehen (obwohl die für das Update der MyFRITZ!-Adresse sogar verwendet wird - mithin also auch funktionierend(!) implementiert ist) - es wäre ja ohnehin schon zu spät, denn die Credentials gehen schon mit dem ersten Request raus.

Die Tests erfolgten alle mit einer 113.07.24-86493, weil die gerade installiert war - von AVM gab es aber m.W. auch keine Informationen, daß sich an diesen Stellen etwas geändert hätte bis zur 07.27; daher würde ich die auch für die 07.27 als gültig ansehen, solange niemand das Gegenteil "ertestet".

---

Diese Feststellung/Behauptung:

Erwähnen könnte man noch, dass "https://" beim AVM nie notwendig ist, das wird offensichtlich ergänzt.

konnte ich hingegen nicht verifizieren (mit der angegebenen Version) ... bei der Angabe einer URL wie 192.168.131.2/update?... kommt es zu folgenden Requests:

- eindeutig "plain HTTP" und auch wenn da kein Listener ist:

, sieht es nicht anders aus - ein automatischer Versuch mit HTTPS erfolgt (zumindest bei den Parametern in meinem Beispiel) also auch NICHT - weder als erste Wahl, noch als Fallback-Option. Da auch hier schon der erste Request (bei vorhandenem Listener, denn nur dann wird der 3-Way-Handshake beim TCP fertig) bereits wieder die Credentials quasi im Klartext enthält, sollte man also immer den HTTPS-Präfix in der URL mit angeben, solange der Server das auch beherrscht ... denn dann findet erst einmal ein TLS-Handshake statt (bei https://192.168.131.2/update?... in der URL):

und man kann die Daten in der darin gekapselten HTTP-Verbindung nicht mehr einfach mitlesen. Kleiner Spoiler: Der Request endete wieder mit 404, wie der erste.

---

Ansonsten müßte ich mich schon schwer irren, wenn hier im Thread bei der schlußendlich verwendeten Lösung nicht einfach der Umstand ausgenutzt wird, daß DIESER Provider das Aktualisieren mehr als eines Namens ermöglicht, indem diese als "Aufzählung" (also durch Kommata getrennt) in der URL als hostname angegeben werden (was bei No-IP iirc auch der Fall wäre, da kann man die Namen als h[] oder so angeben).

Sowohl 3 als auch 5 verwenden eine solche "Liste" aus zwei Namen. Das mag dann für diesen Provider funktionieren (und hat mit dem FRITZ!OS fast gar bis überhaupt nichts zu tun - das klappt auf diesem Weg selbst mit einem Browser), ist aber für andere Provider nur dann ebenfalls eine Lösung, wenn diese genauso die Verarbeitung einer Liste von Namen implementiert haben. Die einzige Frage, die sich hier dann stellt und die tatsächlich im Zusammenhang mit dem FRITZ!OS steht, ist die, wie man eine benutzerdefinierte URL in das dafür vorgesehene Feld eingibt - und hier tatsächlich auch nur eine einzelne. Will man zwei URLs verwenden, sind diese auch weiterhin mit einem Leerzeichen zu trennen.

Außerdem ist auf diesem Weg tatsächlich bei zwei Namen (bzw. zwei URLs) Schluß, denn die Angabe von mehr als zwei URLs funktioniert auch bei einem benutzerdefinierten DynDNS-Service nicht im FRITZ!OS - die Trennung erfolgt einfach am ersten Leerzeichen und wenn es weitere davon gibt, werden die der zweiten URL zugeschlagen (und nicht mal richtig kodiert für eine URL, denn die werden tatsächlich als Leerzeichen übertragen).

Wenn man zwei URLs angibt, werden auch die (gemeinsamen) Credentials automatisch in diesen beiden Requests direkt beim ersten Mal mitgesendet (und sind bei Verbindungen ohne TLS damit lesbar) - wenn man für die beiden Requests unterschiedliche Credentials verwenden will und der Provider die tatsächlich eher aus der URL als aus dem Request lesen sollte (was auch nicht zwingend ist), DANN muß man die tatsächlich für den Request in der URL angeben, zu dem die in der GUI-Maske eingetragenen Credentials ansonsten nicht passen würden oder man macht es gleich bei beiden - für die "Übermittlung" bzw. die Sicherheit der Credentials spielt das keine Rolle, die steht und fällt mit der Verwendung von TLS.

EDIT: Wie man die Parameter richtig einträgt, ist dann hier: https://service.avm.de/help/de/FRITZ-Box-Fon-WLAN-7490/019p2/hilfe_dyndns bei AVM beschrieben.

 

[trulli]

... und jetzt ist auch dieser Thread so Übersichtlich, wie alle Deine Doktorarbeiten. Von mir bekommst Du denn Oskar.

 

[PeterPawn]

Auch wenn die zusätzlichen Infos jenseits Deines (bzw. Eures, wenn es mehreren so ergehen sollte) eigenen Horizontes sein könnten ... das ist auch hier immer noch nicht Deine Privatveranstaltung und es gibt auch Leute, die mit diesen Informationen (hier und in anderen Threads) etwas anfangen können. Das mag Dir jetzt gegen den Strich gehen ... interessiert mich am Ende aber kein Stück - ich hoffe, Du kannst mir das nachsehen.

 

[Benares]

Sowohl 3 als auch 5 verwenden eine solche "Liste" aus zwei Namen. Das mag dann für diesen Provider funktionieren...

Das ist nichts Besonderes. Sowas unterstützen viele Provider. Ich hab das auch schon öfter gebraucht. Klar hat das mit FRITZ!OS recht wenig zu tun, das sorgt ja "nur" für die Aufbereitung des URL-Strings und die Prüfung/Kommunikation. Alle DDNS-Updater (auch auf NAS...) arbeiten so. Und auch hinter den auswählbaren DDNS-Providern steckt nichts anderes als eine Konfi-Datei mit den jeweiligen Update-URLs. Auch bei der Fritzbox ist das sicherlich ebenso.

Hier mal als Beispiel die DDNS-Konfi meines Synology-NAS. Als "__HOSTNAME__" geht fast bei allen auch eine Komma-separierte Liste mehrerer Namen.

root@DS415:/etc# cat ddns_provider.conf
# Input:
#    1. DynDNS style request:
#       modulepath = DynDNS
#       queryurl = [Update URL]?[Query Parameters]
#
#    2. Self-defined module:
#       modulepath = /sbin/xxxddns
#       queryurl = DDNS_Provider_Name
#
#       Our service will assign parameters in the following order when calling module:
#           ($1=username, $2=password, $3=hostname, $4=ip)
#
# Output:
#    When you write your own module, you can use the following words to tell user what happen by print it.
#    You can use your own message, but there is no multiple-language support.
#
#       good -  Update successfully.
#       nochg - Update successfully but the IP address have not changed.
#       nohost - The hostname specified does not exist in this user account.
#       abuse - The hostname specified is blocked for update abuse.
#       notfqdn - The hostname specified is not a fully-qualified domain name.
#       badauth - Authenticate failed.
#       911 - There is a problem or scheduled maintenance on provider side
#       badagent - The user agent sent bad request(like HTTP method/parameters is not permitted)
#       badresolv - Failed to connect to  because failed to resolve provider address.
#       badconn - Failed to connect to provider because connection timeout.
#
[CloudNS]
        modulepath=/usr/syno/bin/ddns/cloudns.php
        queryurl=https://www.cloudns.net/
[Google]
        modulepath=/usr/syno/bin/ddns/google.php
        queryurl=https://domains.google.com/
[DNSEXIT]
        modulepath=/usr/syno/bin/ddns/dnsexit.php
        queryurl=http://www.dnsexit.com/
[Joker.com]
        modulepath=DynDNS
        queryurl=svc.joker.com/nic/update?username=__USERNAME__&password=__PASSWORD__&myip=__MYIP__&hostname=__HOSTNAME__
[OVH]
        modulepath=DynDNS
        queryurl=www.ovh.com/nic/update?system=dyndns&hostname=__HOSTNAME__&myip=__MYIP__
[DYNDNS.org]
        modulepath=DynDNS
        queryurl=members.dyndns.org/nic/update?hostname=__HOSTNAME__&myip=__MYIP__&system=dyndns&wildcard=NOCHG&mx=NOCHG&backmx=NOCHG
[TwoDNS.de]
        modulepath=DynDNS
        queryurl=update.twodns.de/update.php?hostname=__HOSTNAME__&myip=__MYIP__
[NoIP.com]
        modulepath=DynDNS
        queryurl=dynupdate.no-ip.com/nic/update?hostname=__HOSTNAME__&myip=__MYIP__
[able.or.kr]
        modulepath=DynDNS
        queryurl=able.or.kr/ddns/src/update.php?hostname=__HOSTNAME__&myip=__MYIP__&ddnsuser=__USERNAME__&pwd=__PASSWORD__
[3322.org]
        modulepath=DynDNS
        queryurl=www.3322.org/dyndns/update?hostname=__HOSTNAME__&system=dyndns
[selfHOST.de]
        modulepath=DynDNS
        queryurl=carol.selfhost.de/nic/update?hostname=__HOSTNAME__&myip=__MYIP__
[Dynamic DO!.jp]
        modulepath=Ddojp
        queryurl=free.ddo.jp/dnsupdate.php?dn=__HOSTNAME__&pw=__PASSWORD__&ip=__MYIP__
[ChangeIP.com]
        modulepath=DynDNS
        queryurl=nic.ChangeIP.com/nic/update?hostname=__HOSTNAME__&myip=__MYIP__&system=dyndns
[DNSPod.com]
        modulepath=/usr/syno/bin/ddns/dnspod_com.php
        queryurl=https://api.dnspod.com/
[DNSPod.cn]
        modulepath=DNSPod
        queryurl=dnsapi.cn/Record.Modify?login_email=__USERNAME__&login_password=__PASSWORD__&format=xml&domain_id=__DOMAINID__&record_id=__RECORDID__&sub_domain=__SUBDOMAIN__&record_type=A&record_line=__RECORDLINE__&value=__MYIP__&mx=__MX__&ttl=__TTL__
[Zoneedit.com]
        modulepath=Zoneedit
        queryurl=dynamic.zoneedit.com/auth/dynamic.html?host=__HOSTNAME__&dnsto=__MYIP__
[Freedns.org]
        modulepath=Freedns
        queryurl=freedns.afraid.org/dynamic/update.php?user=__FreednsSHA1__&host=__HOSTNAME__&address=__MYIP__
[DNS-O-Matic]
        modulepath=/usr/syno/bin/ddns/dns_o_matic.php
        queryurl=https://updates.dnsomatic.com/nic/update
[RU-CENTER]
        modulepath=/usr/syno/bin/ddns/ru_center.php
        queryurl=https://api.nic.ru/dyndns/update
        website=http://dns-master.ru/dynamic_dns/
[STRATO]
        modulepath=DynDNS
        queryurl=dyndns.strato.com/nic/update?hostname=__HOSTNAME__&myip=__MYIP__
[Oray.com]
        modulepath=DynDNS
        queryurl=ddns.oray.com/ph/update?hostname=__HOSTNAME__&myip=__MYIP__
[Synology]
        modulepath=Synology
        queryurl=ddns.synology.com
        register_module=synology
        website=https://myds.synology.com

Edit:
Wichtig vielleicht noch: Die Update-URLs enthalten nie irgendwelche Leerzeichen. Deshalb kann es sein, dass der jeweilige DDNS-Client auch eine ganze (durch Blanks separierte) Liste von Update-URLs in einer Schleife verarbeiten kann. Meines Wissens macht das auch die Fritzbox so. Deshalb war ich verwundert, das Variante 6 nicht ging, obwohl ich das selbst jahrelang benutzt habe.

 

[kleinkariert]

P.Pawn:
Jetzt hatte ich gedacht, AVM würde HTTPS ergänzen, weil alle Beispiele ohne HTTP/HTTPS sind und HTTPS bei sämtlichen DynDNS-Anbietern eigentlich Standard ist - vor allem wenn da Kennworte in der URL sind!

Benares:
AVM hat in seiner Config auch eine Liste, aber die von Synology ist eindeutig länger.
Wo ist denn die Quelle für das "geht fast bei allen auch eine Komma-separierte Liste mehrerer Namen".

nur die PC's, die hinter meiner Fritzbox sind, können zugreifen.

Aha, eine Fritzbox per IPsec/IKEv1 angebunden und alle Geräte im Home-LAN/WLAN können ins Firmennetz. Das ist verdammt mutig von eurem Admin.

 

[Benares]

Wo ist denn die Quelle für das "geht fast bei allen auch eine Komma-separierte Liste mehrerer Namen".

Relativiere: Bei allen, die ich bisher genutzt habe: DynDNS, NOIP, Strato - man muss es einfach ausprobieren.

 

[HabNeFritzbox]

Mein Vorschlag ist nix?
Unabhängig vom Router, kein Login ins Portal, einfach nur Script starten ggf. Autostart vom Lappy, oder Browser Lesezeichen.

 

[PeterPawn]

Auch bei der Fritzbox ist das sicherlich ebenso.

Wie bereits geschrieben ... beim FRITZ!OS stehen diese vordefinierten Provider in keiner Text-Datei. Die bekannten Dienste stehen in binärer Form in einer Library (libar7cfg.so) und werden beim Speichern einer ar7.cfg mit den vorhandenen gemischt. Was aber nicht heißt, daß man keine eigenen hinzufügen könnte bzw. daß ältere und mittlerweile nicht mehr als Vorbelegung präsente Einträge dabei gelöscht werden, wenn sie in der Datei vorhanden sind.

Und eine Liste von Host- bzw. DynDNS-Namen (die auch tatsächlich ausgewertet wird) ist nicht wirklich selbstverständlich ... manche DynDNS-Anbieter verwenden auch eine "Verlinkung" mehrerer Adressen, wo ein Update für eine einzige dann alle anderen ebenfalls aktualisiert - als Beispiel FreeDNS: https://freedns.afraid.org/faq/#4

Und ob bei diesen dann tatsächlich eine "Liste" ausgewertet wird, kann schon sehr unterschiedlich implemetiert sein (ich kenne auch kein OpenSource-Projekt, was jetzt der "Standard" für solche Server wäre - denn auch die letztlich per HTTP(S) aktualisierten Name-Server verwenden schon stark unterschiedliche Software) ... vor allem deshalb, weil dann bei einem Update eines Users für drei Hosts, die auch noch zusätzlich verlinkt sind, immerhin 9 Updates erfolgen würden (unter der Annahme, daß die eingetragene Adresse vor einem Update nicht erst mal verifiziert wird - dann wären das aber auch wieder 9 Überprüfungen) und das wächst dann mit jedem weiteren Namen schneller. Die jeweiligen Skript-Dateien bei den ganzen DynDNS-Providern sind wohl eher "handgeklöppelt" von Programmierern oder sogar von Administratoren (manchmal auch in Personalunion).

Und es gibt auch hier keine Standards (zumindest kenne ich keine "offiziellen", also nehme ich gerne entsprechende Links) - die wurden zwar mal in grauer Vorzeit durch DynDNS.org (damals eigentlich noch .com) quasi gesetzt (üblicherweise als "DynDNS v1" und der Nachfolger als "DynDNS v2" bezeichnet) und die nächsten Provider orientierten sich dann daran, aber heutzutage gibt es eben so viele dieser Provider, daß diese Mühe haben, sich von anderen zu unterscheiden und so kommen da immer wieder mal ein paar neue Funktionen hinzu, die dann auch neue Schnittstellen (oder zumindest Erweiterungen) und neue Algorithmen beinhalten.

Es gibt/gab durchaus ein paar Provider, bei denen solche "Mehrfach-Updates" nicht möglich waren - ich kann mich irgendwo an eine Liste von möglichen APIs für diese Dienste bei den Source-Files von ddclient erinnern (das waren dann diejenigen, die von diesem Programm unterstützt wurden). Das Projekt war früher mal auf Sourceforge gehostet - wo es heute abgeblieben ist, weiß ich aber auch nicht.

Falls jemand tatsächlich DEN Standard (und vielleicht sogar DIE Software) für solche DynDNS-Updates über HTTP(S) kennen sollte (und selbstverständlich geht es um die Server- und nicht um die Client-Seite), nehme ich auch hier gerne jeden Tipp zur Kenntnis. Projekte wie nsupdate.info (https://nsupdateinfo.readthedocs.io/en/latest/intro.html) oder ddns (https://github.com/pboehm/ddns) kenne ich allerdings - nur ist keines von beiden meines Wissens "bei den Großen" (DynDNS-Providern) im Einsatz.

---

Ausgehend von "DynDNS2 Update Protokoll" auf der Seite (https://www.ddnss.de/index.php), sollte auch ddnss.de mit mehreren DynDNS-Namen umgehen können - vom Betreiber hat man auch schon lange nichts mehr gelesen (18 Monate) - aber der Service läuft offenbar noch, auch wenn's selbst auf dem Twitter-Account (https://twitter.com/ddnss_de) schon seeehr ruhig ist. Andererseits ist das oft auch ein gutes Zeichen - ein Dienst, der keine Probleme macht, braucht nicht unbedingt ständig neue Meldungen.

Es mag also tatsächlich "bei vielen" so funktionieren ... aber es hat mit dem FRITZ!OS bzw. irgendwelchen "Spezialitäten" der FRITZ!Boxen immer noch nichts zu tun, sondern reduziert sich (nach vielem Hin und Her) letztlich auf die Frage, WIE man eine Update-URL für den benutzerdefinierten DynDNS-Provider in die Maske einträgt, wenn man zwei oder mehr DynDNS-Namen mit einem Request aktualisieren will.

---

BTW ... beim "Stöbern" nach anderen Infos bin ich dann auf diesen Thread gestoßen: https://www.ip-phone-forum.de/threads/how-to-andere-dyn-dns-provider.67498/post-307690 - da war also schon in 2004 bei den FRITZ!Boxen die Angabe eines eigenen Dienstes möglich und es gab keinen "fest eingestellten" Provider DynDNS.org.

---

Ich finde jetzt auch das Vorgehen der Administratoren in dieser Firma nicht sooo ungewöhnlich - so ein DynDNS-Account KANN zwar auch zum Auflösen eines bekannten Namens in eine IP-Adresse verwendet werden und das ist sicherlich auch der überwiegende Teil, der so genutzt wird ... aber es ist gleichzeitig auch die einzige (und eine recht zuverlässige) Möglichkeit, sich mit einer (unmodifizierten) FRITZ!Box so bei einem Server anzumelden, daß dieser für die Zieladresse zusätzliche Dienste freischaltet - das erspart z.B. beim einem Asterisk-Server jede Menge sinnloser INVITE-Anfragen, bei einem SSH-Server irgendwelche Portscans und Login-Versuche aus Fernost (oder ganz weit Osteuropa) und sogar bei einem LDAP(S)-Server senkt das die Last durch Angriffsversuche deutlich. Alles das sind z.B. Dienste, die ich auf Servern bereithalte und wo sich die FRITZ!Boxen an einem (eigenen) DynDNS-Service anmelden müssen, damit sie auf deren Ports Zugriff erhalten.

Dabei wird gleichzeitig noch geprüft (wo es sinnvoll ist), daß die Update-Requests auch tatsächlich aus dem Netz des Providers stammen, der diesen Anschluß betreibt (per Reverse-Lookup) - damit werden Updates von anderen Adressen (das ist ja TCP und daher auch nicht einfach zu fälschen) unterbunden, wenn die erwarteten Daten vorher bekannt sind. Parallel dazu läuft alle 15 Minuten ein "Aufräumen" in den Tabellen (per ipset werden die zulässigen Adressen und eine Blacklist mit den letzten "Angreifern" verwaltet, so daß irgendwelche Angreifer gar nicht erst bis zur überbordenden Nutzung von Ressourcen kommen - nach zwei erfolglosen Authentifizierungen landen die Adressen für 60 Minuten in der Blacklist), damit ältere (dynamische) IP-Adressen zeitnah entsorgt werden.

Und jeder DynDNS-Client hat eine max. Zeitspanne, nach der er seine Registrierung erneuert haben muß - ansonsten wird beim nächsten Aufräumen für diesen Account bzw. diese Adresse keine neue Freischaltung ausgeführt. Glücklicherweise bietet der AVM-Client aber auch dafür eine Option (auch wenn man die nur per Editieren der ar7.cfg erreichen kann), mit der man die Zeit einstellen kann, bis der DynDNS-Client von AVM eine solche Registrierung erneuert (die heißt dann touchtime).

Das "man will doch nur einen Rechner/Namen im Internet finden" ist also EINE mögliche Anwendung eines DynDNS-Accounts auf einer FRITZ!Box (und sicherlich auch der häufigste Fall), aber eben doch nicht der einzige - #23 liest sich bei Dir anders.

Und auch das hier:

Meines Wissens macht das auch die Fritzbox so.

mit Bezug auf mehr als zwei URLs ist definitiv falsch - es wird (wie bereits geschrieben) am ersten Leerzeichen getrennt und der komplette Rest wird als zweite URL (inkl. nicht standardkonformer Kodierung der weiteren Leerzeichen) verwendet und landet so am (zweiten) Server. Getestet mit der weiter oben angegebenen Version des FRITZ!OS - das wird sich kaum geändert haben.

---

EDIT:
Hier - der Vollständigkeit halber - noch der Link zur API-Dokumentation von dyn.org (war mal DynDNS.org): https://help.dyn.com/remote-access-api/

 

[sonyKatze]

Es sieht so aus, als wenn die Version 5 fehlerfrei läuft.

Variante 5 – also Benares Einwurf aus Post #7 – mache ich seit – ohje, jetzt muss ich raten/lügen/schätzen –, knapp sechs Jahren und bisher keine Probleme. Dürfte also für Deinen Zweck mehr als tun. Aber auch interessant, dass Securepoint den Parameter myip braucht. Mein Tipp für unterwegs: Schreibe dort eine private IP-Adresse wie „192.168.178.1“ rein. Dann musst Du laut deren Anleitung nicht umständlich erst die öffentliche IP raussuchen.

Das alles geschützt auch noch mit Username und Passwort ist eine recht gute Absicherung.

Grummel. Wenn Du eine Zwei-Faktor-Authentifizierung für Dein/Euer VPN machen willst … ich würde einen neuen Thread aufmachen, damit man das dort separat diskutieren kann. Meine spontane Empfehlung wäre eine VPN-Anwendung, die Security-Tokens unterstützt (Signatur-Chipkarten wie zum Beispiel die USB-basierten YubiKeys). Der Vorteil ist, dass Du damit auch noch andere „schöne“ Dinge machen kannst (GitHub, OpenPGP, …). Problem bei Eurer jetzigen Lösung ist: Ihr seit auf IPv4 angewiesen. Wenn Du irgendwann einmal ein IPv6-only-Netz nutzt (was in Hotels nach dem Absturz des DHCPv4-Server gar nicht so selten ist), stehst Du dann blöd da. Und manche Dynamic-DNS-Updater checken die vorgezeigten TLS/SSL-Zertifikate gar nicht – klar das bräuchte einen aktiven Angreifer für einen MiTM-Attack.