Ich denke, die Wildcard-Logik ist FALSCH implementiert. Erstellt man eine IPv6 Subdomain, dann funktioniert der IPv4 Wildcard für diese Subdomain NICHT mehr. Das ist schlicht und einfach ein BUG, der nicht gefixt werden will oder kann.
Das würde ich mir auch wünschen. Ich aktualisieren meine Domain momentan nur mit der externen IPv4 des Routers, habe aber einige AAAA-Records, die auf die IPv6 meiner internen Geräte auflösen (z.B. ds1522.meinedomain.ipv64.net), weil sie den Prefix über ein Prefix-Update bekommen.
Bekommt man es irgendwie hin, dass bei Namensauflösung eines solchen Namens auch die IPv4 der Domain mitkommt?
Oder z.B. nur die IPv4 oder IPv6, indem man z.B. ipv4.ds1522.meinedomain.ipv64.net oder ipv6.ds1522.meinedomain.ipv64.net abfragt?
Dennis macht das ja auch so ähnlich bei ipv64.net selbst.
Mal daran gedacht eventuell ein kleines bash-Script zu schreiben und laufen zu lassen?
Ja natürlich, nur
- Das geht nicht immer so einfach, gerade wenn man mit docker containern arbeitet.
- Ändert das nicht an der Tatsache, dass die Wildcard-Logik bei ipv64.net einfach für mich nicht brauchbar ist und wie ich finde nicht so funktioniert wie ich es erwarten würden. Ganz einfaches Beispiel:
Ich würde bei folgender DNS Anfrage erwarten, dass 12.13.14.15 aufgelöst wird.
dig test.doraloe.ipv64.de A
Fakt ist, dass gar keine IP-Adresse aufgelöst wird.
(Man ist ja auch nicht gezwungen ipv64 zu nutzen. Ich einfach zu do.de gewechselt. Dort ist es korrekt implementiert. Oder man schreibt ein bash skript als workaround)
Zu 1:
Das ist nicht so einfach weil …?
Wenn du sowieso schon mit docker arbeitest, was spricht gegen einen weiteren Container, wenn du das Script nicht auf deinem Hostsystem laufen lassen möchtest?
Zu 2:
$ nslookup test.doraloe.ipv64.net
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: test.doraloe.ipv64.net
Address: 144.76.85.238
Name: test.doraloe.ipv64.net
Address: 2a01:4f8:192:1326::bad:c0de
$ nslookup test.doraloe.ipv64.net 8.8.8.8
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
Name: test.doraloe.ipv64.net
Address: 144.76.85.238
Name: test.doraloe.ipv64.net
Address: 2a01:4f8:192:1326::bad:c0de
Ich kann dir natürlich nicht sagen, ob die Antworten “korrekt” sind, aber zumindest sind sie da.
Entweder eine Kombination aus Caching und Ungeduld oder jemand hat seine DNS Infrastruktur nicht unter Kontrolle.
Das ist die Antwort, die immer kommt, wenn etwas nicht existiert. Dann werden die IPs von ipv64.net selbst geliefert.
Okay, dein Problem lässt sich grundsätzlich nachstellen:
Der Wildcard Record wird ignoriert, sobald du auf gleicher Ebene einen anderen Record anlegst.
bla.tld A 1.1.1.1
*.bla.tld A 1.1.1.1
foo.bla.tld AAAA 2a01::c0de
dig bla.tld A
-> 1.1.1.1 # wie erwartet
dig bla.tld AAAA
-> -/- # wie erwartet
dig bar.bla.tld A
-> 1.1.1.1 # wie erwartet
dig bar.bla.tld AAAA
-> -/- # wie erwartet
dig foo.bla.tld A
-> -/- # 1.1.1.1 erwartet
dig foo.bla.tld AAAA
-> 2a01::c0de # wie erwartet
Ich habe den RFC nur kurz überflogen und mir nicht die Diskussion über Existenz gegeben, aber ich zitiere mal Wikipedia:
A wildcard DNS record is a record in a DNS zone that will match requests for non-existent domain names.
dig foo.bla.tld A
→ foo.bla.tld existiert
→ Wildcard Regel nicht zulässig
→ foo.bla.tld hat keinen A Record
→ Ergebnis: -
dig bar.bla.tld A
→ bar.bla.tld existiert nicht
→ Wildcard Regel
→ *.bla.tld existiert
→ *.bla.tld hat einen A Record
→ Ergebnis: 1.1.1.1
Aus meiner Sicht ist das Verhalten also korrekt. Wohl gemerkt, habe ich mir die Diskussion über Existenz nicht in ihrer Gänze gegeben.
Damit wäre das Verhalten von PowerDNS bzw. @Dennis_Admin s Dienst korrekt.
Der Dienst, den du jetzt verwendest, @Benares, verhält sich scheinbar nicht Standard-konform.
Das kann zu Problemen führen und dazu, dass sich das von dir erwartete Verhalten mit einem Fix seitens des Betreibers jederzeit ändert.
Ein Wordaround für dein Problem wäre es aber auf Subdomains eben IPv4 wie auch IPv6 zu setzen.
Du hast recht. Auf Seite der DNS-Zones ist das Verhalten so korrekt. Ich habe wieder was gelernt. Ich war bisher der Überzeugung, dass die Wildcards pro „Typ“ gelten. Dem ist aber nicht so. Entschuldigt bitte meine Falsch-Aussage. Es gibt sogar ein RFC, dass die Rolle der Wildcards beschreibt - weil die Definition so unlogisch ist.
DynV6 löst das Problem so, dass man das „Daten-Feld“ für einen A-Record einer Subdomain einfach leer lässt. Dann wird die IPv4 der Zone verwendet. Das kommt dann im Endeffekt auf das gleiche heraus.
Ich habe mir nun folgendermaßen beholfen, keine Ahnung, ob das sauber ist, aber es funktioniert.
1.) DDNS-Update aktualisiert die Haupt-Domain irgendwas.ipv64.net nur mit IPv4 und IPv6-Prefix
2.) Interface-Identifier der internen Geräte (z.B. „ds1522“) als AAAA fest eingetragen mit Prefix aus dem Prefix-Update
3.) 2 CNAMEs, einmal „ipv4.ds1522“ als CNAME auf die Hauptdomain und „ipv6.ds1522“ als CNAME auf „ds1522“
4.) Da ich ipv64.net nicht direkt nutze, sondern nur als Zwischenlager in meiner eigentlichen Hauptdomain bei Netcup, kann ich jetzt frei entscheiden, ob ein Dienst, z.B. „nextcloud.meinedomain.com“, per weiterem CNAME entweder per IPv4 oder IPv6 zugreift.
Ist irgendwie von hinten durch die Brust ins Auge, aber hilft schonmal. Mein eigentlicher Wunsch, dass ich auch Namen habe, die auf die IPv4 der Domain und die IPv6 des Endgeräts zeigen, ist dadurch leider noch nicht erfüllt.
Die ursprüngliche Definition war nicht eindeutig genug. RFC 4592 dient primär dazu Unklarheiten zu beseitigen.
Unlogisch ist das allerdings nicht.
Bedenke, dass in einem DNS Namen jeder . eine Delegation an Verantwortlichkeiten darstellt/ darstellen kann. Wobei man natürlich in umgekehrter Richtung liest.
Damit der unter bla.tld. gesetzte A Record für foo.bla.tld. gültig wäre, müsstest du dich in falscher Richtung durch den Baum der Verantwortlichkeiten bewegen. Das wäre definitiv unlogisch.
Das System von DynV6 liest den übergeordneten Eintrag aus und setzt den A Record für die Subdomain dann aber auch nochmal systemisch. (Mutmaßung)
Ich verstehe immer noch nicht, wieso du nicht einfach IPv4 und IPv6 für die Subdomain pflegst.
Da bräuchte ich wohl zu viele Update-URLs. Meine Fritzbox kann maximal 2.
Oder wie meinst du das?
Updater examples > Example 4 zeigt dir, wie du mit einer URL IPv4 und IPv6 setzen kannst.
Alternativ kannst du natürlich auch mit jedem Script, das irgendwo laufen kann den Eintrag aktualisieren. Wenn du sowieso schon docker nutzt, kannst du das Script ja sogar in irgendeinem Container ausführen.
Aber das kenne ich doch. Nur habe ich bei der Fritzbox keine Platzhalter für die IPv6 meiner Endgeräte. Da gibt’s nur
...&ip=<ipaddr>&ip6=<ip6addr>&ipv6prefix=<ip6lanprefix>
und <ipv6addr> ist die externe IPv6 der Fritzbox selber, und die nützt mir nix. Also muss das über ein Prefix-Update laufen.
Und auch, wenn ein Script irgendwo anders laufen würde, müsste ich die Daten ja erstmal kennen. Ich habe 3 NASe mit Docker und Anwendungen drauf sowie einen Proxmox-Host auf dem auch einiges läuft.
Was heißt du muss “die Daten” erst mal kennen?
Du kennst die Domains die du bespielen willst, du kennst das Token von IPv64 und du wirst ja wohl deine öffentlichen IPs ermitteln können?!
Du verstehst mich nicht.
Die externe IPv4 wechselt täglich, der IPv6-Prefix auch. Das DDNS-Update klappt ja alles auch, nur ist mir halt die Kombination aus externer IPv4 und IPv6 der internen Geräte unter einem Namen noch nicht gelungen. Nur darum geht es hier.
Was genau ist denn dabei dein Problem?
Du willst für eine Subdomain IPv4 und IPv6 hinterlegen, richtig?
Dafür brauchst du:
- IPv64 Token
- Domain
- IPv4 Adresse
- IPv6 Subnetz
- IPv6 Präfix Länge
- statischem Anteil der IPv6 für dein Gerät
Bis auf IPv4, IPv6 Subnetz sollte alles immer bekannt sein.
Für die IPv4 Adresse oder (eine) IPv6 Addresse kannst du entweder sog. IP echo Dienste nutzen (z.B. https://www.ipify.org/) oder wenn du sowieso schon deine FritzBox Updates machen lässt, kannst du die Daten auch von der Domain abfragen, die du ohnehin up2date hältst.
Ja, am liebsten je eine für 1.) IPv4, 2.) IPv6 und 3.) kombiniert für jedes Gerät, um liebsten mit einem DDNS-Update.
1.) und 2.) habe ich inzwischen hinbekommen, nur halt 3.) bisher noch nicht.
Edit: Ich hab mir das mal bei DynV6 angeschaut, da scheint das wirklich einfacher zu gehen. Einfach nur zu jedem AAAA-Record für die Subdomain noch einen A-Record ohne Ziel anlegen, schon löst er auch die IPv4 auf.
Eigentlich geht es hier um eine Frage, die @RainerZufall gestellt hat und nicht um deine Frage.
Scheinbar versteht in 2025 niemand mehr, wie man Foren benutzt und dass man nicht einfach fremde Threads mit seinen eigenen Problemen hijacked.
Mit einem Update wird das nicht gehen.
Aber wie gesagt, bau dir doch einfach ein Script, das die Updates macht.
Da kannst du doch beliebig viele Updates auslösen.
Nehmen wir an, deine FritzBox pflegt den A und AAAA Record für fritz.myfoo.tld
DOMAIN="fritz.myfoo.tld" # enter your domain
PREFIX_LENGTH=56 # replace with your prefix length
IPV4_ADDRESS=$(dig "${DOMAIN}" A | grep "^${DOMAIN}." | sed -r "s/.+\s(.+)$/\1/g")
IPV6_ADDRESS=$(dig "${DOMAIN}" AAAA | grep "^${DOMAIN}." | sed -r "s/.+\s(.+)$/\1/g")
IPV6_PREFIX=$(subnetcalc "${IPV6_ADDRESS}/${PREFIX_LENGTH}" | grep "Network" | sed -r "s/.+ = ([^\s]+) \/ ${PREFIX_LENGTH}/\1/g")
IPV4_ADDRESS enthält jetzt deine öffentlich IPv4 Adresse, IPV6_PREFIX enthält dein IPv6 Präfix.
Mit den Update-Adressen, die Dennis zur Verfügung stellt, kannst du jetzt für weitere Domains passend die A und AAAA Records anpassen.