Warum zeigt /etc/resolv.conf auf 127.0.0.53?

Sie führen wahrscheinlich systemd-resolved aus als Dienst.

systemd-resolved generiert spontan zwei Konfigurationsdateien zur optionalen Verwendung durch DNS-Client-Bibliotheken (wie etwa die BIND-DNS-Client-Bibliothek in C-Bibliotheken):

• /run/systemd/resolve/stub-resolv.conf weist DNS-Clientbibliotheken an, ihre Abfragen an 127.0.0.53 zu senden. Hier steht die systemd-resolved Der Prozess wartet auf DNS-Anfragen, die er dann weiterleitet.
• /run/systemd/resolve/resolv.conf weist DNS-Client-Bibliotheken an, ihre Abfragen an IP-Adressen zu senden, die systemd-resolved sind on-the-fly aus seinen Konfigurationsdateien und DNS-Serverinformationen erhalten hat, die in DHCP-Leases enthalten sind. Dies umgeht effektiv den systemd-resolved Weiterleitungsschritt, auf Kosten der Umgehung von systemd-resolved 's-Logik, um komplexe Entscheidungen darüber zu treffen, was für eine bestimmte Transaktion tatsächlich weitergeleitet werden soll.

In beiden Fällen systemd-resolved konfiguriert eine Suchliste mit Domänennamensuffixen, die wiederum spontan aus ihren Konfigurationsdateien und DHCP-Leases abgeleitet werden (worüber sie über einen Mechanismus informiert wird, der den Rahmen dieser Antwort sprengen würde).

/etc/resolv.conf kann optional sein:

• ein symbolischer Link zu einem von diesen;
• ein symbolischer Link zu einer vom Paket bereitgestellten statischen Datei unter /usr/lib/systemd/resolv.conf , das auch 127.0.0.53 angibt, aber keine spontan berechneten Suchdomänen;
• eine ganz andere Datei.

Wahrscheinlich haben Sie einen solchen symbolischen Link. In diesem Fall ist systemd-resolved115115115115115 , der, wie Sie beobachtet haben, Abfragedatenverkehr an ihn weiterleitet. Ihre DNS-Client-Bibliotheken in Ihren Anwendungsprogrammen sprechen selbst nur mit systemd-resolved .

Ironischerweise, obwohl es könnte Da Sie den Loopback-Schnittstellenverkehr zu/von 127.0.0.53 nicht richtig erfasst haben, ist es wahrscheinlicher, dass Sie ihn nicht sehen, weil systemd-resolved umgeht auch (optional) den BIND-DNS-Client in Ihren C-Bibliotheken und erzeugt keinen solchen zu erfassenden Datenverkehr.

Es gibt ein NSS-Modul, das mit systemd-resolved bereitgestellt wird , benannt nss-resolve , das ist ein Plug-in für Ihre C-Bibliotheken. Früher hätten Ihre C-Bibliotheken ein anderes Plug-in namens nss-dns verwendet der den BIND-DNS-Client verwendet, um Abfragen unter Verwendung des DNS-Protokolls an die Server durchzuführen, die in /etc/resolv.conf aufgeführt sind , unter Verwendung der darin aufgeführten Domainendungen.

nss-resolve wird voran gelistet von nss-dns in Ihrem /etc/nsswitch.conf Datei, was dazu führt, dass Ihre C-Bibliotheken den BIND-DNS-Client oder das DNS-Protokoll überhaupt nicht verwenden, um Name→Adressen-Lookups durchzuführen. Stattdessen nss-resolve spricht ein nicht standardmäßiges und eigenwilliges Protokoll über den (systemweiten) Desktop-Bus zu systemd-resolved , das wiederum Back-End-Abfragen von 192.168.1.1 oder was auch immer Ihre DHCP-Leases und Konfigurationsdateien sagen, macht.

Um das abzufangen Sie müssen den Desktop-Bus-Verkehr mit dbus-monitor überwachen oder ein solches Tool. Es ist nicht einmal IP-Verkehr, geschweige denn IP-Verkehr über eine Loopback-Netzwerkschnittstelle. da der Desktop Bus über eine AF_LOCAL erreicht wird Steckdose.

Wenn Sie einen auflösenden Proxy-DNS-Server eines Drittanbieters unter 1.1.1.1 oder einer anderen IP-Adresse verwenden möchten, haben Sie drei Möglichkeiten:

• Konfigurieren Sie Ihren DHCP-Server so, dass er das ausgibt, anstatt 192.168.1.1. systemd-resolved wird über die DHCP-Leases davon erfahren und es verwenden.
• Konfiguriere systemd-resolved über seine eigenen Konfigurationsmechanismen, um dies anstelle dessen zu verwenden, was es in den DHCP-Leases sieht.
• Machen Sie Ihren eigenen /etc/resolv.conf Datei, eine tatsächliche reguläre Datei anstelle eines symbolischen Links, listen Sie dort 1.1.1.1 auf und denken Sie daran, nss-resolve zu deaktivieren damit Sie wieder nss-dns verwenden und dem BIND-DNS-Client.

Der systemd-resolved Konfigurationsdateien sind eine ganze Reihe von Dateien in verschiedenen Verzeichnissen, die kombiniert werden, und wie man sie für die zweite oben genannte Wahl konfiguriert, geht über den Rahmen dieser Antwort hinaus. Lesen Sie den resolved.conf (5) Handbuchseite dafür.

Der gesamte 127.0.0.0/8 Der CIDR-Block wird für das Loopack-Routing verwendet. Ihr Host scheint (oder scheint zumindest zu glauben) einen eigenen DNS-Server auf dieser spezifischen Loopback-Adresse zu betreiben.

Da Loopback-Verkehr (im Allgemeinen) nie über die Leitung geht, ist es nicht verwunderlich, dass Sie in Snipping-Tools wie Wireshark keinen TCP/53-Verkehr sehen, da sie den Loopback-Verkehr möglicherweise nicht mit den Standardeinstellungen überwachen. Mit einem Tool wie ss (zB ss -plnt | grep ':53' zeigt Ihnen, welcher Prozess, falls vorhanden, auf diesem TCP-Port lauscht, um weitere Untersuchungen durchzuführen.

Möglicherweise Dies hängt damit zusammen, dass Ubuntu anscheinend einen Loopback-Resolver verwendet, systemd-resolved in neueren Versionen, wie in dieser Antwort auf AskUbuntu besprochen.