Jump to content

DNS Probleme


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

Empfohlene Beiträge

Nehme ich deinen DNS Server 194.25.2.129, bekomme ich auf Google oder auch google.com

 

DNS request timed out.

timeout was 2 seconds.

DNS request timed out.

timeout was 2 seconds.

*** Zeitüberschreitung bei Anforderung an dns03.btx.dtag.de

 

Nehme ich einen von Inode (Provider des Kunden) bekomme ich folgendes:

 

Nicht-autorisierende Antwort:

Name: www.google.com.<domain>.co.at

Address: 213.47.222.70

 

Nicht-autorisierende Antwort:

Name: google.com.<domain>.co.at

Address: 213.47.222.70

 

Auch im DNS log finden sich folgende Einträge:

 

20090406 15:24:07 B98 PACKET 01539E10 UDP Rcv 10.133.133.133 0002 Q [0001 D NOERROR] A (6)google(3)com(7)<domain>(2)co(2)at(0)

 

Es scheint also so, als würde der komplette DNS Domain Name mit angehängt.

Link zu diesem Kommentar

Wenn Du einen anderen DNS-Server zum Auflösen via NSLOOKUP benutzt, kann es ja kein Fehler des DNS-Servers bei Dir sein. Es muss ein Fehler bei der Auflösung unvollständiger Namen sein, was vom Resolver gemacht wird. NSLOOKUP bedient sich nicht des Resolvercaches und schreibt dort auch nichts rein. Deswegen brauchst Du den Cache vor der Abfrage auch nicht löschen. Versuche bitte mal Folgendes: Führe eine NSLOOKUP Abfrage durch, die so aussieht - NSLOOKUP Google. <externer DNS-Server> (also nach der aufzulösenden Seite einen Punkt setzen, was den Namen zu einem FQDN macht). Schau Dir mal das Ergebnis im Sniffer an. Prüfe das Ergebnis auch mal auf einem Client im Netzwerk, der die Abfrage so wie beschrieben ohne abschliessenden und mit abschliessendem Punkt durchführt (beide Abfragen an den externen Server). Machen die das genau so ? Poste bitte mal IPCONFIG /ALL des Servers bzw. des Gerätes, welches sich so wie beschrieben verhält.

Link zu diesem Kommentar

Also eine Abfrage mit NSLOOKUP Google. 195.34.133.21 bringt folgendes Ergebnis:

 

Server: viedns09.chello.at

Address: 195.34.133.21

 

Nicht-autorisierende Antwort:

Name: http://www.l.google.com'>http://www.l.google.com

Addresses: 74.125.43.104, 74.125.43.99, 74.125.43.103, 74.125.43.147

Aliases: http://www.google.com'>http://www.google.com

 

 

im Sniffer:

 

38 1.871037 10.133.133.133 195.34.133.21 DNS Standard query PTR 21.133.34.195.in-addr.arpa

39 1.876618 195.34.133.21 10.133.133.133 DNS Standard query response PTR viedns09.chello.at

40 1.878826 10.133.133.133 195.34.133.21 DNS Standard query A http://www.google.com

42 1.884793 195.34.133.21 10.133.133.133 DNS Standard query response CNAME http://www.l.google.com A 74.125.43.104 A 74.125.43.99 A 74.125.43.103 A 74.125.43.147

 

Also korrekt aufgelöst.

 

 

Hier noch das IPCONFIG /all:

 

Windows-IP-Konfiguration

 

Hostname . . . . . . . . . . . . : <servername>

Primäres DNS-Suffix . . . . . . . : <domain>.co.at

Knotentyp . . . . . . . . . . . . : Hybrid

IP-Routing aktiviert . . . . . . : Nein

WINS-Proxy aktiviert . . . . . . : Nein

DNS-Suffixsuchliste . . . . . . . : <domain>.co.at

co.at

 

Ethernet-Adapter LAN-Verbindung des Servers:

 

Verbindungsspezifisches DNS-Suffix:

Beschreibung . . . . . . . . . . : Broadcom BCM5708C NetXtreme II GigE NDIS

VBD Client)

Physikalische Adresse . . . . . . : 00-19-B9-B7-44-F7

DHCP aktiviert . . . . . . . . . : Nein

IP-Adresse. . . . . . . . . . . . : 10.133.133.133

Subnetzmaske . . . . . . . . . . : 255.255.255.0

Standardgateway . . . . . . . . . : 10.133.133.130

DNS-Server . . . . . . . . . . . : 10.133.133.133

Primärer WINS-Server . . . . . . : 10.133.133.133

 

Rot markiert, vermutlich der Fehler. Woher kommen diese Einträge und wie bekomm ich das raus?

Link zu diesem Kommentar

Die benutzerdefinierte Suffixsuchliste kannst Du in den Eigenschaften der Netzwerkkarte - Internetprotokoll - DNS - "Diese DNS-Suffixe anhängen" ändern. Probiere mal mit und ohne abschliessenden Punkt. Teste NSLOOKUP auch mal so wie oben beschrieben, aber der soll den internen DNS-Server benutzen (also keinen Server an das Ende des Befehls schreiben).

Link zu diesem Kommentar

Ohne Punkt bekomme ich folgende Antwort:

 

Server: viedns09.chello.at

Address: 195.34.133.21

 

Nicht-autorisierende Antwort:

Name: www.google.com.<domain>.co.at

Address: 213.47.222.70

 

In den Netzwerkeinstellungen ist aber angehakt:

 

(o)Primäre und verbindungsspezifische DNS-Suffixe anhängen

[x] Übergeordnete Suffixe des primären DNS-Suffixes anhängen

Link zu diesem Kommentar

Hehe, ich sehe gerade, das ist doch richtig :D (habe ich irgendwie übersehen, vielleicht weil es signalrot war ;)). Es ist der primäre Suffix (<domain>.co.at) und der übergeordnete Suffix des primären Suffixes (co.at).

Im Übrigen ist das alles kein Problem, da es eine Eigenart von NSLOOKUP ist, denn Du hast ja keine Probleme beim Surfen ...

http://support.microsoft.com/kb/200525/en-us

Zitat:

"# Nslookup will always devolve the name from the current context. If you fail to fully qualify a name query (that is, use trailing dot), the query will be appended to the current context. For example, the current DNS settings are att.com and a query is performed on http://www.microsoft.com; the first query will go out as http://www.microsoft.com.att.com because of the query being unqualified. This behavior may be inconsistent with other vendor's versions of Nslookup, and this article is presented to clarify the behavior of Microsoft Windows NT Nslookup.exe

# If you have implemented the use of the search list in the Domain Suffix Search Order defined on the DNS tab of the Microsoft TCP/IP Properties page, devolution will not occur. The query will be appended to the domain suffixes specified in the list. To avoid using the search list, always use a Fully Qualified Domain Name (that is, add the trailing dot to the name)."

NSLOOKUP fügt also gleich einen der konfigurierten Suffixe an und schickt diese Anfrage auf die Reise. Bei einer Anfrage GOOGLE.COM.CO.AT ist Dein Server nicht zuständig (er ist nur für domain.co.at zuständig) und leitet es weiter. Wenn Du z.B. ein PING durchführst, wird zuerst ein . angehängt, wenn er nicht explizit angegeben wurde, was den Namen zu einem FQDN macht und daher auch kein Anhängen eines Suffixes erfolgt. Hänge bei NSLOOKUP also einen Punkt hinten ran und gut is´ ... :). Mit der Suffixsuchliste war ich übrigens auf dem falschen Dampfer (das passt zu einem anderen Problem ;)).

Der DNS-Server im Internet für COM.CO.AT hat einen Catchall, was zusammen mit dem Verhalten von NSLOOKUP zu den falschen Ergebnissen führt. Eine Anfrage NSLOOKUP BLABLABLA.COM.CO.AT ergibt die Ausgabe, die Du eingangs gepostet hast ...

Junge Junge, das war ´ne schwere Geburt ... :)

Link zu diesem Kommentar

Ok, ich schecks gerade glaub ich nicht.

 

Du willst mir glaube ich sagen, dass alles ok ist?

 

Das kann es aber nicht sein, da wir die Situation interne Domain=externe Domain bei etlichen anderen Kunden haben, und dort die nslookup Abfragen überall korrekt behandelt werden.

 

Also kann etwas nicht in Ordnung sein bei diesem einen Kunden...

 

Oder es geht gerade um den Catchall... nur hab ich keine Ahnung wie ich das verhindern kann.

 

Edit: Ich habe gerade im DNS Panel einen Eintrag *.<domain>.co.at gefunden und gelöscht. Ich hoffe damit ist das Problem gelöst. Ich warte mal bis sich das über alle DNS Server repliziert hat und poste dann hier das Ergebnis.

 

Danke schonmal vorab für die professionelle Hilfe!

Link zu diesem Kommentar

Ja genau, das Verhalten bei Dir ist normal. Bei Dir kommen 3 Dinge zusammen: Zum ersten der Catchall-Eintrag des DNS-Server für COM.CO.AT, der interne Name, der wie der externe Name ist (dieser Name also auch in der Suffixsuchliste steht) und das Verhalten von NSLOOKUP, wenn man keinen abschliessenden Punkt eingibt ... Also keine Sorge, alles gut ...

Der *.blabla wäre ein Catchall bei Dir, allerdings geht die Anfrage aus Deinem ersten Post zu COM.CO.AT, der auch einen Catchall hat. Hast Du auf diesen DNS-Server auch Zugriff ? Ich denke nicht, dass mit dem Löschen des * Dein "Problem" gelöst ist (was ja kein Problem, sondern normales Verhalten ist) ...

Link zu diesem Kommentar

Das eigentlich Problem ist hierbei nicht das nslookup, sondern dass durch die vermeindlich inkorrekte Namensauflösung der ERS (Email Reputation Service) des Trend Micro Virenscanners alarm schlägt und somit alle einkommenden Emails einfach mal blockt.

 

Aufgrund eines bei TM eröffneten Falls sind wir mit deren Engineers darauf gekommen, dass es ein DNS Problem sein muss, was sich ja auch mit nslookup zu bestätigen schien.

 

Nur weiss ich jetzt immer noch nicht wo ich damit steh...

Link zu diesem Kommentar

Es ist im Grunde kein Problem der Namensauflösung (die funktioniert wunderbar), sondern eher ein Problem mit der Suffixsuchliste auf dem Server. Der Resolver funktioniert offensichtlich tadellos, denn bei einem PING oder so wird nur eine Abfrage zur Namensauflösung des Ziels an den DNS-Server geschickt. NSLOOKUP macht das anders, es benutzt erst die Suffixsuchliste, so dass eine Anfrage nach GOOGLE.COM nicht als vollständig angesehen wird und mit einem Suffix aufgefüllt wird. So wird also aus der Anfrage GOOGLE.COM ein GOOGLE.COM.CO.AT (das was Du auch im Sniffer gesehen hast). Da Dein Server aber nicht für COM.CO.AT zuständig ist (er ist für <Domain>.COM.CO.AT zuständig), schickt er es ins Internet. Der DNS-Server im Internet ist für diese Zone zuständig und hat einen Catchall-Eintrag. Das bedeutet für Euch, dass alle so formulierten Anfragen falsch beantwortet werden. Aber nicht, weil DNS nicht richtig funktioniert, sondern weil die Anfragen falsch formuliert werden und der letztendlich beantwortende DNS-Server so konfiguriert ist.

Würde man eine Suffixsuchliste wie BLABLABLA.LOCAL konfigurieren, so wäre die erste Anfrage zwar falsch (GOOGLE.COM.BLABLABLA.LOCAL), die darauf folgende trifft dann aber (NSLOOKUP Auflösungen funtionieren dann auch ohne abschliessenden Punkt). Bei Dir wird die erste Auflösung (die falsche) vom externen Server beantwortet und dann ist Feierabend ... Du solltest unsere Ergebnisse, die wir über die ungewöhnliche Konfiguration bei Dir herausgefunden haben, den Supportern von Trendmicro mitteilen ...

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...