[Network] IPv6-DNS aus RA/DHCPv6 beantwortet keine externen Anfragen (nur eigene Zone)

    Bug oder Feature?
    Kurz vorweg:
    Für Anwendungen, die den systemd-resolvd nutzen, sollte das (bis auf eine eventuelle kurze Verzögerung bis der Timeout da ist) eigentlich kein Problem sein.
    Betroffen sind nach meinen Tests:
    - reine IPv6-deployments
    - Anwendungen, die am OS-Stub vorbei resolven aber dafür den announcten Server nutzen wollen
    (- das Alpine Image, wenn man dhcpd nachinstalliert und per dhcpd -6 die IPv6 bezieht ... das überschreibt die resolv.conf mit dem nicht rekursiven IPv6 DNS und wirft die beiden IPv4 DNS Server raus)

    Problem:
    Anwendungen™️, die DNS rein über IPv6 abfragen wollen, fahren aktuell gegen die Wand.

    Die Plattform announct in jedem Netz drei DNS-Server an die VMs:

    • per DHCPv4: 94.16.16.16 und 94.16.16.94
    • per RA (RDNSS) und DHCPv6: die ULA-Adresse des Netz-Gateways (fdXX:…::1), mit DNS server lifetime: infinite

    Die beiden 94.16.16.x-Resolver funktionieren einwandfrei (UDP + TCP, extern + interne *.eos.local-Zone).
    Der per RA/DHCPv6 announcte Gateway-Resolver dagegen:

    Anfrage an fdXX::1Ergebnis
    Interne Zone, z. B. <vm>.<netz>.eos.local (A/AAAA)✅ Antwort
    Reverse-Lookup eigener Adressen (PTR)✅ Antwort
    Externe Namen (z. B. deb.debian.org)❌ Timeout (Anfrage wird verworfen, kein REFUSED)
    SOA der eigenen Zone❌ Timeout

    Das Gateway ist also ein reiner Zonen-Responder ohne Rekursion — wird aber via RDNSS/DHCPv6 als vollwertiger DNS-Server announct.


    Repro (auf einer Debian-13-VM):


    Vorschlag:

    Betrifft mich aktuell nicht stark, aber da IPv6 ja langsam doch einigermaßen relevant wird, würde ich entweder:

    1. den Gateway-Resolver rekursiv machen (zum beispiel durch Forwarding an 94.16.16.16/94), oder
    2. per RDNSS/DHCPv6 einen funktionierenden Recursor announcen (z. B. eine v6-erreichbare Adresse der 94.16.16.x-Resolver) und den Gateway-Responder nur zusätzlich für die Zone nutzen, oder
    3. falls das Verhalten so gewollt ist: eventuell dokumentieren (hab gesucht aber nichts gefunden)

    Viele Grüße

    Hi [netcup eos] Stephan P. ,

    Leider ist das Ergebniss eher inkonsistent.
    Vor etwa 2h waren etwa 50% der neu erstellen Netze DNS über IPv6-fähig.
    Jetzt funktioniert keins meiner neu angelegten Netze.
    Das "alte" geht noch mit dem gleichen IPv6 DNS Server.

    Wenn ich nachher aus dem Bett falle klappt sicher alles. :)

    Edited once, last by packettracer: ergänzung altes Netz mit gleichem Server (August 7, 2026 at 4:36 AM).

    Hi packettracer,

    danke nochmal für deine Rückmeldung. Der Quickfix greift also nur bedingt und wir müssen da noch einmal ran. Um dir eine realistische Perspektive zu geben: IPv6-only Support ist aktuell nicht Teil unserer Roadmap. Wir haben aktuell andere, dringendere Themen in Bearbeitung, weshalb wir das Thema nicht kurzfristig priorisieren können. Ich kann dir hier aber ein bisschen Hintergrundinformationen anbieten, was IPv6 auf der eos Platform betrifft.

    Unsere Platform ist grundlegend als Dual-Stack System konzipiert. Wir unterstützen sowohl IPv4 als auch IPv6 gleichermassen und vor allem gleichzeitig. Kein Nutzer soll sich für die eine oder andere Technologie entscheiden müssen, es soll beides funktionieren. IPv6-only haben wir dadurch in dieser Form auch nicht auf unserem Testplan, weil dies abseits der Standard-Konfigurationen liegt, die durch unsere Platform beim Anlegen einer VM vorgenommen werden.
    Als Cloud Platform sind wir all unseren Nutzern und deren Endnutzern weltweit verbunden und wollen, dass die durch uns bereitgestellten Services in möglichst jeder technischen Konfiguration von Endgeräten - unabhängig vom Standort - nutzbar sind. Dual-Stack ist dadurch ein Muss und erlaubt die Nutzung durch sowohl IPv4-only, Dual-Stack als auch IPv6-only Geräte überall auf der Welt.

    Auch wir würden uns wünschen, dass IPv6-only möglich wird, sind davon aber leider noch ein gutes Stück entfernt.
    Unsere Überlegungen dazu beruhen auf IPv6 Nutzungs-Statistiken wie der von Google (https://www.google.com/intl/en/ipv6/statistics.html). Diese ist im Vergleich zu anderen Statistiken tendenziell optimistisch, zeigt aber trotzdem auch: global liegt die Nutzung von IPv6 bei rund 50%, es gibt aber regional starke Unterschiede. Basierend auf den Daten mit Stand August 2026: Positive Beispiele in unserer regionalen Nähe sind Frankreich (86%) und Deutschland (76%) und negative Österreich (39%) und Italien (18%). Ein stark treibender Faktor sind dabei übrigens die marktbeherrschenden ISPs im jeweiligen Land, die es in der Hand haben, die IPv6-Nutzung zu erhöhen, indem sie ihren Kunden IPv6-enabled Anschlüsse bereitstellen - was diesen starken Unterschied zwischen den Ländern erklärt.
    Wir würden ohne IPv4 - egal in welcher Konstellation - also Endkunden, die einen Dienst nutzen, der über unsere Platform bereitgestellt wird, eine schlechte Erfahrung bereiten. Unsere Lösung ist also Dual-Stack und auf dieser liegt unser Fokus.

    Hi [netcup eos] Stephan P. ,

    Vielen Dank für den detailierten Einblick. :)
    Zwei Gedanken:
    - In Deutschland ist es andersrum, bei Vodafone zum beispiel bekommt man (zumindest im Kabel) erstmal nur eine IPv6 - Vodafones interpretation von DS Light ist manchmal ... interessant
    - In Zeiten von IPv4-shortage (bei euch anscheinend erfreulicherweise nicht :D) sollte es meine Entscheidung als Admin sein, auf eine IPv4 gänzlich verzichten zu können, wenn ich weiß (oder denke zu wissen) dass es kein problem sein wird. Mein Hauptargument (später): kosten ;)
    -> ein bisschen in die Richtung von: dem post

    Aber erstmal alles fair.
    Leider ist auch Dual Stack aktuell kaputt.

    Ich weiß nicht, ob ich heute Nach halluziniert habe - aktuell funktioniert zwar die DNS auflösung wieder - aber traffic geht bei den meisten nicht übers gateway hinaus.
    In 4 von 64 heute (Nacht ausgenommen) generierten Netzen funktioniert IPv6 Outgoing und Incoming.
    In den anderen Netzen geht weder rein noch raus via IPv6.
    Wenn man Glück hat ist das erzeugte "Netz" bei einer dedicated IPv6 funktionsfähig.

    Outgoing:

    ausgehende VerbindungServer A – Netz B (defekt)Server B – Netz B (defekt)Server C – Netz A (intakt)
    IPv4✅ über ded. IP ✅ über Netz-Auto-IP ✅ über ded. IP
    Dual-Stack-Ziel (http://www.google.com/)✅ 0,42 s (Fallback auf v4)✅ 0,42 s (Fallback auf v4)✅ 0,48 s
    ICMPv6 (ping6 2606:4700:4700::1111)❌❌ ✅
    TCP über IPv6 (curl -6 ifconfig.co)❌ Timeout❌ Timeout✅
    AAAA-only-Ziel (ipv6.google.com, ohne -6-Flag)❌ 12 s Timeout❌ 12 s Timeout✅ HTTP 200 in 0,36 s
    DNS-AAAA-Auflösung (getent)✅✅✅

    Incoming:

    eingehende VerbindungServer A – Netz B (defekt)Server B – Netz B (defekt)Server C – Netz A (intakt)
    IPv4✅ ~0,22 s✅ ~0,21 s✅ über ded. IP, ~0,25 s
    IPv6❌ Port-Forward: 0/12 – nur Timeouts❌ ded. IPv6: 0/12 – nur Timeouts✅ ded. IPv6: Erfolg in <0,1 s
    ✅ Port-Forward: Erfolg in <0,1 s
    Kontrolle: IPv6 des Testclients✅✅✅ (HTTPS via v6 zu one.one.one.one 0,9 s; DNS-Query an 2606:4700:4700::1111 0,1 s)


    Ich lese aber aus deiner letzten Nachricht raus, dass ihr schon dran seid. :)

    gruß

    • New

    Hallo zusammen,

    ich kann das Routing-Problem auf einem weiteren Block bestätigen und habe noch einen
    Messwert beizutragen, der die Fehlerstelle etwas eingrenzt.

    Setup: 5 vServer mit Debian 13, alle im selben Netzwerk im Block "at-preview1-da".
    Jede VM hat eine öffentliche IPv6-Adresse zugewiesen, Status im Panel "ready".
    Die ACL ist eine einzige Allow-All-Regel, scheidet als Ursache also aus.

    Was funktioniert:

    - VM zu VM über die ULA-Adressen: 0 % Paketverlust.
    - Und das halte ich für den interessanten Teil: eine VM kann die gemappte
    ÖFFENTLICHE IPv6-Adresse einer anderen VM im selben Block anpingen —
    0 % Paketverlust, ~6 ms. Das 1:1-Mapping der öffentlichen Adressen
    funktioniert also innerhalb des Blocks einwandfrei.

    Was nicht funktioniert:

    - Kein einziges externes IPv6-Ziel ist erreichbar: 2001:4860:4860::8888,
    2606:4700:4700::1111, 2620:fe::fe — durchweg 100 % Paketverlust.
    - curl -6 läuft zu jedem externen Host in den Timeout.
    - Das Link-Local-Gateway aus dem RA antwortet auf NDP (Status REACHABLE),
    aber nie auf ICMPv6-Echo.
    - Die Upstream-Gateway-Adresse einen Hop dahinter ist ebenfalls nicht erreichbar.

    Auf der Gastseite ist alles sauber: disable_ipv6=0, accept_ra=1, IPv4 (ebenfalls
    genattet) läuft völlig problemlos. Die AAAA-Auflösung funktioniert bei mir übrigens
    auch, weil die VMs über die IPv4-Resolver auflösen — das DNS-Thema aus dem ersten
    Beitrag trifft mich also nicht, das Routing-Thema dafür umso mehr.

    Damit deckt sich mein Bild mit dem, was packettracer beschrieben hat: der Traffic
    kommt schlicht nicht über das Gateway hinaus. Da das Mapping innerhalb des Blocks
    nachweislich sauber greift und erst danach nichts mehr weitergeht, würde ich die
    Ursache oberhalb des Blocks vermuten — also beim IPv6-Upstream-Routing bzw. Transit,
    nicht bei der Adresszuweisung oder beim Mapping.

    [netcup eos] Stephan P.: Gibt es dazu einen Zwischenstand? Der letzte Hinweis hier
    ist inzwischen gut eine Woche alt, und die Nachfrage vom 12.08. ist noch offen.
    Betrifft das nur bestimmte Blöcke, oder ist es blockübergreifend? Und macht es Sinn,
    das Netzwerk neu anzulegen — bei 4 von 64 funktionierenden Netzen klingt das nach
    einem Glücksspiel, aber falls es der einzige Weg ist, würde ich es versuchen.

    Weitere Messdaten liefere ich gerne nach, falls das beim Eingrenzen hilft.

    Viele Grüße

    • New

    Hallo zusammen,

    wir arbeiten nach wie vor noch aktiv an diesem Thema. Aufgrund der Fülle an Themen die wir aktuell bearbeiten sind wir hier noch nicht fertig. Um euch aber einen Ausblick zu geben: wir haben einen Fix dafür bereits vorbereitet und dieser wird vorraussichtlich Anfang kommender Woche den Weg auf at-preview1-da finden.

    Danke für eure Geduld.

    • New

    Hallo zusammen,

    der angekündigte Fix wurde gerade auf at-preview1-da angewendet. Es sollten damit alle Probleme mit IPv6 Adressen behoben sein, was ich zumindest bie all meinen Netzwerken nachvollziehen konnte. Ich würde mich über Rückmeldungen dazu freuen ob das wirklich alle betrifft oder ob wir noch ein zweites Fehlerbild haben, dass wir uns genauer ansehen müssen.

    • New
    Quote from [netcup eos] Stephan P.

    Hallo zusammen,

    der angekündigte Fix wurde gerade auf at-preview1-da angewendet. Es sollten damit alle Probleme mit IPv6 Adressen behoben sein, was ich zumindest bie all meinen Netzwerken nachvollziehen konnte. Ich würde mich über Rückmeldungen dazu freuen ob das wirklich alle betrifft oder ob wir noch ein zweites Fehlerbild haben, dass wir uns genauer ansehen müssen.

    Vielen Dank für den schnellen Fix und die Rückmeldung!

    Ich habe es gerade getestet und kann bestätigen, dass IPv6 bei mir jetzt wieder wie erwartet funktioniert. Das Problem scheint damit auf meiner Seite vollständig behoben zu sein.

    Vielen Dank für die schnelle Analyse und Behebung! 👍