Ich meinte auch weniger die technischen Möglichkeiten, die eigene öffentliche IP-Adresse zu ermitteln, als vielmehr den
Browser und seine Beweggründe ... ich kenne bisher keine ins Auge springende Notwendigkeit, warum ein Browser einem Server explizit seine eigene (ggf. ja sogar mehrfache ge"NAT"ete) IP-Adresse übermitteln müßte.
EDIT: Und auch beim MyFRITZ!-Dienst prüft der DynDNS-Client vor dem Request die Notwendigkeit des Updates. Wie sollte das ansonsten aussehen? Nehmen wir mal an, es gäbe "nur" 864.000 FRITZ!Boxen mit MyFRITZ!-Konto an Anschlüssen mit Zwangstrennung. Selbst wenn dann jede dieser FRITZ!Box nur einmal am Tag einen solchen Request nach überstandener Trennung auslösen würde (was ja auf einem kaskadierten Router und Requests "auf Verdacht" eher unrealistisch - weil viel zu wenig - ist, wenn man zeitnah eine Änderung erreichen will), dann sind das immer noch 10 Request pro Sekunde am Server und das auch nur dann, wenn sich das tatsächlich gleichmäßig verteilt. Das dürfte auch eher nicht der Fall sein, denn garantiert liegt bei 95% dieser Boxen die selbst ausgelöste Zwangstrennung auch noch irgendwo in den Nachtstunden. Da braucht es garantiert nicht noch zusätzliche Last, nur weil ein Client seine eigene Adresse nicht selbst ermitteln kann oder will ... da kann ja der MyFRITZ!-Dienst nichts dafür. Selbst wenn so ein kaskadierter Router nur alle 5 Minuten einen Request senden würde, erzeugte er schon dieselbe Last wie 288 andere Geräte.
Ich würde mich als Anbieter eines DynDNS-Dienstes auch bedanken, wenn die Anzahl solcher Clients/Kunden nur groß genug ist ... da mit einem solchen Request ja auch auf der Serverseite noch entsprechende Aktionen verbunden sind, ist das eben etwas vollkommen anderes als das Ausliefern einer statischen HTTP-Seite.
Wenn man auf Server-Seite nicht prüft, ob das Update notwendig ist, belastet man die DNS-Server (solche Änderungen müssen ja auch noch auf sekundäre Server repliziert werden) ... wenn man es vorher prüft, belastet man die DNS-Server auch zusätzlich, denn man muß ja den gerade hinterlegten Wert dazu abfragen.
Warum sollte man das also auf einem Server machen, wo sich diese Anfragen/Aufgaben dann konzentrieren würden, wenn es der Client schon vorher machen kann und das auch nur für sich selbst und damit ohne nennenswerten Stress? Schon deshalb haben eben zumindest die großen Anbieter auch eine "abuse"-Sperre bei den Updates (max. n Updates pro Zeiteinheit), was gleichzeitig auch fälschlicherweise freidrehende DynDNS-Clients ausbremst. So eine FRITZ!Box ist eben nicht alleine und ich wäre schon froh, wenn der MyFRITZ!-DNS-Dienst als HA-Lösung ausgelegt sein sollte. Ob er dann gleichzeitig noch mit "Request-Bursts" klarkommen könnte, steht nochmal auf einem anderen Blatt. Der DynDNS-Client der FRITZ!Box ist jedenfalls recht geduldig, wenn so ein Update nicht gleich beim ersten Anlauf klappt.
Wenn Du unbedingt eine DynDNS-Lösung für einen solchen kaskadierten Router brauchst, kannst Du die ja problemlos selbst realisieren ... allerdings nur ohne den MyFRITZ!-Dienst, denn der redet nicht mit jedem, denn nicht jeder ist eine FRITZ!Box. Das Ermitteln der eigenen IP-Adresse - z.B. eben über einen STUN-Server - ist leicht erledigt und mit einem regelmäßigen "Polling" kriegt man dann auch als FRITZ!Box mit, wenn sich die externe Adresse ändert. Dann einen Update-Request auszulösen ist entsprechend simpel, bei den meisten Anbietern reicht ein "wget".
Spannender wird es dann schon bei der - von vielen solchen Lösungen vernachlässigten - Kontrolle des Update-Erfolgs ... es ist zwar schön, wenn der primäre DNS-Server die Adresse aktualisiert hat, aber die wenigsten "Nutzer" fragen direkt diesen PDNS ab und somit muß sich die Änderung dann auch erst einmal verbreiten. Bei einer TTL von einer bis zu fünf Minuten für einen solchen dynamischen DNS-Eintrag macht eine unmittelbar auf das Update folgende Kontrollabfrage der im Router hinterlegten DNS-Servers meist gar keinen Sinn, denn in aller Regel wird beim eigenen Provider (bzw. auf dessen DNS-Server, der bei den meisten Kunden verwendet werden dürfte) noch der Wert von der letzten Vergleichsabfrage im Cache vorliegen und für diesen muß nun erst einmal die TTL ablaufen, bevor sich der DNS-Server des Providers tatsächlich wieder nach einer aktualisierten Adresse umsieht. Also muß man schon beim Design einer solchen Kontrolle auch die TTL des aktualisierten DynDNS-Eintrags berücksichtigen (die kriegt man ja in der Antwort übermittelt,, meist aber als zu kleinen Wert, wenn der Eintrag nicht "frisch" ist und schon ein wenig im Cache des DNS-Servers liegt), ansonsten macht man wieder unnötige Updates (TTL 5 Minuten mit minütlichem Polling paßt eben nicht zusammen).
Das sieht auf den ersten Blick eben alles etwas simpler aus, als es am Ende tatsächlich ist, wenn man eine kooperative Lösung erhalten will, die nicht nur die eigenen Bedürfnisse im Blick hat. Zumindest als nennenswerter Router-Hersteller kann man sich einen "aufdringlichen" Client auch nicht leisten, sonst spielen ganz schnell die DynDNS-Anbieter nicht mehr mit und sperren im schlechtesten Fall solche Clients ganz aus (hatten wir meines Wissen schon desöfteren). Bei "Dyn" steht dann eben sogar explizit in den API-Beschreibungen:
All clients must send a well-formed user agent that includes company name, model number, and software build revision.
