[Frage] Mehrere DynDns-Domains /-Accounts in 7490

[koyaanisqatsi]

Zweiter Account?
Das ist mein zweiter Account.
Der erste ist bei myfritz.net.
Ich muss dazu einen zweiten Typ A Hostnamen bei spdns.org anlegen.
...moment...

 

[Benares]

"myfritz.net" ist aber m.E. kein weiterer DDNS-Account sondern ein komplett anderer Mechanismus, oder?

 

[PeterPawn]

"myfritz.net" ist aber m.E. kein weiterer DDNS-Account sondern ein komplett anderer Mechanismus, oder?

Ja und nein.

Wird vom ddnsd genauso aktualisiert wie andere DynDNS-Accounts auch (s. /var/tmp/ddnslog_n.txt) ... aber natürlich vollkommen anders konfiguriert. Daher "ja und nein", es gibt Gemeinsamkeiten und gewaltige Unterschiede.

@koy:
Einfacher wäre der Test (es ist ja offenbar HTTPS-verschlüsselt), wenn die beiden URLs auf unterschiedliche Server/Dienste zeigen - reicht ja schon, wenn die zweite URL meinetwegen auf irgendeine exotische Adresse zeigt und trotzdem ein Request an diese Adresse geht und nicht nur an die erste.

@b0mbel:
Eigentlich kann die unter der von Dir angeführten URL beschriebene Vorgehensweise nicht funktioniert haben. Das Prinzip klappt zwar, aber definitiv nicht mit den Daten aus zwei verschiedenen Export-Dateien. Wenn Du Dir die Daten im Beispiel ansiehst, erkennst Du auch ganz leicht, daß da bei den zwei Accounts der einzige Unterschied der verwendete Provider ist, während der Domainname, der Benutzername und das Kennwort identisch sind. Sind diese Angaben dann auch noch so bei den beiden Providern hinterlegt, klappt das vielleicht sogar, aber das sind nicht die Daten aus zwei verschiedenen Sicherungen, die Du da siehst, auch wenn der Text etwas anderes behauptet.

Die Bemerkung zur Vereinfachung durch Verwendung von Klartext-Daten findest Du aber auch noch auf der Seite in den Kommentaren.

Wenn das mit dem Zusammenkopieren von (verschlüsselten) Daten aus zwei Export-Dateien funktionieren soll, müßte ja der Export für identische Daten auch identische Chiffrate ergeben. Wie Du aber ganz leicht feststellen kannst, erhältst Du bei jedem neuen Export (sogar bei jedem internen Speichern der Dateien durch die Firmware) unterschiedliche Chiffrate (das sind die Daten, die mit vier Dollarzeichen beginnen, denen dann nur A-Z und 1-6 folgen) für ein und dieselben Daten.

Und nur für das Erzeugen des zweiten Eintrags braucht man keine zweite Sicherungsdatei. Die Daten kann man im Klartext in die entsprechenden Felder bei den Accounts eintragen und gut ist's ... dann noch eine gültige Prüfsumme berechnet und - bei richtiger und sorgfältiger Arbeit, sonst verwirft die Box beim Neustart die ar7.cfg und startet mit der Standarddatei aus /etc/default.$CONFIG_PRODUKT/$OEM - läßt sich die entsprechende Datei auch importieren. Dabei darf man ab 06.10 dann aber nicht mehr den Fehler machen, die "NoChecks"-Angabe überhaupt einzufügen - sie wird bei gültiger Prüfsumme schlicht nicht gebraucht.

 

[koyaanisqatsi]

@koy:
Einfacher wäre der Test (es ist ja offenbar HTTPS-verschlüsselt), wenn die beiden URLs auf unterschiedliche Server/Dienste zeigen - reicht ja schon, wenn die zweite URL meinetwegen auf irgendeine exotische Adresse zeigt und trotzdem ein Request an diese Adresse geht und nicht nur an die erste.

Nein, davon war nie die Rede, es geht um 2 verschiedene Hostnamen beim selben Anbieter...

Was ich aber möchte sind 2 unterschiedliche Domains bei einem Anbieter.
Angelegt sind beide mit dem gleichen Account bei DynDns.org

...User/Passwort gelten also für denselben Account beim Anbieter.
Und dieser ist in der Dynamic-DNS Seite eingetragen und wird beim Aktualisieren von der Fritz!Box mitgeliefert.

 

[PeterPawn]

Nein, davon war nie die Rede, es geht um 2 verschiedene Hostnamen beim selben Anbieter...

Es geht hier doch eigentlich darum, ob die FRITZ!Box bei Angabe von zwei URLs durch Leerzeichen getrennt, auch zwei Requests erzeugt.

Die Update-URLs können beide angegeben werden in: Internet/Freigaben/Dynamic DNS: [Benutzerdefiniert] Update-URL
Code:

https://update.spdns.de/nic/update?hostname=<domain>&myip=<ipaddr> https://update.spdns.de/nic/update?hostname=<domain>&myip=<ip6addr>

Dabei wäre es wesentlich einfacher festzustellen, ob da wirklich zwei Requests erzeugt werden (wozu sonst zwei URLs?), wenn die an unterschiedliche Adressen gehen, da ja der Inhalt der Kommunikation (sprich der HTTP-Request) bei HTTPS-Verbindungen nicht zu sehen ist.

Ich bezweifele im Endeffekt ja nicht, daß bei spdns das Update mehrerer Hostnamen (unter demselben Account) mit einem einzelnen Request möglich ist. Ich glaube nur nicht daran, daß die FRITZ!Box aus der von Dir verwendeten Syntax bei der "Update-URL" tatsächlich zwei Requests erzeugt.

 

[b0mbel]

Vielen Dank für Eure FeedBacks.

@PeterPawn
danke, dass Du Dir die Zeit nimmst.
Ich habe mich nicht eingelesen, wie die Fritz mit sensitiven Daten umgeht, weil es auch nicht meine Intention war, deren Sec.Policies zu betrachten … ich wollte ja nur 2 unterschiedliche DynDNS-Domains up2date halten

Du hast Recht, so wie in dem o.g. Link beschrieben, hat es nicht funktioniert.
Auch mit der URLs klappt es nicht … wobei ich auch hier mir die Frage gestellt habe, wenn ich 2 unterschiedliche Accounts gehabt hätte, wie hätte es denn funktionieren sollen, wenn hier nirgends das Passwort und/oder der Benutzername abgefragt werden.

Ich werde es morgen im Laufe des Tages mit den Klartext-Daten ausprobieren. Mal schauen, ob das funktioniert.

Nochmals Danke!

 

[Benares]

Hallo PeterPawn,

ich denke, das von koyaanisqatsi beschriebene Verfahren um zwei Hosts beim gleichen Provider zu aktualisieren, funktioniert schon. Es ist ja schliesslich so (oder so ähnlich) auch auf den Hilfeseiten beschrieben. Für zwei Hosts bei unterschiedlichen Provider kann es m.E. aber nicht funktionieren, da unterschiedliche Account-Daten notwendig wären.

Ich würde mir eine universelle Syntax wie beispielsweise

https://username:[email protected]/nic/update?hostname=<domain>&myip=<ipaddr> [https://...]

mit gut dokumentierten Platzhaltern wünschen. Damit könnte man alles erschlagen.

 

[koyaanisqatsi]

Der Protokollmitschnitt enthält für jede UpdateUrl ein GET und ein abschliessendes:
User-Agent: Fritz!Box DDNS/1.0.1
Connection: close

Für jede IP gibt es auch noch...

HTTP/1.1 200 OK
Date: Tue, 24 Feb 2015 19:51:23 GMT
Server: Apache
Content-Location: update.php
Vary: negotiate,Accept-Encoding,User-Agent
TCN: choice
Set-Cookie: PHPSESSID=sessionidhash; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: PHPSESSID=sessionidhash; path=/
Strict-Transport-Security: max-age=3600;
Content-Length: 19
Connection: close
Content-Type: text/html

nochg [IP-Adresse]

...weil HTTP-Aufruf auch erlaubt ist.

 

[PeterPawn]

Ich würde mir eine universelle Syntax wie beispielsweise [...] mit gut dokumentierten Platzhaltern wünschen.

Hast Du es einfach mal ausprobiert? Die Platzhalter (inkl. Username/Password) sind ja dokumentiert, das einzige, was m.W. im Moment noch nicht beschrieben ist, ist der "ip6lanprefix"-Parameter (und zwei verschiedene Namen für das Kennwort: passwd/pass).

Die unterschiedlichen Accountdaten sind auch nicht zwingend zwischen unterschiedlichen Providern, wenn da z.B. eine E-Mail-Adresse als Benutzername und ein identisches Kennwort verwendet wird, sollte das schon klappen.

Mich irritiert ja nur die Schreibweise in dem einzelnen URL-Feld etwas - das man das auch so programmieren kann, habe ich nie bezweifelt. Wenn koy jetzt bestätigt hat, daß das tatsächlich so funktioniert, werde ich mir das demnächst mal ansehen ... ich finde dabei interessant, ob diese Syntax nur für "<userdefined>" oder auch für die anderen Einträge gilt. Der "benutzerdefinierte" Eintrag ist schon ein wenig anders in der Behandlung (die Angabe von HTTPS als Protokoll in der URL funktioniert z.B. bei "normalen" Einträgen im "server"- oder ip6server-Feld nicht) ... dabei könnte ich mir sogar vorstellen, daß die Variante mit Username/Password in der URL tatsächlich klappt, wenn das die StdLib entsprechend auflösen kann in einer höher abstrahierenden ("wget"-analogen bzw. meist heißen die dann HttpStream o.s.ä.) Funktion.

@koy:
Danke für den Test ... ich hatte nur nicht verstanden, daß das von AVM sogar so dokumentiert ist.

Ich werde demnächst mal testen, wie weit man das treiben kann (rein von der Anzahl der URLs her), denn das ist ja sogar eine weitere "Angriffsmöglichkeit" (halt in einem benutzerdefinierten Account versteckt, dafür aber sogar über das GUI zu erreichen).

Auch interessiert mich, ob der DynDNS-Client in vorauseilendem Gehorsam einen "www-authentication"-Header hinzufügt oder sich auf das Frage-Antwort-Spiel mit 401 im ersten Versuch einläßt. Die "vorauseilende Authentifizierung" kann dann ja eigentlich nur HTTP-Basic-Auth sein, wo Benutzername/Kennwort praktisch unverschlüsselt (nur B64-kodiert) übertragen werden. Die ansonsten noch mögliche Digest-Auth ist zwar auch nicht der Weisheit letzter Schluß, aber wenigstens ist das kein Klartext ... dafür braucht es aber mehrere "Anläufe" wegen der Nonce.

Ich persönlich werde aber weiter dabei bleiben, in der Box eigene Provider einzurichten und dann mit einem Array von Accounts zu arbeiten, da bei mir unterschiedliche Domain-Namen und unterschiedliche Server zum Einsatz kommen und durch die DynDNS-Registrierung gleich noch entsprechende Ports in den Server-Firewalls für die Clients freigeschaltet werden. Wenn das dann auch noch mit SSL möglich wäre, wäre ich schon zufrieden.

 

[GottSeth]

Danke für den Tipp .. leider nicht die Antwort auf meine Frage

Mit Verlaub - dein "Problem" kann so gelöst werden - und dein eigener Lösungsansatz ist Unsinn !

In etwa so, als wenn Du in einen Porsche noch Fahrradpedale für den Beifahrer einbauen wolltest :silly:

 

[PeterPawn]

Mit Verlaub - dein "Problem" kann so gelöst werden - und dein eigener Lösungsansatz ist Unsinn !

Dir ist aber schon bewußt, daß z.B. ein Apache-Server auf der FRITZ!Box mit "VirtualHostname" bei dem von Dir vorgeschlagenen Vorgehen mit CNAME-Einträgen nicht unbedingt zwischen den beiden Präsenzen unterscheiden könnte, weil das am Ende (hängt ein wenig vom Browser ab) mal auf denselben und mal auf unterschiedliche "Host"-Header im HTTP-Request hinauslaufen würde?

 

[alarbiere]

Der Protokollmitschnitt enthält für jede UpdateUrl ein GET und ein abschliessendes:
User-Agent: Fritz!Box DDNS/1.0.1
Connection: close

...

Ich habe das auch mal versucht. Ich habe 5 verschiedene DDNS Einträge bei demselben Provider (und aus technischen Gründen können dies keine Aliase/CNAME sein).
Hat leider nicht geklappt. Nur der erste Eintrag wurde berücksichtigt und ausgeführt.

Wäre wircklich toll gewesen wenn es geklappt hätte.

 

[koyaanisqatsi]

Moin

Das mit dem DynDNS Update in der Fritz!Box klappt bei mir am Besten so...
1. Aktualisierung: Ganz Normal einmal für IPv4 & 6
2. 1. Update URL (IPv4) die <domain> ändern auf zweiten Hostnamen.
3. Übernehmen klicken, deaktivieren, wieder Übernehmen, aktivieren, Übernehmen.
4. Jetzt sind 2x IPv4 und 1x IPv6 aktuell, ohne Fehlermeldungen im Log.

Ich weiss, Punkt 3. liest sich komisch, aber so klappt es.
Viel zu umständlich für mich, dafür würde ich ein Skript schreiben, wenn ich es denn brauchen würde.

 

[Benares]

Hast Du es einfach mal ausprobiert?

Nein, hab ich nicht. Die Syntax "userass@host" ist frei erfunden, bzw. hab ich so schon bei wget o.ä. gesehen.
Ich werden aber mal etwas im Browser damit herumspielen, vielleicht klappt es ja.

 

[PeterPawn]

Das ist als Syntax in vielen Standard-Libraries möglich, damit dann - je nach Lib - auch in Browsern. Das führt auch nicht dazu, daß eine URL in dieser Form tatsächlich gesendet wird ... das wird vorher geparsed und dann mit den erkannten Bestandteilen ein passender HTTP-Request (bzw. was auch immer als Protokoll angegeben ist in der URL) generiert.

 

[Benares]

Ich hab es mal mit der hier beschriebenen Syntax direkt mit verschiedenen Browsern probiert (jeweils den Browser zuvor neu gestartet, damit da nicht noch eine Session offen ist)

Mit

https://<user>:<pass>@members.dyndns.org/nic/update?system=dyndns&hostname=<domain>&myip=<ip>&wildcard=NOCHG&mx=NOCHG&backmx=NOCHG

(Werte in <> jeweils ersetzt mit meinen aktuellen Daten) klappt es mit Chrome sofort. In Firefox bekomm ich ich eine Warnung, dass ich mich anmelden würde, danach klappt es aber. Nur der IE zickt und meldet eine ungültige Syntax ("Die Datei ... wurde nicht gefunden"). Laut Doku müsste es sogar gehen, bei <domain> gleich mehrere Namen (bis zu 20, durch Komma getrennt) anzugeben und die auf einen Schlag zu aktualisieren.

Als nächstes werde ich mir mal Infos zur Update-URL bei NO-IP besorgen und dann versuchen, beides in der FB zu kombinieren.

 

[PeterPawn]

Beim IE ist es "by design", daß er die userass@host-Syntax nicht kennt (früher war das mal anders).

In einer HTTP-URL können auch problemlos Variablennamen mehrfach angegeben werden:

www.mydomain.de/update?hostname=host1&hostname=host2&hostname=host3

ist eine gültige URL. Was daraus am Ende wird, legt die betreffende dynamische "Seite" fest, die da aufgerufen wird. Normalerweise wird in höheren Programmiersprachen dann kein Skalar, sondern ein Array für die Variable "hostname" erzeugt.

 

[koyaanisqatsi]

spdns.org

Ja, der Hammer.
Ich hab die Doku auch gelesen aber das...

Laut Doku müsste es sogar gehen, bei <domain> gleich mehrere Namen (bis zu 20, durch Komma getrennt) anzugeben

...ging irgendwie total an mir vorbei.

Das funktioniert superklasse, aber ans Limit von 20 trau ich mich nicht ran, darf ja nur Fünf haben, gratis.

Auch die Mischform geht: <domain>,meins.spdns.org&...u.s.w.
...sowas kann ich natürlich schon gebrauchen.

PS: Der Rückgabewert nochg IP bedeutet übrigens, dass keine Aktualisierung erfolgte, weil die IP noch gültig ist.

 

[Benares]

Bei NO-IP klappt es in Chrome mit

https://<user>:<pass>@dynupdate.no-ip.com/nic/update?hostname=<domain>&myip=<ip>

nun auch.

Als nächstes werde ich mal probieren, beides in der Fritzbox zu kombinieren - aber heute nicht mehr.

 

[Benares]

So, ich hab jetzt einiges probiert, mit/ohne https://, mit ohne user/password in den URLs, usw. Ich muss aber sagen, so richtig zuverlässig klappt es nicht. Mein letzter Stand war folgende Monster-Update-URL, bestehend aus 3 Teilen (mit Leerzeichen getrennt, hier als einzelne Zeilen dargestellt):

https://members.dyndns.org/nic/update?system=dyndns&hostname=[domain1],[domain2]&myip=<ipaddr>&wildcard=NOCHG&mx=NOCHG&backmx=NOCHG
https://members.dyndns.org/nic/update?system=dyndns&hostname=[domain1],[domain2]&myip=<ip6addr>&wildcard=NOCHG&mx=NOCHG&backmx=NOCHG
https://dynupdate.no-ip.com/nic/update?hostname=[domain3]&myip=<ipaddr>

Die Werte in [] sind fest eingetragene Hosts, zwei bei DynDNS, einer bei NO-IP. Username/Password ist bei DynDNS und NO-IP gleich, also hab ich's bei den URLs weggelassen und so eingetragen. DDNS-Update im NAS ist erstmal aus.

Bisherige Erkenntnisse nach einigen provozierten Trennungen:
Das Update der beide IPv4-Domains bei DynDNS klappt eigentlich immer, die zugehörigen IPv6 manchmal. NO-IP klappt so gut wie nie. Ich werde morgen noch etwas weitertesten (Reihenfolge z.B.), mach aber für heute erstmal Schluss.