Thomas.will: Die Seite wurde neu angelegt: „=DNS64= =Worum geht es?= Stell dir ein Netz vor, in dem die Clients '''nur noch IPv6''' haben. Kein IPv4 mehr, keine privaten 192.168er-Adressen, nichts. Das…“

2026-10-07T07:58:00Z

Die Seite wurde neu angelegt: „=DNS64= =Worum geht es?= Stell dir ein Netz vor, in dem die Clients '''nur noch IPv6''' haben. Kein IPv4 mehr, keine privaten 192.168er-Adressen, nichts. Das…“

Neue Seite

=DNS64=

=Worum geht es?=
Stell dir ein Netz vor, in dem die Clients '''nur noch IPv6''' haben. Kein IPv4 mehr, keine privaten 192.168er-Adressen, nichts.

Das funktioniert wunderbar, solange das Ziel ebenfalls IPv6 kann. Ein großer Teil des Internets ist aber immer noch '''nur über IPv4''' erreichbar. Ein reiner IPv6-Client kann mit einer IPv4-Adresse nichts anfangen: Er hat gar keinen IPv4-Stack, über den er das Paket schicken könnte.

Genau dieses Problem lösen '''DNS64''' und '''NAT64''' gemeinsam:
*DNS64 sorgt dafür, dass der Client für ein reines IPv4-Ziel trotzdem eine '''IPv6-Adresse''' bekommt.
*NAT64 sorgt dafür, dass Pakete an diese IPv6-Adresse '''tatsächlich beim IPv4-Ziel ankommen'''.

Keiner der beiden ist alleine sinnvoll. DNS64 ohne NAT64 liefert Adressen, die ins Leere führen. NAT64 ohne DNS64 hat keine Clients, die es benutzen.

=Die Grundidee in einem Satz=
Der DNS-Server '''versteckt die IPv4-Adresse in einer IPv6-Adresse''', und das NAT64-Gateway '''holt sie wieder heraus'''.

=Das Präfix 64:ff9b::/96=
Eine IPv6-Adresse hat 128 Bit, eine IPv4-Adresse 32 Bit. Es bleiben also 96 Bit übrig. Diese 96 Bit werden mit einem festen Präfix gefüllt, die IPv4-Adresse kommt in die letzten 32 Bit.

Für diesen Zweck ist ein Präfix offiziell reserviert, das sogenannte '''Well-Known Prefix''' (RFC 6052):
*64:ff9b::/96

<pre>
|<-------------- 96 Bit Präfix ------------->|<-- 32 Bit IPv4 -->|
64:ff9b:0000:0000:0000:0000 c000:020a
</pre>

Man kann auch ein eigenes Präfix verwenden. Wichtig ist nur, dass DNS64 und NAT64 '''dasselbe Präfix''' kennen.

=Umrechnung einer IPv4-Adresse=
Beispiel: 192.0.2.10

Jedes Oktett wird in Hex umgerechnet:
<pre>
192 -> c0
0 -> 00
2 -> 02
10 -> 0a
</pre>

Zusammengesetzt ergibt das c000:020a, verkürzt c000:20a. Die vollständige IPv6-Adresse lautet:
*64:ff9b::c000:20a

IPv6 erlaubt für genau solche Fälle auch eine gemischte Schreibweise. Diese Adresse ist identisch mit der oben:
*64:ff9b::192.0.2.10

=Der Ablauf Schritt für Schritt=
Ausgangslage:
*Der Client hat nur IPv6.
*Der Client benutzt einen DNS64-fähigen Resolver.
*Der Webserver ipv4only.example hat nur einen A-Record: 192.0.2.10
*Im Netz steht ein NAT64-Gateway mit einer öffentlichen IPv4-Adresse.

<pre>
+--------+ +--------+ +-------------+ +-----------+
| Client | | DNS64 | | NAT64 | | Webserver |
| (v6) | | Server | | Gateway | | (nur v4) |
+--------+ +--------+ +-------------+ +-----------+
| | | |
|-- AAAA? -------->| | |
| |-- AAAA? ins Internet: keine Antwort |
| |-- A? ins Internet: 192.0.2.10 |
|<- AAAA ----------| | |
| 64:ff9b::c000:20a | |
| | |
|-- IPv6-Paket an 64:ff9b::c000:20a -->| |
| |-- IPv4-Paket ------->|
| | an 192.0.2.10 |
| |<-- Antwort ----------|
|<-- Antwort als IPv6 -----------------| |
</pre>

==1. Der Client fragt nach einer IPv6-Adresse==
Der Client will ipv4only.example erreichen. Da er nur IPv6 kann, fragt er seinen Resolver nach dem AAAA-Record.

==2. Der DNS64-Server findet keinen AAAA-Record==
Der DNS64-Server fragt ganz normal im Internet nach. Ergebnis: Es gibt keinen AAAA-Record, der Server hat kein IPv6.

==3. Der DNS64-Server holt sich den A-Record==
Jetzt kommt der Trick: Statt dem Client einfach "gibt es nicht" zu antworten, fragt der DNS64-Server zusätzlich nach dem A-Record und bekommt 192.0.2.10.

==4. Der DNS64-Server baut einen künstlichen AAAA-Record==
Er setzt die IPv4-Adresse hinter das Präfix und schickt dem Client:
*ipv4only.example AAAA 64:ff9b::c000:20a

Der Client weiß nicht, dass diese Adresse "erfunden" ist. Für ihn ist das eine ganz normale IPv6-Adresse.

==5. Der Client schickt sein Paket los==
Der Client schickt ein ganz normales IPv6-Paket an 64:ff9b::c000:20a. Im Netz gibt es eine Route, die dieses Präfix zum NAT64-Gateway führt.

==6. Das NAT64-Gateway übersetzt nach IPv4==
Das Gateway sieht das Präfix 64:ff9b::/96 und weiß: Die letzten 32 Bit sind eine IPv4-Adresse. Es baut ein neues IPv4-Paket:
*Ziel: 192.0.2.10
*Quelle: die eigene öffentliche IPv4-Adresse des Gateways
Es merkt sich in einer Tabelle, welcher IPv6-Client zu dieser Verbindung gehört. Das ist dasselbe Prinzip wie beim bekannten NAT mit IPv4.

==7. Die Antwort kommt zurück==
Der Webserver antwortet an die IPv4-Adresse des Gateways. Das Gateway schaut in seiner Tabelle nach, übersetzt das Paket zurück nach IPv6 und schickt es an den Client. Als Absender steht dort wieder 64:ff9b::c000:20a.

=Was passiert, wenn das Ziel IPv6 kann?=
Dann passiert '''gar nichts Besonderes'''. Findet der DNS64-Server einen echten AAAA-Record, gibt er nur diesen weiter und erfindet nichts. Der Client spricht direkt per IPv6 mit dem Ziel, das NAT64-Gateway wird nicht benutzt.

DNS64 greift also nur dann ein, wenn es wirklich nötig ist.

=Wer macht was?=
{| class="wikitable"
! Baustein !! Aufgabe !! Fasst Datenpakete an?
|-
| DNS64 || Erzeugt künstliche AAAA-Records aus A-Records || Nein, nur DNS
|-
| NAT64 || Übersetzt IPv6-Pakete in IPv4-Pakete und zurück || Ja
|}

Typische Software:
*DNS64: BIND9, Unbound, PowerDNS Recursor
*NAT64: Jool oder Tayga unter Linux, pf unter FreeBSD/OPNsense, viele Router und Firewalls

=Konfiguration=
==BIND9==
;In /etc/bind/named.conf.options innerhalb von options
<pre>
options {
dns64 64:ff9b::/96 {
clients { any; };
};
};
</pre>
;Konfiguration prüfen und neu laden
*named-checkconf
*systemctl reload named

==Unbound==
;In /etc/unbound/unbound.conf im Abschnitt server
<pre>
server:
module-config: "dns64 validator iterator"
dns64-prefix: 64:ff9b::/96
</pre>
;Konfiguration prüfen und neu starten
*unbound-checkconf
*systemctl restart unbound

=Testen=
==Funktioniert DNS64?==
Für Tests gibt es den speziellen Namen ipv4only.arpa. Er hat absichtlich nur A-Records (192.0.0.170 und 192.0.0.171).
;Ohne DNS64: keine AAAA-Antwort
;Mit DNS64: eine künstliche Adresse mit dem Präfix
*dig AAAA ipv4only.arpa @2001:db8:1::53
;Erwartete Antwort
<pre>
ipv4only.arpa. IN AAAA 64:ff9b::c000:aa
ipv4only.arpa. IN AAAA 64:ff9b::c000:ab
</pre>
c000:aa ist 192.0.0.170, c000:ab ist 192.0.0.171.

Clients können über diese Abfrage auch selbst herausfinden, welches Präfix im Netz verwendet wird (RFC 7050).

==Funktioniert NAT64?==
;Ein bekanntes IPv4-Ziel über das Präfix anpingen (hier 1.1.1.1)
*ping -6 64:ff9b::1.1.1.1
;Ein Name, der nur IPv4 hat
*curl -6 -I http://ipv4.google.com

=Grenzen und Stolperfallen=
==IPv4-Adressen direkt im Programm==
DNS64 funktioniert nur, wenn ein '''Name''' aufgelöst wird. Ein Programm, das direkt 192.0.2.10 anspricht, stellt keine DNS-Anfrage, und der reine IPv6-Client kann die Adresse nicht benutzen.

Lösung: '''464XLAT'''. Dabei läuft auf dem Client ein kleiner Übersetzer (CLAT), der dem Betriebssystem eine IPv4-Adresse vortäuscht und die Pakete selbst nach IPv6 übersetzt. So machen es Mobilfunknetze, Android und neuere Windows-, macOS- und iOS-Versionen.

==DNSSEC==
Ein künstlicher AAAA-Record hat keine gültige DNSSEC-Signatur. Validiert der Client selbst, verwirft er die Antwort. Validiert der DNS64-Resolver, funktioniert es, weil er vor der Synthese prüft.

==Fremde DNS-Server==
DNS64 funktioniert nur, wenn der Client den DNS64-Resolver tatsächlich benutzt. Ein fest eingetragener öffentlicher DNS-Server oder DNS-over-HTTPS im Browser umgeht ihn. Der Client bekommt dann keine künstlichen Adressen und erreicht IPv4-Ziele nicht mehr.

==Private IPv4-Ziele==
Das Well-Known Prefix 64:ff9b::/96 ist nur für öffentliche IPv4-Adressen gedacht. Sollen interne Server mit Adressen wie 10.0.0.0/8 oder 192.168.0.0/16 erreichbar sein, braucht man ein eigenes Präfix aus dem eigenen Adressbereich.

=Zusammenfassung=
*DNS64 erfindet für reine IPv4-Ziele eine IPv6-Adresse, indem es die IPv4-Adresse hinter ein Präfix hängt.
*NAT64 erkennt dieses Präfix, holt die IPv4-Adresse heraus und übersetzt das Paket.
*Hat das Ziel einen echten AAAA-Record, wird DNS64 nicht aktiv.
*Beide Bausteine müssen dasselbe Präfix verwenden, meistens 64:ff9b::/96.
*Für Programme, die IPv4-Adressen direkt benutzen, braucht man zusätzlich 464XLAT.

IPv6 DNS64 - Versionsgeschichte

Thomas.will: Die Seite wurde neu angelegt: „=DNS64= =Worum geht es?= Stell dir ein Netz vor, in dem die Clients '''nur noch IPv6''' haben. Kein IPv4 mehr, keine privaten 192.168er-Adressen, nichts. Das…“