type ANY bringt timeout; A, NS, MX z.B. nicht

rseffner

New Member
Hallo,

ich administriere und konfiguriere unixoide System schon seit über anderthalb Jahrzeht, aber jetzt bin ich mit meinem Latein echt am Ende.

Ich habe zwei Clients als gateway an t-online DSL und einen Server in einem RZ. Der Server ist NS, die Clients hängen an unterschiedlichen POPs, regional und vom Routing her recht nahe beieinander. Alle Systeme laufen unter einem stets aktuellen debian lenny.

Egal ob dig oder nslookup, wenn ich von einem der Clients gegen den Server frage bekommen ich bei type ANY einen timeout, bei A, MX oder NS jedoch sofort Antwort. Vom zweiten Client aus geht es. Der Server spielt für das Phänomen eigentlich keine Rolle, ich nutze ihn hier nur, weil ich Zugriff drauf habe. tcpdump zeigt bei ANY vom probematischen Client ein ausgehendes Paket, der Server hat dazu aber kein einkommendes. Die ANY Anfrage sieht im dump genau so aus, wie vom Client, der eine Antwort bekommt. Der Server (es betrifft ja auch Fragen an alle anderen wie goole oder dell) unterscheidet die Clients natürlich nicht. Ein Paketfilter ist zwar zwischen, der unterscheidet ja aber nach Protokoll und Port, nicht nach Typ der Anfrage - egal, auch abgeschalten bleibt das Problem. Selbst Clients hinter dem betroffenen gateway habe bei ANY keine Chance, bei anderen Typen aber Funktion.

Ist der Netzwerkstack vom gateway kaputt oder filtert der rosa Riese hier? Was noch aussteht, ist, das gateway mal durch eine andere Maschine zu ersetzen, sprich den Anschluß mit anderem Gerät zu testen. Aber selbst wenn ich den Provider ausschließen kann, was kann auf dem gateway so quer stecken. Ich verstehe immer gern den Grund und installier nicht einfach so mal neu, nur damit es dann irgendwie geht ...

Hat irgendwer Ideen?

Gruß
Ronny
 
Last edited by a moderator:
oder filtert der rosa Riese hier?

Zensursula läßt grüßen. :mad:

Sind die beiden DSL-Anschlüsse irgendwie unterschiedlich (z.B. t-dialin/t-ipconnect) oder so?

Kannst Du mal temporär den DNS zusätzlich auf einen anderen Port binden?
 
Ich glaube nicht, daß das die Ursache ist. Wenn ich rseffner richtig verstehe, fragt er nicht die zugewiesenen rekursiven Nameserver ab, sondern auf direktem Wege den jeweiligen authoritativen. Das ist eine reine UDP-Verbindung ohne Beteiligung von Nameservern des Providers.

Ob die Navigationshilfe aktiv ist, kann man recht einfach sehen:

Bis zur Umsetzung der ganzen Zensurgeschichte wurde der regionale Cluster auch als e. und 2. DNS-Server vorgegeben, also Ort-lb-a/b01/2.isp.t-ipnet.de (Ort ist dabei das KFZ-Kennzeichen des Clusters, a/b 1/2 die Kennung des Knotens, meist aus 217.237.148.0/22).

Inzwischen wird ohne Navigationshilfe ein DNS-Proxy (Ort-mdrex-a/b01/2.isp.t-ipnet.de, 217.0.41.0/24) vergeben, mit ein anderer (Ort-nxr-a/b01/2.isp.t-ipnet.de, 217.0.43.0/24), also Umsetzung laut Minimalanforderung.
 
Back
Top