Keine lokale DNS-Auflösung über DC ohne Internetverbindung
Hallo zusammen,
ich habe hier ein Problem, was ich mir selbst mittlerweile nicht mehr erklären kann.
Kurz zum Ist-Stand:
AD1 und AD2, jeweils mit DNS-Dienst. (Primary und Secondary DC)
GW1 (Firewall mit mehreren öffentlichen IP's) spielt DHCP
GW2 (Hitron Modem des Providers mit öffentlicher IP)
Domäne xyzgmbh.de
Lokale A-Records in den DNS-Servern
Nun zum Problem:
Wir hatten jetzt gestern einen längeren Internetausfall, da der Provider einen Umzug in Auftrag gegeben hat, nur um unsere Adresse zu korrigieren... (danke vodafone!)
Dabei ist aufgefallen, dass leider auch interne Dienste (z.B. wie im Screenshot "idoit.xyzgmbh.de" per DNS nicht aufrufbar waren, obwohl diese den internen DNS-Servern per A-Record bekannt sind.
Ich habe sämtliche Konfiguration geprüft, und bin gerade ratlos.
Habt ihr eine Idee oder einen Tipp für mich?
ich habe hier ein Problem, was ich mir selbst mittlerweile nicht mehr erklären kann.
Kurz zum Ist-Stand:
AD1 und AD2, jeweils mit DNS-Dienst. (Primary und Secondary DC)
GW1 (Firewall mit mehreren öffentlichen IP's) spielt DHCP
GW2 (Hitron Modem des Providers mit öffentlicher IP)
Domäne xyzgmbh.de
Lokale A-Records in den DNS-Servern
Nun zum Problem:
Wir hatten jetzt gestern einen längeren Internetausfall, da der Provider einen Umzug in Auftrag gegeben hat, nur um unsere Adresse zu korrigieren... (danke vodafone!)
Dabei ist aufgefallen, dass leider auch interne Dienste (z.B. wie im Screenshot "idoit.xyzgmbh.de" per DNS nicht aufrufbar waren, obwohl diese den internen DNS-Servern per A-Record bekannt sind.
Ich habe sämtliche Konfiguration geprüft, und bin gerade ratlos.
Habt ihr eine Idee oder einen Tipp für mich?
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 666509
Url: https://administrator.de/contentid/666509
Ausgedruckt am: 21.11.2024 um 22:11 Uhr
11 Kommentare
Neuester Kommentar
Hallo,
Microsoft möchte halt wissen, was Ihr macht. Wenn Ihr mangels Internet keine Daten liefert, gibt 's auch kein DNS, Basta!
Ernsthaft: Ich persönlich neige grundsätzlich dazu, den lokalen Router als DNS im AD einzutragen. Wäre das in dem Fall keine Option?
Im Übrigen entspricht das Verhalten genau dem Hinweistext: Die Weiterleitungen sind nicht verfügbar (da kein Internet), also werden die Rootserver befragt. Und da diese ebenfalls nicht verfügbar sind, gibt 's auch keine Antwort.
Insofern könnte man auch noch mal ausprobieren, ob man das umgehen kann, indem man für die entsprechende Domain eine bedingte Weiterleitung einträgt. Die dann halt auf die DC zeigt.
Gruß,
Jörg
Zitat von @DTCTVE:
Dabei ist aufgefallen, dass leider auch interne Dienste (z.B. wie im Screenshot "idoit.xyzgmbh.de" per DNS nicht aufrufbar waren, obwohl diese den internen DNS-Servern per A-Record bekannt sind.
Dabei ist aufgefallen, dass leider auch interne Dienste (z.B. wie im Screenshot "idoit.xyzgmbh.de" per DNS nicht aufrufbar waren, obwohl diese den internen DNS-Servern per A-Record bekannt sind.
Microsoft möchte halt wissen, was Ihr macht. Wenn Ihr mangels Internet keine Daten liefert, gibt 's auch kein DNS, Basta!
Ernsthaft: Ich persönlich neige grundsätzlich dazu, den lokalen Router als DNS im AD einzutragen. Wäre das in dem Fall keine Option?
Im Übrigen entspricht das Verhalten genau dem Hinweistext: Die Weiterleitungen sind nicht verfügbar (da kein Internet), also werden die Rootserver befragt. Und da diese ebenfalls nicht verfügbar sind, gibt 's auch keine Antwort.
Insofern könnte man auch noch mal ausprobieren, ob man das umgehen kann, indem man für die entsprechende Domain eine bedingte Weiterleitung einträgt. Die dann halt auf die DC zeigt.
Gruß,
Jörg
@117471
Das von Dir Genannte halte ich nicht für wahrscheinlich. Wenn die Anfrage für "idoit.xyzgmbh.de" beim internen DNS-Server ankommt, und er selbst stellt eine Zone mit dieser Domäne bereit, dann wird er keinen anderen DNS-Server fragen. Entweder kennt er diesen Record oder nicht. Wenn nicht, dann gibt er eine negative Antwort.
@dkoerner
Das von Dir Genannte halte ich nicht für wahrscheinlich. Wenn die Anfrage für "idoit.xyzgmbh.de" beim internen DNS-Server ankommt, und er selbst stellt eine Zone mit dieser Domäne bereit, dann wird er keinen anderen DNS-Server fragen. Entweder kennt er diesen Record oder nicht. Wenn nicht, dann gibt er eine negative Antwort.
@dkoerner
Nein. Eine Auflösung war zu dem Zeitpunkt nicht mehr möglich. (Geprüft per nslookup)
Wir sieht denn die Ausgabe von nslookup aus, wenn das Internet nicht verfügbar ist? Verfügbar für wen überhaupt? Für den DNS-Server oder für den DNS-Client?
Hallo,
Sagen wir mal so - ich würde nicht für klug halten. Aber es wird nun mal genau so in dem Hinweistext beschrieben. Ob der Hinweis jetzt richtig oder falsch ist, kann ich leider nicht beurteilen.
Abgesehen davon, dass m.Ea. nichts dagegen spricht, den DNS vom Router in den DC zu klötern.
Gruß,
Jörg
Sagen wir mal so - ich würde nicht für klug halten. Aber es wird nun mal genau so in dem Hinweistext beschrieben. Ob der Hinweis jetzt richtig oder falsch ist, kann ich leider nicht beurteilen.
Abgesehen davon, dass m.Ea. nichts dagegen spricht, den DNS vom Router in den DC zu klötern.
Gruß,
Jörg
Hallo,
Also wenn der Client beim Test mit nslookup die Adresse nicht auflösen konnte, gibt es nicht so viele Erklärungen. Eigentlich bleibt nur:
beides würde ich prüfen.
zum testen kann man bei NS-Lookup schön die Server umschalten:
Betreibt ihr für die Domäne ein Split-DNS?
Grüße
lcer
Zitat von @DTCTVE:
Nein. Eine Auflösung war zu dem Zeitpunkt nicht mehr möglich. (Geprüft per nslookup)
Kann der betreffende DNS-Client den FQDN "idoit.xyzgmbh.de" in eine IP-Adresse auflösen? Ja oder nein?
Und wenn ja: Ist es die richtige IP-Adresse?
Und wenn ja: Ist es die richtige IP-Adresse?
Nein. Eine Auflösung war zu dem Zeitpunkt nicht mehr möglich. (Geprüft per nslookup)
Also wenn der Client beim Test mit nslookup die Adresse nicht auflösen konnte, gibt es nicht so viele Erklärungen. Eigentlich bleibt nur:
- der Client hat nicht Euren DC am Standort abgefragt
- der Server ist schlicht falsch konfiguriert.
beides würde ich prüfen.
zum testen kann man bei NS-Lookup schön die Server umschalten:
PS C:\>nslookup
Standardserver: DC1.domäne.de
> www.google.de
Server: DC1.domäne.de
Address: 192.168.200.10
Nicht autorisierende Antwort:
Name: www.google.de
Addresses: 2a00:1450:4001:82b::2003
172.217.18.99
> server 192.168.1.12
Standardserver: DC2.domäne.de
Address: 192.168.1.12
> www.google.de
Server: DC2.domäne.de
Address: 192.168.1.12
Nicht autorisierende Antwort:
Name: www.google.de
Addresses: 2a00:1450:4001:811::2003
142.250.185.99
>
Betreibt ihr für die Domäne ein Split-DNS?
Grüße
lcer
Servus!
Warum schwärzt du deine privaten IP's? Das macht das Thema für uns nicht einfacher - oder sind das ggf. sogar die externen IP'?
Wie sind denn die IP-settings der DNS/ DC Server? Welche DNS Server haben die eingetragen?
Gruß
Luigi
Warum schwärzt du deine privaten IP's? Das macht das Thema für uns nicht einfacher - oder sind das ggf. sogar die externen IP'?
Wie sind denn die IP-settings der DNS/ DC Server? Welche DNS Server haben die eingetragen?
Gruß
Luigi
Mahlzeit.
Ich tippe ins Blaue: Ihr habt IPv6 (richtigerweise) nicht deaktiviert, es aber auf Auto-Config gelassen? Und auf den DCs selbst den DNS-Server für das IPv6-Protokoll nicht von ::1 auf DHCP geändert? Dann ist das Verhalten "normal", wenn auch unschön.
Dein nslookup, den du oben gepostet hast, hat übrigens nix mit ner DNS-Anfrage zu tun: Du hast nur den Hostnamen abgefragt, keinen FQDN. Ohne zu wissen, welche DNS-Suffixe bei euch so per DHCP, GPO oder manuell eingerichtet sind, ist das absolut nicht aussagekräftig.
Cheers,
jsysde
Ich tippe ins Blaue: Ihr habt IPv6 (richtigerweise) nicht deaktiviert, es aber auf Auto-Config gelassen? Und auf den DCs selbst den DNS-Server für das IPv6-Protokoll nicht von ::1 auf DHCP geändert? Dann ist das Verhalten "normal", wenn auch unschön.
Dein nslookup, den du oben gepostet hast, hat übrigens nix mit ner DNS-Anfrage zu tun: Du hast nur den Hostnamen abgefragt, keinen FQDN. Ohne zu wissen, welche DNS-Suffixe bei euch so per DHCP, GPO oder manuell eingerichtet sind, ist das absolut nicht aussagekräftig.
Cheers,
jsysde
Hallo,
nein, irgendwie macht das alles keinen Sinn. Du solltest das Scenario nochmal nachstellen. Besonders die Sache mit dem "Internetausfall". Vielleicht war auch eines der FirewallGeräte gestört und das DHCP war kaputt (längerer Ausfall - DHCP-Leases abgelaufen ....)? Ich würde so vorgehen:
Die beiden DCs sind am selben Standort?
Und überprüfe mal, ob nicht ganz blöde Fehler passiert sind:
Grüße
lcer
nein, irgendwie macht das alles keinen Sinn. Du solltest das Scenario nochmal nachstellen. Besonders die Sache mit dem "Internetausfall". Vielleicht war auch eines der FirewallGeräte gestört und das DHCP war kaputt (längerer Ausfall - DHCP-Leases abgelaufen ....)? Ich würde so vorgehen:
- DSL/Glasfaserkabel-wasauchimmer rausziehen.
- testen, ob DHCP /renew funktioniert
- testen, ob die DNS-Auflösung funktioniert: Zuerst an den Firewalls, dann DC1, DC2, einem Client.
- Dann die erste Firewall anschalten und wieder testen
- Dann die zweite.
Die beiden DCs sind am selben Standort?
Und überprüfe mal, ob nicht ganz blöde Fehler passiert sind:
- Es sind mehr als 1 DHCP-Server aktiv (welche nicht voneinander wissen)
- Es sind irgendwelche komischen DNS-Weiterleitungen definiert, die bei Ausfall der Internet-DNS-Server relevant werden. Beispielweise ein Fallback auf nicht-DNSSEC, was dann aber gefordert wird.
- Irgendwelche Sicherheitsfeatures. Beispielsweise liefert Unbound in der Standartkonfiguration keine IPs aus Privaten Netzbereichen aus. Oder irgend ein IDS/IPS verhindert DNS-Auflösungen, wenn seine Listen nicht aktualisiert sind....
Grüße
lcer
Hallo,
*hust*
Du hast die Google-DNS-Server als Weiterleitungsziel eingetragen. Bitte tue uns einen Gefallen und benutze niemals wieder das Wort "Datenschutz", sonst landet der Kaffee in der Tastatur. O.K., das war jetzt ein bisschen fies von mir - mea culpa
Hm. Jetzt, wo ich mir das noch einmal durch den Kopf gehen lasse kann IPv6 durchaus eine weitere Fehlerursache sein. Auf der anderen Seite - wenn es kaputtgeschrotet ist, müsste der DC konsequent über IPv4 fragen...
Oder, sagen wir mal so: Wenn du jetzt nicht gerade geschrieben hättest, dass das IPv6 kaputt ist, dann wäre das tatsächlich eine weitere (mögliche) Ursache.
Klingt merkwürdig, ich hätte es auch anders gemacht, aber - siehe z.B. hier: https://www.dell.com/support/kbdoc/de-de/000128457/best-practices-f%c3%b ...
Zitat:
Gruß,
Jörg
*hust*
Du hast die Google-DNS-Server als Weiterleitungsziel eingetragen. Bitte tue uns einen Gefallen und benutze niemals wieder das Wort "Datenschutz", sonst landet der Kaffee in der Tastatur. O.K., das war jetzt ein bisschen fies von mir - mea culpa
IPv6 ist leider von meinem Vorgänger bei allen Servern und vor allem bei den DC's im Netzwerkadapter deaktiviert.
Hm. Jetzt, wo ich mir das noch einmal durch den Kopf gehen lasse kann IPv6 durchaus eine weitere Fehlerursache sein. Auf der anderen Seite - wenn es kaputtgeschrotet ist, müsste der DC konsequent über IPv4 fragen...
Oder, sagen wir mal so: Wenn du jetzt nicht gerade geschrieben hättest, dass das IPv6 kaputt ist, dann wäre das tatsächlich eine weitere (mögliche) Ursache.
- DC1 hat als Primary DNS den DC2 eingetragen, dann als Secondary DNS localhost
- DC2 hat als Primary DNS den DC1 eingetragen, dann als Secondary DNS localhost
- DC2 hat als Primary DNS den DC1 eingetragen, dann als Secondary DNS localhost
Klingt merkwürdig, ich hätte es auch anders gemacht, aber - siehe z.B. hier: https://www.dell.com/support/kbdoc/de-de/000128457/best-practices-f%c3%b ...
Zitat:
Wenn mehrere DCs als DNS-Server konfiguriert sind, sollten Sie so konfiguriert sein, dass Sie zuerst den anderen und an zweiter Stelle sich selbst für die Auflösung verwenden. Die Liste der DNS-Server jedes DC sollte seine eine eigene Adresse enthalten, aber nicht als ersten Server in der Liste. Wenn ein DC nur sich selbst für die Auflösung verwendet, repliziert er unter Umständen nicht mehr mit anderen DCs. Dies ist offenkundig kein Problem in einer Domäne mit nur einem DC.
Gruß,
Jörg