Eigener DNS bei einer IPv6 Konfiguration

[meyergru]

Variante 4, und die Welt ist Wwunderbar...

You cannot view this attachment.

Das erklärt nichts. Zu welcher Situation ist das eine Lösung?

a. Hast Du IPv4-only-Clients?
b. Was trägst Du im internen DNS ein? IPv4-only, ULA-only oder beides?

Wahrscheinlichster Fall:

Falls a = ja und b = beides (was dann nötig ist), werden Aufrufe der internen DNS-Bezeichnungen immer dazu führen, dass die IPv4 genutzt wird, nie die ULA. Somit bleiben die ULAs für den internen DNS wirkungslos. Stattdessen erhöhst Du die Komplexität, weil Du für den externen IPv6-Zugriff nun auch noch NAT64 benötigst. Was gewinnst Du also nochmal genau gegenüber Variante 3 durch die ULAs?

Und make no mistake: Deine Grafik aus #32 beweist lediglich, dass Deine Clients IPv6 nutzen. Ich vermute, das sind (externe) GUAs, keine ULAs - denn: interne Zugriffe müssten so zwangsläufig auf die IPv4 des Service laufen.

[Zapad]

Und make no mistake: Deine Grafik aus #32 beweist lediglich, dass Deine Clients IPv6 nutzen. Ich vermute, das sind (externe) GUAs, keine ULAs - denn: interne Zugriffe müssten so zwangsläufig auf die IPv4 des Service laufen.

Natürlich ist WAN GUA, die Clients intern nutzen ULA über Sense KEA mit RA.

wenn die Clients IP4 DNS abfragen sollen wie denn? natürlich IP6 DNS.

...aber wenn es deine Welt durcheinander bringt....

You cannot view this attachment.

[Maurice]

@meyergru Es gibt noch eine weitere Variante: DNS so konfigurieren, dass Clients, die Queries per IPv6 schicken nur AAAA-Records genannt bekommen. Das umgeht u. A. das Problem der Priorität von IPv4 vs. ULAs.

Gelöst habe ich das bei mir so:
Die internen DNS-Zonen sind in Bind (OPNsense-Plugin) angelegt. Dort gibt es AAAA-Records (ULAs) und A-Records (RFC1918).
Als Rekursiver Resolver läuft Unbound, mit Forwardings zu Bind für die internen Zonen. DNS64 und AAAA-only-Modus sind aktiv.
Über RAs und DHCPv6 wird die IPv6-Adresse von Unbound als DNS-Server verteilt. IPv6-Clients bekommen somit ausschließlich AAAA-Records (der AAAA-only-Modus filtert A-Records).
Über DHCPv4 wird die IPv4-Adresse von Bind als DNS-Server verbreitet, IPv4-Clients befragen also direkt Bind und bekommen somit auch A-Records.

Die NAT64-Aversion wirst Du auch noch überwinden, mittelfristig kommt ohnehin niemand daran vorbei. ;)

[bimbar]

Ich habe für NAT64 noch nie einen guten Nutzen gefunden.

Interne v4 only Server werden bei mir per reverse Proxy erreicht.

[n3]

Für mich zumindest eine spannende Diskussion. Meine Idee mit en ULA war, dass ich kein IPv4 mehr habe. Vielleicht ist das untergegangen. Hier mal eine Visualisierung:

You cannot view this attachment.

Die ULA nutze ich für interne Kommunikation zwischen Reverse Proxy und Services, sodass diese Dienste nicht über ihre globale Adresse angesprochen werden müssen.
Dadurch sind interne Abhängigkeiten unabhängig vom ISP-Prefix.
Zusätzlich reduziert ULA das Risiko, dass Services durch Fehlkonfigurationen versehentlich öffentlich erreichbar werden, da sie intern nur auf ULA lauschen.
Die GUA dient ausschließlich für kontrollierten ausgehenden Traffic, während eingehender Zugriff zentral über den Reverse Proxy erfolgt.

Das war die Überlegung hinter den ULAs. Macht das Sinn? Ich befürchte nur, dass ich einige Geräte habe, die nur IPv4 können und dann ist das hinfällig, oder?

Bzgl. der festen IP. Diese würde mich 5€ mtl. mehr kosten. Aber es scheint egal welche Lösung man fährt, wäre eine feste IP besser.

[Maurice]

@bimbar Ein Reverse Proxy mag für manche interne Dienste eine Alternative zu NAT64 sein, löst aber nicht das Problem, dass es noch ein klein wenig dauern wird, bis sämtliche Services im Internet über IPv6 erreichbar sein werden. Ohne NAT64 wirst Du daher noch bis zum Sankt-Nimmerleins-Tag Dual Stack im LAN fahren müssen.

[meyergru]

@Maurice: Klar, mit Tricks geht das. Aber 1. sind wir da wieder bei komplexen Umgehungslösungen und b. funktioniert auch das nur bedingt, siehe unten...


@Zapad: Das beweist wieder nichts. Ich streite dich nicht ab, dass Deine Clients IPv6 nutzen - und wenn sie nur ULAs haben, dann auch nur diese. Aber: sie nutzen die ULAs nicht für intra-LAN- oder (mutmaßlich) für inter-VLAN-Traffic!

Nochmal ganz simpel erklärt - mach mal einen Test: Trage eins Deiner Geräte mit IPv4 und IPv6 ULA in den DNS ein, sagen wir:

smtp.xyz -> 192.168.10.100 und fd05::100

Dann versuchst Du, auf irgendeinem IPv6-fähigen CLient den Namen aufzulösen:

#nslookup smtp.xyz
Server:        192.100.10.1
Address:        192.168.10.1#53

Non-authoritative answer:
Name:  smtp.xyz
Address: 192.168.10.100
Name:  smtp.xyz
Address: fd05::100

Fein. Und dann kontaktierst Du den Server:

#ping smtp.xyz
PING smtp.xyz (192.168.10.100) 56(84) bytes of data.
64 bytes from smtp.xyz (192.168.10.100): icmp_seq=1 ttl=64 time=0.034 ms
64 bytes from smtp.xyz (192.168.10.100): icmp_seq=2 ttl=64 time=0.034 ms
64 bytes from smtp.xyz (192.168.10.100): icmp_seq=3 ttl=64 time=0.052 ms

Wie? Wieso IPv4? Wie gesagt, das ist das Standardverhalten. IPv4 wird den ULAs vorgezogen. Wenn Du also nicht ausschließlich ULAs (und keine IPv4) im DNS-Reply zurückbekommst, wird nur die IPv4 verwendet. Den Trick, den Maurice nennt, mal außen vorgelassen - dabei würdest Du den ULA-Clients die IPv4 niemals zeigen. Das bedeutet natürlich auch, dass diese Clients niemals irgendwelche IPv4 gezeigt bekommen - Zugriff auf IPv4-only Geräte im IoT Netz (z.B. schaltbare Steckdosen) ist damit dann per DNS-Name nicht mehr drin.

Über die IPv4-only Clients müssen wir nicht diskutieren, die nehmen ohnehin nur die IPv4-Adresse. Also:

Deine ULAs nutzen im LAN nichts - sie werden schlicht ignoriert, Du kannst sie ebensogut aus dem internen DNS löschen. Du nutzt bei LAN-internem Traffic de facto ausschließlich IPv4 - zumindest, wenn Du es "normal" per DNS probierst. Die Rahmenbedingungen habe ich in den Varianten genannt.

Den einzigen Effekt, den Du erzielst, ist, dass Du im LAN GUA vermeidest und stattdessen NAT66 benötigst. Warum das nützlich ist, ist mir immer noch unklar (außer, man will IPv6-only im LAN und muss dann für Github und andere IPv4-only Websites NAT machen).

[Zapad]

Ich habe für NAT64 noch nie einen guten Nutzen gefunden.

ich weiss nicht woher NAT64 (pfui) aufkommt aber in meinem Kontext habe ich immer NAT66 gemeint.

@n3
nutze die ULAS so wie du mags wenn es funktioniert und wenn ein ULA doch noch internet braucht kannst du ja immernoch NAT66 dazuschalten.

[Maurice]

@n3 Kannst Du so machen, wobei Du dann auch im Client-Netz GUA + ULA verwenden solltest.
IPv4-only-Clients am besten in ein eigenes IPv4-only-LAN packen. Über Tayga kannst Du dann die Brücke zu den IPv6-LANs herstellen.

Für einen Fünfer mehr würde ich definitiv das statische GUA-Präfix nehmen. Das hast Du zwar auch nicht bis in alle Ewigkeit, anders als z. B. eine Telefonnummer kann es nicht "portiert" werden und ist spätestens beim Provider-Wechsel weg. Aber ein manuelles Renumbering alle paar Jahre ist etwas völlig anderes als ein sich ständig änderndes dynamisches Präfix.

@meyergru

Den Trick, den Maurice nennt, mal außen vorgelassen - dabei würdest Du den ULA-Clients die IPv4 niemals zeigen. Das bedeutet natürlich auch, dass diese Clients niemals irgendwelche IPv4 gezeigt bekommen - Zugriff auf IPv4-only Geräte im IoT Netz (z.B. schaltbare Steckdosen) ist damit dann per DNS-Name nicht mehr drin.

Doch, natürlich. DNS64 (Unbound-Feature) synthetisiert AAAA-Records, falls es nur A-Records gibt. Und NAT64 (Tayga-Plugin) übersetzt zwischen IPv6 und IPv4. Mein Smartphone im IPv6-only-Netz greift so z. B. problemlos auf Smart Home-Kram im IPv4-only-Netz zu.

[meyergru]

@Maurice: Das hast Du aber einen ganz hübschen Stapel von Mechanismen beisammen, um "modern" zu sein. Bin gespannt auf das HOWTO dazu... ;-)

[Zapad]

Bitte ein paar beispiele für IP6-only Clients?

Bitte keine wo man Dualstack manuell deaktiviert.

Mmn. gibs es nur IP4-Only clients, zb meine Reolink Cams....

und wenn man Dualstack sowieso hat, ist man frei intern alles zu benutzen was man will.

[n3]

Schlimm wenn es nicht die eine Lösung gibt ;-) Verstehe ich es grob richtig, dass aktuelle zwei Ansätze diskutiert werden. Der eine zielt möglichst auf IPv6 only ab und bindet IPv4 dort ein, wo nötig. Führt aber zu einer komplexeren Konfiguration.
Der andere Ansatz ist Dual-Stack, was vielleicht nicht optimal ist, jedoch einfacher zu konfigurieren/betreiben.

Welche Vorteile hat Ansatz 1 und welche Nachteile Ansatz 2?

Gibt es einen Favoriten für mein Szenario (der initiale Aufwand mal außen vor gelassen):
- HomeLab
- Feste/Dynamisch IP Adresse möglich
- Mehrere Interfaces (Consumer-Clients, Server, Kameras, Außennetzwerk)
- proxmox mit opnsense, homeassistant, nextcloud, AdGuard, etc.
- Consumer-Clients sollten von am besten nahtlos von Außen auf homeassistant, nextcloud zugreifen können
- nextcloud sollte aber auch für Dritte verfügbar sein
- Prio 1 Sicherheit, Prio 2 Stabilität und Prio 3 Maintenance

P.S. Hab mich geirrt. Die feste IP kostet 10€  und ab dem 7. Monat dann 23€/mtl.

[Zapad]

Hast du DS-Lite?
kannst du ip4 nicht richtig nutzen? vllt. wäre sowas für dich nützlich:

https://www.feste-ip.net/fip-box/allgemeine-informationen/

[meyergru]

Schlimm wenn es nicht die eine Lösung gibt ;-) Verstehe ich es grob richtig, dass aktuelle zwei Ansätze diskutiert werden. Der eine zielt möglichst auf IPv6 only ab und bindet IPv4 dort ein, wo nötig. Führt aber zu einer komplexeren Konfiguration.
Der andere Ansatz ist Dual-Stack, was vielleicht nicht optimal ist, jedoch einfacher zu konfigurieren/betreiben.

Welche Vorteile hat Ansatz 1 und welche Nachteile Ansatz 2?

Gibt es einen Favoriten für mein Szenario (der initiale Aufwand mal außen vor gelassen):
- HomeLab
- Feste/Dynamisch IP Adresse möglich
- Mehrere Interfaces (Consumer-Clients, Server, Kameras, Außennetzwerk)
- proxmox mit opnsense, homeassistant, nextcloud, AdGuard, etc.
- Consumer-Clients sollten von am besten nahtlos von Außen auf homeassistant, nextcloud zugreifen können
- nextcloud sollte aber auch für Dritte verfügbar sein
- Prio 1 Sicherheit, Prio 2 Stabilität und Prio 3 Maintenance

P.S. Hab mich geirrt. Die feste IP kostet 10€  und ab dem 7. Monat dann 23€/mtl.

Wenn Du ein von außen erreichbares Homelab betreiben willst wäre eine feste IP von Vorteil (aber nicht zwingend - ich habe keine, nutze nur DynDNS für IPv4 und IPv6, da full Dual Stack). Ich betreibe alle die von Dir beschriebenen Sachen wie im Howto beschrieben. Sicherheit durch Betrieb der von außen erreichbaren Services in einer separaten DMZ, außerdem in den meisten Fällen per Reverse Proxy. Falls kein HTTPS, über Port forwarding (IPv4 und IPv6). Dadurch sind nur WAN IPv4 und IPv6 exponiert. Im LAN keine ULA, nur GUA per SLAAC und IPv4 ("old style"). Konkret über RADVD und Kea DHCP mit Unbound.

Das erlaubt IPv4-only Clients (und Server - die müssen bis auf nicht-proxy-fähige Dienste ja sowieso nur IPv4 können, weil ich im Reverse Proxy eh nur IPv4 nach innen nutze).

Sicher, keine Tricksereien, kein Tayga, kein NAT66, VLANs straightforward mit IPv4/24 und IPv6/64, keine Pflege von internem DNS mit IPv6 (nur IPv4). Funktioniert auch für IPv4-Clients.

Potentielle Nachteile:

a. Geräte, die keine Privacy Extensions unterstützen, telefonieren mit Ihrer festen EUI-64 nach außen
b. old style, d.h. nicht "IPv6 first"

DS-Lite ist ein separates Thema, weil man sich dann Gedanken machen muss, wie man Dienste nach außen per IPv4 verfügbar macht, was auf Tunnellösungen hinausläuft.

[Maurice]

Das hast Du aber einen ganz hübschen Stapel von Mechanismen beisammen, um "modern" zu sein.

"Modern zu sein" ist nicht die Motivation. Es geht darum, frühzeitig Erfahrungen mit Technologien zu sammeln, die mittelfristig unser aller Alltag sein werden. Und es hilft dabei, ein kleiner Teil der Lösung zu sein und nicht des Problems. Das Problem ist, dass zu viele warten, bis andere vorangehen und die Steine aus dem Weg räumen. So kommen wir aber nicht voran. Und gerade das Heimnetz / Home Lab ist prädestiniert für Bleeding Edge, denn kritische Infrastruktur ist das eher selten.

Bin gespannt auf das HOWTO dazu.

Das How-to zu DNS64 / NAT64 mit Tayga und Unbound habe ich vor Jahren geschrieben, das ist Teil der OPNsense-Doku.
Die Geschichte mit BIND als authoritativem DNS-Server für die internen Zonen und Unbound als rekursivem Resolver mit DNS64 und Forwarding zu BIND ist fast trivial, aber vielleicht ist das nur die Innenperspektive. ;)
Der Weg war tatsächlich steinig, so manches OPNsense-Feature musste erst implementiert und der eine oder andere Bug gefixt werden. Im jetzigen Zustand ist es aber relativ einfach zu konfigurieren. Vielleicht schreibe ich mal ein How-to für das Gesamtpaket.

Schlimm wenn es nicht die eine Lösung gibt

Die Qual der Wahl. Es gibt mehrere passable Lösungen und viele schlechte. ;)

Verstehe ich es grob richtig, dass aktuelle zwei Ansätze diskutiert werden. Der eine zielt möglichst auf IPv6 only ab und bindet IPv4 dort ein, wo nötig.

Richtig.

Führt aber zu einer komplexeren Konfiguration.

Einerseits komplexer durch DNS64 / NAT64 und ggfs. etwas mehr DNS-Konfiguration, andererseits einfacher dadurch, dass es in jedem Netz nur einen Stack gibt - entweder IPv6 oder IPv4. D. h. jeweils nur ein Satz Firewall-Regeln, entweder RAs + ggfs. DHCPv6 oder DHCPv4 etc. Was man unterm Strich präferiert ist eine individuelle Entscheidung.

Der andere Ansatz ist Dual-Stack, was vielleicht nicht optimal ist, jedoch einfacher zu konfigurieren/betreiben.

Es ist die konservativere, etablierte Lösung.

Welche Vorteile hat Ansatz 1 und welche Nachteile Ansatz 2?

Möchtest Du zwei Schritte vorausgehen und nimmst dafür den etwas holprigeren Weg auf dich? Dann Ansatz 1.
Gehst Du lieber zwei Schritte hinterher und hast dafür eine gut dokumentierte, ausgereifte Konfiguration? Dann Ansatz 2.
Beide Wege sind legitim.

Die feste IP kostet 10€  und ab dem 7. Monat dann 23€/mtl.

Wäre mir persönlich auch zu teuer, ist aber wieder eine individuelle Entscheidung. Privat habe ich momentan auch nur ein dynamisches Präfix, einzig aus Kostengründen. Das erfordert schon einige Klimmzüge mit ULAs, DynDNS etc. Bei meinem vorherigen ISP hatte ich ein quasi statisches Präfix und das war wirklich wesentlich einfacher zu handhaben.

nutze nur DynDNS für IPv4 und IPv6

Von außen ist mein Heimnetz ausschließlich über IPv6 erreichbar (zur Zeit ebenfalls per DynDNS). Macht es auch wieder einfacher und reicht für meine Anforderungen völlig, spätestens seit es IPv6 hierzulande in allen Mobilfunknetzen gibt. Und falls mein ISP morgen auf DS-Lite umstellt bzw. €€€ für "Premium Dual Stack" möchte, dann bin ich tiefenentspannt und sage: Mach doch, kannst IPv4 gerne abschalten.