Suche und Domain in resolv.conf = langsame Suche unter Ubuntu

Ich habe einen Computer mit Ubuntu 10.04 Server. Ich habe angefangen, lange (5-10 Sekunden) Verzögerungen zu bekommen, wenn ich mit Tools wie curlund Verbindungen zu (einigen) Standorten außerhalb des LAN herstelle wget.

Bei Verwendung von tcpdumpund wireshark habe ich festgestellt, dass das Problem in den DNS-Suchvorgängen liegt, die zum Einrichten der Verbindung durchgeführt werden:

BEISPIEL

Wenn ich renne:

wget www.site1.com

Ich sehe folgendes Verhalten:

LOOKUP: AAAA www.site1.com       
        # => fail, no delay, site1 doesn't have an IPv6 AAAA record
LOOKUP: AAAA www.site1.com.mydomain.lan
        # => fail, BIG DELAY, crazy domain doesn't exist
LOOKUP: A www.site1.com
        # => success, no delay, resolves as expected (site1 has IPv4 A record)
CONNECTION PROCEEDS ...

MEIN SETUP

Die resolv.conf meines Servers sieht folgendermaßen aus:

nameserver 192.168.0.1  # my router
domain mydomain.lan    # made up domain name, for my lan
search mydomain.lan

Die Hosts-Datei meines Servers sieht folgendermaßen aus:

127.0.0.1       localhost.localdomain   localhost
192.168.0.10    server1.mydomain.lan   server1
# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

ENTSCHLIESSUNGEN?

Warum wird meine resolv.conf-Suchliste beim Erstellen des Namens für die 2. Suche verwendet, wenn die Manpage resolv.conf vorschlägt, dass sie nur beim Nachschlagen von Hostnamen (keine Punkte) verwendet wird:

"Resolver-Abfragen mit weniger als ndots Punkten (Standard ist 1) werden nacheinander mit jeder Komponente des Suchpfads versucht, bis eine Übereinstimmung gefunden wird."

Ich habe den Eindruck, die 2. Suche ist fehlerhaft und sollte überhaupt nicht durchgeführt werden ...

Wenn ich die Zeilen domainund searchaus resolv.conf entferne , wird die zweite Suche nicht mehr durchgeführt und meine Verzögerungen verschwinden.

(Wenn ich wget zwinge, nur mit IPv4 umzugehen, werden die AAAA-Suchvorgänge nicht durchgeführt, sodass die Verzögerungen verschwinden.)

wget --inet4-only www.site1.com

Dieses Verhalten ist beabsichtigt.

IPv6 wird bevorzugt - daher wird zuerst der Status der Ressource AAAAermittelt. Eine NXDOMAINAntwort kommt zurück - der Kunde geht also davon aus, dass er den searchPfad anhängen muss.

Beachten Sie, dass die ndotsBemerkung, die Sie gemacht haben, richtig ist - aber nicht die ganze Geschichte. Wenn die ndotsNummer höher als der abgefragte Name ist (in diesem Fall ein einzelner Labelname), besteht der einzige Unterschied zum Abfrageverhalten darin, dass die Abfrage mit dem angehängten Suffix erfolgt, bevor der Rohname versucht wird. Da Sie den ndotsSchwellenwert überschreiten, wird der Name wie angegeben zuerst ausprobiert. Siehe weiter unten in der Manpage:

Der Standardwert für n ist 1, dh wenn ein Name Punkte enthält, wird der Name zuerst als absoluter Name versucht, bevor Suchlistenelemente an ihn angehängt werden.

Diese Abfrage ist fehlgeschlagen, daher muss die Suchliste verwendet werden. Beachten Sie den Unterschied im Abfrageverhalten mit wget http://site1/.

Was Sie sehen, ist beabsichtigtes Verhalten. Ich denke, Sie müssen das Zusammenfließen von Faktoren beheben, die diese langsame Suche verursachen.

• Korrigieren Sie Ihren DNS-Server oder den Upstream, von dem er rekursiv ist. Ein Rekursor sollte das, was NXDOMAINer von den Roots erhält, leicht zwischenspeichern können, wenn er versucht, eine nicht vorhandene TLD nachzuschlagen. Da das Deaktivieren von IPv6 das Problem behebt, befindet sich möglicherweise ein DNS-Server im Pfad, der beim Zwischenspeichern bei AAAASuchvorgängen kläglich fehlschlägt . Versuchen Sie, Ihren Resolver zu ändern, um dies 8.8.8.8zu überprüfen.
• Fügen Sie keinen Suchpfad mehr für eine DNS-Zone hinzu, nach der Sie anscheinend nicht suchen können. Wenn Ihr DNS-Server für diese Zone autorisierend wäre (was erforderlich wäre, damit diese searchEinstellung von Nutzen ist, da es sich nicht um einen gültigen Namen in der öffentlichen Hierarchie handelt), würde er sofort reagieren. Sie benötigen diese searchKonfiguration wahrscheinlich nicht - stellen Sie sie jedoch auf einen Wert ein, der aufgelöst wird, damit nicht versucht wird, sie anhand des Hostnamens des Computers zu erraten. search comsollte gut tun.

Wenn Sie an einer Shell-Eingabeaufforderung $ sagen hostname und zurückkehren foo.bar.baz, versteht der DNS-Resolver, dass Ihr Hostname foound Ihr Domainname lautet bar.baz. Im Allgemeinen sind die Zeilen "domain" und "search" in /etc/resolv.conf nur dann von Nutzen, wenn dies nicht der Fall ist (oder wenn Sie ungewöhnliches Verhalten provozieren möchten ).

Wenn Ihr Domainname ist wirklich bar.baz, dann am ehesten sollten Sie nicht angeben , entweder die „Domäne“ oder die Zeilen in /etc/resolv.conf „suchen“. Im Gegensatz zu dem, was an anderen Orten häufig der Fall ist, führt die Tatsache, dass /etc/resolv.conf durch erneutes Angeben von Informationen, die bereits verfügbar sind, "zimperlich" hostnameist, normalerweise zu bizarren und unerwünschten Verhaltensweisen (einschließlich alberner langer Zeitüberschreitungen). Dies gilt sowohl für große gewerbliche als auch für kleine private Umgebungen.

(Vorsichtsmaßnahme: Jedes Anwendungsprogramm kann /etc/resolv.conf möglicherweise ein wenig anders interpretieren, so dass dies theoretisch möglicherweise nicht universell zutrifft. Auf den meisten modernen Systemen werden 99% der Resolver-Anforderungen über GLIBC abgewickelt oben ist fast immer wahr.)