web-dev-qa-db-ja.com

systemd-resolvedを適切に無効にする方法

私のUbuntu Eoanラップトップでは、ルーターのDNSサーバーへのリクエストがまだ機能している場合でも、systemd-resolvedがローカルDNSリクエストに127.0.0.53への応答に不可解に失敗することがわかりました。

（具体的には、WiFiが切断してから再接続した後、/ etc/resolv.confのsystemd-resolvedによって提供される127.0.0.53のローカルDNSサーバーが、手動で「systemctl restart systemd-resolved」を実行するまで要求に応答しなくなります。）

私はwicdでDHCPを使用してワイヤレスネットワークを使用しており、通常はwicd-gtkで制御しています。 DHCPを使用したWiFi接続で、DHCPによって割り当てられたDNSサーバーを使用するようにシステムを正しく構成するにはどうすればよいですか？ systemd-resolvedサービスを無効にしましたが、それでは不十分なようです。これは、存在しない/run/systemd/resolve/stub-resolv.confにシンボリックリンクされた/etc/resolv.confを残しました。それを削除しても、WiFiに再接続すると、NetworkManagerによって/etc/resolv.confファイルが作成され、役に立たない127.0.0.53がポイントされます。そのファイルを削除してNetworkManagerを停止してからWiFiに再接続しても、/ etc/resolv.confが取得されないため、DNSルックアップで使用するサーバーがありません。

WiFi DHCPでのローカルIPアドレス、サブネット、ゲートウェイの設定に加えて、DNSサーバーの通常の設定を行うために、wicdまたはシステムのネットワーク設定を適切に構成するにはどうすればよいですか？接続するWiFiを手動で選択するには、通常wicd-gtkを使用します。また、他のデバイスには問題がなく、以前はsystemd-resolvedを実行していたこともあるので、WiFiには問題がありません。また、システムトレイなしでxmonadを使用していて、NetworkManagerシステムトレイGUIを簡単に使用できないため、NetworkManagerの使用を避けようとしています。

WiFiに接続した後、システムログで非常に疑わしいのは、dhclientがDHCPACKを受け取った後、systemd-resolvedが再起動しなかったことです。 systemd-resolvedはその直前におそらくネットワークがまだ準備できていないときに開始されました。したがって、/ etc/dhcp/dhclient-enter-hooks.d/resolvedが意図したとおりに機能していないようです。

編集：systemd-resolvedを無効にすることで、既知のバグに遭遇したようです： https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/174546

networkingwirelessdhcpwicdsystemd-resolved
1
Syncopated

散発的な問題はバグ1396379、1805027、1804487のように聞こえます。散発的な18.04の名前解決の失敗に対する解決策は、パッケージlibnss-resolveを追加することでした。これにより、/ etc/nsswitch.confホストの行が次のように変更されました。

hosts:          files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns myhostname

デフォルトのインストールに他の変更は必要ありません。 /etc/resolv.confリンクはデフォルトのstub-resolv.confのままにしておきます。

1
ubfan1