Setup-Problem mit ddnss und ipv6

[beedaddy]

Hallo,

ich habe gestern einen Rasperry Pi aufgesetzt. In der Fritzbox habe ich die Ports 80 und 443 (nur IPv6) für den Pi freigeschaltet. Direkter Zugriff von Außen über die IPv6-Adresse funktioniert auch. Nun würde ich gerne ddnss gerne verwenden, damit ich auch über einen fqdn darauf zugreifen kann. Ich habe nun das Beispiel-Bashscript von ddnss.de so angepasst, dass das mit der IPv6-Adresse auch funktioniert. Jedenfalls wird, wenn sich die IPv6 ändert, diese bei ddnss auch aktualisiert.

Allerdings, zugreifen kann ich darauf heute (noch?) nicht. Firefox gibt mir die Meldung "Die Website ist nicht erreichbar" (DNS_PROBE_POSSIBLE). Ein `ping -6 mydomain.ddnss.de` sagt mir "Zu diesem Hostnamen gehört keine Adresse". Die Frage ist also, woran das noch liegen kann. Funktioniert so eine reine IPv6-Lösung gar nicht? Oder braucht es nur noch Geduld?

(Hintergrund, dass ich das nur über IPv6 machen möchte ist, dass an der FritzBox bereits für einen anderen Host diese Ports für IPv4 belegt sind und ich eigentlich den Aufwand gering halten wollte.)

Danke und Grüße
Martin

 

[Hagen2000]

Bei IPv6 hat jedes Gerät eine eigene, globale Adresse. D. h. Du musst die IPv6-Adresse des Raspberry Pi bei ddnss hinterlegen und nicht die der FRITZ!Box. Also musst Du entweder den DDNS-Update auf dem Raspberry Pi laufen lassen, oder aber Du nutzt statt dessen eine MyFRITZ!-Freigabe (dafür musst Du dich aber bei MyFRITZ! registrieren).
Alternativ könntest Du die Namensauflösung auch mit einem dig AAAA mydomain.ddnss.de analysieren.

 

[beedaddy]

Danke, ja, da habe ich mich wohl nicht verständlich ausgedrückt; dass die IP-Adresse vom Pi kommen muss, ist mir klar. Sie wird auch übermittelt. Und wenn ich direkt über diese IP zugreife, funktioniert es auch.

Die Ausgabe von dig kann ich leider nicht so recht deuten:

; <<>> DiG 9.20.15 <<>> AAAA myhost.ddnss.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50796
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;myhost.ddnss.de.            IN    AAAA

;; Query time: 303 msec
;; SERVER: 192.168.178.1#53(192.168.178.1) (UDP)
;; WHEN: Sat Oct 25 13:09:34 CEST 2025
;; MSG SIZE  rcvd: 31

 

[sonyKatze]

Die ist leer, also keine IPv6 hinterlegt. Wenn Du +short angibst, wird es lesbarer.

Ich habe nun das Beispiel-Bashscript von ddnss.de so angepasst, dass das mit der IPv6-Adresse auch funktioniert. Jedenfalls wird, wenn sich die IPv6 ändert, diese bei ddnss auch aktualisiert.

Welchen Status bekommst Du zurück? Und welche IPv6-Adresse wird übergeben, eine LLA, ULA oder GUA?

 

[Hagen2000]

Naja, sein Gerätename wird ja nicht „myhost“ lauten, da muss schon der richtige Name eingesetzt werden. Und ja, mit +short wird es übersichtlicher, aber in der Zeile mit AAAA sollte die IPv6-Adresse deines Pi auftauchen, also beginnend mit 2000:xxxx - 3fff:xxxx.

 

[BenaresNeu]

Hast du eine Ausnahme beim DNS-Rebind-Schutz eingetragen?

 

[Hagen2000]

Sehr wichtige Einstellung, sonst funktioniert die DNS-Abfrage nicht im eigenen Netz, vergisst man immer wieder.

 

[beedaddy]

Die ist leer, also keine IPv6 hinterlegt. Wenn Du +short angibst, wird es lesbarer.

Stimmt, da ist die Ausgabe überschaubar, sprich leer.

Welchen Status bekommst Du zurück?

Vom Bash-Skript? 0.

Und welche IPv6-Adresse wird übergeben, eine LLA, ULA oder GUA?

Laut FritzBox ist es die "IPv6-GUA-Temporary".

Hast du eine Ausnahme beim DNS-Rebind-Schutz eingetragen?

Bingo! Ich glaube das war es! Lustig, denn ich hatte das ja für den anderen Rechner (damals) auch gemacht … und nun völlig vergessen. Danke!

 

[BenaresNeu]

Laut FritzBox ist es die "IPv6-GUA-Temporary".

Hoffentlich zeigt da die Fritte keinen Schrott an. Ich habe auch Geräte bei denen die IPv6-GUA (die mit ff:fe drin, die brauchst du) als "IPv6-GUA-Temporary" angezeigt wird. Bei anderen stimmt es.

 

[beedaddy]

Das eigentliche Problem ist gelöst, danke nochmals.

(Caddy hat allerdings noch Probleme mit Let's Encrypt/ZeroSSL. Ob das mit IPv6-only überhaupt geht? Aber das ist ein anderes Problem.)

 

[Hagen2000]

Laut FritzBox ist es die "IPv6-GUA-Temporary".

Dann sind vermutlich die IPv6-Privacy-Extensions oder RFC 7217 noch aktiv. Diese lassen sich unter Debian Bookworm durch Erstellen folgender Datei abschalten:

sudo vim /etc/NetworkManager/conf.d/no-privacy.conf

Folgende Zeilen dort eintragen:

[connection]
ipv6.ip6-privacy=0
ipv6.addr-gen-mode=0

Edit: RFC 7217 ergänzt.

 

[BenaresNeu]

Muss man das? Ist die Privacy-Extension nicht immer nur eine zusätzliche, temporäre IPv6 über die man ins Internet geht?

 

[Hagen2000]

M. E. ist die alternativ, zumindest hat mein Pi nur die eine öffentliche IPv6-Adresse.
Ob es zwingend erforderlich ist, die Privacy-Extensions abzuschalten, kann ich Dir jetzt auch nicht sagen. Könnte mir aber vorstellen, dass ein externer Zugriff stabiler funktioniert, wenn sich die Interface-Id nicht immer wieder ändert.
Nachtrag; Bei aktivierten Privacy-Extensions gibt es vermutlich immer wieder Phasen, in denen ein Gerät mehrere Adressen hat (mindestens die zuletzt benutzte und die aktuelle).
Edit: Typo

 

[BenaresNeu]

Mein Verständnis der Privacy-Extension ist die, dass man halt noch eine weitere IPv6 hat, über die man zwar rausgeht, aber über die man nicht erreichbar ist. Deshalb braucht es die "richtige" IPv6-GUA für DDNS. Richtig?
Dass ein Gerät so viele IPv6-Adressen für verschiedene Einsatzzwecke hat, verwirrt mich auch immer wieder. Meines Wissens wird eine bestehende Verbindung auch nicht getrennt, wenn es eine neue IPv6 gibt. Die alte IPv6 gilt einfach auch weiter, solange die Verbindung besteht.

 

[stoney]

Über welches Bash-Script geht es hier überhaupt genau?

Ich nutze den ddclient welcher gleich mehrere Anbieter mit jeweils mehreren Subdomains aktualisiert (noip.com und dynu.com) inzwischen auf einem RPi 5 - zuvor auf einem RPi 3, auf dem RPi 5 habe ich jedoch durch die Mehrleistung das ganze auf kleine Dokercontainer-Instanzen installiert, statt alles auf "Root" zu installieren (ich habe damals auf einen mir kostenlos für längere Zeit überlassenen vServer auf Debian ohne Desktop angefangen mich mit Linux zu beschäftigen und da waren die Mittel und Ressourcen eben begrenzt, sodass alles auf einer "Maschine" laufen musste).

Da muss man natürlich nochmals extra darauf achten welcher virutelle NIC verwendet wird und ob die IPv6 bis hin zur FRITZ!Box eben konsistent durchgereicht wird.

Wobei all dies ja keine wirkliche Rolle mehr spielt, da das Problem ja beim TE am Rebind-Schutz lag - ich habe dort überhaupt nichts eingetragen und erreiche sowohl rein lokal erreichbare Domains (zB pi.hole) sowie von drinnen nach draußen und wieder zurück (zB meine.nextcloud) alles.



//typo

 

[BenaresNeu]

Der DNS-Rebind-Schutz soll m.W. verhindern, dass externe Namen von der Fritte selbst in interne IPs aufgelöst werden.
Jetzt überleg mal selbst, was bei dir anders ist, damit du das nicht brauchst

 

[stoney]

Ja bitte, erkläre es mir, denn ich verstehe es leider nicht was anders sein sollte?

Falls du den PiHole meinst, das ging auch genauso als dieser nach einem SD-Karten-Ausfall und dem Umzug mit dem Pi3 auf eine HDD bzw. SSD dann lange nicht mehr im Einsatz war.

###

Wie man sieht, wird egal ob über den PiHole oder die FRITZ!Box aufgelöst wird immer kommt es immer zu selben Ergebnis, es werden die externen IPs aufgelöst.

 

[BenaresNeu]

Keine Ahnung, was dein pi.hole da treibt. Aber Fritten lösen externe Namen in interne IPs nur auf, wenn der Name beim DNS-Rebind-Schutz hinterlegt ist. Dazu ist diese Einstellung ja da.

 

[Hagen2000]

@stoney DNS-Abfragen der WAN-Adresse der FRITZ!Box selbst werden nicht geblockt, sondern nur DNS-Abfragen, die zu Geräten im Heimnetz führen (was beim TE ja der Fall ist).

 

[stoney]

@BenaresNeu
das habe ich schon verstanden, jedoch verstehe ich den Zusammenhang zum Topic dadurch nicht, denn der TE betreibt doch nichts anderes als ich auch und bei mir funktioniert es ohne DNS-Rebind, da zB meine Nextcloud im Moment nur erlaubten URLs überhaupt auf die Loginseite gelangen, da auf einem NIC ja auch durchaus mehrere Dienste laufen können und somit wird gewährleistet, dass nur Verbindungen angenommen werden, welche auch erlaubt/genehmigt sind.

@Hagen2000
dies ist doch auch bei mir gegeben oder wo sollte sich sonst mein RPi befinden, welcher hinter meiner FRITZ!Box über einen ddclient eigenständig seine DynDNS-Updates (alle 5 Minuten bei mir) pushed und die FRITZ!Box lediglich MyFRITZ! aktualisiert und ich nicht nicht mit MyFRITZ!Freigaben sondern eben mit Portweiterleitungen/freigaben arbeite.

Manchmal glaube ich, dass ich beim Thema DynDNS und externe Erreichbarkeit ein Unicorn hier bin ^^