Erzwingen Sie Weiterleitungs-DNS-Anforderungen in den TCP-Modus

Ich habe einen DNS-Server auf SLES10 (derzeit Bindung 9.6) auf einem Multi-Homed-Server eingerichtet. Dieser Server kann von allen internen Netzwerken abgefragt werden und liefert Antworten für alle internen Netzwerke. Wir haben zwei separate DNS "Master" -Zonen. Jede dieser Zonen wird von einer Reihe autorisierender Windows-DNS-Server bedient.

Jetzt ist mein Linux-Server ein sekundärer DNS-Server für eine dieser Zonen (private interne Zone) und fungiert als Weiterleitung für die andere Zone (öffentliche interne Zone).

Bis vor kurzem funktionierte dieses Setup ohne Probleme. Jetzt erhalte ich - beim Abfragen der öffentlichen internen Zone (zB durch den hostBefehl auf einem Linux-Client) die Fehlermeldung

;; Abgeschnitten, erneuter Versuch im TCP-Modus

Ein Wireshark-Dump hat die Ursache dafür aufgedeckt: Die erste Abfrage wird im UDP-Modus ausgeführt, die Antwort passt nicht in UDP (aufgrund der längeren Liste autorisierender NS), dann wird sie im TCP-Modus wiederholt und liefert die richtige Antwort.

Nun die Frage: Kann ich meine Bindung so konfigurieren, dass die Weiterleitungen im TCP-Modus abgefragt werden, ohne zuerst UDP zu versuchen?

Update: Ich versuche mich an ASCII-Kunst ...

+--------------+   +--------------+   +-----------------+
| W2K8R2 DNS   |   | SLES 10 DNS  |   | W2K8R2 DNS      |
| Zone private +---+ All internal +---+ Zone public     |
| internal 2x  |   |   Zones      |   | internal 30+ x  |
+--------------+   +-+----------+-+   +-----------------+
                     |          |
                  +--+---+   +--+---+
                  |Client|   |Client|
                  +------+   +------+

— Nils
quelle

Ein kleines Diagramm davon wäre nützlich - ich habe Mühe, anhand Ihrer Beschreibung herauszufinden, welcher Server welcher ist.

— Alnitak

etwas besser, obwohl immer noch unklar ist, zwischen welchen Hosts Sie diesen hostBefehl ausführen und welche Abfrage gesendet wird.

— Alnitak

Die Clients fordern über SLES10 die Einträge von der Zone public internal an. Die Zone privat intern leidet nicht - da dort nur 2 NS-Einträge vorhanden sind.

— Nils

und die Kunden sind einfach nur Stub-Resolver?

— Alnitak

Schlagen Sie vor, dass Sie minimal-responses: yesder BIND-Konfiguration auf SLES 10 hinzufügen - dies kann die Antwortgröße verringern. In jedem Fall überschreiten die meisten normalen Abfragen nicht das 512-Byte-Limit.

— Alnitak

Antworten:

Erstens würde ich das nicht als Fehler bezeichnen, sondern nur als Informationsnachricht.

Zweitens beantworten DNS-Server immer UDP-Abfragen (zumindest BIND, ich kann keine Optionen zum Deaktivieren von UDP finden), und Clients versuchen immer (?), Zuerst eine UDP-Abfrage zu senden (zum Beispiel gibt es in resolv.conf keine Optionen, um dies zu ändern noch in der JVM) - wenn sie in ein UDP-Paket passen (Anforderungen normalerweise)

Wenn Sie einen bestimmten Anwendungsfall haben, können Sie die Verwendung von TCP angeben, z. B. im Shell-Skript 'dig + tcp' oder 'host -T' zur Auflösung verwenden, und Sie können Systemaufrufe 'sethostent / gethostbyname / endhostent' verwenden (siehe man Seite), um TCP in anderen Fällen zu erzwingen.

Wenn Sie wirklich versuchen möchten, UDP zu blockieren, kann ich nur eine iptable-Regel sehen, aber ich bin nicht sicher, ob diese Einrichtung funktionieren würde. Ich gehe davon aus, dass die DNS-Auflösung einfach fehlschlagen würde.

— Dan Andreatta
quelle

Es ist nominell ein Leistungsvorteil, wenn Sie a priori wissen, dass die UDP-Abfrage fehlschlägt, und zuerst TCP ausprobieren. Siehe RFC 5966 für eine Diskussion darüber.

— Alnitak

@Alnitak und ich möchten diesen Vorteil erhalten.

— Nils

@Nils also müssen wir herausfinden, warum EDNS anscheinend nicht funktioniert ...

— Alnitak

Ich habe keinen speziellen Anwendungsfall - die Clients verwenden ihre Resolver-Bibliothek - aber jede Anfrage und jede Antwort wird zweimal über das Netzwerk gesendet - das gefällt mir nicht.

— Nils

@Nils, das Problem ist, dass der Client UDP / TCP entscheidet, der Server jedoch die Größe der Antwort kennt.

— Dan Andreatta

Ihr BIND-Server sollte EDNS verwenden (siehe RFC 2671), um UDP-Pakete zuzulassen, die länger als 512 Byte sind.

options {
    edns-udp-size 4096;
    max-udp-size 4096;
};

Dies sollte ermöglichen, dass Ihr großer NS-Satz über UDP abgerufen werden kann, ohne dass für andere kleinere Abfragen der Overhead einer TCP-Verbindung erforderlich ist.

Beachten Sie jedoch, dass dies tatsächlich die Standardwerte sind. Wenn EDNS nicht verwendet wird, blockiert es entweder etwas oder die Server, die die EDNS-Optionen erhalten, unterstützen es nicht.

Beachten Sie auch, dass hostEDNS nicht unterstützt wird. Es ist durchaus möglich, dass Ihre Weiterleitung -> Serverabfragen bereits EDNS verwenden, und Sie können es einfach nicht sehen, wenn Sie es mit Ihrem lokalen Client versuchen.

Versuchen Sie es dig +bufsize=4096 @server hostname Aanstatt zu verwenden host.

— Alnitak
quelle

Wer sollte das benutzen? Vermutlich sowohl mein Server als auch meine Spediteure aus der Zone "public internal"?

— Nils

Was bedeutet es überhaupt, die vollständige Liste der NS in der Antwort zu senden?

— Nils

@Nils das DNS-Protokoll erfordert, dass der vollständige Satz von Einträgen, die mit demselben Tupel (QNAME, QTYPE und QCLASS) übereinstimmen, unteilbar ist (auch bekannt als "RRset")

— Alnitak

Können Sie mich bitte bezüglich dieses RRset auf den RFC hinweisen?

— Nils

Actaully Host verwendet die Standard-Resolver-Bibliothek und unterstützt auf meiner Workstation EDNS0. Um zu testen, ob die Anforderungen EDNS0 angeben, führen Sie 'tcpdump -x port 53' aus, und der Hex-Dump sollte (gegen Ende im zusätzlichen Abschnitt) die Sequenz 0029 1000 0000 8000 0000 enthalten, die die binäre Darstellung der OPT RR ist.

— Dan Andreatta