だから私はネットワーク上のすべてのコンピュータ（DNSサーバーを含む）にランダムなIPv6アドレスを追加するルータをテストしています。どういうわけか、これらのIPは有効なDNSサーバーにブロードキャストされていましたが（実際のルーターだけがIPv6 RAパケットを送信する方法はわかりません）、簡単に言えば、すべてのコンピュータが存在しないIPアドレスにDNSクエリを送信しています。
再起動すると、これらの偽のIPresolvedはまだ有効なネームサーバーとして表示されます。systemctl restart systemd-resolvedresolvectl
リストにあるので、/etc/resolv.confそこから削除して再起動すると、systemd-resolved偽のIPが再追加されます。
ログを見ると、journalctl --unit=systemd-resolved偽のIPが「機能低下モード」で実行されていることがわかりますが、そのIPをどこで見つけたかはわかりません。
これらの間違ったIPアドレスはどこから取得されますか？ IPv6ルーター広告が提供するIPのみを再利用するには、一部のキャッシュファイルを削除する必要がありますか？
答え1
いくつかの調査とシステムのバグを報告した後、次を発見しました。
systemd-resolvedはsystemd-networkdからすべてのDNS情報を取得するため、悪意のあるサーバーを修正するとsystemd-networkdに集中してsystemd-resolvedに入ります。
/var/run/systemd/netif/各インタフェースのデータはファイルに保存されます。これは内部的で変更される可能性があるため、この記事を読んだときには移動された可能性がありますが、私は悪意のあるサーバー用のこれらのファイルをgrepしてそのファイルを含むファイルを削除することができました。 systemd-networkdを再起動すると、削除されたファイルが完全に再生成されました。
私の場合、ファイルを再生成しましたが、まだ悪意のあるDNSサーバーが一覧表示されていました。これは、そのファイルがsystemdによってキャッシュされておらず、まだネットワークのどこかに広告されていることを意味します。
私はIPv6アドレスだったのでradvd（IPv6 Router Advertising Daemon）をインストールして実行し、radvdumpコンピュータに到達したすべてのIPv6 RAを表示しました。もちろんしばらくして、悪意のあるDNSサーバーを一覧表示する電子メールが表示され、それを見つけて修正することができました。
それでも問題が解決しない場合は、一部のsystemd-networkdオプションを使用して問題を解決できます。これは、ネットワークを構成するファイルの1つに配置する必要があります（/etc/systemd/network/*.network）。
# Don't use DNS servers from DHCP responses received via IPv4 (default is true)
[DHCPv4]
UseDNS=false
# Don't use DNS servers from DHCPv6 responses received via IPv6 (default is true)
[DHCPv6]
UseDNS=false
[IPv6AcceptRA]
# Don't use DNS servers from IPv6 Router Advertisement (RA) messages (default is true)
UseDNS=false
# Don't start a DHCPv6 client when an RA message is received.
DHCPv6Client=false
答え2
あなたはそれを使用することができますこれコマンド：sudo systemd-resolved --flush-cachesまたはsudo resolvectl flush-caches（後者のコマンドは次のものから取得されます。マニュアルページのsystemd-resolved）
更新が成功したことを確認するには、次のようにします。sudo systemd-resolved --statistics
出力例：
Cache
Current Cache Size: 0
Cache Hits: 101
Cache Misses: 256
systemd-resolvedまた、/etc/resolv.confマンページの「どのモードで実行していますか？」セクションを参照してください。
/etc/resolv.conf
/etc/resolv.confを処理する4つのモードがサポートされています（resolv.conf（5）を参照）。
systemd-resolvedは、レガシーLinuxプログラムとの互換性のために/run/systemd/resolve/stub-resolv.confファイルを維持します。このファイルは/etc/resolv.confのシンボリックリンクです。このファイルには、127.0.0.53 DNSスタブ（上記を参照）が唯一のDNSサーバーとしてリストされています。また、systemd-resolvedで使用される検索ドメインのリストも含まれています。検索ドメインのリストは常に最新の状態です。アプリケーションは/run/systemd/resolve/stub-resolv.confを直接使用しないでください。/etc/resolv.confのシンボリックリンクを介してのみ使用してください。このファイルは /etc/resolv.conf でシンボリックリンクされ、ローカル DNS API をバイパスするすべてのローカルクライアントを正しい検索ドメイン設定で systemd-resolved に接続できます。この動作モードをお勧めします。
127.0.0.53 DNSスタブ（上記参照）を唯一のDNSサーバーとしてリストする静的ファイル/usr/lib/systemd/resolv.confが提供されています。このファイルは /etc/resolv.conf でシンボリックリンクされ、ローカル DNS API をバイパスするすべてのローカルクライアントを systemd-resolved に接続できます。このファイルには検索フィールドは含まれません。
systemd-resolved は、レガシー Linux プログラムとの互換性のために /run/systemd/resolve/resolv.conf ファイルを維持します。このファイルは/etc/resolv.confからシンボリックリンクすることができ、常に最新の状態であり、既知のすべてのDNSサーバーに関する情報が含まれています。ファイル形式の制限に注意してください。インターフェイス固有のDNSサーバーの概念が認識されないため、システム全体のDNSサーバー定義のみが含まれます。アプリケーションは/run/systemd/resolve/resolv.confを直接使用しないでください。/etc/resolv.confのシンボリックリンクを介してのみ使用してください。この動作モードを使用すると、ローカルDNS APIをバイパスするローカルクライアントはsystemd-resolvedもバイパスし、既知のDNSサーバーと直接通信します。
または、/etc/resolv.confを別のパッケージで管理することもできます。この場合、systemd-resolvedはそれを読み取り、DNS設定データを取得します。この作業モードでは、systemd-resolvedはプロバイダではなく、この設定ファイルのコンシューマです。
/etc/resolv.confが/run/systemd/resolve/resolv.confへのシンボリックリンクであるか、127.0.0.53をDNSサーバーとして一覧表示するかによって、このファイルに対して選択された作業モードが完全に自動検出されます。
アップデート：systemd-resolveのミス修正Dありがとう、Binghuo
答え3
/etc/resolv.conf直接編集できません。これにより、サービスを再起動しても変更は適用されません。次のステップ/etc/resolv.confはUbuntu 20.04 desktop。
sudo nano /etc/resolvconf/resolv.conf.d/head- Nanoエディタで必要な変更を行います。
- 必要に応じてサービスを再起動します。私の場合は、次のようになりました。
systemctl stop resolvconf.service;systemctl start resolvconf.service