8
DNS Architektur, DNS best practice
Hallo zusammen,
wir möchten unsere DNS-Architektur anpassen und hätten dazu noch ein paar Fragen. Zunächst ein paar Infos zur Ausgangslage:
- Alle Server entweder Windows Server 2008 R2 oder 2012 R2
- Deutschland Stammsitz ca. 1.000 Mitarbeiter, 2 DCs, alle Clients zeigen auf beide DNS-Server
- Deutschland 10 Niederlassungen, jeweils ca. 50 Mitarbeiter, 2x VPN Verbindung zum Stammsitz, kein lokaler DC, 1x Fileserver vor Ort mit DNS-Dienst der alle Anfragen auf die DCs am Stammsitz forwarded, Clients bekommen per DHCP den lokalen Fileserver und einen DC aus dem Stammsitz als DNS-Server
- Weltweit 20 Niederlassungen mit 20-200 Mitarbeitern, 1-2x VPN-Verbindung zum Stammsitz, ca. 10 Niederlassungen mit lokalem DC, 1x Fileserver vor Ort mit DNS-Dienst der alle Anfragen an den lokalen DC bzw. zum Stammsitz forwarded, Clients bekommen per DHCP den lokalen Fileserver und den lokalen DC oder wenn nicht vorhanden einen DC aus dem Stammsitz als DNS-Server
Aufgrund einiger Probleme mit geoblocking bzw. geolocation und des recht hohen DNS-Traffics am Stammsitz (ca. 10 GB pro Tag) wollen wir unsere DNS-Struktur überarbeiten. Hier der Plan:
DC - Static network settings
- all DCs point to another / remote DC’s IP as DNS
--> Next DC as primary DNS
--> Next but one DC as secondary DNS
--> The private IP of the DC as third DNS (not 127.0.0.1)
DC - DNS service settings (forwarders)
- 2x public DNS servers of ISP (good performance and reliability)
- No conditional forwardings because all DNS zones are available on the DC itself
File server branch office - Static network settings
- Next DC as primary DNS
- Next but one DC as secondary DNS
File server - DNS service settings (forwarders)
- Next two DCs as forwarders for everything
- No conditional forwarding
Clients branch office - DHCP network settings
- Local file server as primary DNS
- No secondary DNS
Überlegung hier: Wenn der Fileserver weg ist können die Clients sowieso nicht mehr richtig arbeiten. Bei zwei DNS-Einträgen könnten zusätzliche Probleme auftreten, da die DNS-Server unter Windows, welche per DHCP kommen angeblich per round-robbin sporadisch durchgewechselt werden.
Other servers branch office / machines with static IPs in branch office - Static network settings
- Local file server as primary DNS
- Next DC as secondary DNS
Jetzt meine Fragen dazu.
1. Seht ihr irgendwelche gravierenden Schwachstellen bzw. Nachteile gegenüber dem aktuellen Konzept oder generell?
2. Der DNS-Dienst sendet eine Anfrage immer an alle Forwarder und nimmt dann die erste Antwort, ist das korrekt? Oder geht er die einzelnen Forwarder nacheinander durch. Habe da leider keine hundertprozentige Aussage gefunden.
3. Die Aussage der Clients habe ich hier gelesen: https://web.archive.org/web/20131116075859/http://blogs.technet.com/b/aj ...
Anscheinend ist die Seite aber nicht mehr online weshalb ich an der Aussage zweifle. Allerdings habe ich ähnliche Phänomene erst vor ein paar Monaten beobachtet weshalb der von uns geplante Lösung eine gangbare Alternative wäre.
4. Gerade bei den DCs selbst gibts widersprüchliche Aussagen, auch direkt von Microsoft (private IP vs. 127.0.0.1). Immerhin scheint klar zu sein diese Adresse bei den Netzwerkeinstellungen des DCs nicht als primäre zu verwenden. Könnt ihr hier aus eurer Erfahrung berichten?
Hier noch ein paar Quellen:
http://blogs.technet.com/b/stdqry/archive/2011/12/02/dns-clients-and-ti ...
http://blogs.technet.com/b/stdqry/archive/2011/12/15/dns-clients-and-ti ...
https://technet.microsoft.com/en-us/library/dd197552%28WS.10%29.aspx
https://abhijitw.wordpress.com/2012/03/03/best-practices-for-dns-client- ...
http://www.howtodigitalstuff.com/dns-server-settings-for-domain-control ...
http://firelogic.net/best-practices-for-windows-server-dns-and-how-to-a ...
http://www.dell.com/support/article/us/en/19/SLN155801/en
wir möchten unsere DNS-Architektur anpassen und hätten dazu noch ein paar Fragen. Zunächst ein paar Infos zur Ausgangslage:
- Alle Server entweder Windows Server 2008 R2 oder 2012 R2
- Deutschland Stammsitz ca. 1.000 Mitarbeiter, 2 DCs, alle Clients zeigen auf beide DNS-Server
- Deutschland 10 Niederlassungen, jeweils ca. 50 Mitarbeiter, 2x VPN Verbindung zum Stammsitz, kein lokaler DC, 1x Fileserver vor Ort mit DNS-Dienst der alle Anfragen auf die DCs am Stammsitz forwarded, Clients bekommen per DHCP den lokalen Fileserver und einen DC aus dem Stammsitz als DNS-Server
- Weltweit 20 Niederlassungen mit 20-200 Mitarbeitern, 1-2x VPN-Verbindung zum Stammsitz, ca. 10 Niederlassungen mit lokalem DC, 1x Fileserver vor Ort mit DNS-Dienst der alle Anfragen an den lokalen DC bzw. zum Stammsitz forwarded, Clients bekommen per DHCP den lokalen Fileserver und den lokalen DC oder wenn nicht vorhanden einen DC aus dem Stammsitz als DNS-Server
Aufgrund einiger Probleme mit geoblocking bzw. geolocation und des recht hohen DNS-Traffics am Stammsitz (ca. 10 GB pro Tag) wollen wir unsere DNS-Struktur überarbeiten. Hier der Plan:
DC - Static network settings
- all DCs point to another / remote DC’s IP as DNS
--> Next DC as primary DNS
--> Next but one DC as secondary DNS
--> The private IP of the DC as third DNS (not 127.0.0.1)
DC - DNS service settings (forwarders)
- 2x public DNS servers of ISP (good performance and reliability)
- No conditional forwardings because all DNS zones are available on the DC itself
File server branch office - Static network settings
- Next DC as primary DNS
- Next but one DC as secondary DNS
File server - DNS service settings (forwarders)
- Next two DCs as forwarders for everything
- No conditional forwarding
Clients branch office - DHCP network settings
- Local file server as primary DNS
- No secondary DNS
Überlegung hier: Wenn der Fileserver weg ist können die Clients sowieso nicht mehr richtig arbeiten. Bei zwei DNS-Einträgen könnten zusätzliche Probleme auftreten, da die DNS-Server unter Windows, welche per DHCP kommen angeblich per round-robbin sporadisch durchgewechselt werden.
Other servers branch office / machines with static IPs in branch office - Static network settings
- Local file server as primary DNS
- Next DC as secondary DNS
Jetzt meine Fragen dazu.
1. Seht ihr irgendwelche gravierenden Schwachstellen bzw. Nachteile gegenüber dem aktuellen Konzept oder generell?
2. Der DNS-Dienst sendet eine Anfrage immer an alle Forwarder und nimmt dann die erste Antwort, ist das korrekt? Oder geht er die einzelnen Forwarder nacheinander durch. Habe da leider keine hundertprozentige Aussage gefunden.
3. Die Aussage der Clients habe ich hier gelesen: https://web.archive.org/web/20131116075859/http://blogs.technet.com/b/aj ...
Anscheinend ist die Seite aber nicht mehr online weshalb ich an der Aussage zweifle. Allerdings habe ich ähnliche Phänomene erst vor ein paar Monaten beobachtet weshalb der von uns geplante Lösung eine gangbare Alternative wäre.
4. Gerade bei den DCs selbst gibts widersprüchliche Aussagen, auch direkt von Microsoft (private IP vs. 127.0.0.1). Immerhin scheint klar zu sein diese Adresse bei den Netzwerkeinstellungen des DCs nicht als primäre zu verwenden. Könnt ihr hier aus eurer Erfahrung berichten?
Hier noch ein paar Quellen:
http://blogs.technet.com/b/stdqry/archive/2011/12/02/dns-clients-and-ti ...
http://blogs.technet.com/b/stdqry/archive/2011/12/15/dns-clients-and-ti ...
https://technet.microsoft.com/en-us/library/dd197552%28WS.10%29.aspx
https://abhijitw.wordpress.com/2012/03/03/best-practices-for-dns-client- ...
http://www.howtodigitalstuff.com/dns-server-settings-for-domain-control ...
http://firelogic.net/best-practices-for-windows-server-dns-and-how-to-a ...
http://www.dell.com/support/article/us/en/19/SLN155801/en
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 294406
Url: https://administrator.de/contentid/294406
Ausgedruckt am: 17.11.2024 um 16:11 Uhr
8 Kommentare
Neuester Kommentar
Hallo,
zu 1.
also ich sehe da noch nicht wie du den DNS Traffic im Stammsitz reduzieren willst. Ich hätte in den Zweigstellen generell Conditional Forwarder eingestellt sodass immer nur die eigenen/internen DNS Domains zu den DCs gehen und alle anderen Anfragen an lokale Resolver Caches entweder des ISP oder auf dem Zugangsrouter falls der dazu in der Lage ist.
Repliziert Ihr eure eigenen DNS Zonen zu allen DCs und verwendet Ihr dynamische DNS Updates für die Clients in einer eigenen Sub-Zone? Da wäre es eventuell auch möglich Traffic zu reduzieren indem man diese Zonen pro größerem Standort einrichtet und nur an diesen Standorten repliziert.
zu 2.
https://technet.microsoft.com/en-us/library/cc754931.aspx
der Reihe nach würd ich sagen
zu 3.
https://technet.microsoft.com/en-us/library/dd197552%28WS.10%29.aspx
So wie ich das verstehe geht er die Resolver der Reihe nach durch
zu 4.
soweit ich das kenne nehme ich bei DCs mit DNS Server immer die eigene IP als erster Resolver und einen weiteren DC als zweiter. Dazu fehlt mir allerdings die Quelle.
Gruß
Andi
zu 1.
also ich sehe da noch nicht wie du den DNS Traffic im Stammsitz reduzieren willst. Ich hätte in den Zweigstellen generell Conditional Forwarder eingestellt sodass immer nur die eigenen/internen DNS Domains zu den DCs gehen und alle anderen Anfragen an lokale Resolver Caches entweder des ISP oder auf dem Zugangsrouter falls der dazu in der Lage ist.
Repliziert Ihr eure eigenen DNS Zonen zu allen DCs und verwendet Ihr dynamische DNS Updates für die Clients in einer eigenen Sub-Zone? Da wäre es eventuell auch möglich Traffic zu reduzieren indem man diese Zonen pro größerem Standort einrichtet und nur an diesen Standorten repliziert.
zu 2.
https://technet.microsoft.com/en-us/library/cc754931.aspx
der Reihe nach würd ich sagen
zu 3.
https://technet.microsoft.com/en-us/library/dd197552%28WS.10%29.aspx
So wie ich das verstehe geht er die Resolver der Reihe nach durch
zu 4.
soweit ich das kenne nehme ich bei DCs mit DNS Server immer die eigene IP als erster Resolver und einen weiteren DC als zweiter. Dazu fehlt mir allerdings die Quelle.
Gruß
Andi
Danke für deine Antwort.
1. Die Hauptreduktion findet dadurch statt, dass die weltweit vorhandenen DCs die unbekannten DNS-Anfragen nicht mehr alle an den Stammsitz senden, sondern direkt zum DNS des ISPs. Ich denke dadurch lässt sich locker eine Reduktion um 30-40% erreichen, was ja schon mal sehr gute wäre. Bei Niederlassungen ohne DNS findet keine Reduktion statt, allerdings sind dies dann eher kleinere Büros mit generell weniger Trafficaufkommen.
Ja unsere DNS-Zonen werden auf allen DCs repliziert und dynamische DNS-Updates finden auch statt.
2. Danke. Dann könnte ich ohne Probleme als dritte Alternative noch den Google-DNS dazunehmen.
3. Kann mir auch kaum vorstellen, dass Windows sich in der Funktionsweise zwischen fest eingetragenen DNS-Servern und solchen, die per DHCP kommen unterscheidet. Dennoch macht mich der oben genannte Link etwas stutzig.
1. Die Hauptreduktion findet dadurch statt, dass die weltweit vorhandenen DCs die unbekannten DNS-Anfragen nicht mehr alle an den Stammsitz senden, sondern direkt zum DNS des ISPs. Ich denke dadurch lässt sich locker eine Reduktion um 30-40% erreichen, was ja schon mal sehr gute wäre. Bei Niederlassungen ohne DNS findet keine Reduktion statt, allerdings sind dies dann eher kleinere Büros mit generell weniger Trafficaufkommen.
Ja unsere DNS-Zonen werden auf allen DCs repliziert und dynamische DNS-Updates finden auch statt.
2. Danke. Dann könnte ich ohne Probleme als dritte Alternative noch den Google-DNS dazunehmen.
3. Kann mir auch kaum vorstellen, dass Windows sich in der Funktionsweise zwischen fest eingetragenen DNS-Servern und solchen, die per DHCP kommen unterscheidet. Dennoch macht mich der oben genannte Link etwas stutzig.
Zitat von @jaegerschnitzel:
Danke für deine Antwort.
1. Die Hauptreduktion findet dadurch statt, dass die weltweit vorhandenen DCs die unbekannten DNS-Anfragen nicht mehr alle an den Stammsitz senden, sondern direkt zum DNS des ISPs. Ich denke dadurch lässt sich locker eine Reduktion um 30-40% erreichen, was ja schon mal sehr gute wäre. Bei Niederlassungen ohne DNS findet keine Reduktion statt, allerdings sind dies dann eher kleinere Büros mit generell weniger Trafficaufkommen.
Danke für deine Antwort.
1. Die Hauptreduktion findet dadurch statt, dass die weltweit vorhandenen DCs die unbekannten DNS-Anfragen nicht mehr alle an den Stammsitz senden, sondern direkt zum DNS des ISPs. Ich denke dadurch lässt sich locker eine Reduktion um 30-40% erreichen, was ja schon mal sehr gute wäre. Bei Niederlassungen ohne DNS findet keine Reduktion statt, allerdings sind dies dann eher kleinere Büros mit generell weniger Trafficaufkommen.
So wie ich es verstanden habe reduziert das nur den Traffic in den Lokationen mit DC, nicht in denen mit DNS Server (Cache) auf dem Dateiserver weil diese nur die DCs als Forwarder verwenden?
Ja unsere DNS-Zonen werden auf allen DCs repliziert und dynamische DNS-Updates finden auch statt.
2. Danke. Dann könnte ich ohne Probleme als dritte Alternative noch den Google-DNS dazunehmen.
2. Danke. Dann könnte ich ohne Probleme als dritte Alternative noch den Google-DNS dazunehmen.
Würd ich nicht mal machen, wenn der Dateiserver/DC weg ist brauchen die auch nicht im Internet surfen
Ich würde eher als zweiten einen Resolver im Stammsitz nehmen, damit ist dann Notbetrieb möglich solange das VPN funktioniert.
3. Kann mir auch kaum vorstellen, dass Windows sich in der Funktionsweise zwischen fest eingetragenen DNS-Servern und solchen, die per DHCP kommen unterscheidet. Dennoch macht mich der oben genannte Link etwas stutzig.
Ich bin mir nicht sicher ob der DHCP Server die "Reihenfolge" der Resolver vorgibt, ansonsten würde ich behaupten das es keinen Unterschied macht.
Gruß
Andi
Hi,
es macht definitiv keinen Unterschied, ob der Client seinen DNS-Server-Eintrag von einem DHCP-Server bekommt oder statisch eingetragen hat.
Es macht aber auch definitiv keinen Sinn, einem Client mehrere DNS-Server einzutragen, um darüber die Abfragen zu streuen. Man gibt einem Client nur als Redundanz zwei oder mehrere DNS-Server mit. Falls der 1. nicht erreichnar ist, nimm den 2. Falls der 2. auch nicht erreichbar ist nimm den 3. Aber auch immer nur dann. Wenn der 1. DNS-Server einen FQDN nicht auflösen kann (negative Antwort), dann fragt der Client keinen weiteren DNS-Server ab.
Die Reihenfolge der DNS-Server in der TCP/IP-Konfiguration der Clients ist auch dann interessant, wenn Ihr dynamische Aktualsierungen einsetzt und darauf baut. Ein Windows Client kann und wird seinen Record nur bei jenem DNS-Server aktualisieren, welchen er für die Zone als ersten anspricht.
Bsp.
Wenn Du am Standort einen DC/DNS-Server hast, dann nimm diesen als primären DNS-Server für die Clients und lass diesen Server alle Anfragen, welche er nicht selbst auflösen kann, an andere DNS-Server weiterleiten. i.A. die in der Zentrale.
Wenn der Standort auch noch einen eigenen Internetzugang hat, dann lass den lokalen DC/DNS nur für Zonen an die Zentrale weiterleiten, welche auch in der Zentrale gehostet werden. Alle Anfragen für andere Zonen lass an DNS-Server im Internet weiterleiten und die Route dafür sollte über den lokalen Internet-Router gehen. U.u. ist dieser Router selbst auch als DNS-Forwarder eingerichtet. Dann eben an diesen weiterleiten.
Falls der Internet-Router am Standort auch DNS-Forwarder ist, dann schauen, ob der auch bedingte Weiterleitungen kann. Falls ja, dann für die internen Zonen an den DNS in der Zentrale weiterleiten. Dann kann man diesen Router als 2. DNS-Server an die Clients verteilen. Wenn der lokale DC/DNS ausfällt, dann benutzen die Clients den Router/DNS. Dieser leitet die Anfragen für die internen Zonen (u.a. AD) an die DNS in der Zentrale weiter. Alle anderen Anfragen gehen ins Internet.
E.
Edit: habe noch ein paar Schreibfehler korrigiert
es macht definitiv keinen Unterschied, ob der Client seinen DNS-Server-Eintrag von einem DHCP-Server bekommt oder statisch eingetragen hat.
Es macht aber auch definitiv keinen Sinn, einem Client mehrere DNS-Server einzutragen, um darüber die Abfragen zu streuen. Man gibt einem Client nur als Redundanz zwei oder mehrere DNS-Server mit. Falls der 1. nicht erreichnar ist, nimm den 2. Falls der 2. auch nicht erreichbar ist nimm den 3. Aber auch immer nur dann. Wenn der 1. DNS-Server einen FQDN nicht auflösen kann (negative Antwort), dann fragt der Client keinen weiteren DNS-Server ab.
Die Reihenfolge der DNS-Server in der TCP/IP-Konfiguration der Clients ist auch dann interessant, wenn Ihr dynamische Aktualsierungen einsetzt und darauf baut. Ein Windows Client kann und wird seinen Record nur bei jenem DNS-Server aktualisieren, welchen er für die Zone als ersten anspricht.
Bsp.
- Client fragt DNS A --> DNS A hostet die Zone schreibbar --> Client kann seinen Record aktualisieren
- Client fragt DNS A --> DNS A hostet die Zone nicht schreibbar (Sekundär-Zone) --> Client kann seinen Record nicht aktualisieren und versucht es auch nicht bei einem anderen DNS
- Client fragt DNS A --> DNS A hostet die Zone nicht --> DNS A hat eine Delegierung für diese Zone an DNS B - DNS A meldet DNS B als zuständig - Client wendet sich an DNS B - DNS B hat eine schreibbare Zone --> Client kann seinen Record aktualisieren
- Client fragt DNS A --> DNS A hostet die Zone nicht --> DNS A hat eine Weiterleitung für diese Zone (oder generell) an DNS B --> DNS B hat eine schreibbare Zone --> Client kann seinen Record nicht aktualisieren und versucht es auch nicht bei einem anderen DNS
Wenn Du am Standort einen DC/DNS-Server hast, dann nimm diesen als primären DNS-Server für die Clients und lass diesen Server alle Anfragen, welche er nicht selbst auflösen kann, an andere DNS-Server weiterleiten. i.A. die in der Zentrale.
Wenn der Standort auch noch einen eigenen Internetzugang hat, dann lass den lokalen DC/DNS nur für Zonen an die Zentrale weiterleiten, welche auch in der Zentrale gehostet werden. Alle Anfragen für andere Zonen lass an DNS-Server im Internet weiterleiten und die Route dafür sollte über den lokalen Internet-Router gehen. U.u. ist dieser Router selbst auch als DNS-Forwarder eingerichtet. Dann eben an diesen weiterleiten.
Falls der Internet-Router am Standort auch DNS-Forwarder ist, dann schauen, ob der auch bedingte Weiterleitungen kann. Falls ja, dann für die internen Zonen an den DNS in der Zentrale weiterleiten. Dann kann man diesen Router als 2. DNS-Server an die Clients verteilen. Wenn der lokale DC/DNS ausfällt, dann benutzen die Clients den Router/DNS. Dieser leitet die Anfragen für die internen Zonen (u.a. AD) an die DNS in der Zentrale weiter. Alle anderen Anfragen gehen ins Internet.
E.
Edit: habe noch ein paar Schreibfehler korrigiert
Ich habe das Gefühl, dass der Client bei zwei eingetragenen DNS Server, diese nicht immer der Reihe nach abfrägt, sondern auch mal den zweiten obwohl der erste erreichbar ist.
Das Problem:
Pc bekommte alle paar Tage oder Wochen (unregelmässig) eine Fehlermeldung, dass der Proxy nicht erreichbar ist. (Proxy ist in einer Anderen Filiale)
Diverse Analysen ergaben, dass die Internetlinie dieser Filiale wunderbar funktioniert, auch die PCs usw.
Ping mässig ist der Proxy auch immer erreichbar.
Jetzt habe ich bemerkt, dass der erste eingetragene DNS Server der interne ist, als Sekundäre ein öffentlicher DNS Server, welcher den internen Proxy logischerweise nicht auflösen kann.
Bin mir sicher, dass das Problem mit dem entfernen des öffentlichen DNS Server gelöst wird.
Das Problem:
Pc bekommte alle paar Tage oder Wochen (unregelmässig) eine Fehlermeldung, dass der Proxy nicht erreichbar ist. (Proxy ist in einer Anderen Filiale)
Diverse Analysen ergaben, dass die Internetlinie dieser Filiale wunderbar funktioniert, auch die PCs usw.
Ping mässig ist der Proxy auch immer erreichbar.
Jetzt habe ich bemerkt, dass der erste eingetragene DNS Server der interne ist, als Sekundäre ein öffentlicher DNS Server, welcher den internen Proxy logischerweise nicht auflösen kann.
Bin mir sicher, dass das Problem mit dem entfernen des öffentlichen DNS Server gelöst wird.
Zitat von @cyber8607:
Bin mir sicher, dass das Problem mit dem entfernen des öffentlichen DNS Server gelöst wird.
Bin mir sicher, dass das Problem mit dem entfernen des öffentlichen DNS Server gelöst wird.
Denke ich auch.
Außerdem würde dies meine oben erwähnte These bestätigen:
Bei zwei DNS-Einträgen könnten zusätzliche Probleme auftreten, da die DNS-Server unter Windows, welche per DHCP kommen angeblich per round-robbin sporadisch durchgewechselt werden.
https://web.archive.org/web/20131116075859/http://blogs.technet.com/b/aj ...
@jaegerschnitzel
Der verlinkte Artikel kommt mir sehr spanisch vor.
Es kann sein, dass der Client beim nächsten Reset der DNS-Server-Priorität die Reihenfolge der konfigurierten DNS-Server ändert. Aber auch nur dann, wenn der vom Autor beschriebene 2. Fall eintritt: Wenn zum Zeitpunkt der Entscheidung oder bei der nächsten nötigen Abfrage der z.Z. erste DNS-Server nicht schnell genug reagiert. Dann wird jener konfigurierte DNS-Server an die erste Stelle gesetzt, welcher als erstes reagiert (geprüft in der konfigurierten Reihenfolge), und verbleibt dort für die Dauer bis zum nächsten Reset (zur nächsten Prüfung).
Wenn der an erster Stelle konfigurierte DNS-Server immer schnell genug reagiert, dann wird der Client auch immer nur diesen benutzen. Egal wie oft die DNS-Server-Liste neu berechnet (priorisiert) wird.
Den im - vom Autor verlinkten - MS-Artikel genannten Reg-Wert ServerPriorityTimeLimit würde ich nur dann auf 0 setzen, wenn alle konfigurierten DNS-Server im gleichen Netz sind, gleich schnell erreichbar sind, und über die selben Informationen verfügen (Zonen, Weiterleitungen). Anderfalls kann das ganz schnell nach hinten losgehen, wenn plötzlich ein "minderwertiger" DNS-Server an die erste Stelle gesetzt wird und der Client das bis zum nächsten Reboot oder bis zur ersten Nicht-Antwort des "minderwertigen" Servers so beibehält.
Dieser MS-Artikel besagt lediglich, dass der Client (standardmäßig) alle 15 min die Liste der DNS-Server neu priorisiert. Er besagt nicht, dass der Client einfach so alle 15 min die Reihenfolge der Server ändert. Und außerdem bezieht er sich ausschließlich auf WinXP.
Mal abgesehen davon, dass alles andere unlogisch wäre ...
Der verlinkte Artikel kommt mir sehr spanisch vor.
The Windows DNS Client will reset the DNS Server Priority at periodic intervals. By default, the server priorities are reset every 15 minutes.
Let's look at an example:
I have a DNS Client configured as follows:
Preferred DNS: 192.168.0.1
Alternate DNS: 10.10.0.1
The DNS Client will start by sending queries to 192.168.0.1. After 15 minutes it will switch priority to 10.10.0.1. Thus all queries will first be sent to 10.10.0.1 for a period of 15 minutes before switching back to 192.168.0.1
Leider untermauert der Autor seine Behauptung mit keinerlei Fakten und/oder Referenzen. Ich halte sie für schlicht weg falsch. Ich nehme an, er hat hier etwas falsch verstanden oder sich sehr missverständlich ausgedrückt.Let's look at an example:
I have a DNS Client configured as follows:
Preferred DNS: 192.168.0.1
Alternate DNS: 10.10.0.1
The DNS Client will start by sending queries to 192.168.0.1. After 15 minutes it will switch priority to 10.10.0.1. Thus all queries will first be sent to 10.10.0.1 for a period of 15 minutes before switching back to 192.168.0.1
Es kann sein, dass der Client beim nächsten Reset der DNS-Server-Priorität die Reihenfolge der konfigurierten DNS-Server ändert. Aber auch nur dann, wenn der vom Autor beschriebene 2. Fall eintritt: Wenn zum Zeitpunkt der Entscheidung oder bei der nächsten nötigen Abfrage der z.Z. erste DNS-Server nicht schnell genug reagiert. Dann wird jener konfigurierte DNS-Server an die erste Stelle gesetzt, welcher als erstes reagiert (geprüft in der konfigurierten Reihenfolge), und verbleibt dort für die Dauer bis zum nächsten Reset (zur nächsten Prüfung).
Wenn der an erster Stelle konfigurierte DNS-Server immer schnell genug reagiert, dann wird der Client auch immer nur diesen benutzen. Egal wie oft die DNS-Server-Liste neu berechnet (priorisiert) wird.
Den im - vom Autor verlinkten - MS-Artikel genannten Reg-Wert ServerPriorityTimeLimit würde ich nur dann auf 0 setzen, wenn alle konfigurierten DNS-Server im gleichen Netz sind, gleich schnell erreichbar sind, und über die selben Informationen verfügen (Zonen, Weiterleitungen). Anderfalls kann das ganz schnell nach hinten losgehen, wenn plötzlich ein "minderwertiger" DNS-Server an die erste Stelle gesetzt wird und der Client das bis zum nächsten Reboot oder bis zur ersten Nicht-Antwort des "minderwertigen" Servers so beibehält.
Dieser MS-Artikel besagt lediglich, dass der Client (standardmäßig) alle 15 min die Liste der DNS-Server neu priorisiert. Er besagt nicht, dass der Client einfach so alle 15 min die Reihenfolge der Server ändert. Und außerdem bezieht er sich ausschließlich auf WinXP.
Mal abgesehen davon, dass alles andere unlogisch wäre ...
Klingt logisch. Ich würde das sehr gerne mal genauer untersuchen, aber leider fehlt mir die Zeit. Wie es aussieht werde ich auch die nächsten Monate keine Zeit dafür haben.
Wir haben mittlerweile auf jeden Fall nur noch den lokalen FileServer als DNS bei den Clients eingetragen und konnten bisher keine Probleme feststellen. Läuft bisher definitiv besser als das alte Konzept mit 2-3 DNS-Servern, von denen mindestens einer über WAN erreichbar war.
Das mit Windows XP würde ich nicht zu hoch bewerten. Wir haben schon zwei Technet- bzw. KB-Artikel von Microsoft gefunden, die sich ebenfalls nur auf XP beziehen, nachweislich aber auch unter Windows 7, 8.1 und sogar nch Windows 10 gültig sind. Der Premier Support von Microsoft hat dies sogar bestätigt, die Artikel wurden aber trotz mehrmaliger nachfrage noch nicht angepasst
Wir haben mittlerweile auf jeden Fall nur noch den lokalen FileServer als DNS bei den Clients eingetragen und konnten bisher keine Probleme feststellen. Läuft bisher definitiv besser als das alte Konzept mit 2-3 DNS-Servern, von denen mindestens einer über WAN erreichbar war.
Das mit Windows XP würde ich nicht zu hoch bewerten. Wir haben schon zwei Technet- bzw. KB-Artikel von Microsoft gefunden, die sich ebenfalls nur auf XP beziehen, nachweislich aber auch unter Windows 7, 8.1 und sogar nch Windows 10 gültig sind. Der Premier Support von Microsoft hat dies sogar bestätigt, die Artikel wurden aber trotz mehrmaliger nachfrage noch nicht angepasst
