joru1407
Goto Top

Windows DNS Server mehrere AAAA Records im IPv6 Netzwerk

Hallo zusammen,

mich beschäftigt zur Zeit folgendes Problem:

Ein Netzwerk ist vollständig IPv4 und IPv6 fähig. IPv4 läuft wie üblich in einer privaten Range via NAT.
Für IPv6 habe ich folgenden Weg gewählt: Unser Router erhält vom Provider ein /56er Präfix und verteilt daraus ein /64er Präfix per SLAAC an alle Clients.
Um bei einem Wechsel des GUA Präfixes (bspw. Providerwechsel) nicht vor Problemen zu stehen, haben wir ebenfalls ein /64er ULA (Unique Local Address) Präfix generiert.

Jeder Client erhält also im Endergebnis:
1x IPv4 Adresse
1x IPv6 Link Local Address
1x IPv6 Unique Local Address
1x IPv6 Global Unicast Address

Im Windows DNS Server der Domäne wird nun ein A Record auf die IPv4 Adresse angelegt. Für die IPv6 Link Local scheint der Windows DNS keine Einträge anzulegen. Für die ULA wird ein AAAA Record angelegt. Für die GUA wird (leider) ebenfalls ein AAAA record angelegt.

Somit ergeben sich zwei AAAA Records für einen Client / DNS-Namen.

Auf der einen Seite finde ich das nicht wirklich sauber, auf der anderen Seite bereitet uns das Probleme:

Clients greifen auf einen Server der per DNS aufgelöst wird nun manch mal über seine GUA Adresse zu, manch mal über seine ULA Adresse.
Gerade bei Webservern und auch bei einigen anderen Diensten sorgt das schnell für Probleme, wenn der jeweilige Port nur für eine IPv6 lauscht.

Insgesamt würden wir uns intern gerne ausschließlich auf die ULA's beschränken und die GUA's nur für Webzugriff nutzen, um von öffentlichen Präfixen unabhängig zu bleiben.
Bisher habe ich aber keine Möglichkeit gefunden, den Windows DNS Server dazu zu bringen, ausschließlich einen AAAA Record für die ULA anzulegen und die GUA genau so wie die Link Local zu ignorieren.

Geht das? Wie löst Ihr das?

Viele Grüße
Joshua

Content-ID: 448814

Url: https://administrator.de/contentid/448814

Ausgedruckt am: 25.11.2024 um 09:11 Uhr

lcer00
lcer00 09.05.2019 um 08:12:49 Uhr
Goto Top
Hallo,

an einem ähnlichen Dilemma bastle ich schon eine Weile: IPv6 Konfiguration von Site-Site-VPN ohne feste IP - vielleicht hilfts weiter.

Mein Fazit:

ULAs sind vermutlich keine Lösung. Das Konzept der 64-bit IPv6-Adressen schließt die These ein, dass es genug IP-Adressen für alles gibt. siehe auch https://tools.ietf.org/html/rfc4193 - ULAs sind quasi ein Add-ON für IPv6 für spezielle Fälle, aber eben nicht die primäre Empfehlung.

Der Präfixwechsel durch den Provider hingegen dürfte kein Problem sein, da genau hierfür die Möglichkeit in IPv6 vorgesehen ist, mehrere Adressen an einen Node zu haben.

Grüße

lcer
aqui
aqui 09.05.2019 um 12:08:08 Uhr
Goto Top
ULA ist ganz sicher keine Lösung, denn das sind Adressen die im Internet nicht geroutet werden. Da es bei v6 kein NAT gibt schafft das erhebliche Probleme. Das sind einzig nur Adressen für ein isoliertes Spiel- und Testnetzwerk, niemals aber etwas für ein produktives Netz.
Es macht nur Sinn den per PD vom Provider vergebenen Prefix als /64 im lokalen LAN weiterzugeben. SLAAC only hat den Nachteil das dort keine v6 Resolver Adresse propagiert wird an die Clients. Damit scheitert dann in der Regel ein v6 DNS Request. Besser ist es DHCPv6 zu verwenden. Siehe auch hier:
Cisco 880, 890 und ISR Router Konfiguration mit xDSL, Kabel oder FTTH Anschluss plus VPN und IP-TV
Ist zwar Cisco bezogen, gilt aber analog auch für alle anderen Router und Firewalls.
JoRu1407
JoRu1407 09.05.2019 um 12:41:01 Uhr
Goto Top
Hallo aqui,

das sehe ich - zumindest bisher - etwas anders:

ULA's führen ja nicht zwangsläufig zu einem v6 NAT. Letztendlich erhält natürlich jeder Client eine GUA Adresse und hat damit auch Internetzugriff. Die ULA's sehe ich persönlich eher als Ergänzung - Öffentlich können die natürlich nicht geroutet werden, aber intern können Sie eben schon geroutet werden und sind damit im Vergleich zu den link-local Adressen auch über VPN's und über verschiedene Subnetze hinweg nutzbar.

Aus meiner Sicht ergibt sich damit eine gewisse Unabhängigkeit von Providern. Schließlich möchte ich ja nicht, dass mein Netzwerk still steht wenn der Provider wechselt oder plötzlich vom Markt verschwindet. Zwar kann man seinem Unternehmen auch ein festes Präfix zuteilen lassen, aber ich rede hier größtenteils nicht von Großkunden sondern von kleineren Netzen. Auch der Provider muss mir mein Firmen-Subnetz ja erst mal weiterreichen können und wollen... :/

Ist der DNS Server bei SLAAC nicht i.d.R. automatisch über seine DNS Multicast Adresse erreichbar?

Korrigiere mich gerne, nur bisher war ich der Meinung das ULA's als ergänzende Adressierung sinnvoll sind.

Viele Grüße
Joshua
JoRu1407
JoRu1407 09.05.2019 um 12:55:16 Uhr
Goto Top
Hallo Icer,

danke für deine Antwort und für deinen Beitrag!
Das deckt sich letztendlich mit meinen Beobachtungen, die du sehr ausführlich beschrieben hast.

Ich hatte für mich entschieden dass die Prefixpolicies keine Lösung sind, da ich ungern jeden Client anpacken möchte um etwas lauffähig zu kriegen. Android, Apple und sonst was macht dann u.U. ja auch noch Probleme.

Aus meiner Sicht wäre es demnach also schön das Problem "an der Wurzel" zu packen:

Wenn der DNS nur einen passenden AAAA zurückliefern würde, wäre das Problem erledigt. Das manuelle Eintragen der Hosts ohne automatische DNS Publizierung war bisher die einzige Möglichkeit die mir in den Sinn gekommen ist, schön ist aber leider anders.

Sehe ich den Präfixwechsel eines Providers wirklich zu kritisch?
Wenn ich nen DB Server, nen Drucker o.ä. irgendwo per IPV6 Adresse anspreche - Dann muss ich bei einem Präfixwechsel doch sämtliche Druckertreiber, Datenbank-Connections etc. abändern, oder?
aqui
aqui 09.05.2019 aktualisiert um 13:14:20 Uhr
Goto Top
ULA's führen ja nicht zwangsläufig zu einem v6 NAT.
Das ist richtig. Es sollte ja auch nur anmerken das diese Adressen rein nur lokal bzw. intern nutzbar sind. Das wäre dann aber wieder Unsinn denn du hast ja so oder so die Unique Local Unicast Adressen. Die haben dann auch noch den Vorteil das sie nicht rausgeroutet werden können. OK zugegeben die nützen nix in einem segmentierten Netz.
Wenn du dazu noch ein offizielles Provider Subnetz per PD bekommst welchen tieferen Sinn sollten dann ULAs noch haben. Wäre nur eine sinnfreie Verkomplizierung des lokalen v6 Adressschemas ohne Grund.
Um Unabhängigkeit vom Provider zu bekommen lässt du dir offiziell immer fest einen Prefix zuteilen. Kein Mensch der ein strukturiertes und segmentiertes v6 Netzwerk hat macht sich von PDs vom Provider abhängig. Was die Abhängigkeit anbetrifft hast du also Recht, keinen Frage. Nicht was die Adressierung anbetrifft.
Ein offizielles v6 Subnetz bekommst du heute ohne Probleme wozu dann also so ein halbgares Konzept mit ULA Adressen was so oder so wieder verworfen wird und dann wieder einen Eingriff erfordert.
Aber ok, es gibt da sicher unterschiedliche Ansichten über ein ToDo.
Hilfreich ist da: https://www.amazon.de/IPv6-Address-Planning-Designing-Future/dp/14919027 ...
lcer00
lcer00 09.05.2019 aktualisiert um 14:31:06 Uhr
Goto Top
Hallo,
Zitat von @JoRu1407:

Sehe ich den Präfixwechsel eines Providers wirklich zu kritisch?
Wenn ich nen DB Server, nen Drucker o.ä. irgendwo per IPV6 Adresse anspreche - Dann muss ich bei einem Präfixwechsel doch sämtliche Druckertreiber, Datenbank-Connections etc. abändern, oder?

Na ja, ich glaube der Grundgedanke hinter IPv6 ist ein anderer als hinter IPv4. IPv4 war im Grunde das primäre Internetprotokoll, da ist eine Menge dazugekommen. Zum Beispiel DNS. face-smile Die Entwickler von IPv6 gingen sicherlich davon aus, das eine saubere DNS-Infrastruktur existiert (nebenbei, wie hieß noch mal die alte Namensauflösungsdingens …. ach ja WINS face-smile ). Auch wenn IPv6 natürlich ohne DNS lauffähig ist.

Der Präfixwechsel erfolgt unmittelbar - wird quasi ins Netzwerksegment hineingeschmissen. Die nodes sollten sich dann beim DNS-Server neu registrieren und die aktualisierte Adresse wird ausgegeben. DynDNS funktioniert doch auch (eigentlich …. meistens ….).

Problem entstehen durch fehlerhafte Implementationen der Protokolle. Ich würde auch nicht jedem Drucker zutrauen, dass er den Präfixwechsel sofort weitermeldet.

Nochmal, IPv4 ist historisch im arpanet verwurzelt. IPv6 ist eine komplette Neuentwicklung. Den Wechsel sieht man zum Beispiel gut, wenn man mal die Unterschiede zwischen DHCPv4 und DHCPv6 anschaut. Das ist ein völlig anderes Konzept! Deshalb dürfen wir bei Implementation von IPv6 nicht 1:1 die IPv4 Strukturen übernehmen. ULAs sind die Entsprechungen für private IPv4-IPs aber im IPv6-Kontext entbehrlich.

lies mal https://de.wikipedia.org/wiki/IPv6#Unique_Local_Unicast und insbesondere https://de.wikipedia.org/wiki/IPv6#Site_Local_Unicast_(veraltet) Wir würden gerne private IPs verwenden. Dafür waren einmal Site Local Unicasts vorgesehen - die wurden aber verworfen! und jetzt wollen wir stattdessen ULAs verwenden, um sie doch noch zu realisieren? Das ist so bei IPv6 nicht vorgesehen!

Ich befürchte wir müssen da halt den Blickwinkel ändern und das Gesamtkonzept überdenken. Und zur Not muss langfristig auch Hardware getauscht werden, wenn der Hersteller keine saubere Implementation liefert.

Grüße

lcer

Edit: soll natürlich heißen, dass es keine Probleme gibt, wenn man FQDNs anstelle von IP-Adressen verwendet.
JoRu1407
JoRu1407 10.05.2019 um 14:27:13 Uhr
Goto Top
Hallo zusammen,

Eure Aussagen nach sollte ich mich also lieber wieder von den ULA's trennen, und stattdessen eher auf ein sauberes DNS Setup setzen?
Klar, letztendlich würden so die tatsächlichen IPv6 Adressen nahezu irrelevant und man würde hauptsächlich nur noch via DNS arbeiten.

Nun aber die Frage: Windows Clients registrieren sich schön beim DNS Server. Aber wie schaut's denn mit Druckern, Kameras und anderen typischen Netzwerkgeräten aus, die nicht Mitglied der Domäne sind? Derzeit müsste ich für solche Geräte ja jeweils statische DNS Records anlegen und diese auch alle anpassen, wenn sich das Präfix ändert.

Wenn alle Geräte die per SLAAC eine IPV6 Adresse erhalten auch vom DNS Server registriert würden, könnte ich mich mit reinen GUA Adressen anfreunden, solange der Präfixwechsel dann auch noch problemlos funktioniert. Wenn nur einzelne Geräte mit Präfixwechseln Probleme haben, dann müsste man eben wirklich über einen Austausch nachdenken.

Viele Grüße
Joshua
aqui
aqui 10.05.2019 um 19:10:42 Uhr
Goto Top
Kein v6 Endgerät "registriert" sich beim DNS Server ! Da hast du wohl grundlegend was verwechselt ! Woher hast du diese "Weisheit" ??
Du solltest besser mal was zu den IPv6 Grundlagen der Adressverteilung lesen.
Empfehlenswert ist die folgende kostenlose Lektüre:
https://danrl.com/projects/ipv6-workshop/
JoRu1407
JoRu1407 10.05.2019 um 21:25:10 Uhr
Goto Top
Hallo aqui,

mit den Grundlagen von IPv6 bin ich soweit vertraut, ansonsten würde ich mir keine Gedanken um die Nutzung von ULA's, GUA's und Proider(un)abhängigkeit oder über die Einführung von IPv6 machen.

Meine Geräte erhalten eine IPv6 Adresse. Die link-local generieren sie selbst. Die GUA kommt entweder per SLAAC oder per DHCPv6.
Das hat aber erst mal nichts mit einem DNS Server meiner Windows Domäne zu tun.

Bei Windows Clients ist in den erweiterten IPv6 TCP/IP Einstellungen standardmäßig die Option "Adressen dieser Verbindung in DNS registrieren" gesetzt. Ich denke in diesem Zusammenhang kann man dann auch klar von "registrieren" sprechen, oder?

Die Geräte erhalten ein oder mehrere IPv6 und propagieren/registrieren diese am DNS Server Ihrer Domäne.
Der DNS Server erstellt aber definitiv keine generischen AAAA (oder auch A Records) für andere Netzwerkgeräte, sondern ausschließlich für unterstütze Domainmitglieder. Für alle anderen IPv6 Geräte müssten also manuelle AAAA Einträge auf die jeweilige IP gesetzt werden - Und damit würde ich wieder einem Problem beim Präfixwechsel gegenüber stehen.
aqui
aqui 11.05.2019 um 11:01:42 Uhr
Goto Top
Das hat aber erst mal nichts mit einem DNS Server meiner Windows Domäne zu tun.
Da hast du zweifelsohne Recht !
OK, dein "Registrierungs" Einwand hat was mit dynamisch generierten IP Adressen bzw. Hostnamen zu tun. Das ist aber eine Sache die per se erstmal mit dem eigentlich DNS Prozess des Adress Lookups nichts zu tun hat.
Du meinst mit "Registrieren" ja nur das dynmaische Einfügen von dynmaischen DHCP Hostnamen in den DNS Server. Letztlich wie gesagt nichts wa smit dem eigentlichen Lookup Prozess als solchem zu tun hat denn das muss man ja nicht machen im DNS wenn man es nicht unbedingt will.
Aber OK, in dem Umfeld hast du natürlich dann Recht mit dem "registrieren".