Windows DNS Server liefert veraltete Records aus

boranto
Goto Top
Hallo zusammen,

ich wende mich heute mit einem Problem an euch, welches mir bereits seit längerem Kopfschmerzen bereitet.
Eigentlich ist meine ganzes Netzwerk eine Baustelle und nun versuche ich den Ursprung allen Übels zu finden.
Um so weiter ich grabe, desto mehr Fehler finde ich.
Die momentanen Herausforderungen sind:
  • IPv6 im lokalen Netz (DHCPv6 auf dem Windows Server funktoniert nicht und das RA auf der pfsense läuft nicht rund)
  • Richtige Einstellungen des DNS Servers inkl. DNS und IP Blacklist
  • Windows Firewall auf dem Domain Controller

netzwerkdiagram
Hierbei möchte ich mich zunächst mit den DNS-Einstellungen befassen, da diese ernorme Einschränkungen im Netzwerk verursachen.
Da ich bis heute IPv6 nicht fehlerfrei zum Laufen gebracht habe, ist dieses (momentan) vollständig abgeschaltet.

Aber hier zunächst der Aufbau meines Netzes:
Als Internetanbieter kommt Vodafone zum Einsatz. Der gewählte Tarif ist CableMax 1000/50 aus NRW, welcher mittels in den Bridge Modus versetzten Arris TG3442DE (aka Vodafone Station) an eine pfSense Firewall und Gateway weitergeleitet wird. Die pfSense erhält per DHCP (und DHCPv6) eine IPv4 bzw. eine IPv6/128 Adresse.

Als Domain Controller läuft ein Windows Server 2016 core, auf welchem die Rolle AD DC, AD CS, DNS und DHCP sowie Storage Server installiert sind. Zudem läuft (so halb) ein Unify Controller und von Schneider APC die PowerChute (Verwaltung der USV). Die Domain ist auch eine echte, mir gehörende, TLD. Wobei ich hier eine subdomain gewählt habe, welche auf dem Name Server des Domainanbieters nicht hintgerlegt wurde. Also kein .local, .arpa oder so, sondern subdomain.domain.com.

Auf der pfSense läuft der DNS Resolver, jedoch kein DHCP Server. Ich möchte lieber selbst die Root-Server anfragen und keinen externen upstream DNS-Server aka Google oder Quad9 nutzen. Bei dem Lesen von verschiedenen Empfehlungen komme ich zu dem Entschluss, dass die sauberste/beste Lösung ist, den DHCP und nur den DNS-Server vom Domain Controller an die Clients zu geben. Die pfSense soll dann als DNS forwarder in den Einstellungen des Windows DNS-Servers eingetragen werden.

Soweit so gut. Leider werden dann nicht alle Seiten erfolgreich im Browser aufgebaut bzw. deren Domainnamen richtig aufgelöst. Einige, wie z.B. google.com funktonieren, andere wie z.B. netflix.com jedoch nicht. Um eine Fehlkonfiguration der pfSense Firewall auszuschließen, sind Suricata, pfBlockerNG und squid vollständig deaktiviert. Wobei Suricata zuletzt eh nur im Alert Mode lief.

Ein nslookup netflix.com liefert mir tatsächlich von meinem Domain Controller (und dieser dann von der pfSense) mehre A und AAAA Records zurück:
Jetzt kommt aber der Knackpunkt ins Spiel. Richte ich mein nslookup an die Server von Google bzw. 1.1.1.1 kommen andere Ergebnisse zurück:

Befragt man jedoch centralops.net nach netflix.com, so kommen wieder andere Ergebnisse zustande:

domaindossier_netflix
Hier sehe ich jedoch zum ersten Mal, dass die TTL auf 60 Sekunden steht. Offenbar ist dies in meinem Fall das Problem.
netflix_ttl

ipconfig /displaydns auf einem Client liefert mir folgendes (gekürztes) Ergebnis:


Mein Domain Controller (bzw. pfSense) liefert mir (offenbar) einen zu alten A-Record zurück. Denn gebe ich am Client als DNS-Server einen von Google oder 1.1.1.1 ein, so funktoniert die Netflix Webseite wieder tadellos. Jedoch ist dann mein gesamtes Domainnetzwerk nicht zu verwenden (Roaming, UNC-Netzlaufwerke, etc.)

Ich bin immer davon ausgegangen, dass derDNS-Server die TTL berücksichtigt. Besonders da ich in der pfSense das Ausliefern von abgelaufenen DNS-Einträgen nicht aktivert habe.

Zunächst möchte ich jedoch sicherstellen, dass die Konstellation vom Domain Controller und pfSense unabhängig von dem Netflix Fehler richtig ist:
Ergänzend hierzu möchte ich anmerken, dass dies nicht nur bei Netflix passiert. Die Online-Funktion der Nintendo Switch ist ebenso die AliExpress Webseite sind beeinträchtigt.

Für eure Unterstüzung bin ich sehr dankbar.
services dns resolver general settings
services dns resolver advanced settings
dns-server config
dns server forwarders
dns root server

Content-Key: 1728644236

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

Ausgedruckt am: 18.05.2022 um 12:05 Uhr

Mitglied: ChriBo
ChriBo 16.01.2022 um 19:28:14 Uhr
Goto Top
Hi,
leider keine Lösung:
Die pfSense soll dann als DNS forwarder in den Einstellungen des Windows DNS-Servers eingetragen werden.
und welche DNS Server hast du in der pfSense eingetragen ? Wahrscheinlich die Server von Vodafone, ich erhalte hier bei einem nslookup netflix.com die gleichen Ergebnisse wie du (bin auch bei Vodafone).
Von der Performance und der Stabilität macht es mehr Sinn im DC direkt die DNS vom Provider einzutragen, anstelle den Resolver der pfSense.

bei mir löst 1.1.1.1 und 8.8.8.8 nach den gleichen IP Adressen wie der DNS von Vodafone aus und ich erhalte auch problemlos netflix.com im Browser angezeigt.

Was mich bei dir irritiert ist das du andere Ergebnisse bei 1.1.1.1 und 8.8.8.8 erhältst. Es sieht so aus als ob hier nicht Server in DE abgefragt werden.

Gruß
CH
Mitglied: lcer00
lcer00 16.01.2022 um 20:48:49 Uhr
Goto Top
Hallo,

eigentlich ist DNS nicht so problematisch. Entweder der Server liefert, oder eben nicht. Gelegentlich antwortet er zu langsam. Dann klappt meist der 2. Seitenaufruf. 60 Sekunden TTL sind im DNS auch kein Problem, Seiten wechseln selten schneller ihre IP :) face-smile

Ich glaube eher, das Problem liegt wo anders. Wie hast Du denn IPv6 deaktiviert? Auch auf den Clients?

Wenn Deine Clients vom DNS IPv6 und IPv4 Adressen ausgeliefert bekommen, versuchen sie zuerst, das Ziel per IPv6 zu erreichen ( wenn sie ein IPv6 Interface haben). Wenn es dann keine IPv6 Route zum Ziel gibt, wird erst nach dem Timeout versucht, die Verbindung über IPv6 herzustellen. Das ist Standart unter Windows und unter Linux.

Prüfe daher zuerst die Routen über IPv6 und IPv4 zu den Zielen.

Grüße

lcer
Mitglied: C.R.S.
Lösung C.R.S. 16.01.2022 um 21:23:23 Uhr
Goto Top
Hi,

deaktiviere die Strict QNAME Minimization in der pfSense.

Grüße
Richard
Mitglied: Boranto
Boranto 16.01.2022 aktualisiert um 22:50:45 Uhr
Goto Top
Zitat von @ChriBo:
und welche DNS Server hast du in der pfSense eingetragen ? Wahrscheinlich die Server von Vodafone, ich erhalte hier bei einem nslookup netflix.com die gleichen Ergebnisse wie du (bin auch bei Vodafone).

Ich möchte keinen Upstream Server in meinem Netz verwenden, sondern selbst die Anfragen an die Root-Server bzw. jeweiligen Name Server der Domains richten. Bei mir sind die Felder in der pfSense Box leer und "Allow DNS server list to be overridden by DHCP/PPP on WAN" ist deaktivert.
dns server settings

Zitat von @ChriBo:
Was mich bei dir irritiert ist das du andere Ergebnisse bei 1.1.1.1 und 8.8.8.8 erhältst. Es sieht so aus als ob hier nicht Server in DE abgefragt werden.

Meiner Auffassung nach sollten unabhängig vom Standort die identischen Ergebnisse ausgeliefert werden. Das Loadbalancing bzw. die Wahl des nächsten CDN erfolgt ja nicht auf DNS-Ebene (oder?)
Ich kann dir garnicht genau sagen, welche Server abgefragt werden. Ich gehe davon aus, dass die pfSense Box die offizellen Root Server (https://www.iana.org/domains/root/servers) anfragt. Wie kann ich dies prüfen?

Zitat von @lcer00:>
Ich glaube eher, das Problem liegt wo anders. Wie hast Du denn IPv6 deaktiviert? Auch auf den Clients?

Wenn Deine Clients vom DNS IPv6 und IPv4 Adressen ausgeliefert bekommen, versuchen sie zuerst, das Ziel per IPv6 zu erreichen ( wenn sie ein IPv6 Interface haben). Wenn es dann keine IPv6 Route zum Ziel gibt, wird erst nach dem Timeout versucht, die Verbindung über IPv6 herzustellen. Das ist Standart unter Windows und unter Linux.

Prüfe daher zuerst die Routen über IPv6 und IPv4 zu den Zielen.

IPv6 Habe ich zunächst nicht explizit deaktiviert. Besonders auf der Xbox und Switch gibt es hierfür keine Möglichkeit. In Windows habe ich bei den Clients in den Adaptereinstellungen den IPv6 Treiber deaktivert:
Für mich ergibt dies keinen Sinn, da ja bei Eingabe der Google DNS Server Netflix und Co. sofort funktoniert. Ich habe es jedoch gerade erneut getestet.

Auf der pfSense habe ich dem WAN und LAN Interface IPv6 Configuration Type "None" gegeben. Desweiteren habe ich unter System/Advanced/Networking "Allow IPv6
All IPv6 traffic will be blocked by the firewall unless this box is checked" den Haken entfernt.
Dann habe ich auf dem Windows Server IPv6 von static auf DHCP gestellt, die IPv6 DNS-Server entfernt (2a02:908 und ::1) und alles mal neu gestartet.
Ohne Erfolg.
server_ip_settings

Zitat von @C.R.S.:
deaktiviere die Strict QNAME Minimization in der pfSense.

Habe ich versucht, auch ohne Erfolg.

Folgende Domains haben das identische Problem:

netflix.com
aliexpress.com
sun.hac.lp1.d4c.nintendo.net (Nintendo Online Funktion)

Vielen dank für eure Unterstüzung, morgen wird dann weiter geforscht.
Mitglied: C.R.S.
C.R.S. 16.01.2022 um 23:15:33 Uhr
Goto Top
Zitat von @Boranto:

Zitat von @C.R.S.:
deaktiviere die Strict QNAME Minimization in der pfSense.

Habe ich versucht, auch ohne Erfolg.

Folgende Domains haben das identische Problem:

netflix.com
aliexpress.com
sun.hac.lp1.d4c.nintendo.net (Nintendo Online Funktion)

Da hat dir vermutlich das Caching einen Streich gespielt, denn Fehler mit diesen Domains sind charakteristisch für QNAME-Minimization und das Unterbinden des Fallbacks in der pfSense (DNS_PROBE_FINISHED_NXDOMAIN in Chrome). Oder du hast mehrere verkettete Fehler, jedenfalls werden sie mit dem Setting über die pfSense nicht funktionieren.
Mitglied: Boranto
Boranto 17.01.2022 um 10:57:24 Uhr
Goto Top
Zitat von @C.R.S.:
Da hat dir vermutlich das Caching einen Streich gespielt, denn Fehler mit diesen Domains sind charakteristisch für QNAME-Minimization und das Unterbinden des Fallbacks in der pfSense (DNS_PROBE_FINISHED_NXDOMAIN in Chrome). Oder du hast mehrere verkettete Fehler, jedenfalls werden sie mit dem Setting über die pfSense nicht funktionieren.

Dies kann tatsächlich sein. Obwohl ein löschen des DNS-Cache auf dem Server als auf den Clients gestern Abend keine Besserung gebracht hat. Heute Morgen lief jedoch alles wie von Zauberhand ohne Probleme.

Vielen Dank für deinen Hinweiß.
Jetzt steht als nächstes an, dass IPv6 vollumfänglich zu integrieren. Mensch, da hab ich voll Bock drauf :) face-smile