IPv6 DNS: AAAA Records, Dual-Stack Resolution und Best Practices

DNS ist der Punkt, an dem IPv6-Bereitstellungen erfolgreich sind oder scheitern. Veröffentlichen Sie einen AAAA Record, bevor Ihre IPv6-Konnektivität funktioniert, und Nutzer warten durch Timeouts. Überspringen Sie Reverse DNS, und Mailserver lehnen Ihren Traffic ab. Konfigurieren Sie Dual-Stack Resolution falsch, und Sie machen das Netzwerk langsamer statt schneller.

Dieser Leitfaden behandelt, wie DNS mit IPv6 funktioniert, was kaputt geht und wie Sie es beheben, bevor es zum Problem wird.

AAAA Records: IPv6s Antwort auf A Records#

Ein AAAA Record (ausgesprochen „Quad-A") ordnet einen Hostnamen einer IPv6-Adresse zu. Es ist das IPv6-Äquivalent eines A Records, enthält aber eine 128-Bit-Adresse anstelle von 32 Bits.

Format und Struktur#

example.com.    3600    IN    AAAA    2001:db8::1

Die Struktur entspricht A Records: Name, TTL, Klasse, Typ und Adresse. Die Adresse verwendet Standard-IPv6-Notation mit Doppelpunkten und Hexadezimalziffern.

Führende Nullen in jeder Gruppe können weggelassen werden, und aufeinanderfolgende Null-Gruppen werden zu :: komprimiert. Diese beiden sind gültig und identisch:

example.com.    IN    AAAA    2001:0db8:0000:0000:0000:0000:0000:0001
example.com.    IN    AAAA    2001:db8::1

Verwenden Sie das komprimierte Format. Es ist leichter zu lesen und weniger fehleranfällig beim Tippen.

Abfragen von AAAA Records#

Fragen Sie AAAA Records genauso ab wie A Records, geben Sie nur den Typ an.

Mit dig:

dig AAAA example.com
dig AAAA @2001:4860:4860::8888 example.com

Mit nslookup:

nslookup -type=AAAA example.com
nslookup -type=AAAA example.com 2001:4860:4860::8888

Mit host:

host -t AAAA example.com

Sie können auch unser DNS Lookup Tool verwenden, um sowohl A- als auch AAAA-Records gleichzeitig abzufragen und Ergebnisse zu vergleichen.

AAAA vs A Records#

Beide dienen demselben Zweck — Namen in Adressen übersetzen — unterscheiden sich aber in wichtigen Punkten:

A- und AAAA-Records sind vollständig unabhängig. Sie können unterschiedliche TTLs haben, auf verschiedene Server zeigen oder ohne den anderen existieren. Diese Flexibilität ist nützlich, schafft aber Möglichkeiten für Fehlkonfigurationen.

Dual-Stack DNS Resolution#

Die meisten Netzwerke laufen Dual-Stack: IPv4 und IPv6 funktionieren gleichzeitig. Wenn ein Client einen Hostnamen nachschlägt, erhält er sowohl A- als auch AAAA-Records. Das Betriebssystem entscheidet dann, welches zu verwenden ist.

Happy Eyeballs (RFC 8305)#

Moderne Betriebssysteme implementieren Happy Eyeballs, einen Algorithmus, der sowohl IPv4 als auch IPv6 versucht, aber IPv6 bevorzugt, wenn es funktioniert. Der Algorithmus:

1. Fragt DNS nach A- und AAAA-Records ab
2. Beginnt zuerst mit Verbindung zur IPv6-Adresse
3. Wartet 50-250ms (implementierungsabhängig)
4. Wenn IPv6 noch nicht verbunden ist, startet parallele IPv4-Verbindung
5. Verwendet die Verbindung, die zuerst fertig wird

Dieser Ansatz balanciert Performance mit Zuverlässigkeit. IPv6 bekommt Vorrang, aber defektes IPv6 blockiert Verbindungen nicht lange.

Auflösungsreihenfolge#

Die Reihenfolge, in der Clients Records abfragen und Verbindungen versuchen, variiert je nach OS und Konfiguration.

Die meisten Unix/Linux-Systeme:

• Fragen A und AAAA gleichzeitig oder AAAA zuerst ab
• Bevorzugen IPv6-Adressen, wenn sie existieren
• Gesteuert durch /etc/gai.conf (getaddrinfo-Konfiguration)

macOS:

• Fragt beide Record-Typen parallel ab
• Implementiert Happy Eyeballs strikt
• Bevorzugt IPv6 stark, wenn verfügbar

Windows:

• Fragt beide Record-Typen ab
• Bevorzugt IPv6 standardmäßig (konfigurierbar über Registry)
• Implementiert Happy Eyeballs ab Windows 8

Browser:

• Chrome und Firefox implementieren ihr eigenes Happy Eyeballs
• Verlassen sich nicht ausschließlich auf OS-Verhalten
• Können Auflösungsergebnisse aggressiv cachen

Wann IPv6 gewinnt (oder verliert)#

IPv6 gewinnt typischerweise das Rennen, wenn:

• IPv6-Konnektivität nativ ist (nicht getunnelt)
• IPv6-Routing direkt ist ohne zusätzliche Hops
• Das Ziel über IPv6 gut verbunden ist

IPv6 verliert, wenn:

• Es getunnelt ist (6to4, Teredo) mit zusätzlicher Latenz
• Routing längere Pfade als IPv4 nimmt
• Der Server über IPv6 schlecht verbunden ist
• Firewall- oder Middlebox-Probleme Verbindungen verlangsamen

Testen des Dual-Stack Verhaltens#

Erzwingen Sie IPv4 oder IPv6, um das Verhalten zu testen:

# IPv4 erzwingen
curl -4 https://example.com
 
# IPv6 erzwingen
curl -6 https://example.com
 
# OS wählen lassen
curl https://example.com

Vergleichen Sie Antwortzeiten. Wenn IPv6 signifikant langsamer ist, untersuchen Sie Routing- oder Konnektivitätsprobleme, bevor Sie AAAA Records weitreichend veröffentlichen.

DNS64 und NAT64#

DNS64 synthetisiert AAAA Records aus A Records und ermöglicht IPv6-only Netzwerken den Zugriff auf IPv4-only Dienste. Es arbeitet mit NAT64 zusammen, das Pakete zwischen IPv6 und IPv4 übersetzt.

Wie DNS64 funktioniert#

Wenn ein IPv6-only Client einen Hostnamen abfragt:

1. DNS64 Server empfängt die Abfrage
2. Prüft auf einen AAAA Record
3. Wenn AAAA existiert, gibt ihn normal zurück
4. Wenn nur ein A Record existiert, synthetisiert einen AAAA Record mit speziellem Präfix
5. Client verbindet sich zur synthetisierten IPv6-Adresse
6. NAT64 Gateway übersetzt die Verbindung zu IPv4

Das Well-Known Präfix: 64:ff9b::/96#

Das häufigste DNS64-Präfix ist 64:ff9b::/96, definiert in RFC 6052. Die letzten 32 Bits der Adresse betten die IPv4-Adresse ein.

Beispiel-Synthese:

A Record:    192.0.2.1
Präfix:      64:ff9b::/96
AAAA Record: 64:ff9b::192.0.2.1
             oder 64:ff9b::c000:201 (in Hex)

Einige Netzwerke verwenden andere Präfixe wie 2001:db8::/96 oder benutzerdefinierte Bereiche. Das Präfix muss konsistent auf DNS64 und NAT64 konfiguriert sein.

Wann Sie DNS64/NAT64 benötigen#

DNS64 ist essentiell für:

• IPv6-only Mobilfunknetze (üblich bei T-Mobile, AT&T)
• IPv6-only Rechenzentren, die auf Legacy-IPv4-Dienste zugreifen
• Testen von IPv6-only Client-Verhalten

Sie benötigen DNS64 nicht, wenn:

• Ihr Netzwerk Dual-Stack ist
• Alle Dienste, auf die Sie zugreifen, natives IPv6 haben
• Sie IPv6 auf allen Backend-Diensten vorschreiben können

Einschränkungen und Fallstricke#

DNS64 bricht mehrere Dinge:

DNSSEC-Validierung schlägt fehl – Der synthetisierte AAAA Record passt nicht zur signierten Zone. DNS64 Server müssen DNSSEC-Signaturen entfernen, was die Sicherheit reduziert.

Anwendungen, die IP-Adressen einbetten, brechen – Wenn eine Anwendung eine IPv4-Adresse in JSON, XML oder anderen Datenformaten erhält, wird DNS64 sie nicht übersetzen. Die App versucht, sich von einem IPv6-only Stack zu einer IPv4-Adresse zu verbinden und schlägt fehl.

Load Balancer und CDNs werden verwirrt – DNS64 lässt alle Clients von der Adresse des NAT64 Gateways kommen. Geolokalisierung, Rate Limiting und Client-Identifikation brechen.

Referrals und Redirects schlagen fehl – Wenn eine DNS-Antwort IPv4-Adressen in zusätzlichen Sektionen enthält (wie NS Glue Records), können Clients sie nicht erreichen.

Reverse DNS (PTR Records)#

Reverse DNS ordnet eine IPv6-Adresse zurück zu einem Hostnamen. Es ist nicht obligatorisch für Konnektivität, aber erforderlich für Mailserver und nützlich für Logging und Sicherheitstools.

Die ip6.arpa Zone#

IPv6 Reverse DNS verwendet die ip6.arpa Domain. Jedes Nibble (4 Bits oder eine Hexadezimalziffer) der Adresse wird ein Label im Domainnamen, in umgekehrter Reihenfolge geschrieben.

Adressen ins PTR-Format konvertieren#

Nehmen Sie die vollständige, unkomprimierte IPv6-Adresse, kehren Sie sie Nibble für Nibble um und hängen Sie ip6.arpa an.

Beispiel: 2001:db8::1

Schritt 1: In vollständige Form expandieren:

2001:0db8:0000:0000:0000:0000:0000:0001

Schritt 2: Alle Nibbles ausschreiben:

2 0 0 1 0 d b 8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1

Schritt 3: Reihenfolge umkehren:

1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 8 b d 0 1 0 0 2

Schritt 4: Mit Punkten trennen und ip6.arpa anhängen:

1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa

Das ist der PTR Record Name. Er zeigt auf Ihren Hostnamen.

Reverse DNS abfragen#

Mit dig und automatischer Konvertierung:

dig -x 2001:db8::1

PTR Record direkt abfragen:

dig PTR 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa

Mit host:

host 2001:db8::1

Reverse DNS delegieren#

Reverse DNS Zonen werden von Ihrem ISP oder RIR delegiert. Wenn Sie ein /48 haben, kontrollieren Sie einen /48-Wert an Reverse DNS Raum. Die meisten Anbieter lassen Sie ihn über eine Weboberfläche verwalten oder erlauben Ihnen, Ihre eigenen DNS-Server für die Reverse Zone zu betreiben.

Für kleinere Allokationen (wie ein /64) handhaben einige ISPs individuelle PTR Records für Sie. Kontaktieren Sie sie mit der Adresse und dem Hostnamen.

Häufige DNS-Fehler mit IPv6#

AAAA ohne funktionierendes IPv6 veröffentlichen#

Das ist der Fehler Nummer eins. Sie aktivieren IPv6 auf einem Server, erstellen den AAAA Record und nehmen an, es funktioniert. Aber wenn die Firewall IPv6 blockiert, Routing defekt ist oder der Server nicht wirklich auf IPv6 lauscht, warten Clients auf Timeouts.

Symptom: Langsame Website-Ladezeiten, besonders auf Mobilnetzen, die IPv6 bevorzugen.

Lösung: Testen Sie die Konnektivität von mehreren externen IPv6-Netzwerken, bevor Sie den AAAA Record veröffentlichen. Verwenden Sie unser Ping Tool, um Erreichbarkeit zu verifizieren.

Reverse DNS vergessen#

Forward DNS funktioniert gut, aber Sie überspringen Reverse DNS. Das bricht Mail-Zustellung, verwirrt Log-Analyse und wirkt unprofessionell.

Symptom: Mail-Ablehnung, „Reverse DNS lookup failed" Fehler.

Lösung: Richten Sie PTR Records für alle Serveradressen ein. Verifizieren Sie mit dig -x von mehreren Standorten.

TTL-Mismatch zwischen A und AAAA#

Ihr A Record hat einen 3600 Sekunden TTL, aber AAAA hat 300. Wenn Sie DNS aktualisieren, bekommen Clients stundenlang inkonsistente Ergebnisse.

Symptom: Einige Clients lösen zu alten Adressen auf, andere zu neuen. Schwer zu troubleshooten.

Lösung: Gleichen Sie TTLs für A- und AAAA-Records an. Sie sollten identisch sein. Senken Sie beide vor Änderungen, dann erhöhen Sie sie danach wieder.

Firewall blockiert DNS über IPv6#

Ihr DNS-Server hat eine IPv6-Adresse und AAAA Record, aber die Firewall blockiert UDP und TCP Port 53 über IPv6. Clients können ihn nicht abfragen.

Symptom: DNS-Abfragen schlagen von IPv6-only Clients oder Netzwerken fehl.

Lösung: Erlauben Sie UDP und TCP Port 53 für IPv4 und IPv6. Testen Sie von einem IPv6-only Host. Denken Sie daran, dass DNS über TCP obligatorisch ist, nicht optional.

Unvollständige Dual-Stack Konfiguration#

Sie konfigurieren AAAA Records für Ihre Website, aber nicht für Ihr CDN, Mailserver oder API-Endpunkte. Nutzer bekommen gemischte Ergebnisse.

Symptom: Hauptseite funktioniert über IPv6, aber eingebetteter Content, API-Aufrufe oder Mail fallen auf IPv4 zurück und verlieren Performance-Vorteile.

Lösung: Aktivieren Sie IPv6 für alle Dienste in der Kette, nicht nur das Frontend. Testen Sie vollständige Workflows von IPv6-only Clients.

Hardcodierte IPv4-Adressen in Konfiguration#

Ihr DNS löst sich gut auf, aber Anwendungskonfigurationsdateien enthalten hardcodierte IPv4-Adressen. Dienste brechen, wenn IPv6-only Clients versuchen zu verbinden.

Symptom: Anwendung schlägt mit Verbindungsfehlern auf IPv6-only Netzwerken fehl.

Lösung: Verwenden Sie Hostnamen, nicht IP-Adressen, in Konfigurationsdateien. Lassen Sie DNS zur entsprechenden Adressfamilie auflösen.

Best Practices#

Gründlich testen vor dem Veröffentlichen#

Bevor Sie AAAA Records zu Produktions-DNS hinzufügen:

1. Verifizieren Sie, dass der Dienst auf IPv6 lauscht: netstat -an | grep :80 (oder Ihr Port)
2. Testen Sie von einer externen IPv6-Adresse: curl -6 https://[2001:db8::1]/
3. Prüfen Sie, dass Firewall-Regeln IPv6-Traffic erlauben
4. Verifizieren Sie korrektes Routing mit traceroute6
5. Testen Sie von mehreren IPv6-Netzwerken (Mobil, Breitband, Rechenzentrum)

Nehmen Sie nicht an, es funktioniert, weil das OS eine IPv6-Adresse hat.

TTLs für A- und AAAA-Records angleichen#

Setzen Sie identische TTLs. Das hält Cache-Verhalten konsistent und vereinfacht DNS-Updates.

example.com.    3600    IN    A       192.0.2.1
example.com.    3600    IN    AAAA    2001:db8::1

Wenn Sie Adressen ändern müssen, senken Sie den TTL 24-48 Stunden vor der Änderung, machen Sie das Update, dann erhöhen Sie ihn wieder.

Reverse DNS konfigurieren#

Richten Sie PTR Records für alle öffentlich routbaren IPv6-Adressen ein. Es ist erforderlich für Mailserver und hilfreich für alles andere.

Arbeiten Sie mit Ihrem ISP oder RIR, um die Reverse Zone zu delegieren. Halten Sie PTR Records synchron mit Forward DNS — sie sollten übereinstimmen.

Beide Protokolle überwachen#

Verfolgen Sie DNS-Abfragevolumen, Antwortzeiten und Fehlerraten separat für A- und AAAA-Records. Überwachen Sie Resolution über IPv4- und IPv6-Transport.

Richten Sie Alerts ein für:

• AAAA-Abfragen, die fehlschlagen, während A-Abfragen erfolgreich sind
• Antwortzeitunterschiede zwischen IPv4 und IPv6
• Plötzliche Rückgänge im IPv6-Abfragevolumen

Separate Überwachung fängt Probleme ab, bevor Nutzer sich beschweren.

IPv6-fähige DNS-Server verwenden#

Ihre DNS-Server müssen Abfragen über IPv4 und IPv6 beantworten. Konfigurieren Sie beide Adressfamilien, auch wenn Ihr Netzwerk noch nicht vollständig Dual-Stack ist.

Testen Sie von IPv6-only Clients. Eine überraschende Anzahl von DNS-Servern haben AAAA Records, akzeptieren aber tatsächlich keine Abfragen über IPv6.

DNSSEC vorsichtig implementieren#

DNSSEC funktioniert mit IPv6, aber DNS64 bricht es. Wenn Sie DNS64 in Ihrem Netzwerk verwenden, können Sie DNSSEC auf synthetisierten Records nicht validieren.

Für Produktionsbereitstellungen entwerfen Sie für natives Dual-Stack und vermeiden Sie DNS64 wo möglich.

Verwandte Artikel#

• IPv6 Grundlagen – Verstehen Sie IPv6-Adressierung und wie sie sich von IPv4 unterscheidet
• IPv6 Troubleshooting – Diagnostizieren und beheben Sie häufige IPv6-Konnektivitätsprobleme
• IPv6 Deployment Checkliste – Vollständiger Leitfaden zur Bereitstellung von IPv6 in Produktion

Häufig gestellte Fragen#