DNS, IPv6 DualStack und Happy Eyeballs

Probleme bei der Mailzustellen mit Exchange Hybrid Connectoren haben mich auf eine IPv6 Dual-Stack-Besonderheit hingewiesen, die vielleicht bei Exchange SE ein Problem sein könnte. Zumindest sollen Sie um die Zusammenhänge wissen, wenn Sie nach Fehlern bei TCP-Verbindungen suchen.

Kurzfassung: Das Problem SMTP-Hybrid-Zustellung

Der Kunde hat eine Exchange SE/Exchange Online Hybrid-Bereitstellung konfiguriert bekommt und der Mailversand von OnPremises zu Exchange Online hat nicht funktioniert. Wir wissen alle, dass der HCW - Hybrid Configuration Wizard dazu einen "Send-Connector" anlegt, damit der lokale Exchange Server alle Mails an <tenantname>.mail.onmicrosoft.com über den MX-Record direkt zur richtigen Exchange Online Gegenstelle sendet. Der MX-Record löst über einen Zwischenschritt auf die IP-Adressen auf.

DNS löst die Adresse sowohl auf IPv4 als auch IPv6 Adressen auf. Das liegt daran, dass der Client per DNS einfach beide DNS-Records (A und AAAA) abfragt, Microsoft beide Klassen bereitstellt und der DNS-Server auch beide liefert. Auf dem Exchange Server sind aber Mails an dieses System nun "hängen" geblieben, wie ein Get-Queue angezeigt hat:

Eine Detailanzeige zeigte dann, dass Exchange hier versucht die IPv6-Adresse zu erreichen.

Das Bild reiche ich noch nach. 

Das hat mich überrascht, da der Server keine Unique Global IPv6-Address hatte und daher eigentlich nie eine IPv6-Verbindung starten sollte. Um besser zu verstehen, was hier passiert und ob Exchange SE sich "anders" verhält, habe ich eine Testserie auf meinem Laborsystemen gestartet, um die Funktion von IPv6 auf Windows besser zu verstehen. Zwei Dinge sind mir aufgefallen:

• DNS-Server  liefern auch bei Anfragen per IPv4-Verbindung als Antwort auch AAAA-Records mit IPv6-Adressen
  Ich bin früher davon ausgegangen, dass ein DNS-Server nur dann IPv6-Antworten liefert, wenn er auch per IPv6 gefragt wird. Wenn ein Client per IPv4 fragt, könnte der DNS-Server annehmen, dass der Client kein IPv6 kann und verwirrt ihn nicht mit IPv6-Antworten. Das ist aber nicht der Fall.
• Windows IPv6 Steuerung mit "REGEDIT DisabledComponents"
  Über diesen Schlüssel kann ich Einfluss auf die IPv4/IPv6-Nutzung des Windows TCP/IP-Stacks nehmen. Die Veränderungen sind aber weitreichender, als ich erwartet habe.

Neugierig? Dann wünsche ich viel Spaß beim weiteren Lesen der Seite.

RFC 6724: Default Address Selection for Internet Protocol Version 6 (IPv6)

Die Einführung von IPv6 zieht sich schon über viele Jahre hin und Anfangs war IPv6 quasi optional. Heute ist aber ein Großteil des Internets schon IPv6-tauglich und viele private Internetanschlüsse sind auch schon IPv6-Ready oder haben so gar gar keine echte IPv4-Adresse mehr (Siehe auch Carrier Grade NAT (CGNAT) und 100.64.0.0/10 Subnetz). Die anderen machen dann IPv6-DualStack. Moderne Betriebssysteme sind so ausgelegt, dass Sie das IPv6-Protokoll bevorzugen, wenn eine IPv6-Verbindung möglich ist. Dazu muss natürlich das Ziel per DNS auch auf eine IPv6-Adresse auflösen und ein Routing möglich sein.

Furthermore, dual- or hybrid-stack implementations, which support both IPv6 and IPv4, will very often need to choose between IPv6 and IPv4 when initiating communication, for example, when DNS name resolution yields both IPv6 and IPv4 addresses and the network protocol stack has available both IPv6 and IPv4 source addresses. In such cases, a simple policy to always prefer IPv6 or always prefer IPv4 can produce poor behavior. As one example, suppose a DNS name resolves to a global IPv6 address and a global IPv4 address. If the node has assigned a global IPv6 address and a 169.254/16 auto- configured IPv4 address [RFC3927], then IPv6 is the best choice for communication. But if the node has assigned only a link-local IPv6 address and a global IPv4 address, then IPv4 is the best choice for communication. The destination address selection algorithm solves this with a unified procedure for choosing among both IPv6 and IPv4 addresses.
Quelle: RFC 6724: Default Address Selection for Internet Protocol Version 6 (IPv6) https://www.rfc-editor.org/info/rfc6724/

Die RFC 6724 beschreibt sehr ausführlich nicht nur die Wahl der Zieladresse sondern auch der passenden Quell-Adresse. Es ist klar, das eine IPv4 Quelle nicht mit IPv6-Zielen direkt sprechen kann und DNS64/NAT64 diskutieren wir hier nicht weiter. Aber bei IPv6 hat ein Client in der Regel mehrere IPv6-Adressen (link-local, site-local oder global), die in eine Prioritäten sortiert werden. Stark vereinfacht können Sie sich merken:

• IPv6-First
  Wenn ihr Client per DNS eine IPv6-Adresse für das Ziel erhält und er eine geeignete IPv6-Adresse zum Versand findet, dann versucht er erst einmal IPv6.
• IPv4-Fallback
  Wenn IPv6 nicht möglich ist, dann versucht der Client per IPv4 über IPv4

Dieses Verhalten ist natürlich steuerbar.

• RFC 6724: Default Address Selection for Internet Protocol Version 6 (IPv6)
  https://www.rfc-editor.org/info/rfc6724/

IPv6 Steuerung

Sie können das Verhalten des Clients aber auch DNS-Server steuern.

Ich rate davon ab, die Standardeinstellungen zu verändern und eher zu prüfen, warum sie ein Problem damit haben. Oft sind es Fehlkonfigurationen an anderer Stelle, die Sie später wieder einholen.

Serverfunktion

Ehe wir uns die verschiedenen Einstellungen auf dem System anschauen, welche die Verbindung startet, müssen wir natürlich auf der Gegenseite sicher sein, dass diese das gewünschte Protokoll anbietet. Ich habe es schon mehrfach erlebt, dass Server zwar IPv6 nutzen, aber die IIS-Bindung mit der passenden Zertifikat nicht für IPv6 konfiguriert war. Auch könnte eine "vergessene Regel" in der Windows Firewall verhindern, dass der Server überhaupt eine IPv6-Verbindung korrekt annimmt. Der einfachste Check ist hier auf dem Server selbst mit IPCONFIG /ALL sich einmal die Adressen anzuschauen. Mein Server hat hier drei IP-Adressen:

• 2-Prefix - Global Unique IPv6 Addresses (GUA)
  Dies ist eine weltweit eindeutige Adresse und das ist eigentlich der einzige Adresstyp, der im Internet genutzt werden sollte. Es kann auch 3x,4x,5x etc. werden
• FD/FD-Prefix - Unique-Local Scope: Unique-Local IPv6 Addresses (ULA)
  Dies ist eine nur lokal eindeutige Adresse. Man kann das mit 192.168.x.x/172.16.x.x-172.31.x.x und 10.x.x.x vergleichen. Im internen Firmen-Lan ist diese Erreichbar aber nicht aus dem Internet. Eine Gegenstelle im Internet sollte diese Adresse also gar nicht erst versuchen.
• FE-Prefix - Link-Local Scope: Link-Local IPv6 Unicast Addresses (LLA)
  Diese Adresse ist nur im gleichen Subnetz erreichbar. Jeder IPv6-Host hat so eine Adresse.

Windows Client

Auf einem Windows Client können Sie natürlich IPv6 komplett abschalten und damit IPv4 erzwingen. Das ist möglich aber von Microsoft nicht empfohlen und kann auch interne Funktionen, z.B. Exchange DAG Clusterfunktion, negativ beeinflussen. Ausgehend muss ein Client also nicht nur die richtige Zieladresse finden, sondern auch die passende lokale Adresse als Absender verwenden. Wenn ich zu Systemen komme, die IPv6 teilweise oder ganz deaktiviert haben, dann drehen Administratoren an einer von zwei Stellen:

• Deaktivieren von IPv6 auf der einzelnen Netzwerkkarte
  Das ist möglich und scheint zu funktionieren, aber es ist nicht von Microsoft empfohlen, da der IPv6-Stack als solches damit schon noch aktiv bleibt. Wenn z.B. dann ein VPN per IPv6 gestartet wird oder interne Prozesse IPv6 nutzen, dann funktioniert das über die Link Local Address immer noch aber manchmal nur partiell.

# Anzeige der IPv6 Bindungen auf Netzwerkkarten
Get-NetAdapterBinding -ComponentID ms_tcpip6| ft InterfaceDescription,Enabled

# Abschalten von IPv6-Bindungen per PowerShell
Disable-NetAdapterBinding -Name "*" -ComponentID ms_tcpip6

# Einschalten von IPv6-Bindungen per PowerShell
Enable-NetAdapterBinding -Name "*" -ComponentID ms_tcpip6

Ich rate davon ab, IPv6 auf einzelnen Netzwerkkarten zu deaktivieren.

• Steuerung über den IP-Stack
  Über einen einzelnen Registrierungsschlüssel können Sie steuern, wie IPv6 genutzt wird.

# Anzeige der aktuellen Einstellung
(Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters").DisabledComponents

# leer oder 0  -> IPv6 Standardverhalten
#  32dez       -> IPv4 vor IPv6
# 255dez       -> IPv6 abgeschaltet

# IPv6 abschalten mit 
New-ItemProperty `
   -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters" `
   -Name "DisabledComponents" `
   -PropertyType DWord `
   -Value 255 `
   -Force

Wer IPv4 vorziehen will, sollte den Wert auf 32 stellen. Der Schlüssel kann noch weitere Werte annehmen.

• Guidance for configuring IPv6 in Windows for advanced users
  https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/configure-ipv6-in-windows

Jedes Bit hat eine Funktion:

1xxxxxxx 127 
x1xxxxxx  64
xx1xxxxx  32 Bevorzuge IPv4 vor IPv6
xxx1xxxx  16 IPv6 auf allen NichtTunnel-Interfaces abschalten
xxxx1xxx   8
xxxxx1xx   4
xxxxxx1x   2
xxxxxxx1   1 IPv6 auf allen Tunnel-Interfaces abschalten

Die Einstellung wirkt erst nach dem nächsten Neustart, während eine Änderung an den Netzwerkkarten sofort wirkt.

Achtung: Wenn ihr Windows Server auch "Routing und RAS"-Server ist, dann dürfen Sie nur "0" oder "32" nutzen. bei anderen Werten startet der RRAS-Dienst nicht mehr.

Windows DNS-Server

Über den Registrierungsschlüssel können wir auch beeinflussen, ob der Client eine AAAA-Anfrage an den DNS-Server stellt. Es gibt aber auch Einstellungen am DNS-Server selbst als auch bei Forwardern und sogar Firewalls, mit dem Sie die Antworten beeinflussen können. Sie könnten:

• DNS Server liefert bei einer AAAA-Anfrage dennoch keine AAAA-Antwort.
  Damit unterbinden sie indirekt jegliche IPv6-Nutzung, wenn der Zugriff nicht über IP-Adressen oder andere Wege der Namensauflösung (z.B. mDNS) erfolgt. Wenn kein Client eine IPv6-Adresse auflösen kann, dann kann er auch keine Verbindung über IPv6 aufbauen.
• DNS-Server stellt keine AAAA-Anfragen an den Forwarader
  So könnten Sie intern sehr wohl IPv6, z.B. über Unique Local oder LinkLocal-Adressen nutzen aber da der DNS-Server selbst nach extern keine AAAA-Anfragen stellt, bekommt er keine IPv6-Antworten, die er intern weitergeben kann.
• Firewall
  Wenn die DNS-Abfragen nicht per DNSSEC gesichert sind, dann nutzt DNS einfach Port 53/UDP oder 53/TCP ohne Verschlüsselung. Jede moderne Firewall kann DNS-Anfragen und Antworten nicht nur inspizieren, sondern auch verändern oder unterdrücken. Wenn Sie also keine DNS-Richtlinien konfigurieren wollen und auch eine Umgehung des DNS-Services zu fremden DNS-Servern wie 8.8.8.8, 9.9.9.9, 1.1.1.1 etc. verhindern wollen, dann sind Firewall-Regeln ein Platz.

Linux/MacOS

Alles was unter Windows geht, ist natürlich auch unter Linux möglich. Sie können auch unter Linux die IPv6-Unterstützung je nach Distribution abschalten, die Namensauflösung beeinflussen und die DNS-Funktion steuern.

Die richtigen Wege hängen etwas vom Bootloader und der Distribution ab. Eine Suche im Internet oder mittels KI sollte für ihr System sicher eine passende Anleitung liefern.

• Chapter 17. Using NetworkManager to disable IPv6 for a specific connection
  https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/configuring_and_managing_networking/using-networkmanager-to-disable-ipv6-for-a-specific-connection_configuring-and-managing-networking
• Deactivation of IPv6
  https://www.thomas-krenn.com/en/wiki/Deactivation_of_IPv6   
• Debian: IPv6 deaktivieren
  https://www.andysblog.de/debian-ipv6-deaktivieren

Test: Wireshark mit IPv6 deaktiviert

Zuerst habe gemacht, was Microsoft explizit als "unsupportet" kommentiert:

Unbind IPv6 from an interface
https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/configure-ipv6-in-windows#unbind-ipv6-from-an-interface

Ich habe auf meinem Windows 2016 Server auf der Netzwerkkarte die IPv6-Bindung entfernt:

Auf dem Server war dies die einzige Netzwerkkarte und Wireshark zeigt schön, dass die Namensauflösung nur nach "A"-Records fragt aber mein "telnet www.google.com 25" insgesamt 8 Wiederholungen startet, die jede für sich ca. 21 Sek dauern. Mein Telnet "hängt" also ganz schön lange

Danach habe ich IPv6 wieder reaktiviert.

Wireshark und DisabledComponents

Der richtig Weg unter Windows die IPv6-Funktion zu steuern, ist der Registrierungsschlüssel:

# Anzeige der aktuellen Einstellung
(Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters").DisabledComponents

In der Standardeinstellung ist der Wert nicht gesetzt. Ich habe meinen Test wiederholt. Ich weiß, dass Google, z.B. IPv4 und IPv6 unterstützt und mein Windows Client eine echte "Global Unique IPv6-Adresse"-Adresse hat. Mit einem "Telnet www.google.com 25" kam zwar nie eine Verbindung zustande, aber ich konnte so sehen, wann der Client von IPv6 auf IPv4 und umgekehrt wechselt.

Achtung:
Nach jeder Änderung muss Windows neu gestartet werden. Der TCP-Stack übernimmt die Änderung nicht im laufenden Betrieb. 

Wireshark DisabledComponents=leer (Default)

In der Standardeinstellung ist der Schlüssel nicht gesetzt. Sie können den Wert einfach per PowerShell entfernen:

Remove-ItemProperty `
   -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters" `
   -Name "DisabledComponents" 

Der Client fragt sowohl A als auch AAAA Einträge und versucht dann zuerst einen IPv6-Verbindung, ehe er nach 12 Sekunden auf IPv4 wechselt.

"Telnet.exe" nutzt aber genau eine Verbindung pro Protokoll-Stack und kehrt nach 2x 18 Sekunden wieder zurück.

Wireshark DisabledComponents=0

Laut Microsoft sollte diese Einstellung die gleiche Funktion wie "nicht gesetzt" haben. Das kann ich aber nicht bestätigen.

New-ItemProperty `
   -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters" `
   -Name "DisabledComponents" `
   -PropertyType DWord `
   -Value 0 `
   -Force 

Der Client fragt A und AAAA ab und startet dann acht! Versuche per IPv6 eine Verbindung aufzubauen, ehe er dann auf IPv4 wechselt. Auch über IPv4 versucht er acht Mal die Gegenstelle zu erreichen, eher er nach ca. 160 Sekunden dann aufgibt.

Mein "Telnet"-Aufruf hat hier also ca. 320 Sekunden versucht eine Verbindung zu erreichen. Das ist definitiv ein anderes Verhalten.

Wireshark DisabledComponents=32 (IPv4 preferred)

Mit dem Wert 32 teile ich Windows mit, dass es zuerst IPv4 versuchen soll.

New-ItemProperty `
   -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters" `
   -Name "DisabledComponents" `
   -PropertyType DWord `
   -Value 32 `
   -Force 

In Wireshark sehen Sie dann, dass der Client per DNS sowohl "A" als auch "AAAA" anfragt aber dennoch zuerst die IPv4-Adresse nutzt, ehe er dann auf IPv6 wechselt.

Die Verbindung habe ich um 23:05:24 gestartet aber erst um 23:08:12 hat der TCP-Stack dann die Verbindung auf IPv6 versucht. Wir sehen aber auch sehr viele erneute Versuche per IPv4, als wenn die Option "32" den IP-Stack anweist, es auf jeden Fall und häufiger per IPv4 zu versuchen.

Wireshark DisabledComponents=255 (IPv6 deaktiviert)

Zuletzt habe ich IPv6 komplett deaktiviert.

New-ItemProperty `
   -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters" `
   -Name "DisabledComponents" `
   -PropertyType DWord `
   -Value 255 `
   -Force 

In Wireshark bleibt dann nicht mehr viel übrig.

Wie sehen ein ganz anderes Verhalten:

• Der Client fragt per DNS nur nach "A"
  Er versucht erst gar nicht eine IPv6-Adresse abzufragen und wird daher auch keine IPv6-Verbindung aufbauen können
• Nur eine TCP-Connection
  Obwohl ich das gleiche "Telnet.exe" nutze, sehe ich nur einen TCP-Versuch mit zwei Retransmits. Mein Telnet kommt sehr viel schneller mit einer Fehlermeldung zurück

Die Einstellung blockiert aber nicht nur IPv6 sondern reduziert auch die IPv4 Wiederholungen.

Zwischenstand DisabledComponents

Die Einstellungen wirken, wie Microsoft es sich vorgestellt hat. Man kann mit "255" die IPv6-Funktion komplett abschalten oder ohne das Feld die Standardfunktion hinterlegen.

Ich bin aber irritiert, dass 0 nicht identisch mit "nicht definiert" ist, da der TCP-Stack viel mehr versuche startet.
Und auch beim 32 wird zwar IPv4 bevorzugt, aber auch hier kommen viel mehr Retries zum Einsatz.

Hinweis: Ich habe auch einmal IPv6 "unbrauchbar" gemacht, indem ich bei der Firewall das Routing unterbunden habe. Die Ergebnisse waren die gleichen.

Diese Tests beziehen sich auf Windows 2016 Server (Patchstand Sep 2026).

Wenn ich dazu komme, würde ich die Testserie auch noch mal mit aktuelleren Versionen durchspielen.
Offen ist auch der Test, wie sich ein Client verhält, der keine Unique Global IP hat.

Wireshark DNS und IPv4 Link Local Only

Auslöser für die Seite war ein Verhalten von Exchange SE, welcher IPv6 bevorzugt hat, obwohl der Server keine IPv6-Verbindung aufbauen konnte. Wir haben bisher nur gesehen, dass der IP-Stack eigentlich beide Protokolle versuchen sollte, wenn er denn per DNS auch die Adressen bekommt. In dem Kundenumfeld gab es aber kein IPv6-Deployment. Die Server hatten weder eine Unique Local noch eine Unique Global-Adresse. Sie hatten nur eine LinkLocal-Adresse, mit der sie nur im gleichen Subnetz kommunizieren könnten.

Auf dem Exchange Server habe ich mit Wireshark mir die DNS-Anfragen mal genauer angeschaut. Er fragt natürlich dennoch per DNS nach einem AAAA-Record aber nutzte dann einfach nur IPv4-Adressen für die Namensauflösung und Verbindung:

Wenn ich mir die DNS-Antwort aber genauer anschaue, dann liefert der DNS-Server sehr wohl nicht nur IPv4 sondern auch IPv6-Adressen.

Allerdings nutzt der Server diese nicht. DNS-Server war ein Windows 2022 DC, der extern auch nur per IPv4 fragen kann.

Server mit IPv6-Connectivity

Nur zur Sicherheit habe ich meinen Exchange Server die Verbindung erlaubt. Hier sehen Sie die Namensauflösung aber auch die TCP-Verbindung bis zum ersten Willkommensgruß von Exchange Online.

Soweit passt alles.

DNS Clientanfragen und Server

Ich habe daher eine kleine Testserie von verschiedenen Clients gemacht. Alle sind "Standard" konfiguriert, d.h. Domainmitglieder aber keine Gruppenrichtlinien, um IPv6 zu beeinflussen, abzuschalten oder zu beschränkten.

• IPv4-Client
  Ich habe einen Client genutzt, der nur IPv4 spricht aber eine FE80-Adresse hat.
• IPv6-Client
  Dieser Client hat eine richtige IPv6-Verbindung

Den Test habe ich einfach per NSLOOKUP gemacht

nslookup -q=<querytype> msxfaq-mail-onmicrosoft-com.mail.protection.outlook.com- <serverip>

Die angefragten Querytypes waren:

A=IPv4
AAA (ungültig) 
AAAA = IPv6

• List of DNS record types
  https://en.wikipedia.org/wiki/List_of_DNS_record_types

Die jeweiligen Antworten habe ich hier dokumentiert.

Wir könnten folgende Aussagen festhalten:

• Wenn ein Client nach "A" fragt, bekommt er nur IPv4-Antwort, egal über die Anfrage selbst über IPv4 oder iPv6 erfolgt
• Wenn ein Client nach "AAAA" fragt, bekommt er nur IPv6-Antwort, egal über die Anfrage selbst über IPv4 oder iPv6 erfolgt
• Wenn ein Client falsch nach "AAA" fragt, bekommt er sowohl IPv4 als auch IPv6 Antwort, egal über die Anfrage selbst über IPv4 oder iPv6 erfolgt

Wenn ich absichtlich mit "AAA" frage, dann macht mein Client eine Anfrage auf A und AAAA

Wenn ich explizit nach "A" oder "AAAA" frage, dann bekomme ich auch genau diese Adresse zurück. Welche Anfrage eine Applikation stellt, bestimmt der Entwickler. Er kann

• Selbst die Namensauflösung machen und die IP-Adresse im TCP-CONNECT verwenden
  Das ist aber eher unüblich und Mehraufwand. Es lohnt sich eher, wenn Sie z.B. zu einem Namen explizit die Systeme ermitteln und individuell abprüfen wollen.
• Dem TCP-Connect den Namen übergeben
  Dann kümmert sich der TCP-Stack gemäß den Vorgaben um die Namensauflösung und Verbindung.

Hinweis
Wenn Sie den Namen der TCPClient.Connect-Methode übergeben, dann löst er nur A/AAAA/CNAME auf. Wer einen Mailserver sucht, muss schon selbst den MX-Record auflösen.

• TcpClient.Connect Methode (System.Net.Sockets)
  https://learn.microsoft.com/de-de/dotnet/api/system.net.sockets.tcpclient.connect?view=net-10.0

DNS und Dualstack Quellen

Früher habe ich immer gedacht, dass eine DNS-Abfrage per IPv4 auch nur IPv4-Antworten zurück gibt. Aber auch eine IPv6-Anfrag liefert immer auch IPv4-Antworten mit aus.

Das hat mich natürlich neugierig gemacht, seit wann das ist und es gibt hier wohl tatsächlich unterschiede nach dem Betriebssystem.

Halten wir also fest

• Moderne Clients fragen auch nach AAAA
  Das hat nichts damit zu tun, ob sie keine IPv6-Adresse oder nur LinkLocalIPV6-Adressen haben. Nur wenn Sie in Windows IPv6 "richtig" abschalten, unterbleibt auch auch die DNS-Anfrage nach "AAAA"-Einträgen
• DNS-Server liefert auch über IPv4-Rechte die IPv6-Antworten
  Dem DNS-Server ist es egal, ob der DNS-Query per IPv4 oder IPv6 kommt. Er antwortet passend zu gestellten Anfrage und unabhängig vom IP-v4/IPv6-Übertragungsweg,.
• Happy Eyeball Prinzip
  Clients sollten per DNS Round Robin alle Adressen durchprobieren´. Normalerweise versuchen Sie zuerst IPv6, wenn eine Verbindung zustandekommen könnte. Ein Client ohne eigene "Unique Global Address" wird nicht versuchen eine andere Unique Global Address zu erreichen und daher sehr schnell auf IPv4 wechseln.

Die Köpfe hinter IPv6 haben sich schon sehr viele Gedanken über die unterschiedlichen Konstellationen aber auch Fehlkonfiguration in Netzwerken gemacht und nach so vielen Jahren können wir davon ausgehen, dass die IP-Stacks der verschiedenen Betriebssysteme auch eher nicht der Fehler bei Verbindungsproblemen sind

• Operational Guidelines for DNS Transport in Mixed IPv4/IPv6 Environments
  https://datatracker.ietf.org/doc/rfc10001/
• RFC 3483 Default Address Selection for Internet Protocol version 6 (IPv6)
  https://www.rfc-editor.org/rfc/rfc3484.txt
• Get-NetPrefixPolicy
  https://learn.microsoft.com/en-us/powershell/module/nettcpip/get-netprefixpolicy
  

DNS Policies

Der Vollständigkeit halber dokumentiere ich hier noch meine Einstellungen, wie ich bei einem Windows DNS-Server das Antwortverhalten auf IPv6-Adressen steuern kann. Wenn ich verhindern möchte, dass mein Windows DNS-Server irgendwas mit IPv6 macht, kann ich folgenden Befehl verwenden. 

# Windows DNS blockt alles AAAA Anfragen (lokale Zonen und Forwarder)
Add-DnsServerQueryResolutionPolicy `
   -Name "BlockAAAA" `
   -Action IGNORE `
   -QueryType AAAA

Der Windows DNS Service kann aber auch feiner konfiguriert werden. Hier ignoriere ich Anfragen nach "AAAA", außer es sind meine z.B. internen eigenen Domains. So kann ich intern weiter IPv6 nutzen aber die externe IPv6-Kommunikation zumindest erschweren. Wenn ein Client natürlich einen anderen DNS-Server fragt oder die IP-Adresse manuell eingibt dann ist das kein Schutz

Add-DnsServerQueryResolutionPolicy `
-Name "BlockExternalAAAA" `
-Action IGNORE `
-QueryType AAAA `
-FQDN "NE,*.msxfaq.local" `
-FQDN "NE,*.msxfaq.de"

Weitere Informationen zu der Filterung finden Sie bei Microsoft 

• Use DNS Policy for Applying Filters on DNS Queries
  https://learn.microsoft.com/en-us/windows-server/networking/dns/deploy/apply-filters-on-dns-queries

Unique Local/Global Address

Bei IPv6 gibt es nicht nur eine sondern gleich mehrere Adressen. Der Client, welcher die Verbindung startet, muss sich von seinen lokalen Adressen die "passende" für das Ziel auswählen. Daz uhabe ich mienen Windows 11 Client mit echter IPv6-Adresse als Beispiel genommen. Meine IP-Adressen waren:

Sie sehen, dass ich insgesamt fünf IPv6-Adressen eine eine IPv4-Adresse habe:

2a00:6020:4e92:e200:4619:2671:966b:e555  Primär    Unique Global-Adresse
fd1d:baaf:d80b:0:2d3d:338e:23ce:9ac3     Primär    Unique Local-Adresse
2a00:6020:4e92:e200:94c:b383:7ef5:5951   Temporär  Unique Global-Adresse
fd1d:baaf:d80b:0:94c:b383:7ef5:5951      Temporär  Unique Local-Adresse 
fe80::6c66:43a0:c052:ce02%40             Primär    LinkLocal-Adresse
192.168.178.50                           Primär    IPv4-Adresse

Wer mag, kann die Dynamisierung der IPv6-Adressen auch deaktivieren. Die Dynamic wurde aber eingeführt, damit ein Client nicht anhand er quasi statischen Adresse erkannt werden kann. Wobei für Werbefirmen auch schon das Subnetz genug Informationen einer Identifizierung erlaubt. Ich habe diese Optionen daher nicht verändert.

Set-NetIPv6Protocol -RandomizeIdentifiers Disabled
Set-NetIPv6Protocol -UseTemporaryAddresses Disabled

Ausgehend hiervon habe ich per PING verschiedene Adressen angesprochen und mir die Source-IP-Adresse mit Wireshark angeschaut:

Wie sie gut sehen können, gibt es keine ausgehende Verbindungen auf eine "Unique Global Address" mit einer LinkLocal oder UniqueLocal-Addresse

Das bedeutet nicht, dass es nicht technisch möglich wäre. Der Client lauscht einfach auf die "Router Announcements" und folgt seiner Route
Sie können diese mit "Get-NetRoute -AddressFamily IPv6" anzeigen lassen. Sie sollten keinen Leitweg für "::/0" sehen, wenn sie IPv6 nicht routen.

Für die Verbindungen gibt es folgende Matrix:

Sicher lassen sich einige Verbindungen, die ich hier "Rot" gekennzeichnet habe, auch per NAT oder Proxy-Server irgendwie ermöglichen. Aber IPv6 mit dem sehr großen Adressraum ist ja auch mit dem Ziel angetreten, dass wir kein NAT mehr mit all den Einschränkungen nutzen müssen.

Lösung für Exchange

Am Anfang habe ich über ein Problem mit einem Exchange SE Server gesprochen, welcher beim Versand per SMTP zu Exchange Online per DNS eine gültige Unique Global Address der Gegenstelle bekommen und anscheinend eine Verbindung zu dieser Adresse versucht hat. Dies muss aber auf eine besondere Weise nicht erfolgreich gewesen sein, so dass der Exchange Server die Mail nicht per Fallback über IPv4 gesendet, sondern in eine Warteschlagen mit der IPv6-Zieladresse gelegt hat.

Das hätte so nie passieren sollen, denn Exchange überlässt die Arbeit ja dem IP-Stack und startet einfach nur einen TCP-Connect mit dem DNS-Namen aber kümmert sich eigentlich nicht selbst um eine Namensauflösung. Wobei ich das ohne Zugriff auf den Ausschnitt des Quellcode natürlich nicht abschließend bewerten kann. Sobald der Fehler wieder auftaucht, hoffe ich mit Wireshark mehr Licht ins Dunkel bringen zu können. Technisch sollte ein Exchange Server ohne eigene Unique Global Address nie eine IPv6-Verbindung zu einer anderen Unique Global Address aufbauen.

Eine Ursache und damit eine Lösung habe ich noch nicht gefunden.

Weitere Links

• HCW - Hybrid Configuration Wizard
• DNS im Netzwerk
• FTTH mit IPv6 (DG)
• DS-Lite (Dual Stack)
• Glasfaser in Hövelhof
• Carrier Grade NAT (CGNAT) und 100.64.0.0/10 Subnetz
• Guidance for configuring IPv6 in Windows for advanced users
  https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/configure-ipv6-in-windows
• RFC 6724: Default Address Selection for Internet Protocol Version 6 (IPv6)
  https://www.rfc-editor.org/info/rfc6724/
  https://www.rfc-editor.org/info/rfc3484/ (Obsoleted)
• RFC 8305: Happy Eyeballs Version 2: Better Connectivity Using Concurrency (ersetzt RFC6555)
  https://www.rfc-editor.org/info/rfc8305
• Get-NetPrefixPolicy
  https://learn.microsoft.com/en-us/powershell/module/nettcpip/get-netprefixpolicy
• Response policy zone
  https://en.wikipedia.org/wiki/Response_policy_zone

• List of DNS record types
  https://en.wikipedia.org/wiki/List_of_DNS_record_types

• What ist RPZ - Response Policy Zone
  https://efficientip.com/glossary/what-is-rpz/
• RFC 8305 Happy Eyeballs Version 2: Better Connectivity Using Concurrency
  https://datatracker.ietf.org/doc/rfc8305/
• RFC 6555: Happy Eyeballs: Success with Dual-Stack Hosts
  https://datatracker.ietf.org/doc/rfc6555/
• Exchange EDGE tries to deliver via IPv6 even though it is disabled
  https://learn.microsoft.com/en-us/answers/questions/299005/exchange-edge-tries-to-deliver-via-ipv6-even-thoug
• How to Configure Exchange Server for IPv6
  https://oneuptime.com/blog/post/2026-03-20-exchange-server-ipv6/view
• IPv4 and IPv6 on the Same Host: Why You'd Run Both and How to Keep Them Sane
  https://www.runxbuild.com/blog/ipv4-and-ipv6