Ihre Website läuft über IPv4 – aber was sehen IPv6-Nutzer?
Ein AAAA-Record kann eine zweite Produktionsroute öffnen. So prüfen Sie DNS, Erreichbarkeit, TLS, Redirects und Sicherheitskontrollen getrennt für IPv4 und IPv6.
Ihre Website ist online, Monitoring ist grün und im eigenen WLAN funktioniert alles. Trotzdem meldet ein Kunde: Im Mobilfunknetz lädt die Seite nicht.
Eine mögliche Ursache liegt in einer Ebene, die bei Website-Checks oft nicht separat betrachtet wird: IPv4 und IPv6 können denselben Hostnamen über zwei unterschiedliche Produktionspfade ausliefern.
Ein A-Record veröffentlicht eine IPv4-Adresse. RFC 3596 definiert den AAAA-Record für IPv6-Adressen. Sobald beides existiert, teilt DNS Clients mit, dass der Host über beide Protokollfamilien erreichbar ist. Ob beide Wege tatsächlich dieselbe funktionierende Website liefern, ist eine andere Frage.
Happy Eyeballs kann Fehler verstecken – nicht beheben
Dual-Stack-Clients müssen zwischen möglichen IPv4- und IPv6-Zielen wählen. RFC 6724 beschreibt die Standard-Adressauswahl. RFC 8305 ergänzt mit Happy Eyeballs einen Ansatz, der A- und AAAA-Ergebnisse berücksichtigt und Verbindungsversuche so koordiniert, dass blockierte, defekte oder langsame Adresspfade möglichst wenig sichtbare Verzögerung verursachen.
Das ist gut für Nutzer. Für Betreiber kann es ein Problem verdecken. RFC 8305 behandelt ausdrücklich "Hostnames with Broken AAAA Records": Ein gültiger A-Record existiert, der AAAA-Record sieht plausibel aus, die IPv6-Adresse antwortet aber nicht. Als Ursachen nennt der Standard unter anderem Tippfehler in DNS, Routing-Blackholes und Service-Ausfälle.
Ein Browser kann in manchen Dual-Stack-Situationen auf IPv4 ausweichen. Das beweist nicht, dass IPv6 gesund ist. Auf IPv6-only- oder NAT64/DNS64-Netzen kann ein kaputter AAAA-Pfad außerdem deutlich problematischer werden.
Red Flag 1: A und AAAA führen zu unterschiedlichen Produktionsständen
Die beiden Adressen müssen nicht zum selben physischen Server gehören. Der ausgelieferte Dienst sollte aber bewusst äquivalent sein.
Ein typischer Migrationsfehler: Der A-Record wurde auf den neuen Hoster umgestellt, der AAAA-Record zeigt noch auf die alte Umgebung. Beide Server antworten weiterhin. Deshalb sieht niemand einen vollständigen Ausfall – unterschiedliche Nutzer bekommen nur unterschiedliche Releases.
Noch kritischer ist eine gespaltene Sicherheitsarchitektur: A zeigt auf CDN oder WAF, AAAA direkt auf den Origin. Dann können IPv4-Besucher Rate Limits, Bot-Schutz oder Edge-Header erhalten, während IPv6 einen Teil dieser Kontrollen umgeht. IPv6 ist dabei nicht das Sicherheitsproblem. Die inkonsistente Route ist es.
Red Flag 2: DNS funktioniert, HTTPS aber nicht
Ein AAAA-Record, der auf eine erreichbare Adresse zeigt, ist noch kein funktionierender Webdienst. Für beide Familien sollten mindestens geprüft werden:
- Erreichbarkeit auf Port 443,
- richtiger virtueller Host und SNI,
- gültiges Zertifikat und vollständige Kette,
- identische HTTP-zu-HTTPS-Weiterleitung,
- erwartetes Ziel für Apex-Domain und
www, - gleiche Anwendungsversion und zentrale Header.
Ein alter IPv6-Webserver kann erreichbar sein und trotzdem ein falsches Zertifikat oder eine frühere Website ausliefern. Ein DNS- oder Ping-Test bleibt dabei erstaunlich optimistisch.
Red Flag 3: "IPv6 aktiviert" ist kein Architekturplan
Ein Request kann durch mehrere Ebenen laufen: Browser → CDN → Load Balancer → Reverse Proxy → Anwendung. Nicht jede interne Strecke muss IPv6 verwenden. Entscheidend ist, dass klar ist, wo IPv6 terminiert und welche Komponente danach übernimmt.
AWS dokumentiert bei Route 53 getrennt, welche Ressourcen A- beziehungsweise AAAA-Records unterstützen; für CloudFront mit aktiviertem IPv6 werden beispielsweise A- und AAAA-Alias-Records verwendet. Der allgemeine Betriebsgrundsatz ist wichtiger als der Anbieter: DNS-Record, Zielressource und deren tatsächliche IPv6-Fähigkeit müssen zusammenpassen.
Red Flag 4: Firewall und Allowlist wurden nur über IPv4 geprüft
Netzwerkregeln werden oft separat gepflegt. Port 443 kann über IPv4 erlaubt sein, während die entsprechende IPv6-Regel fehlt. Umgekehrt kann eine administrative Route über IPv6 unbeabsichtigt offener sein.
Prüfen Sie deshalb:
- eingehende Regeln für beide Familien,
- Rate Limits und Abuse-Schutz,
- Proxy- und Client-IP-Erkennung,
- Logging von IPv6-Adressen,
- IP-basierte Allow- und Denylists,
- direkte Origin-Erreichbarkeit außerhalb des vorgesehenen CDN/WAF-Pfads.
Red Flag 5: Monitoring prüft nur "die Domain"
Ein Check auf https://example.de sagt nicht automatisch, welche Adressfamilie der Monitoring-Agent verwendet hat. Happy Eyeballs kann einen defekten Pfad sogar elegant umgehen.
Ein belastbarer Audit trennt deshalb drei Perspektiven:
DNS
Welche A- und AAAA-Antworten liefern die autoritativen Nameserver? Gibt es alte Ziele, unerwartete TTLs oder vergessene Subdomains?
Netzwerk
Lässt sich derselbe Host gezielt über IPv4 und gezielt über IPv6 verbinden?
Anwendung
Liefern beide Wege denselben erwarteten Status, Redirect, Release-Marker, TLS-Zustand und dieselben relevanten Sicherheitsheader?
Ein 200 OK reicht nicht, wenn IPv6 noch die Website vom letzten Quartal ausliefert.
Praktischer Dual-Stack-Check
- Inventarisieren Sie A-, AAAA-, CNAME- und Alias-Ziele für Apex,
www, App, API, Login, Checkout und andere kritische Hosts. - Erzwingen Sie Tests getrennt über IPv4 und IPv6, statt nur das Browser-Default zu verwenden.
- Vergleichen Sie TLS, Statuscodes, Redirect-Ketten, HTML beziehungsweise Release-Version, Cache- und Security-Header sowie CDN/WAF-Merkmale.
- Prüfen Sie den Fehlerfall: Was passiert, wenn nur der IPv6-Pfad ausfällt?
- Überwachen Sie wichtige Dienste mit mindestens einem IPv4- und einem IPv6-Check getrennt.
Abweichungen sind nicht automatisch falsch. Sie müssen aber beabsichtigt, dokumentiert und betreibbar sein.
Muss jede Website sofort IPv6 anbieten?
Nein. Ein sauberer IPv4-only-Dienst ist besser als ein halb konfigurierter Dual-Stack-Dienst. Wenn Ihre Infrastruktur IPv6 noch nicht zuverlässig unterstützt, ist es sinnvoller, keinen falschen AAAA-Record zu veröffentlichen, als Erreichbarkeit zu versprechen, die nicht existiert.
Umgekehrt gilt: Sobald ein AAAA-Record öffentlich ist, ist IPv6 Teil Ihrer Produktionsoberfläche.
Was Website-Pflichtencheck dabei prüfen würde
Bei einem Hosting- und Erreichbarkeitscheck können wir A- und AAAA-Auflösung getrennt inventarisieren, IPv4- und IPv6-Verbindungen unabhängig testen und vergleichen, ob TLS, Redirects, HTTP-Antworten, Sicherheitsheader sowie CDN- und Proxy-Verhalten übereinstimmen.
Zusätzlich lässt sich erkennen, ob alte IPv6-Ziele nach einer Migration übrig geblieben sind, ein AAAA-Record den vorgesehenen WAF-Pfad umgeht, Firewall-Regeln auseinanderlaufen oder das bestehende Monitoring einen Ausfall einer einzelnen Adressfamilie überhaupt bemerken würde.
Das Ziel ist nicht IPv6 um jeden Preis. Das Ziel ist eine klare Produktionsaussage: Jede Adresse, die Ihr DNS veröffentlicht, muss zu einer Route führen, die Sie kennen, überwachen und betreiben.
Wenn Ihre Website nur deshalb zuverlässig wirkt, weil Browser einen defekten Netzwerkpfad höflich umgehen, ist das keine Redundanzstrategie. Es ist ein Fehler, der gut versteckt wird.
Quellen
- RFC 3596: DNS Extensions to Support IP Version 6 — https://www.rfc-editor.org/rfc/rfc3596.html
- RFC 6724: Default Address Selection for Internet Protocol Version 6 — https://www.rfc-editor.org/rfc/rfc6724.html
- RFC 8305: Happy Eyeballs Version 2 — https://www.rfc-editor.org/rfc/rfc8305.html
- Amazon Route 53: Supported DNS record types — https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/ResourceRecordTypes.html