Die Webseite öffnet sich im Büro und im eigenen WLAN ohne Auffälligkeiten. Trotzdem melden einzelne Mobilfunk- oder Unternehmensnutzer lange Ladezeiten und Verbindungsfehler. Ein DNS-Check zeigt neben dem bekannten A-Record zusätzlich einen AAAA-Record. Damit rückt ein zweiter, oft separat konfigurierter Zugangsweg in den Mittelpunkt: IPv6.
Ein AAAA-Record ist ein DNS-Eintrag, der einen Domain- oder Subdomainnamen auf eine IPv6-Adresse verweist. Er ist das IPv6-Gegenstück zum A-Record für IPv4. Moderne Domains können beide Record-Typen gleichzeitig veröffentlichen und dadurch grundsätzlich über IPv4 sowie IPv6 erreichbar sein.
Der DNS-Eintrag liefert jedoch nur eine Zieladresse. Ob die Webseite dort tatsächlich funktioniert, entscheiden erst Routing, Firewall, Server-Listener, TLS-Konfiguration, ein möglicher Proxy oder CDN-Dienst und die Anwendung. Genau diese Trennung erklärt, warum ein formal vorhandener AAAA-Record einen Dienst verbessern, aber bei falscher Konfiguration auch nur einen Teil der Nutzer aussperren kann.
AAAA-Record präzise erklärt: IPv6 im DNS neben dem A-Record
IPv4-Adressen bestehen technisch aus 32 Bit und erscheinen üblicherweise als vier Dezimalzahlen, beispielsweise 192.0.2.10. IPv6 verwendet 128 Bit und wird hexadezimal mit Doppelpunkten geschrieben, etwa 2001:db8::10. Die verkürzte Schreibweise mit zwei aufeinanderfolgenden Doppelpunkten fasst Nullblöcke zusammen. Entscheidend ist nicht die sichtbare Zahl der Zeichen, sondern die feste Bitlänge: IPv6 stellt einen erheblich größeren Adressraum als IPv4 bereit.
Ein A-Record ordnet einem Namen eine IPv4-Adresse zu. Ein AAAA-Record ordnet ihm eine einzelne IPv6-Adresse zu. Soll www.example.net über beide Protokolle erreichbar sein, kann der DNS-Bestand deshalb beispielsweise einen A-Record mit 192.0.2.10 und einen AAAA-Record mit 2001:db8::10 enthalten. Die verwendeten Adressen stammen aus reservierten Dokumentationsbereichen und stehen hier nicht für reale Server.
Pro Name sind auch mehrere A- oder AAAA-Records möglich. DNS kann dann mehrere mögliche Ziele zurückgeben, etwa für verteilte Server. Ein einzelner AAAA-Record enthält trotzdem nicht vier Teiladressen, sondern genau eine 128-Bit-IPv6-Adresse. Der Record-Typ ist standardisiert und wird in der IANA-Registrierung unter dem numerischen Typwert 28 als IPv6-Adresse geführt.
Im Betrieb heißt der Record häufig „Quad-A“. Als Eselsbrücke dient die Länge: Eine IPv6-Adresse umfasst mit 128 Bit das Vierfache der 32 Bit eines A-Records. Daher wird AAAA verbreitet als vierfaches A erklärt. Der maßgebliche Standard RFC 3596 definiert den Namen und das Datenformat, dokumentiert diese Herleitung aber nicht ausdrücklich als offizielle Etymologie.
DNS-Abfrage und Webseitenzugriff sind zwei verschiedene Tests
Der Inhalt einer DNS-Antwort sagt nichts darüber aus, über welche IP-Version die Abfrage übertragen wurde. Ein Resolver kann einen AAAA-Record über eine IPv4-Verbindung abfragen. Ebenso lässt sich ein A-Record über IPv6 ermitteln. Wenn ein Prüfwerkzeug eine IPv6-Adresse anzeigt, belegt dies deshalb nur, dass der Resolver einen entsprechenden DNS-Datensatz erhalten hat. Es beweist weder eine IPv6-Verbindung des prüfenden Geräts noch eine erreichbare Webseite.
Für eine belastbare Prüfung müssen Sie zwei Fragen getrennt beantworten: Liefert das DNS die beabsichtigte IPv6-Adresse, und lässt sich der Dienst über genau diesen IPv6-Pfad vollständig aufrufen? Erst der zweite Test erfasst Routing, Ports, TLS und Anwendung. Diese Trennung verhindert den häufigsten Diagnosefehler rund um AAAA-Records.
Dual Stack und Clientauswahl: Warum A und AAAA gemeinsam funktionieren müssen
Dual Stack bedeutet, dass ein Dienst über IPv4 und IPv6 vollständig kommunikationsfähig ist. Zwei DNS-Records allein reichen dafür nicht. Beide Protokollpfade benötigen nutzbare Adressen, Routing, erreichbare Ports, passende Sicherheitsregeln und eine Anwendung, die Anfragen korrekt verarbeitet. A und AAAA veröffentlichen lediglich die jeweiligen Ziele. Dual Stack entsteht erst durch die funktionierende Dienstkette hinter diesen Einträgen.
Wie Clients zwischen IPv6 und IPv4 auswählen
Erhält ein modernes Betriebssystem oder eine Anwendung A- und AAAA-Antworten, arbeitet es die Adressen nicht zwingend in der Reihenfolge der DNS-Ausgabe ab. Ziele werden nach lokalen Auswahlregeln sortiert. Dabei können Adressfamilie, Erreichbarkeit, Netzwerkschnittstelle, Richtlinien und frühere Verbindungswerte eine Rolle spielen. Eine pauschale Regel wie „Jeder Browser versucht immer zuerst IPv6“ wäre daher zu grob.
Happy Eyeballs Version 2 beschreibt ein Verfahren, das A- und AAAA-Ergebnisse zeitnah verarbeitet und Verbindungsversuche in kurzem Abstand startet. IPv6 erhält im beschriebenen Standardablauf eine Präferenz, ohne IPv4 unnötig lange zurückzuhalten. Reagiert ein Pfad nicht, kann ein weiterer Versuch über die andere Adressfamilie folgen. Konkrete Programme dürfen Verzögerungen, historische Messwerte und Sortierung unterschiedlich umsetzen. Deshalb lässt sich aus dem Verhalten eines einzelnen Browsers keine universelle Reihenfolge ableiten.
Bei einer gesunden Dual-Stack-Konfiguration fällt diese Auswahl kaum auf. Der Client verwendet einen erreichbaren Weg, der TLS-Handshake gelingt und der Webserver liefert für den angefragten Domainnamen dieselbe erwartete Webseite aus. Welcher IP-Pfad gewonnen hat, bleibt für Nutzer meist unsichtbar.
Konkreter Fehlerfall: IPv4 funktioniert, die veröffentlichte IPv6-Adresse nicht
Angenommen, der A-Record zeigt auf den aktuellen IPv4-Server, während der AAAA-Record noch eine alte, nicht mehr geroutete IPv6-Adresse enthält. Ein Client mit wirksamem IPv6 startet einen Verbindungsversuch zu dieser Adresse. Bleibt die Antwort aus, beginnt er abhängig von seiner Implementierung später einen IPv4-Versuch. Der zweite Weg funktioniert, doch der erste Versuch hat bereits Zeit gekostet.
Daraus können drei unterschiedliche Nutzererfahrungen entstehen. Ein Client fällt so schnell auf IPv4 zurück, dass keine Verzögerung auffällt. Ein anderer zeigt zunächst einen stockenden Seitenaufbau und lädt erst danach über IPv4. Ein dritter scheitert vollständig, etwa weil sein Fallback anders arbeitet, die Anwendung den ersten aufgebauten Pfad beibehält oder der Fehler erst nach dem Verbindungsaufbau bei TLS oder HTTP auftritt.
Deshalb melden möglicherweise nur Nutzer aus bestimmten Mobilfunk-, Unternehmens- oder Zugangsnetzen einen Ausfall. Geräte ohne nutzbares IPv6 fragen den AAAA-Record zwar unter Umständen ab, verwenden für die Webseite aber IPv4. Andere Netze stellen einen funktionierenden IPv6-Zugang bereit und führen den Client damit direkt zum defekten Ziel. Tests aus nur einem Netz bilden diese Unterschiede nicht zuverlässig ab.
Happy Eyeballs hilft hauptsächlich bei der Auswahl und beim Aufbau einer Verbindung. Das Verfahren repariert keinen falschen virtuellen Host, kein ungeeignetes Zertifikat und kein Backend, das nach erfolgreichem TLS-Handshake fehlerhaft antwortet. Auch spätere Probleme mit HTTP, Pfad-MTU, Proxy-Kommunikation oder Anwendungssitzungen können bestehen bleiben. Funktionierendes IPv4 kann einen solchen IPv6-Fehler im Alltag verdecken, beseitigt ihn aber nicht.
Überwachen Sie Dual-Stack-Dienste deshalb mit getrennten externen IPv4- und IPv6-Prüfungen. Ein gewöhnlicher Webseitencheck kann sonst einen erfolgreichen IPv4-Fallback melden, obwohl der veröffentlichte IPv6-Pfad seit Tagen ausfällt.
Defekten AAAA-Record systematisch finden: DNS, Netzwerk, TLS und Anwendung
Beginnen Sie nicht mit einer vorschnellen DNS-Löschung. Prüfen Sie den Datenweg in seiner tatsächlichen Reihenfolge: DNS-Antwort, veröffentlichte Adresse, Routing, Port, Firewall, Listener, TLS, HTTP und Anwendung. So erkennen Sie, ob der AAAA-Record selbst falsch ist oder lediglich auf einen Dienstpfad verweist, der an einer späteren Stelle ausfällt.
Mit dig www.example.net A und dig www.example.net AAAA lassen sich die DNS-Antworten trennen. Für den anschließenden Webseitenvergleich eignen sich beispielsweise curl --ipv4 https://www.example.net/ und curl --ipv6 https://www.example.net/. Diese Befehle setzen eine lokale Installation der Werkzeuge sowie einen tatsächlich nutzbaren IPv6-Zugang für den IPv6-Test voraus.
| Prüfebene | Konkreter Vergleichstest | Typisches Fehlerbild | Technische Einordnung | Nächste sichere Prüfung |
|---|---|---|---|---|
| DNS | Fragen Sie A und AAAA getrennt ab. Dokumentieren Sie Zieladressen und TTL. Vergleichen Sie bei Unstimmigkeiten den verwendeten rekursiven Resolver mit einem autoritativen Nameserver. | AAAA fehlt, verweist auf eine alte IPv6-Adresse oder unterscheidet sich je nach Resolver. | Der Fehler liegt in der DNS-Veröffentlichung, im Cache oder in einer noch nicht überall sichtbaren Änderung. In DNS64-Umgebungen kann ein rekursiver Resolver außerdem eine AAAA-Antwort synthetisieren. | Klären Sie, welches System die autoritative Zone verwaltet und welche Adresse der aktuelle Hosting-, CDN- oder Load-Balancer-Dienst tatsächlich verlangt. |
| Adresse und Routing | Vergleichen Sie die veröffentlichte IPv6-Adresse mit der dem Dienst zugewiesenen Adresse. Testen Sie den Pfad von einem externen Netz mit funktionsfähigem IPv6. | Die Adresse gehört zu einem früheren Server, wird nicht mehr angekündigt oder das Hosting stellt gar kein produktives IPv6 bereit. | Ein formal gültiger AAAA-Record kann auf ein nicht erreichbares Ziel zeigen. Ein lokaler Ping ist dafür kein ausreichender Gegenbeweis. | Lassen Sie sich IPv6-Zuweisung und externes Routing vom zuständigen Anbieter bestätigen. Veröffentlichen Sie keine frei gewählte oder nur intern sichtbare Adresse. |
| HTTPS-Transport | Rufen Sie denselben Domainnamen gezielt mit curl --ipv4 und curl --ipv6 auf. Vergleichen Sie Verbindungszeit, Fehlertext, Status und Antwort. | IPv4 liefert sofort eine Antwort, während IPv6 abbricht, hängen bleibt oder keine Verbindung aufbaut. | DNS hat eine Adresse geliefert, aber der IPv6-Dienstpfad scheitert vor oder während TCP beziehungsweise QUIC. | Prüfen Sie Port 443, Rückrouting, vorgeschaltete Filter und den Listener. Für unverschlüsseltes HTTP kann Port 80 ergänzend getestet werden. |
| Firewall und Sicherheitsgruppen | Kontrollieren Sie die Freigabewirkung für IPv6 an Host-Firewall, Netzwerk-Firewall, Cloud-Sicherheitsgruppe und vorgeschaltetem Anbieterfilter. | Port 443 ist über IPv4 offen, über IPv6 aber blockiert oder nur aus bestimmten Präfixen erreichbar. | IPv4- und IPv6-Regeln können getrennt gepflegt werden oder trotz gemeinsamer Oberfläche unterschiedlich wirken. Auch der Rückweg muss zugelassen und geroutet sein. | Verifizieren Sie die Regel gezielt für IPv6, das richtige Ziel, den richtigen Port und die korrekte Richtung. Übernehmen Sie IPv4-Regeln nicht ungeprüft. |
| Webserver oder Load Balancer | Prüfen Sie, auf welchen Adressen und Ports der Webserver, Reverse Proxy oder Load Balancer tatsächlich lauscht. | Das Betriebssystem besitzt eine IPv6-Adresse, der Dienst bindet jedoch nur an IPv4 oder an eine andere Schnittstelle. | Ein aktiver Netzwerkstack startet nicht automatisch einen IPv6-Listener. Syntax und Verhalten von Wildcard-Sockets unterscheiden sich je nach Serversoftware, Plattform und Version. | Prüfen Sie die offizielle Dokumentation Ihrer konkreten Software und kontrollieren Sie die aktiven Sockets nach einer validierten Konfigurationsänderung. |
| TLS und virtueller Host | Kontrollieren Sie über IPv6 das ausgelieferte Zertifikat, den angefragten Servernamen und den ausgewählten virtuellen Host. | Die TCP-Verbindung gelingt, aber der Client erhält ein fremdes Zertifikat, einen TLS-Fehler oder die Standardseite eines anderen Hosts. | Bei demselben Domainnamen ist normalerweise kein separates IPv6-Zertifikat erforderlich. Der IPv6-Endpunkt muss jedoch das zur Domain passende Zertifikat und die richtige Hostkonfiguration ausliefern. | Prüfen Sie SNI-Zuordnung, Zertifikatskette, Domainnamen und TLS-Terminierung am tatsächlich über IPv6 erreichten Endpunkt. |
| HTTP und Anwendung | Vergleichen Sie Statuscode, Weiterleitungen, Header und Inhalt beider Aufrufe. Testen Sie mehr als nur die Startseite, wenn Anmeldung oder API betroffen sind. | Der TLS-Handshake funktioniert, über IPv6 erscheinen aber Fehlerseiten, falsche Weiterleitungen oder anwendungsabhängige Abbrüche. | Die Transport- und TLS-Schicht ist erreichbar, doch virtueller Host, Anwendung, Sitzung, Datenbankzugriff oder eine nachgelagerte Abhängigkeit reagiert unterschiedlich. | Untersuchen Sie Webserver- und Anwendungsprotokolle mit Zeitstempel, Hostnamen und Quelladressfamilie. Prüfen Sie, ob die Anwendung IPv6-Adressen korrekt verarbeitet. |
| CDN, Proxy und Backend | Trennen Sie den öffentlichen IPv6-Endpunkt vom Origin. Prüfen Sie Edge-Antwort, Origin-Verbindung und interne Route als eigene Abschnitte. | Das CDN liefert ein korrektes Zertifikat, meldet danach aber einen Origin-Fehler oder gibt fehlerhafte Inhalte aus. | Ein funktionierender TLS-Endpunkt am Netzrand beweist nicht, dass das Backend erreichbar ist. Die CDN-Konfiguration kann für IPv6 unvollständig sein oder auf ein falsches Origin zeigen. | Kontrollieren Sie Origin-Adresse, Host-Header, Port, Zertifikatsprüfung und die vom Anbieter verwendete Protokollfamilie zwischen Edge und Backend. |
| Monitoring | Richten Sie getrennte externe Prüfungen ein, die IPv4 und IPv6 jeweils erzwingen und bis zur erwarteten HTTP-Antwort testen. | Das allgemeine Monitoring bleibt grün, obwohl IPv6-Nutzer Fehler melden. | Ein Check mit automatischem Fallback kann über IPv4 erfolgreich sein und den defekten IPv6-Pfad verdecken. | Alarmieren Sie pro Adressfamilie und prüfen Sie DNS, TLS, Statuscode sowie einen erwarteten Inhaltswert. Nutzen Sie möglichst mehr als einen externen Standort. |
Der sichere Ablauf bleibt damit überschaubar: Vergleichen Sie zuerst A, AAAA und TTL. Erzwingen Sie anschließend denselben HTTPS-Aufruf einmal über IPv4 und einmal über IPv6. Scheitert bereits der Verbindungsaufbau, untersuchen Sie Routing, Portfreigaben und Listener. Gelingt die Verbindung, folgen Zertifikat, virtueller Host, HTTP-Antwort, Proxy und Anwendung.
Was einzelne Testergebnisse tatsächlich beweisen
Eine erfolgreiche AAAA-Abfrage beweist ausschließlich, dass eine IPv6-Adresse aufgelöst wurde. Scheitert curl --ipv6 bereits beim Verbindungsaufbau, prüfen Sie nicht zuerst das Zertifikat, sondern Adresse, Routing, Firewall und Listener. Zeigt AAAA auf ein früheres Hostingziel, ist der DNS-Eintrag selbst wahrscheinlich die Ursache.
Ein erfolgreicher TCP-Verbindungsaufbau bestätigt nur die Erreichbarkeit des Ports. Erst der TLS-Handshake zeigt, ob der verschlüsselte Endpunkt für den Domainnamen korrekt konfiguriert ist. Selbst danach können HTTP und Anwendung scheitern. Prüfen Sie deshalb die erwartete Antwort und nicht nur, ob irgendeine Verbindung zustande kommt.
Auch Ping eignet sich höchstens als ergänzendes Signal. Ein Server kann ICMPv6 beantworten, während Port 443 blockiert ist. Umgekehrt kann ein Webdienst funktionieren, obwohl Echo-Anfragen gefiltert werden. Für die Webseiten-Erreichbarkeit bleibt der erzwungene Aufruf des echten Domainnamens über HTTPS der aussagekräftigere Test.
AAAA sicher betreiben oder entfernen: Firewall, Monitoring und häufige Fragen
IPv6 ist nicht allein aufgrund seines Adressformats unsicherer als IPv4. Es bildet jedoch einen eigenständigen Protokollpfad, der wirksames Routing, Filterregeln, Systemhärtung und Überwachung benötigt. Dual Stack erhöht damit die Zahl der zu betreibenden Wege. Eine Firewalloberfläche kann Regeln gemeinsam für beide Protokolle verwalten; entscheidend ist trotzdem, dass Sie die tatsächliche Freigabe- und Schutzwirkung für IPv4 und IPv6 separat testen.
AAAA beibehalten, reparieren oder vorübergehend entfernen
Treffen Sie die Entscheidung anhand des vollständigen Dienstpfads und nicht anhand des DNS-Eintrags allein:
- Beibehalten: Der AAAA-Record kann bestehen bleiben, wenn die Adresse aktuell ist und DNS, Routing, Firewall, TLS, Anwendung sowie externes IPv6-Monitoring zuverlässig funktionieren.
- Reparieren: Unterstützt die Plattform IPv6 grundsätzlich, beheben Sie eine klar eingegrenzte Störung wie eine falsche Firewall-Regel, einen fehlenden Listener oder eine unvollständige CDN-Zuordnung.
- Vorübergehend entfernen: Verursacht der IPv6-Pfad einen produktiven Ausfall und ist keine schnelle, sichere Reparatur möglich, kann das kontrollierte Entfernen des AAAA-Records die Störung begrenzen.
Dokumentieren Sie vor einer Änderung die bisherige IPv6-Adresse, die TTL, den zuständigen DNS-Dienst und mögliche CDN- oder Hostingabhängigkeiten. Bereits zwischengespeicherte Antworten verschwinden nicht sofort. Resolver dürfen einen Record grundsätzlich bis zum Ablauf seiner TTL verwenden; in bestimmten Ausnahmesituationen können sie zeitweise sogar abgelaufene Daten ausliefern. Eine Löschung wirkt deshalb nicht augenblicklich und weltweit.
Kein AAAA-Record ist für die Erreichbarkeit meist besser als ein AAAA-Record zu einem defekten IPv6-Pfad. Die Entfernung ersetzt jedoch keine geplante IPv6-Bereitstellung. Soll der Dienst wieder über Dual Stack laufen, veröffentlichen Sie die IPv6-Adresse erst nach einem externen Ende-zu-Ende-Test und richten Sie getrenntes Monitoring ein.
Häufige Fragen zum AAAA-Record
Was ist ein AAAA-Record?
Ein AAAA-Record ist ein DNS-Eintrag, der einen Domain- oder Subdomainnamen auf eine IPv6-Adresse verweist. Er veröffentlicht das IPv6-Ziel eines Namens, garantiert aber nicht, dass der dort angebotene Dienst vollständig funktioniert.
Warum heißt der Record AAAA?
Die verbreitete Erklärung lautet: IPv6-Adressen umfassen mit 128 Bit das Vierfache einer 32-Bit-IPv4-Adresse im A-Record. AAAA beziehungsweise Quad-A dient daher als einprägsame Herleitung. Der Standard selbst erläutert die Namensgeschichte nicht ausdrücklich.
Was ist der Unterschied zwischen A und AAAA?
Ein A-Record verweist einen Namen auf eine 32-Bit-IPv4-Adresse. Ein AAAA-Record verweist ihn auf eine 128-Bit-IPv6-Adresse. Beide können parallel für denselben Domainnamen vorhanden sein.
Braucht jede Webseite IPv6?
Eine allgemeine technische Pflicht, für jede Webseite einen AAAA-Record zu veröffentlichen, besteht nicht. IPv6 ist sinnvoll, wenn Hosting, CDN, Firewall und Anwendung diesen Pfad vollständig unterstützen und überwachen. Veröffentlichen Sie keinen AAAA-Record nur deshalb, weil das DNS-Formular ein entsprechendes Feld anbietet.
Was ist Dual Stack?
Dual Stack bezeichnet einen Dienst, der über IPv4 und IPv6 vollständig erreichbar ist. Dazu gehören nicht nur A- und AAAA-Records, sondern auch funktionierende Netzwerk-, Sicherheits-, TLS- und Anwendungskomponenten auf beiden Wegen.
Warum funktioniert meine Webseite nur bei manchen Nutzern nicht?
Die betroffenen Nutzer verwenden möglicherweise einen funktionierenden IPv6-Zugang und erreichen dadurch einen defekten IPv6-Pfad. Andere Geräte nutzen IPv4 oder wechseln schnell dorthin zurück. Unterschiedliche Netze, Clientregeln und Fallbackverfahren führen deshalb zu abweichenden Fehlerbildern.
Kann man einen AAAA-Record löschen?
Ja. Bei einem akuten IPv6-Ausfall kann die kontrollierte Entfernung eine sinnvolle Störungsbegrenzung sein. Prüfen Sie vorher Zuständigkeit, aktuelle Adresse, TTL und Abhängigkeiten. Wegen DNS-Caches erreicht die Änderung nicht sofort alle Nutzer.
Warum muss die Firewall IPv6 separat berücksichtigen?
IPv6-Verkehr nutzt einen eigenen Protokoll- und Routingpfad. Eine IPv4-Freigabe für Port 443 gilt daher nicht automatisch für IPv6. Selbst bei gemeinsam verwalteten Regeln müssen Sie prüfen, ob beide Adressfamilien dieselbe beabsichtigte Schutz- und Freigabewirkung erhalten.
Ein getesteter und über beide Adressfamilien überwachter AAAA-Record unterstützt einen belastbaren Dual-Stack-Dienst. Ein AAAA-Record zu einem nicht funktionierenden IPv6-Pfad verschlechtert dagegen die Erreichbarkeit. Prüfen Sie vor Veröffentlichung, Änderung oder Löschung stets DNS, Netzwerk, TLS und Anwendung als zusammenhängende Dienstkette.
Werbung
(**) UVP: Unverbindliche Preisempfehlung
Preise inkl. MwSt., zzgl. Versandkosten