/etc/resolv.conf
resolv.conf
Normalerweise wird die Datei resolv.conf(5) von verschiedenen Netzwerkdienst-Dämonen dynamisch verwaltet.
- Dies ist die Standardeinstellung, die für Laptops und andere sehr mobile Systeme gedacht ist, die sich mit verschiedenen Netzwerken verbinden können.
- Es funktioniert auch gut für viele Desktop- und Serversysteme, solange die Netzwerkinfrastruktur perfekt ist.
Bei manchen Systemen und in manchen Netzwerken möchte der Systemadministrator die Datei /etc/resolv.conf von Hand konfigurieren.
- Dies führt zu einem Konflikt zwischen den Änderungen des Administrators und den dynamischen Änderungen, die von den Netzwerkdienst-Dämonen durchgeführt werden.
- Wenn Sie die Datei /etc/resolv.conf von Hand bearbeiten und verhindern müssen, dass die Daemonen Ihre Änderungen überschreiben, finden Sie auf dieser Seite einige der Möglichkeiten, die Sie haben.
openresolv und resolvconf konfigurieren
Debian stellt zwei Pakete zur Verfügung, von denen jedes ein Programm namens resolvconf enthält, das verwendet werden kann, um die Änderung der Datei /etc/resolv.conf durch verschiedene Netzwerkprogramme zu kontrollieren (oder ganz zu verhindern).
- Diese Pakete sind openresolv und resolvconf.
- Sie kollidieren miteinander, da sie buchstäblich beide das gleiche Programm bereitstellen, sodass Sie höchstens eines von ihnen auswählen müssen.
Diese Pakete enthalten verschiedene Konfigurationsdateien für andere Pakete (wie isc-dhcp-client).
- Zum Beispiel enthält resolvconf eine Datei, die die Shell-Funktion make_resolv_conf modifiziert, die von dhclient-script(8) verwendet wird.
Wenn openresolv installiert ist, können Sie es anweisen, nichts zu tun, wenn ein Daemon versucht, resolv.conf zu ändern, indem Sie resolvconf=NO in die Datei /etc/resolvconf.conf eintragen.
Wenn resolvconf installiert ist und Sie ifupdown verwenden, um Ihre Schnittstelle(n) zu konfigurieren, können Sie dns-nameserver-Einträge in der/den entsprechenden Stanza(s) in /etc/network/interfaces verwenden:
iface eth0 inet static address 192.168.1.3 netmask 255.255.255.0 gateway 192.168.1.1 dns-nameserver 192.168.1.254 dns-nameserver 8.8.8.8 dns-search foo.org bar.com
dhclient konfigurieren
Der häufigste Daemon, der resolv.conf überschreibt, ist dhclient(8) (aus isc-dhcp-client).
- In vielen Fällen reicht es aus, diesen einen Daemon davon abzuhalten, die Datei zu verändern.
dhclient daran hindern, /etc/resolv.conf zu ändern
Ein anderer Ansatz macht von den Hook-Skripten von dhclient-script Gebrauch. Laut dhclient-script(8):
- Beim Start definiert das Client-Skript zunächst eine Shell-Funktion, make_resolv_conf , die später zum Erstellen der Datei /etc/resolv.conf verwendet wird.
- Um das Standardverhalten außer Kraft zu setzen, muss diese Funktion im Enter-Hook-Skript neu definiert werden.
Daher können wir dhclient davon abhalten, die Datei resolv.conf zu überschreiben, indem wir folgendes tun:
echo 'make_resolv_conf() { :; }' > /etc/dhcp/dhclient-enter-hooks.d/leave_my_resolv_conf_alone
chmod 755 /etc/dhcp/dhclient-enter-hooks.d/leave_my_resolv_conf_alone
- Das execute-Bit ist erforderlich, weil dhclient-script run-parts(8) verwendet, um zu entscheiden, welche Dateien gelesen werden sollen.
- Aus demselben Grund darf der Dateiname nur Buchstaben, Ziffern, Unterstriche und Bindestriche enthalten.
Ändern von /etc/dhcp/dhclient.conf
Die Datei /etc/dhcp/dhclient.conf kann mit Direktiven versehen werden, die die vom DHCP-Server gesendeten Optionen außer Kraft setzen.
Diese Direktiven setzen die Parameter für Domäne, Suche und Nameserver außer Kraft, die in /etc/resolv.conf eingetragen sind:
supersede domain-name "example.com"; supersede domain-search "example.com"; supersede domain-name-servers 127.0.0.1;
Eine andere Möglichkeit besteht darin, "domain-name, domain-name-servers, domain-search" aus der Anfragezeile zu entfernen.
Dies funktioniert jedoch nur in einigen Netzwerken und nicht in anderen.
Wenn der DHCP-Server unaufgeforderte domain-name-servers (et al.)-Antworten sendet, beachtet dhclient diese trotzdem und überschreibt die Datei resolv.conf.
Modifying /etc/dhcp/dhclient.conf
The /etc/dhcp/dhclient.conf file can be populated with directives that will override the options sent by the DHCP server.
- For example, these directives will override the domain, search, and nameserver parameters that are placed into /etc/resolv.conf:
supersede domain-name "example.com"; supersede domain-search "example.com"; supersede domain-name-servers 127.0.0.1;
Another option is to remove "domain-name, domain-name-servers, domain-search" from the request line.
- However, this only works on some networks, and not on others.
- If the DHCP server sends unsolicited domain-name-servers (et al.) responses, dhclient will still heed them, and will still overwrite the resolv.conf file.
resolv.conf unveränderbar machen
Dieser Ansatz macht /etc/resolv.conf unveränderlich, so dass sie nicht geändert werden kann, unabhängig davon, welche Pakete installiert sind oder wer versucht, sie zu ändern.
rm -f /etc/resolv.conf editor /etc/resolv.conf chattr +i /etc/resolv.conf
Natürlich müssen Sie den entsprechenden Inhalt in die Datei einfügen, bevor Sie das immutable-Bit setzen.
- Jedes Mal, wenn Sie die Datei ändern wollen, müssen Sie das Bit entfernen, Ihre Änderung vornehmen und dann das Bit wiederherstellen.
Eine Folge davon, /etc/resolv.conf unveränderlich zu machen, ist, dass, wenn dhclient-script versucht, die Datei zu ändern und dabei scheitert, es /etc mit temporären Dateien überfüllt.
- Siehe 860928 für Details.
- Der Benutzer/Administrator muss diese Dateien möglicherweise regelmäßig aus /etc entfernen, bis #860928 behoben ist.
Links
RESOLV.CONF(5) File Formats Manual RESOLV.CONF(5)
Manpage
BEZEICHNUNG
resovl.conf - Konfigurationsdatei für den Resolver
ÜBERSICHT
/etc/resolv.conf
BESCHREIBUNG
Der Resolver ist eine Sammlung von Routinen in der C-Bibliothek, über die auf das Internet-Namenssystem (Domain Name System, DNS) zugegriffen wird. Die Konfigurationsdatei des Resolvers enthält Informationen, die beim ersten Aufruf einer Resolver-Routine durch einen Prozess eingelesen werden. Die Datei wurde menschenlesbar entworfen und enthält eine Liste von Schlüsselworten und Werten, die verschiedene Typen von Resolver-Informationen bereitstellen. Die Konfigurationsdatei wird als eine vertrauenswürdige Quelle für DNS-Informationen betrachtet; lesen Sie die nachfolgende Option trust-ad für Details.
Wenn diese Datei nicht vorhanden ist, wird nur der Name-Server auf dem lokalen Rechner abgefragt und die Suchliste enthält nur den aus dem Rechnernamen ermittelten lokalen Domain-Namen.
Die verschiedenen Konfigurationsoptionen sind:
- nameserver IP-Adresse des Name-Servers
Die Internet-Adresse eines Name-Servers, den der Resolver abfragen soll, entweder eine
IPv4-Adresse (in Punkt-Notation) oder eine IPv6-Adresse in Doppelpunkt- (und
möglicherweise Punkt-)Notation gemäß RFC 2373. Es können bis zu MAXNS (derzeit 3, siehe
<resolv.h>) Name-Server angegeben werden, einer je Schlüsselwort. Werden mehrere
DNS-Server angegeben, wird sie der Resolver in der angegebenen Reihenfolge abfragen. Sind
keine nameserver-Einträge vorhanden, wird standardmäßig der Name-Server des lokalen
Systems angesprochen. (Der Algorithmus ist der folgende: Der Resolver richtet eine
Anfrage an einen Name-Server und versucht es nach einer Zeitüberschreitung beim nächsten,
bis alle Einträge abgearbeitet sind. Danach wird die Liste wieder von vorne abgearbeitet,
bis die maximal zulässige Anzahl von Versuchen erreicht wird.)
- search Suchliste für Rechnernamen
Standardmäßig enthält die Suchliste nur einen Eintrag, den lokalen Domain-Namen. Er wird
anhand des lokalen Rechnernamens ermittelt, der von gethostname(2) geliefert wird. Es
wird in diesem Fall davon ausgegangen, dass die lokale Domain der Teil des Namens ist,
der rechts vom ersten '.' steht. Wenn der Rechnername kein '.' enthält, wird die
Root-Domain als Wert für die lokale Domain angenommen.
Dieses Verhalten kann geändert werden, indem mit dem Schlüsselwort search ein Suchpfad
für die Domain-Auflösung angegeben wird, dessen Bestandteile durch Tabulatoren oder
Leerzeichen voneinander zu trennen sind. Anfragen an den Resolver mit weniger als ndots
Punkten (Standardwert ist 1) werden versuchen, jeden Eintrag dieses Suchpfads
abzuarbeiten, bis ein gültiger Namenseintrag gefunden wurde. Für Umgebungen mit mehreren
Subdomains lesen Sie bitte options ndots:n weiter unten, wie Sie
»Mann-in-der-Mitte«-Angriffe und unnötigen Verkehr für die Root-DNS-Server vermeiden.
Beachten Sie, dass dieser Vorgang langsam sein kann und viel Netzwerkverkehr erzeugt,
wenn die DNS-Server für die betreffenden Domains nicht lokal sind. Außerdem können
Anfragen mit einer Zeitüberschreitung beendet werden, wenn kein Server für eine der
genannten Domains erreichbar ist.
Falls es mehrere search-Direktiven gibt, wird nur die Suchliste der letzten Instanz
verwandt.
In Glibc 2.25 und älter ist die Suchliste auf 6 Domains und eine Gesamtlänge von 256
Zeichen beschränkt. Seit Glibc 2.26 ist die Suchliste unbegrenzt.
Die Direktive domain ist ein veralteter Name für die Direktive search, die nur mit einem
Suchlisteneintrag umgeht.
- sortlist
Diese Option ermöglicht die Sortierung von durch gethostbyname(3) ermittelten Adressen.
Eine Sortierliste wird durch Kombinationen von IP-Adresse und Netzmaske angegeben. Die
Netzmaske ist optional, es wird als Standardwert die native Netzmaske des Netzes
angenommen. Die Kombinationen von IP-Adresse und Netzmaske werden durch Schrägstriche
getrennt. Es können bis zu 10 Paare angegeben werden. Ein Beispiel:
sortlist 130.155.160.0/255.255.240.0 130.155.0.0
- options
Mit dieser Option können bestimmte interne Variablen des Resolvers beeinflusst werden.
Die Syntax lautet:
options Option …
Option kann dabei einen der folgenden Werte annehmen:
debug setzt RES_DEBUG in _res.options (nur wirksam, falls Glibc mit Debug-Unterstützung
gebaut wurde, siehe resolver(3)).
ndots:n
definiert einen Schwellwert für die Anzahl der Punkte, die in einem an
res_query(3) übergebenen Namen enthalten sein müssen (siehe resolver(3)), damit
ein initial absolute query ausgeführt wird. Der Standardwert für n ist 1. Das hat
zur Folge, dass zunächst versucht wird, den Namen als absoluten Namen aufzulösen,
bevor ihm ein Eintrag aus der search list angehängt wird. Der Wert für diese
Option wird stillschweigend auf 15 begrenzt.
timeout:n
setzt die Wartezeit auf die Antwort eines Name-Servers in der Ferne fest, nach
deren Ablauf der Resolver die Anfrage an einen anderen Name-Server richtet. Dies
muss nicht die gesamte von dem Resolver-API-Aufruf verwandte Zeit sein und es gibt
keine Garantie, dass ein einzelner Resolver-API-Aufruf auf eine einzelne
Zeitüberschreitung passt. Sie wird in Sekunden gemessen, der Standardwert ist
RES_TIMEOUT (derzeit 5, siehe <resolv.h>). Der Maximalwert für diese Option ist
30.
attempts:n
Diese Option legt die Anzahl der Anfragen fest, die der Resolver an seine
Name-Server sendet, bevor er aufgibt und dem aufrufenden Programm einen Fehler
meldet. Der Standardwert ist RES_DFLRETRY (derzeit 2, siehe <resolv.h>); der
Maximalwert 5.
rotate Diese Option setzt RES_ROTATE in _res.options, was eine Reihum-Auswahl der
Name-Server aus der Liste zur Folge hat. Auf diese Weise werden die Anfragen auf
alle aufgeführten Server verteilt, anstatt dass alle Clients sich zunächst an den
ersten aufgeführten Server wenden.
no-check-names
Diese Option setzt RES_ROTATE in _res.options. Damit wird die moderne von BIND
durchgeführte Prüfung eingehender Rechner- und E-Mail-Namen auf ungültige Zeichen
wie Unterstrich (_), Steuerzeichen und andere Kodierungen als ASCII deaktiviert.
inet6 setzt RES_USE_INET6 in _res.options. Dadurch wird innerhalb der Funktion
gethostbyname(3) zunächst eine AAAA-Anfrage vor einer A-Anfrage durchgeführt.
Außerdem werden IPv4-Antworten in »IPv6 tunneled form« abgebildet, wenn keine
AAAA-Einträge gefunden werden, aber ein Satz von A-Einträgen existiert. Seit Glibc
2.25 ist diese Option veraltet; Anwendungen sollten getaddrinfo(3) statt
gethostbyname(3) verwenden.
Wenn diese Option gewählt wurde, verhalten sich einige Programme recht merkwürdig.
ip6-bytestring (seit Glibc 2.3.4 bis 2.24)
setzt RES_USE_BSTRING in _res.options. Damit verwenden inverse IPv6-Suchen das in
RFC 2673 beschriebene »bit-label«-Format. Wird die Option nicht gewählt (die
Vorgabe), wird das Nibble-Format verwendet. Diese Option wurde in Glibc 2.25
entfernt, da sie auf einer rückwärts-inkompatiblen DNS-Erweiterung basiert, die im
Internet niemals eingesetzt worden war.
ip6-dotint/no-ip6-dotint (Glibc 2.3.4 bis 2.24)
Löscht/Setzt RES_NOIP6DOTINT in _res.options. Wenn diese Option gelöscht ist
(ip6-dotint), werden inverse IPv6-Suchen in der ip6.int-Zone durchgeführt, wovon
abgeraten wird. Wurde die Option gewählt (no-ip6-dotint), werden inverse
IPv6-Suchen standardmäßig in der ip6.arpa-Zone durchgeführt. Diese Optionen sind
in Glibc bis Version 2.24 verfügbar, wo no-ip6-dotint die Vorgabe ist. Da die
Unterstützung von ip6-dotint seit langer Zeit nicht mehr im Internet verfügbar
ist, wurden diese Optionen in Glibc 2.25 entfernt.
edns0 (seit Glibc 2.6)
setzt RES_USE_EDNS0 in _res.options. Damit wird die Unterstützung für die in
RFR 2671 beschriebenen DNS-Erweiterungen aktiviert.
single-request (seit Glibc 2.10)
setzt RES_SNGLKUP in _res.options. Standardmäßig erledigt die Glibc seit Version
2.9 das Abfragen von IPv4- und IPv6-Adressen parallel. Diese Anfragen können
einige Appliance-DNS-Server nicht korrekt verarbeiten und führen zu
Zeitüberschreitungen (timeouts). Diese Option deaktiviert die parallelen Anfragen
und lässt Glibc die IPv6-und IPv4-Anfragen nacheinander erledigen (wodurch der
Prozess etwas langsamer wird).
single-request-reopen (seit Glibc 2.9)
setzt RES_SNGLKUPREOP in _res.options. Der Resolver verwendet die gleichen Sockets
für die A- und AAAA-Anfragen. Einige Hardware sendet fälschlicherweise nur eine
Antwort zurück. Wenn das passiert, wird das Client-System auf die zweite Antwort
warten. Das Einschalten dieser Option ändert das Verhalten: Wenn zwei Anfragen von
dem gleichen Port nicht korrekt gehandhabt werden wird es das Socket schließen und
einen neuen vor dem Versand der zweiten Anfrage öffnen.
no-tld-query (seit Glibc 2.14)
setzt RES_NOTLDQUERY in _res.options. Diese Option führt dazu, dass res_nsearch()
nicht versucht, einen nicht qualifizierten Namen aufzulösen, als ob er ein »top
level domain« (TLD) wäre. Diese Option kann zu Problemen führen, falls die Site
»localhost« als TLD verwendet, statt »localhost« als ein oder mehrere Elemente auf
der Suchliste zu haben. Diese Option hat keinen Effekt, falls weder RES_DEFNAMES
noch RES_DNSRCH gesetzt ist.
use-vc (seit Glibc 2.14)
setzt RES_USEVC in _res.options. Diese Option erzwingt die Verwendung von TCP für
DNS-Auflösungen.
no-reload (seit Glibc 2.26)
setzt RES_NORELOAD in _res.options. Diese Option deaktiviert das automatische
Neuladen einer geänderten Konfigurationsdatei.
trust-ad (seit Glibc 2.31)
setzt RES_TRUSTAD in _res.options. Diese Option steuert das Bit AD-Bit-Verhalten
des Stub-Resolvers. Falls ein überprüfender Resolver das AD-Bit in einer Antwort
setzt, zeigt er an, dass die Daten in der Antwort entsprechend des
DNSSSEC-Protokolls überprüft wurden. Um sich auf das AD-Bit zu verlassen, muss das
lokale System sowohl dem DNSSEC-überprüfenden Resolver als auch dem dahin
führenden Netzwerkpfad vertrauen, weshalb eine ausdrückliche Zustimmung zur
Nutzung notwendig ist. Falls die Option trust-ad aktiv ist, setzt der
Stub-Resolver das AD-Bit in ausgehenden DNS-Anfragen (um AD-Bit-Unterstützung zu
aktivieren) und behält das AD-Bit in Antworten bei. Ohne diese Option wird das
AD-Bit in Anfragen nicht gesetzt und immer in Antworten entfernt, bevor diese an
die Anwendung zurückgeliefert werden. Das bedeutet, dass Anwendungen dem AD-Bit in
Antworten vertrauen können, wenn die Option trust-ad korrekt eingerichtet wurde.
In Glibc bis Version 2.30 wurde AD in Abfrage nicht automatisch gesetzt und in
Antworten an Anwendungen unverändert weitergegeben.
Das Schlüsselwort search aus der resolv.conf eines Systems kann von Prozessen individuell außer Kraft gesetzt werden, indem der Umgebungsvariablen LOCALDOMAIN eine Liste von durch Leerzeichen getrennten Domains zugewiesen wird.
Das Schlüsselwort options der systemweiten resolv.conf-Datei kann von Prozessen individuell ergänzt werden, indem die Umgebungsvariable RES_OPTIONS auf eine Liste von durch Leerzeichen getrennten Resolver-Optionen gesetzt wird, wie sie unter options beschrieben wurden.
Konfigurationsoptionen und ihre Werte müssen gemeinsam auf einer Zeile stehen. Die Zeile muss mit dem Namen der Konfigurationsoption (z.B. nameserver) beginnen. Auf den Namen der Konfigurationsoption folgt der Wert, bzw. folgen die Werte. Alle Felder sind durch Leerzeichen oder Tabulator zu trennen.
Zeilen, die ein Semikolon (;) oder ein Nummernzeichen (#) in der ersten Spalte enthalten, werden als Kommentare behandelt.
DATEIEN
- /etc/resolv.conf
- <resolv.h>
SIEHE AUCH
- gethostbyname(3)
- resolver(3)
- host.conf(5)
- hosts(5)
- nsswitch.conf(5)
- hostname(7)
- named(8)
- Name Server Operations Guide for BIND