Jump to content

Problem bei DNS Forwarding


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Hallo zusammen!

 

Ich habe ein kleines Netzwerk bestehend aus einem Win2008R2 als Domänencontroller (4 NICs) und einem Linux Server, der mit Squid und Dnsmasq auf den Router ausgestattet ist (2 NICs). Dahinter steht ein Router der die Internetverbindung bereitstellt.

 

Router <-> (eth0) Proxy (eth1) <-> DC

(eth0 192.168.1.254

eth1 192.168.5.254)

 

Das routerseitige Netz ist 192.168.1.0, der DC hängt in mehreren VLANs - zum Testen erstmal nur eines, 192.168.5.0, in welchem auch die LAN-seite des Proxies hängt.

 

Mein Problem ist die DNS Konfiguration des DCs. Ein nslookup auf Internetdomains, also Namen außerhalb der eigenen Zone, führt zu einem Timeout ohne Auflösung. Wechsele ich auf den Proxy (server 192.168.5.254), funktioniert die Auflösung.

 

Das Forwarding scheint nicht zu funktionieren. Im DNS Snapin habe ich für den Server unter Weiterleitungen den Proxy (192.168.5.254) eingetragen. Beim Testen der rekursiven Abfrage tritt ein Fehler auf.

 

Ich habe probiert alle Einstellungen nachzuvollziehen, aber mir ist nicht klar wo genau das Problem ist und wie ich es weiter debuggen kann. Mache ich einen grundsätzlichen Denkfehler?

 

Ich wäre über Tipps oder Denkanstöße sehr dankbar.

 

Liebe Grüße

Link zu diesem Kommentar

Vielen Dank für die schnelle Anwort. Und ein guter Hinweis.

 

Wenn ich einen nslookup direkt auf den Proxy mache, also:

 

>nslookup

>server 192.168.5.254

>google.com

 

... passiert folgendes:

 

dnsmasq[7519]: query[A] google.com.mydomain.local from 192.168.5.1

dnsmasq[7159]: forwarded google.com.mydomain.local to 192.168.1.1

dnsmasq[7159]: reply google.com.mydomain.local is NXDOMAIN-IPv4

dnsmasq[7159]: query[AAAA] google.com.mydomain.local from 192.168.5.1

dnsmasq[7159]: forwarded google.com.mydomain.local to 192.168.1.1

dnsmasq[7159]: reply google.com.mydomain.local is NXDOMAIN-IPv6

dnsmasq[7159]: query[A] google.com from 192.168.5.1

dnsmasq[7159]: forwarded google.com to 192.168.1.1

dnsmasq[7159]: reply google.com is 74.125.53.100

dnsmasq[7159]: reply google.com is 74.125.45.100

dnsmasq[7159]: reply google.com is 74.125.67.100

dnsmasq[7159]: query[AAAA] google.com from 192.168.5.1

dnsmasq[7159]: forwarded google.com to 192.168.1.1

dnsmasq[7159]: reply google.com is NODATA-IPv6

 

Auf jedenfall werden Replies vom Router abgesetzt und der Server bekommt die aufgelöste Adresse.

 

Und jetzt der Ausgangsfall:

>nslookup

>google.com

 

dnsmasq[7169]: query[A] google.com from 192.168.5.1

dnsmasq[7169]: forwarded google.com to 192.168.1.1

dnsmasq[7169]: query[AAAA] google.com from 192.168.5.1

dnsmasq[7169]: forwarded google.com to 192.168.1.1

 

In der tat keine Replies! Das schafft aber neue Fragen: Wo ist der Unterschied: Wenn ich manuell eine Abfrage auf dem Zielserver mache und wenn der DNS-Server dies als Weiterleitung macht. Ich werde auf jedenfall mal die Config vom Dns-Masquerading auf dem Proxy auseinandernehmen.

 

Und ein weiterer Punkt, der mich stutzig macht: Wieso werden im ersten Fall zwei Abfragen abgesetzt? Schreit das nach einem Suffix-Problem?

bearbeitet von develmov
Link zu diesem Kommentar

Er fragt nach A (IPv4) und AAAA (IPv6). Wenn nach einem Namen wie EXAMPLE.COM gefragt wird, dann ist das ein Multiple-Label Unqualified Domain Name (der abschliessende Punkt fehlt). Der Resolver hängt also einen Punkt an, was dann EXAMPLE.COM. zu einem Full Qualified Domain Name macht und schickt das zum DNS-Server. Bekommt er eine Antwort, dass der Name nicht existiert, behandelt er den Namen EXAMPLE.COM (ohne abschliessenden Punkt) wie einen Single Label Unqualified Domain Name (SERVER z.B. ist solch ein Name). Jetzt fügt er die Suffixe zu und schliesst mit einem Punkt ab, was EXAMPLE.COM in Deinem Fall zu EXAMPLE.COM.DOMAIN.LOCAL. macht.

Im ersten Fall richtet sich der Resolver direkt an den Proxy und setzt seine Abfragen ab und der leitet es seinerseits an den Router weiter, der es wahrscheinlich wieder weiterleitet. Im zweiten Fall wendet er sich an den Windows DNS-Server, der in seinem Namen die Anfrage an den Proxy schickt, der es seinerseits an den Router weiterleitet, der es dann an den Internet DNS weiterleitet. Das ist auf jeden Fall schon mal ein Unterschied, es wird einmal mehr weitergeleitet. Wenn ich das Log richtig interpretiere, dann kommt keine Antwort von der 192.168.1.1 ...

Ich würde als erstes probieren, die Abfragen direkt an die 192.168.1.1 weiterzuleiten und nicht an den Proxy. Einen Sniffer auf dem Windows-Server würde ich wahrscheinlich auch benutzen, um die Abfragen zu vergleichen. Die Proxykonfiguration würde ich nicht prüfen, weil ich von Linux keine Ahnung habe ... :D , aber das kannst Du ja machen ...

Link zu diesem Kommentar

Hallo!

 

Danke für die Antwort.

 

Die Abfrage leuchtet mir ein. Ich habe den Aufbau einmal vereinfacht und den Server direkt an den Router geklemmt. Jetzt ist der Router beim Forwarding eingetragen und direkt vom Server erreichbar.

 

Ich erhalte das komplett gleiche Verhalten. :confused:

Es liegt also nicht am Proxy. Ideen?

 

Ich werde wohl nicht drumrumkommen mal ein wenig auf dem Server zu sniffen, um rauszukriegen, was da schiefläuft. Wobei es mich bei dieser basic Konfiguration schon sehr wundert.

 

-----------

 

kleiner Zusatz:

 

Ich habe grade in der einfachen Konfiguration den Router mal als Gateway eingetragen. Wenn ich jetzt diverse Inetseiten pinge dauert es manchmal eine Weile und dann kann er die Namen auflösen. Manchmal auch nicht. Ein nslookup bringt beim ersten mal ein Timeout (DNS request timed out. timeout was 2 seconds), beim erneuten eingeben können die Namen dann jedoch aufgelöst werden.

 

Hilfe? Wie **** ist denn das? :rolleyes:

Link zu diesem Kommentar

Ich weiß jetzt zumindest warum die Sache sporadisch funktionierte. :o Es waren Stammhinweise eingetragen - dadurch, dass der Router als Gateway eingetragen war, konnte der Server diese verwenden; d.h. die Weiterleitung sogte mit ihrer Einstellung von 3s (bis zur Zeitüberschreitung der Weiterleitung) für die sporadischen Fehler. Denn so geht es natürlich auch ohne Weiterleitung. Und zwar problemlos. Also Stammhinweise gelöscht.

 

Ich habe derzeit am Server nur einen NIC aktiviert. Und auf den ist der DNS-Dienst gebunden. Wenn ich die externen DNS Server als Weiterleitung eintrage, dann funktioniert die Abfrage - schön schnell dazu.

 

Heißt das also, der Router stellt sich quer? Sobald ein DNS-Server eine weitergeleitete Abfrage startet?

Ist so ein Verhalten bekannt? Ich habe hier zum Testen einen einfachen SOHO Netgear Router.

 

Liebe Grüße

Link zu diesem Kommentar

Hallo!

 

> Aber warum zum Himmel löschst Du die Stammhinweise ?

Um die Weiterleitung als einzigen Eintrag testen zu können. Stammhinweise sind ja schnell wieder vom Server geladen.

 

Ich habe mein System jetzt wieder auf den Ausgangszustand zurückgebaut und das DNS-Masquerading auf die externen DNS-Server eingestellt. Jetzt funktioniert alles problemlos. :) Schön irgendwie. Ich werde Netgear mal dem Verhalten des Routers konfrontieren... vielleicht ist da was bekannt.

 

Für alle, die ein ähnliches Problem haben sollten zur Info: Der von mir verwendete Router war ein Netgear RP614v4 mit der Firmwareversion V0.1.9_05.09GR.

 

Vielen Dank IThome für die helfenden Beiträge - das hat mich auf den richtigen Weg gebracht!

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...