Installiert man ein frisches Ubuntu 22.04 (oder andere „irgendwie Ubuntu“-Distros wie z.B. Mint), konfiguriert sich dessen Netzwerk erwartungsgemäß per DHCP. Aber statt des von dort empfangenen DNS-Servers wird das lokale DNS-Resolving sehr schräg konfiguriert – da wird 127.0.0.53#53 (also irgendwas mit localhost) als DNS-Server verwendet.
Dessen Sinn erschließt sich mir nicht, und vor allem funktioniert es auch nicht für mich und DNS-Requests auf Hosts im lokalen Netz. — Nachfolgend quasi als Notiz für mich selbst nun die eigentlich super simple Lösung, damit ich nicht bei jeder frischen Linux-Installation immer wieder neu suchen und fluchen muss.
Wie im o.a. Screenshot zu sehen: „Echte“ Hosts im Internet, hier: heise.de, werden problemlos korrekt resolved. Wie 127.0.0.53 das macht, ist mir nicht gänzlich klar – nur, dass wohl systemd-resolv daran beteiligt ist. (Hier geht’s zur vertiefenden Lektüre.)
Wenn er es denn auch ordentlich machen würde, würde ich mich ja nicht beschweren. Aber offensichtlich scheitert der Versuch, ein lokales Gerät zu resolven – hier im Beispiel mein treuer Mac mini unter .103 … es könnte aber auch jedes andere Gerät sein. Dieser ist, wie man im o.a. Screenshot sehen kann, meinem echten DNS-Resolver 192.168.xx.1 (einem Raspi mit dnsmasq, der sich bei mir ums DHCP und DNS im (W)LAN kümmert) auch definitiv bekannt.
Und 192.168.xx.1 ist dem System nun auch ausdrücklich per DHCP als primärer DNS zur Benutzung anempfohlen worden – aber warum zum Fuchs benutzt er ihn denn nicht?
Langes Herumrätseln, laute Flüche. Auf meinen Kisten ist typischerweise auch resolvconf a/k/a resolvectl installiert (mehr dazu weiter unten). Aber lasst euch gesagt sein: Es hilft genau gar nichts, an /etc/resolv.conf, /etc/resolveconf/**/* oder /run/resolveconf/**/* herum zu schreiben – das macht nur schlechte Laune, weil /etc/resolve.conf bei jedem Neustart immer wieder frisch überschrieben wird.
Was also tun? Durch erbittertes Nachgoogeln fand ich irgendwann auf die Lösung, die ich hier erneut skizzieren möchte: Man editiere mich seinem Lieblings-Editor die Datei /etc/systemd/resolved.conf. Also z.B.
sudo vi /etc/systemd/resolved.conf
Dort findet sich recht weit unten ein auskommentierter Eintrag, der die Default-Konfiguration beschreibt:
#DNSStubListener=yes
Man ändere diesen bitte zu
DNSStubListener=no
und starte anschließend den systemd-resolved neu mit Hilfe von
sudo systemctl restart systemd-resolved.service
Also in etwa so – und direkt ausprobieren:
Ick kieke, staune, wundre mir,
uff eemal jeht se uff die Tür. (Quelle)
Oder, anders gesagt: Kaum macht man’s richtig, funktioniert’s auch schon. … Mir ist bewusst, dass dieser Kaninchenbau deutlich tiefer geht. Und wer sich ernsthaft mit DNS-Stub-Resolving beschäftigen möchte (also – ich jetzt nicht so), der folge dem bereits oben genannten Link zu den weitergehenden Informationen.
… Aber wo Sie gerade sagen resolvconf a/k/a resolvectl – damit funktioniert meine hemdsärmelige Lösung trotzdem noch. Ich brauche den hauptsächlich für mein Wireguard-VPN, und weil es ja A.D. 2023 leider immer noch keinen leicht bedienbaren offiziellen Wireguard Client für Ubuntu gibt, verwende ich stattdessen wireguird (ja – der schreibt sich wirklich so, und den kann ich ausdrücklich empfehlen).
Keine Kommentare möglich.