Eigener DNS bei einer IPv6 Konfiguration

[Maurice]

@meyergru Das ist jetzt vielleicht nicht der richtige Ort, um IPv6-Only Preferred im Detail zu erläutern; ist auch umfassend dokumentiert.

Kurzform: Dual Stack-Netz mit zusätzlich DNS64 und NAT64. Der DHCPv4-Server teilt den Clients mit, dass in diesem Netz IPv6-only bevorzugt wird. Clients, die das unterstützen brechen DHCPv4 dann ab und verwenden ausschließlich IPv6. Clients, die das nicht unterstützen verwenden ganz klassisch IPv4.

[Patrick M. Hausen]

Wenn man IPv6-Only Preferred verwendet (also die entsprechende Option im DHCPv4-Server konfiguriert

Jetzt verstehe ich was du meinst. Ein designiertes "IPv6 mostly" Netzwerk. [1]

Aber das habe ich halt nicht. Und auch meine Empfehlung dem OP gegenüber basiert auf der Annahme, dass man DHCPv4 und SLAAC im betrachteten Netz vollständig kontrolliert und dann ist dual stack einfach gut nachvollziehbar und bequem.

[1] https://www.ietf.org/archive/id/draft-link-v6ops-6mops-01.html

[Maurice]

@Patrick Ja richtig, das meinte ich. Und stimmt, IPv6-Only Preferred ist nur der Name der DHCPv4-Option, was natürlich nur ein Baustein des ganzen ist. Sorry für die Konfusion.

Auch wenn man das jetzt noch nicht hat, dann ist es doch nur eine Frage der Zeit. Falls man nicht direkt auf IPv6-only mit DNS64 / NAT64 geht. Wieso es dann nicht gleich richtig machen und DNS auch über IPv6 ermöglichen?

Wir wollen doch nicht die nächsten 20 Jahre weiterhin klassisches Dual Stack fahren.

[meyergru]

Das mit dem klassischen Dual-Stack sehe ich auch noch so wie Patrick.

Darüber hinaus haben meine Experimente mit der DHCP option 108 (RFC 8925) mit Kea zumindest bei Windows 11 (noch) nicht funktioniert. Der Client-PC holt sich immer (auch) eine IPv4.

Wenn das besser unterstützt würde, könnte man drüber nachdenken. Allerdings muss man dann im internen DNS beide Varianten (IPv4/6) pflegen, damit alle Clients die Services finden - also Mehraufwand.

[Maurice]

Das zeichnet IPv6-Mostly ja aus (jetzt verwende ich den richtigen Namen): Es funktionieren alle Clients, auch die, die die DHCPv4-Option noch nicht unterstützen oder noch kein CLAT haben (Windows) und sogar die, die gar kein IPv6 unterstützen. Man muss daher mit dem Rollout nicht warten, bis alle Clients IPv6-only unterstützen.

In der internen DNS-Zone benötigt man natürlich A- und AAAA-Records, das ist nicht anders als im öffentlichen DNS.

[meyergru]

Oha. Da kommt aber (theoretisch) viel Arbeit auf einen zu, wenn man dem internen DNS die IPv6 (und zwar aus den genannten pragmatischen Gründen ULAs) hinzufügen will:

a. Wie ich gerade feststelle, wird die IPv6 bei Windows aus einer (zufälligen) DUID abgeleitet. Das bedeutet, ich kann die ULA nicht einmal aus den vorhandenen MAC-Daten für die DHCPv4-Reservierungen ableiten. Es sei denn, ich ändere auf den Windows-Clients per Registry-Setting die Einstellungen so, dass die Ableitung aus der MAC erfolgt, so dass man zumindest die EUI-64 vorab zentral kennt. Das könnte im Extremfall bedeuten, dass ich die DNSv6-Einträge alle nochmal händisch erfassen muss, nachdem ich auf jedem Client die tatsächliche ULA ausgelesen habe. Keine Ahnung, wie Android das macht, aber IOS nimmt m.W. auch eine zufällige EUI-64, wenn man es nicht abschaltet (und das nicht nur für ausgehende Verbindungen mit privacy extensions).

b. Automatisiert kann man die Einträge sowieso nicht so einfach erzeugen, weil man für Nicht-IPv6-fähige Geräte und Services keine DNSv6-Einträge machen will - sonst würden die IPv6-only Clients auf Fehler laufen, weil sie ja dann bevorzugt IPv6 versuchen würden. Wobei: das gälte nur für GUAs, siehe nächster Punkt.

c. Bei ULAs ist es so, dass die ja überraschenderweise niedriger priorisiert werden als IPv4. Wenn also beide Einträge existieren, bringt das rein gar nichts, denn die IPv4 wird der ULA IPv6 immer vorgezogen. IPv4-only Clients nehmen sowieso nur IPv4, und solange diese noch existieren, werden die IPv4-DNS-Einträge auch noch gebraucht - es wäre nicht einmal eine Option, die Einträge exklusiv nur für IPv4 oder IPv6 zu machen.

d. Differenzieren müsste man für echte Services sowieso, denn wenn die per DHCP-Option 108 IPv6-only gesetzt werden, sind sie für IPv4-only Clients nicht mehr erreichbar. M.W. unterstützt Kea DHCP auf OpnSense eine Client-spezifische Steuerung der Option 108 nicht - solche Services müssten also statisch auf Dual-Stack konfiguriert werden.

Ergo: Alle Clients nutzen sowieso nur den IPv4-Teil des DNS-Eintrags. Dann kann ich mir die lokalen IPv6-Einträge im DNS also gleich sparen.

Offenbar wird das also nix bei mir mit "IPv6-mostly" - m.E. klappt das erst gut mit "IPv6 only".

Sorry für Off-Topic, aber wie gesagt, ich versuche nur gerade, das Big Picture zu erfassen (die klassische Version mit internem IPv4 kenne ich).

[Patrick M. Hausen]

Wenn Du in einer Windows-Domäne lebst, werden die Clients authentifiziert DNS-Updates an die Domänen-Controller schicken. Ich nehme fest an, das schließt heutzutage auch IPv6 ein.

Kea unterstützt DDNS-Updates ebenfalls für beide Protokolle, wobei ich noch nicht recherchiert habe, ob RFC 2137 auch AAAA Records einschließt, Kea für IPv6 was eigenes macht, oder es einen Nachfolger/Ergänzung für RFC 2137 gibt ...

Spannendes Thema. :-)

[n3]

Ja, so ist es. Du zeigst in Deinen Screendumps ja gar nicht, welchen DNS-Server Du verwendest. Ruf mal "ipconfig /all" auf, dann sieht Du es.
Dort sollte, wenn es nur einen per DHCPv4 verteilten Server gibt, auch nur eine IPv4 dafür geben.

OK, habs eben geprüft und als DNS ist einmal die IPv4 vom ADG und einmal die IPv6 vom LAN-Interface (also die IPv6 die ich im Dashboard der opnsense auch unter dem LAN-Interface sehe)

Wenn dein Client nur genau einen IPv4-DNS-Server kennt, benutzt er auch nur den. Dann sorg dafür, dass das dein AGH ist und das Problem ist gelöst. Habe ich hier überall genau so am laufen.

Ja mit IPv4 war das auch so und lief ohne Problem. Da meine Clients nun IPv6 haben, habe ich eben gesehen, dass das LAN Interface als DNS eingetragen ist und somit geht es am ADG vorbei.

Bei Anschlüssen mit dynamischem Präfix hat es sich bewährt, auf den LAN-Interfaces zusätzlich Virtual IPs (IP Alias) mit ULAs zu konfigurieren. So bekommt jedes Gerät automatisch auch eine ULA (über SLAAC). Die ULA des DNS-Servers kann man dann über RAs und DHCPv6 verteilen.

Ja ich glaube das geht in die Richtung, wie ich es dachte. Nur wollte ich die IPv6 am Server vergeben. Mit ULAs klingt es sauberer. Verstehe ich das Richtig, dass meine Clients im LAN eine temporäre IPv6 über das WAN bekommen. Diese Adresse ist eher für das Internet gedacht. Lokal nutze ich aktuell IPv4, aber mit ULAs gebe ich den Clients im LAN und im ADMIN Netz lokal IPv6 Adressen zu lokalen Kommunikation. Die ULA vom ADG konfiguriere ich dann als DNS über RAs im Modus Stateless.
Richtig?

Ich versuche eurer Diskussion zu folgen, aber es ist schwer, wenn man das Thema nur privat verfolgt. Ich könnte bei mir auch komplett auf IPv6 sogar mit einer festen IPv6 gehen, aber dann ist das Thema mit Datenschutz im privaten Umfeld so eine Sache.

[meyergru]

@n3: Im RADVD (falls Du den nutzt) kannst Du die Option "Do not send any DNS configuration to clients" setzen - wie gesagt, ich nehme nur SLAAC, keinen DHCPv6. Damit kommt dann kein DNSv6-Server mehr an. So auch das oben verlinkte HOWTO. Das funktioniert - alles, was wir hier diskutieren, ist offenbar komplexer als man sich das so zuerst vorstellt. Mir fehlt bislang jedenfalls das HOWTO, das das lückenlos beschreibt.

Und: Die ULA wird bei DS-Betrieb nie verwendet, solange der Name auch auf eine IPv4 auflöst... das würde m.E. nur mit IPv6-only funktionieren, nicht mit IPv6 mostly. Solange Du dynamische IPv6-Präfixe und IPv4-only Clients hast, wird das nix.

@Patrick: Ich nutze weder Windows-Domänen noch DHCPv6. M.W. unterstützen Android-Clients (und manche andere) auch nur SLAAC für die IPv6-Zuweisung - ich weiß allerdings nicht, ob das aktuell immer noch so ist. D.h., aktuell arbeite ich mit einer festen Reservierung MAC -> IPv4. IPv6 wird eigentlich nur für Outbound genutzt, inbound nehme ich sowieso meist einen Reverse Proxy, deshalb brauche ich da die IPv6 selten.

[Bob.Dig]

und einmal die IPv6 vom LAN-Interface (also die IPv6 die ich im Dashboard der opnsense auch unter dem LAN-Interface sehe)

Aber warum, das solltest Du ja verhindern, in dem Du die Sense entsprechend konfigurierst.

Du kannst natürlich dem AGH auch eine ULA geben, aber auch die müsstest Du dann verteilen und die Sense entsprechend konfigurieren, im Endeffekt nicht einfacher, eher das Gegenteil.

[n3]

@meyergru
Ich habe dein HowTo damals verwendet und eben die Option im RA aktiviert. Der DNSv6 wird nicht mehr ausgeliefert und es scheint alles über den ADG zu gehen.

Somit sollte es jetzt passen.

Aber damit ich es richtig verstehe... Ich rufe z.B. eine Webseite auf und die Kommunikation läuft eigentlich über IPv6. Dennoch geht mein Client über IPv4 an den ADG da dieser als DNSv4 konfiguriert und bekannt ist und löst auch entsprechend auf. Ich dachte, dass wenn die Kommunikation über IPv6 läuft, der DNS auch über v6 bekannt sein muss.

[Maurice]

Wie ich gerade feststelle, wird die IPv6 bei Windows aus einer (zufälligen) DUID abgeleitet.

Zufälliger Interface Identifier, der bei der Installation der NIC generiert wird. DUID ist der Device Identifier für DHCPv6.

Das könnte im Extremfall bedeuten, dass ich die DNSv6-Einträge alle nochmal händisch erfassen muss, nachdem ich auf jedem Client die tatsächliche ULA ausgelesen habe.

Man benötigt doch nicht für jeden Client DNS-Einträge, sondern nur für Dienste, die im lokalen Netzwerk angeboten werden. Möchte man aus grundsätzlichen Überlegungen alle Clients zentral erfassen, dann gibt es dafür bessere Mechanismen, wie das von Patrick genannte AD mit DNS- und DHCPv6-Integration oder eine dedizierte Device Management-Lösung.

Bei ULAs ist es so, dass die ja überraschenderweise niedriger priorisiert werden als IPv4.

Kommt auf die konkrete Implementierung an, ist aber zum Teil leider so. Das ist aber nicht in Stein gemeißelt; es gibt neuere RFCs, die das ändern möchten.
A-Records benötigt man nur für Dienste, auf die wirklich noch per IPv4 zugegriffen werden muss. Und möchte man ganz konsequent sein, dann verwendet man kein IPv6-Mostly, sondern separate Single Stack-Netze für IPv6 und IPv4. So habe ich es bei mir im Heimnetz gelöst.

Differenzieren müsste man für echte Services sowieso, denn wenn die per DHCP-Option 108 IPv6-only gesetzt werden, sind sie für IPv4-only Clients nicht mehr erreichbar.

Server wird man in der Regel statisch konfigurieren. Falls man dafür DHCPv4 verwenden möchte, dann könnte man auf den betroffenen Servern den DHCP-Client so konfigurieren, dass er Option 108 ignoriert.

Verstehe ich das Richtig, dass meine Clients im LAN eine temporäre IPv6 über das WAN bekommen. Diese Adresse ist eher für das Internet gedacht. Lokal nutze ich aktuell IPv4, aber mit ULAs gebe ich den Clients im LAN und im ADMIN Netz lokal IPv6 Adressen zu lokalen Kommunikation. Die ULA vom ADG konfiguriere ich dann als DNS über RAs im Modus Stateless.

Ja richtig, bzw. eigentlich im Modus "Unmanaged". Falls Du "Stateless" verwenden möchtest, dann muss zusätzlich noch der DHCPv6-Server entsprechend konfiguriert werden.

Ich könnte bei mir auch komplett auf IPv6 sogar mit einer festen IPv6 gehen

Falls Du die Möglichkeit hast ein statisches IPv6-Präfix zu bekommen, dann solltest Du das auf jeden Fall tun. Das erspart auch an vielen anderen Stellen Kopfschmerzen.

Ich dachte, dass wenn die Kommunikation über IPv6 läuft, der DNS auch über v6 bekannt sein muss.

Das ist unabhängig voneinander. Der Client kann einen DNS-Server auch über IPv4 nach einem AAAA-Record fragen. Also Kommunikation zwischen Client und DNS-Server über IPv4 und dann Kommunikation zwischen Client und z. B. Web-Server über IPv6.

[meyergru]

Andere Lösungen heißt zumindest bei mir: zusätzliche Lösungen. Ich habe kein Problem damit, die Mechanismen von IPv4 auf IPv6 umzustellen, wenn das aber bedeutet, für alle möglichen Features zusätzliche Mechanismen oder spezifische Geräte-Konfigurationen (Umstellung von DHCP-Verhalten am Server, Registry-Edits auf Windows-Clients, Umstellungen an Android und/oder IOS-Geräten, separate IPv4- / IPv6-Netze) einsetzen zu müssen, bin ich aus Aufwandsgründen raus - für mich persönlich besteht der Ansatz dann den Lackmustest nicht.

Das mag in Business-Umgebungen anders sein, wo AD, LDAP, Windows-Domänen, 802.1x oder IPAM sowieso schon am Start sind. Bei mir ist das mit "IPv4 im LAN" und "IPv6 outbound only" aber anders: Da brauche ich - und zwar nur auf der OpnSense - eine einfache Zuordnung MAC -> IPv4 -> DNS-Einträg(e) und kann damit alles erschlagen.

Es wäre wahrscheinlich auch anders, wenn sich die ISPs nicht auf diese blöde dynamische IPv6-Zuweisung eingeschossen hätten oder langfristiger, wenn IPv6-only eine echte Option darstellt.

[n3]

Falls Du die Möglichkeit hast ein statisches IPv6-Präfix zu bekommen, dann solltest Du das auf jeden Fall tun. Das erspart auch an vielen anderen Stellen Kopfschmerzen.

Im betrieblichen Kontext verstehe ich das, aber im privaten Kontext verlieren ich dann viel an Privatsphäre.