☰

/etc/resolv.confが127.0.0.53を指しているのはなぜですか？

tag-icon • tag-icon linux dns resolv.conf
/etc/resolv.confが127.0.0.53を指しているのはなぜですか？

私のDNSリゾルバが何であるかを確認しようとしましたが、次のことがわかりました。

user@ubuntu:~$ cat /etc/resolv.conf 

nameserver 127.0.0.53
options edns0

私が探しているのは、192.168.1.1これが私のデフォルトゲートウェイ、私のルーターです。

なぜそれが指しているのか理解できません127.0.0.53。その IP にアクセスすると、apache2 はそのコンテンツを提供します。誰でもこの問題を解決するのに役立ちますか？このファイルがDNSリゾルバとして機能するデフォルトゲートウェイを直接指す必要はありませんか？それとも、私が好むDNSを直接指す方が良いでしょうか1.1.1.1？

PS：Wiresharkを使用してポート53でDNSパケットをキャプチャしたときのものとは異なり192.168.1.1ます。127.0.0.53

答え1

おそらくsystemd-resolvedサービスとして実行しているでしょう。

systemd-resolvedDNSクライアントライブラリ（CライブラリのBIND DNSクライアントライブラリなど）でオプションで使用するために、2つの設定ファイルが動的に生成されます。

  • /run/systemd/resolve/stub-resolv.confDNS クライアント ライブラリにクエリを 127.0.0.53 に送信するように指示します。systemd-resolvedプロセスがDNSクエリを受信して​​からクエリを転送する場所です。
  • /run/systemd/resolve/resolv.confsystemd-resolved設定ファイルとDHCPリースに含まれるDNSサーバー情報から動的に取得されたIPアドレスにクエリを送信するようにDNSクライアントライブラリに指示します。効果的に、これはsystemd-resolved転送フェーズを迂回しますが、特定のsystemd-resolvedトランザクションに対して実際に何を渡すかについての複雑な決定を下すすべてのロジックもバイパスする対価を払います。

どちらの場合も、systemd-resolvedドメイン名サフィックス検索リストが構成され、その構成ファイルとDHCPリース（この回答の範囲外のメカニズムによって知られている）から即時から派生します。

/etc/resolv.confオプションは次のとおりです。

  • これらの1つへのシンボリックリンク。
  • パッケージが提供するシンボリックリンクを指します。変化のない/usr/lib/systemd/resolv.conf127.0.0.53 を指定しますが、動的に計算された検索ドメインがないファイルです。
  • 全く異なる文書。

このようなシンボリックリンクがあるかもしれません。この場合、192.168.1.1の設定が（おそらく）LAN上のDHCPサーバーによってDHCPリースに配布されることを理解すると、systemd-resolved観察されたようにクエリトラフィックはそのサーバーに転送されます。アプリケーションのDNSクライアントライブラリ自体はsystemd-resolved。

皮肉にもそうだけどできるsystemd-resolved127.0.0.53とのループバックインターフェイストラフィックを正しくキャプチャしない場合、このトラフィックは（オプションで）CライブラリのBIND DNSクライアントをバイパスし、このクラスを生成しないため、これを見ることができない可能性があります。トラフィックがキャプチャされます。 。

Cライブラリのプラグインであるsystemd-resolvedNSSモジュールが提供されています。nss-resolve以前は、Cライブラリはnss-dnsDNSプロトコルを使用してリストされたサーバーを照会し、/etc/resolv.confここにリストされているドメインサフィックスを適用するBIND DNSクライアントと呼ばれる別のプラグインを使用していました。

nss-resolve上場する最初nss-dnsファイルを/etc/nsswitch.conf削除すると、Cライブラリは名前→アドレス検索を実行するためにBIND DNSクライアントまたはDNSプロトコルをまったく使用しなくなります。代わりにnss-resolve、非標準プロトコルと特殊プロトコルは（システム全体）デスクトップバスを介して使用されsystemd-resolvedます。これは、192.168.1.1またはDHCPリースおよび設定ファイルに指定されているすべてのものに対してバックエンドクエリを再実行します。

傍受それdbus-monitorデスクトップバストラフィックを監視するには、これらのツールを使用する必要があります。ループバック ネットワーク インターフェイスの IP トラフィックだけでなく IP トラフィックもありません。デスクトップバスはソケットを介して接続されるためですAF_LOCAL。

1.1.1.1 またはその他の IP アドレスにサードパーティの確認プロキシ DNS サーバーを使用する場合は、次の 3 つのオプションがあります。

  • 192.168.1.1 を転送する代わりに、このアドレスを転送するように DHCP サーバーを構成します。 systemd-resolvedDHCPリースを通じて理解され使用されます。
  • systemd-resolvedDHCPリースで表示する代わりにそれを使用するには、独自の設定メカニズムを介して設定します。
  • /etc/resolv.confシンボリックリンクではなく、実際の一般ファイルである独自のファイルを作成し、その中に1.1.1.1を一覧表示してから、BIND DNSクライアントを再nss-resolve利用できるように閉じる必要があります。nss-dns

構成systemd-resolvedファイルは、一緒にグループ化されたさまざまなディレクトリにあるファイルの束であり、上記の2番目のオプションの構成方法はこの回答の範囲外です。resolved.conf(5) マニュアルページをお読みください。

答え2

完全な127.0.0.0/8CIDRブロックはループルーティングに使用されます。あなたのホストは特定のループバックアドレスで独自のDNSサーバーを実行しているようです（または少なくともそう思います）。

ループバックトラフィックは通常有線に移動しないため、WiresharkなどのクリッピングツールでTCP / 53トラフィックが表示されないことは驚くべきことではありません。これは、デフォルト設定を使用してループバックトラフィックを監視しないためです。ss（はい）などのツールを使用すると、追加のss -plnt | grep ':53'調査のためにそのTCPポートでリッスンしているプロセス（存在する場合）が表示されます。

可能systemd-resolved関連して、Ubuntuは、以下で説明するように、最新バージョンでループバックリゾルバを使用しているようです。この回答AskUbuntuから。

答え3

これは、ネットワーク名解決に systemd-resolved サービスを使用しているためです。この場合、 resolvectl statusコマンドを使用できます。ネットワーク（例：wlp1s0）に移動します。現在のDNSサーバーを確認してください。最初は私のルーターのIP 192.168.xxで、208.67.222.123ルーターの設定ページのDHCPサーバーオプションでデフォルトのDNSサーバーを（OpenDNS FamilyShield DNSリゾルバー）に更新しました。 NetworkManagerを再起動した後に実行したときに得られる結果は次のとおりです。resolvectl status

Link 3 (wlp1s0)
    Current Scopes: DNS
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 208.67.222.123
       DNS Servers: 208.67.222.123

現在のDNSサーバーが私のルーターIPからOpenDNSサーバーに変更されたかどうかを確認します。

関連情報