A-Record für Subdomains

IPv64.net - Services
1

Hallo zusammen,

ich habe das Forum bereits durchsucht und bin auf mehrere ähnliche Threads gestoßen, die meinem Verständnis nach am Ende ohne echte Lösung geblieben sind. Deshalb frage ich noch einmal gezielt nach, ob ich bei ipv64 eine Konfigurationsmöglichkeit übersehen habe.

Bitte die folgenden Namen nur als Beispiel verstehen:

Mein Aufbau ist vereinfacht gesagt folgender:

Die FRITZ!Box aktualisiert bereits zuverlässig die öffentliche IPv4 und das IPv6-Präfix für example.ipv64.net. Für einen internen Server verwende ich zusätzlich einen Host wie server1.example.ipv64.net. Die IPv6-Seite dieses Hosts funktioniert grundsätzlich so, wie ich es möchte, also über Präfix plus Hostanteil.

Mein Problem betrifft den A-Record dieses Hosts:

Ich möchte, dass server1.example.ipv64.net automatisch dieselbe öffentliche IPv4 bekommt wie example.ipv64.net, ohne dass ich den A-Record bei jeder Adressänderung manuell nachziehen muss.

Wichtig ist dabei:
Die betroffenen öffentlichen Dienstnamen sollen am Ende denselben öffentlichen IPv4-Endpunkt nutzen. Es geht also gerade nicht darum, mehrere unterschiedliche öffentliche IPv4-Adressen zu pflegen, sondern darum, dass mehrere Namen auf denselben öffentlichen Endpunkt zeigen, während die IPv6-Seite hostbezogen aus dem Präfix abgeleitet wird.

Genau an dieser Stelle komme ich mit einem einfachen CNAME allein nicht sauber weiter:
Wenn ich app1.example.tld oder app2.example.tld per CNAME auf server1.example.ipv64.net zeigen lasse, dann hilft mir das nur dann vollständig, wenn server1.example.ipv64.net bereits sowohl den passenden AAAA-Record als auch den passenden A-Record hat. Der AAAA-Record ist in meinem Aufbau das kleinere Problem. Der A-Record von server1.example.ipv64.net wird aber nicht automatisch so nachgeführt, wie ich es brauche.

Wichtig:
Ich kann über die FRITZ!Box keine weiteren Skripte ausführen. Das bestehende DynDNS-/Präfix-Update der FRITZ!Box möchte und muss ich unbedingt beibehalten, weil es in meinem Aufbau die IPv6-Präfix-Aktualisierung sauber erledigt.

Ich habe mir deshalb inzwischen eine Behelfslösung gebaut:
Ein extern laufendes Skript vergleicht regelmäßig den öffentlichen A-Record von example.ipv64.net mit dem A-Record von server1.example.ipv64.net und ruft bei Abweichung den Update-Token für server1.example.ipv64.net auf. Das funktioniert inzwischen, ist aus meiner Sicht aber nur ein Workaround.

Der manuelle Aufruf des Tokens aktualisiert den A-Record übrigens sofort korrekt. Das Problem scheint also nicht der Record oder das Token selbst zu sein, sondern die fehlende Automatisierung dieses Falls.

Daher meine eigentlichen Fragen:

  1. Habe ich bei ipv64 eine Möglichkeit übersehen, den A-Record einer Subdomain bzw. eines Hosts automatisiert an die öffentliche IPv4 der Hauptdomain anzupassen, während der AAAA-Record weiterhin über Präfix und Hostanteil gebildet wird?

  2. Falls ich nichts übersehen habe: Gibt es Pläne, für genau diesen Fall in absehbarer Zeit eine eingebaute Lösung zu schaffen?

Mir geht es also um genau diesen Mischfall:

  • gleiche öffentliche IPv4 wie die Hauptdomain
  • aber eigene, hostbezogene IPv6-Ableitung aus dem Präfix

Falls ich einen Denkfehler habe oder eine vorhandene Funktion falsch verstehe, wäre ich für einen Hinweis dankbar.

Viele Grüße

2

Dat wurr in de vergangen Maanden hier in dat Forum all utführlich besnackt.

3

Ich schrieb ja,

Danke, aber genau das hatte ich in meinem Beitrag bereits geschrieben: Ich habe das Forum vorher durchsucht und bin auf mehrere ähnliche Diskussionen gestoßen, die aus meiner Sicht ohne konkrete Lösung endeten. Wenn es inzwischen einen Thread mit einem belastbaren Ergebnis gibt, verlinke ihn bitte. Sonst bleibt der Hinweis leider zu pauschal, um praktisch weiterzuhelfen.

4

Hi, klingt nach meinem Problem: Update in einem Call möglich? sub.home64.de und pre.sub.home64.de, selbe IPv4, unterschiedliche IPv6 - #9 von Gl1der .

Bisherige Erkenntnis: der Fall scheint nicht vorgesehen oder dokumentiert zu sein. Würde mir die Integration dieses “Features” auch wünschen.

Meine bisherige Lösung: FRITZ!Box klopft gar nicht mehr bei IPv64.net, sondern auf meinem Server (nur billiger Webspace mit PHP) an, und übermittelt einfach sämtliche benötigten Daten (IPv4, IPv6 der Box, IPv6-Präfix, auf Wunsch auch noch Weiteres, man kann die URL ja frei gestalten und auf dem Webspace parsen). Dort läuft ein Skript, welches dann die einzelnen Updates bei IPv64.net ausführt (ist ja nur ne URL abrufen, und die richtigen URLs werden eben von dem Skript zusammengebaut - hier könnte man dann auch die Record-Keys “hardcoden”, oder man übergibt den Domain-Key (oder Account-Key) als “Passwort” aus der FRITZ!Box).

Das Skript meldet dann das Ergebnis seines ersten Updates (“good”, “nochg”…) an die FRITZ!Box zurück (und loggt sämtliche Aufrufe mit URL und JSON-Ergebnis von IPv64.net).

Derzeit versuche ich (bzw. die KI mit meinen blauäugigen Prompts) noch, das Skript so anzupassen, dass es zunächst einmal eine DNS-Anfrage macht, um herauszufinden, ob überhaupt ein Update nötig ist (weil wohl auch nochg gegen das Updatelimit zählt). Aber ich hab auch nicht den ganzen Tag zeit, das ist work in progress. Und das Skript achtet eigentlich auch auf das Maximal-3-Updates-in-10-Sekunden-Limit, aber das habe ich (also die KI) wohl bei einer der letzten Änderungen zerschossen… (das Skript ist ohnehin bisher ein heilloses durcheinander mit verschiedensten Fragmenten, übrig gelassenen alten Codeschnipseln, auskommentierten Funktionen, die ich wahrscheinlich nie wieder brauchen werde, und täglich wird’s noch schlimmer… aber die Grundfunktionalität ist gegeben).

Ach, jüngste Beobachtung: wenn man mit einem Aufruf nur das IPv6-Präfix aktualisieren will, dann sollte man wohl &onlyprefix mit übergeben. Denn auch wenn man keine IPv4 mitsendet, ermittelt IPv64 diese wohl anhand des Aufrufs, und aktualisiert diese auch - mit der des Skript-Servers. Damit wird dann wohl auch eine nur Sekunden vorher “korrekt” auf die der FRITZ!Box gesetzte IPv4 überschrieben. Aber: still more testing needed.

Vorteil einer solchen Lösung meines Erachtens jedenfalls: Updates werden nur ausgeführt, wenn sich an den IPs der FRITZ!Box auch wirklich etwas ändert. Also nicht nach cron-Zeitplan, der x Mal am Tag läuft, aber dann doch vielleicht erst 20 Minuten nach einer Änderung. Und welche Updates ausgeführt werden, kann ich frei bestimmen. Ich könnte auch andere DynDNS-Anbieter (mit URL-Update-Möglichkeit) einbinden. Und mit der vorherigen DNS-Abfrage (wenn sie funktioniert), wird auch kein Update ausgeführt, falls z. B. Teile gleich bleiben sollten. Die FRITZ!Box führt (gut zu Testzwecken) nämlich nach meinen Beobachtungen auch ein Update nach Änderung “ihrer” DynDNS-URL (oder anderen Daten von der Seite) aus.

In deinem Fall könnte so etwas auch klappen, wenn du doch bereit wärst, die URL in der FRITZ!Box (einmalig) zu ändern, und den bisher gut funktionierenden Aufruf eben von deinem Skript erledigen ließest. Es ist jetzt ja auch nicht so, dass es ein Hexenwerk wäre, ein “Backup” von deiner jetzigen URL (und ggf. Domain/Benutzername/Kennwort) in einer Textdatei anzulegen, um zum jetzigen Zustand zurückkehren zu können.

Tatsächlich aber bin ich weiterhin erstaunt, dass eine so nahe liegende Funktionalität nicht einfach bereits in IPv64.net integriert ist. Ich stelle aber natürlich hier keine Ansprüche - was da ist, ist ja schon extrem gut.

5

Hallo,

danke für die bisherigen Hinweise. Nach allem, was ich inzwischen aus den verlinkten Threads und den Antworten hier mitgenommen habe, verdichtet sich bei mir der Eindruck, dass dieser konkrete Fall derzeit weder sauber vorgesehen noch wirklich dokumentiert ist.

Zur Veranschaulichung noch einmal nur mit Beispielnamen:
Die FRITZ!Box aktualisiert zuverlässig eine Hauptdomain wie example.ipv64.net, also insbesondere die öffentliche IPv4 und das IPv6-Präfix. Zusätzlich gibt es einen Host wie server1.example.ipv64.net, der seinen AAAA-Record hostbezogen aus dem Präfix erhalten soll. Was mir fehlt, ist eine automatische Pflege des A-Records dieses Hosts, damit er dieselbe öffentliche IPv4 bekommt wie die Hauptdomain.

Der manuelle Aufruf des Tokens für den A-Record funktioniert sofort korrekt. Das Problem scheint also nicht der Record selbst zu sein, sondern die fehlende Automatisierung genau dieses Falls.

Ich habe mir dafür inzwischen eine externe Skriptlösung gebaut, die den A-Record nachzieht. Das funktioniert, ist aus meiner Sicht aber nur ein Workaround. Ich würde eine eingebaute Lösung innerhalb von ipv64.net klar bevorzugen.

Für mich ist dabei auch relevant, dass die FRITZ!Box nur einen DynDNS-Aufruf direkt bedienen kann. Genau deshalb möchte ich den bestehenden, funktionierenden Präfix-Update-Weg über die FRITZ!Box nicht aufgeben oder künstlich verbiegen. Mein Wunsch wäre vielmehr, dass ipv64.net diesen Mischfall direkt abbilden kann:
gleiche öffentliche IPv4 wie die Hauptdomain, aber eigener hostbezogener AAAA-Record aus dem Präfix.

Daher meine konkrete Frage an @Dennis_Admin:
Ist dieses Verhalten so gewollt, also dass ein solcher Hostname zwar sauber seinen AAAA-Record aus dem Präfix bekommen kann, der zugehörige A-Record aber nicht automatisch an die öffentliche IPv4 der Hauptdomain gekoppelt wird?

Und falls ja:
Gibt es Überlegungen, diesen Fall künftig direkt in ipv64.net zu lösen?

Aus Anwendersicht wirkt das nicht wie ein exotischer Sonderfall, sondern wie ein recht naheliegender Anwendungsfall. Die öffentliche IPv4 der Hauptdomain ist dem System ja bereits bekannt. Deshalb die höfliche Nachfrage, ob hier perspektivisch eine eingebaute Lösung vorgesehen ist.

Vielleicht noch als Hinweis:
Ich habe Unterstützer-Status. Es scheint also nicht um eine Einschränkung zu gehen, die nur kostenlose Nutzer betrifft, sondern eher um eine grundsätzliche Funktions- oder Designfrage.

Falls ich eine vorhandene Möglichkeit übersehen habe, wäre ich für einen konkreten Hinweis dankbar.

6

Ist eigentlich irgendwer von Euch mal auf den Gedanken gekommen, das Häkchen bei

  • Set wildcard (*.) automatically?

in ipv64 zu setzen, wenn nur ein AAAA-Record für einen oder mehrere Domain-Präfixe gesetzt wurde? Wäre doch mal angebracht zu testen, was das dann bewirkt. Wird dann entweder:

  • nur der A-Record per wildcard zu v4-Adresse am WAN aufgelöst und
  • der AAAA-Record weiterhin (wie es sinnvoll wäre) zur im Record gesetzte v6-Adresse hin aufgelöst oder aber
  • werden dann A-Record und AAAA-Record auf die jeweiligen IP-Adressen am WAN des Routers aufgelöst (was nicht sinnvoll wäre)?

Wer also für einen A-Record für Subdomains nach einer Lösung sucht (ich brauche da keine Lösung - da ich wegen CGNAT / DS-Lite gar keine A-Records habe) sollte das mal testen und das Ergebnis hier mitteilen.

7

Danke für den Hinweis. Das habe ich bereits geprüft: Das Häkchen bei „Set wildcard (*.) automatically?“ ist bei mir gesetzt.

Das von mir gesuchte Verhalten tritt damit aber nicht ein. Genau deshalb hatte ich die Frage hier gestellt.

Nach meinem Verständnis der FAQ sorgt die Wildcard-Funktion allgemein dafür, dass Wildcards für A- und AAAA-Einträge gesetzt werden bzw. weitere Unterebenen mit aufgelöst werden können. Genau die von mir gesuchte selektive Logik – also A-Record eines Hosts automatisch an die WAN-IPv4 der Hauptdomain koppeln, während der AAAA-Record dieses Hosts weiter hostbezogen aus Präfix und Hostanteil kommt – ist dort aber gerade nicht beschrieben.

Oder anders gesagt: Ein bloßes Aktivieren der Wildcard löst mein Problem nicht. Das habe ich bereits getestet.

Falls ich die Wirkung der Option falsch verstehe, wäre ich für eine konkrete Erläuterung dankbar, was sie in genau diesem Mischfall bewirken soll.

8

Also bei mir war das Häkchen auch jederzeit, bei all meinen Versuchen, an.

Hab dann jetzt gerade mal getestet, und einen pfsix.sub.home64.de angelegt, mit nur einem ::-AAAA-Record, ohne A-Record.

Ergebnis:

dig AAAA pfsix.sub.home64.de bringt (wie erwartet) die mit Prefix zusammengesetzte IPv6-Adresse,

dig A pfsix.sub.home64.de bringt kein Ergebnis. Und

nslookup pfsix.sub.home64.de bringt “***Can’t find pfsix.sub.home64.de: No answer”.

Während die Wildcard ansonsten problemlos funktioniert: gibt es keinen expliziten Record (weder A noch AAAA) für z. B. wldcrd.sub.home64.de, wird als A (richtigerweise) die IPv4, und als AAAA die IPv6 der FRITZ!Box (also nicht eine mit prefix zusammengesetzte - welche auch, gibt ja keinen ::-Eintrag zum Zusammensetzen) zurückgegeben (irgendwie auch nachvollziehbar, wenngleich von begrenztem Nutzen).

Also scheint es so zu sein, dass ein existenter AAAA-Record bei nicht existentem A-Record zum selben (Domain-)”Präfix” für den Nameserver wohl heißt, dass er nur den AAAA-Record, aber überhaupt keinen A-Record ausliefern soll.

Also, interessante Idee, aber leider: nein.