/etc/resolv.conf

resovl.conf - Konfigurationsdatei für den DNS-Resolver

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.

Beim Begriff "resolvconf" besteht ein Namenskonflikt

* Es gibt eigenständige Programme und Pakete mit diesem Namen. Diese wurden früher (vor 17.10) auch bei Ubuntu eingesetzt.
* Der Name "resolvconf" ist ein Alias für das Dienstprogramm resolvectl von [:systemd/systemd-resolved:systemd-resolved], welches sich unter seinem Alias ganz anders als unter seinem eigentlichen Namen verhält und die Funktionalität der gleichnamigen eigenständigen Programme eingeschränkt nachbildet.

Das Paket resolvconf ist ein Manager für die wichtige Systemdatei /etc/resolv.conf, mit der die DNS-Namensauflösung über die glib-Bibliothek konfiguriert wird.

In der Frühzeit der unixoiden Betriebssysteme war es üblich, die zur DNS-Namensauflösung benötigten Informationen – insbesondere die IP-Adressen der Namensserver und den Suchpfad für die Domänen – in der Textdatei /etc/resolv.conf direkt mit Hilfe eines Texteditors[3] einzutragen; seit dem Jahre 2003 verwenden Debian-Systeme und auch Ubuntu-Desktops bis zur Version 16.10 hierfür jedoch den Manager resolvconf, der diese Aufgabe nach Angaben der eingesetzten Netzwerk-Konfigurationsprogramme wie [:interfaces:ifupdown], [:NetworkManager:], DHCP-Clients automatisch wahrnimmt. Seit Ubuntu 17.10 wird statt resolvconf der Manager [:systemd/networkd/#systemd-resolved:systemd-resolved] verwendet.

Hinweis

Bei einem Rechnersystem mit aktivem Manager für die Datei /etc/resolv.conf sollte man diese Datei nicht selbst direkt mit einem Texteditor bearbeiten, da man sonst Störungen der DNS-Namensauflösung riskiert.

Installation

Bei Ubuntu-Desktop-Systemen wird bei einer normalen Installation vor 17.10 bereits ein Manager für die Systemdatei /etc/resolv.conf installiert.

Bei Ubuntu-Server-Systemen und neueren Desktop-Systemen benötigt man dieses Paket[1]: {{{#!vorlage Paketinstallation resolvconf }}}

Man sollte nicht mehrere Manager für die Systemdatei /etc/resolv.conf parallel installieren. Der bei Ubuntu 16.04 als Standard installierte resolvconf und der bei Ubuntu ab 17.10 als Standard installierte systemd-resolved stören sich gegenseitig. Dieser Konflikt wird im Paketmanagment nicht aufgelöst. Bei Systemen ab 17.10 muss systemd-resolved manuell deaktiviert werden, damit keine Störungen auftreten. Der NetworkManager muss zudem so konfiguriert werden, dass dieser resolvconf nutzt.

Anwendungen

Bei installiertem resolvconf kann man die Namensserver und den Domänen-Suchpfad über die gängigen Netzwerk-Konfigurationsprogramme festlegen:

ifupdown

Hier erfolgen die Angaben in der Datei /etc/network/interfaces:

* Bei Verwendung der Methode `dhcp` werden die vom DHCP-Server empfangenen Informationen vom DHCP-Client direkt an das Programm resolvconf übergeben.
* Bei Verwendung der Methode `static` kann man über die Optionen `dns-nameservers` und `dns-search` angeben, was das Programm resolvconf eintragen soll. Für Beispiele lese den Artikel [:interfaces:].

Network Manager

Hier erfolgen die Angaben in den Verbindungsdateien im Verzeichnis /etc/NetworkManager/system-connections/ mit Hilfe der Optionen `ipv4.dns` für die Server und `ipv4.dns-search` für den Suchpfad. Diese Angaben kann man (als root[4]) direkt per Texteditor in der Verbindungsdatei eintragen, oder man benutzt das [:NetworkManager/NetworkManager_ohne_GUI:Text-Interface von NetworkManager] oder dessen GUI. In gleicher Weise kann man auch IPv6-Adressen für Namensserver über die Option `ipv6.dns` definieren.

systemd-networkd

systemd-networkd enthält keine Schnittstelle zu resolvconf. Man benutzt besser den Manager [:systemd/networkd/#systemd-resolved:systemd-resolved] aus der systemd-Familie.

Manuelle Konfiguration

Man kann das Programm resolvconf auch über eine Console händisch aufrufen[2] und ihm die Informationen übergeben. Das folgende Beispiel definiert beispielhaft einen lokalen und den Google-Nameserver:

(echo 'nameserver 10.11.12.13' ; echo 'nameserver 8.8.8.8' ) | sudo resolvconf -a eth0.manual
sudo  resolvconf -u

Im Prinzip schreibt man den gewünschten Inhalt der Datei /etc/resolv.conf auf den Eingangskanal stdin des Programms resolvconf, welches wegen der Option `-a` diese Informationen im Beispiel unter der Record-Bezeichnung eth0.manual speichert. Man ist selbst für eine sinnvolle Bezeichnung verantwortlich und sollte die Hinweise der Manpage beachten. Ein Aufruf mit der Option `-u` triggert die Aktualisierung der Datei /etc/resolv.conf.

Alternativ kann man, wenn man ohnehin die Datei /etc/resolv.conf händisch pflegen möchte, das Paket resolvconf deinstallieren und damit die Komplexität seines Systems reduzieren. Man beachte aber, dass dann damit auch NetworkManager funktional eingeschränkt wird und in der Datei /etc/network/interfaces die Optionen `dns-nameservers` und `dns-search` nicht mehr funktionieren. Ersatzweise kann/muss man den DHCP-Client direkt konfigurieren.

Syntax

Optionen

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 …

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.

Konfiguration

Dateien

1. /etc/resolv.conf
2. <resolv.h>

Dokumentation

Man-Pages

1. resolv.conf(5)

Siehe auch

1. host.conf(5)
2. hosts(5)
3. nsswitch.conf(5)
4. hostname(7)
5. named(8)
6. Name Server Operations Guide for BIND

Links

1. https://roy.marples.name/projects/openresolv
2. [:systemd/networkd/#systemd-resolved:systemd-resolved] Alternativer Manager (Standard bei Ubuntu ab 17.10)

Testfragen

Testfrage 1

Antwort1

Testfrage 2

Antwort2

Testfrage 3

Antwort3

Testfrage 4

Antwort4

Testfrage 5

Antwort5

Varianten

Es existieren mehrere Varianten des Managers resolvconf, mindestens die ursprüngliche Implementierung von Debian und die des openresolv-Projektes {en}. Das Programm des openresolv-Projektes kennt die Datei /etc/resolvconf.conf, mit der das Programm selbst konfiguriert werden kann. Siehe hierzu dessen Manpage: {{{man resolvconf.conf }}}

resolvconf ersetzt die Textdatei /etc/resolv.conf durch einen symbolischen Link. Die Überschreibung dieses Links oder auch direktes manuelles Ändern des Dateiinhaltes ist eine häufige Ursache für Störungen bei der DNS-Namensauflösung und träges Verhalten beim Zugriff auf das Internet.

Ubuntu-Desktops konfigurieren standardmäßig einen lokalen DNS-Server als Cache; dieser wird realisiert durch dnsmasq (vor 17.10) bzw. systemd-resolved (ab 17.10). Bei einer Verwendung eines solchen Cache darf in der Datei /etc/resolv.conf nur genau ein Namensserver eingetragen sein und dieser Eintrag muss auf den lokalen DNS-Server im Bereich `127.0.0.0/8` zeigen. Änderungen auf andere/weitere Namensserver, auch mit der oben beschriebenen korrekten manuellen Bedienung, führen zu Störungen bei der DNS-Namensauflösung. Die vom lokalen DNS-Server zu benutzenden Forwarder werden weder direkt noch indirekt über die Datei /etc/resolv.conf definiert. Man konsultiere die Dokumentation des als DNS-Cache eingesetzten Programms für weitere Details.

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.