DNSSECにオールインしてください

DNSSECにオールインしてください

次の設定を使用して、システムでDNSSECを完全に有効にしようとしました。

  • dnscrypt-proxy127.0.0.1でのインストール、起動、実行require_dnssec = true
  • systemdの解析は次のように実行されますDNSSEC=yesDNS=127.0.0.1
  • のみnameserver 127.0.0.1/etc/resolv.conf
  • NetworkManager DHCP 構成セット 8.8.8.8 および 8.8.8.4 を、DNS サーバーを介して認識している WiFi ネットワークに接続します。

/run/systemd/resolve/resolv.conf8.8.8.8および8.8.8.4は、127.0.0.1の下にリストされています。

resolvectl statusプログラム

DNSSEC setting: yes
DNSSEC supported: yes
Current DNS Server: 127.0.0.1
DNS Servers: 127.0.0.1

グローバルセクションにあるが、

 DNSSEC setting: yes
 DNSSEC supported: yes
 Current DNS Server: 8.8.8.8
 DNS Servers: 8.8.8.8
                           8.8.8.4

私のインターフェースセクションに(なぜ?)

tcpdumpWebブラウザ、発掘、またはその他の一般的な使用を使用すると、udp:53にはまったくアクティビティが表示されません。これは、私のローカルdnscrypt-proxyが私のシステム上のすべてのDNS要求を処理していることを意味すると思います。また、上記の構成設定のために常にDNSSECを使用すると仮定します。

ただし、日記には以下の内容が含まれる場合もあります。

Nov 30 09:10:41 tuxifaif systemd-resolved[179937]: DNSSEC validation failed for question v.dropbox.com IN SOA: failed-auxiliary
Nov 30 09:10:41 tuxifaif systemd-resolved[179937]: DNSSEC validation failed for question bolt.v.dropbox.com IN DS: failed-auxiliary
Nov 30 09:10:41 tuxifaif systemd-resolved[179937]: DNSSEC validation failed for question bolt.v.dropbox.com IN SOA: failed-auxiliary
Nov 30 09:10:41 tuxifaif systemd-resolved[179937]: DNSSEC validation failed for question bolt.v.dropbox.com IN A: failed-auxiliary
Nov 30 09:10:43 tuxifaif systemd-resolved[179937]: DNSSEC validation failed for question v.dropbox.com IN SOA: failed-auxiliary
Nov 30 09:10:43 tuxifaif systemd-resolved[179937]: DNSSEC validation failed for question d.v.dropbox.com IN A: failed-auxiliary
Nov 30 09:10:43 tuxifaif systemd-resolved[179937]: DNSSEC validation failed for question v.dropbox.com IN SOA: failed-auxiliary
Nov 30 09:10:43 tuxifaif systemd-resolved[179937]: DNSSEC validation failed for question d.v.dropbox.com IN A: failed-auxiliary
Nov 30 09:10:43 tuxifaif systemd-resolved[179937]: DNSSEC validation failed for question d2e801s7grwbqs.cloudfront.net IN SOA: failed-auxiliary
Nov 30 09:10:43 tuxifaif systemd-resolved[179937]: DNSSEC validation failed for question d2e801s7grwbqs.cloudfront.net IN A: failed-auxiliary
  • resolvectl query v.dropbox.com同じDNSSEC検証エラーが発生します。
  • dig v.dropbox.com非常にうまく動作
  • dig v.dropbox.com @8.8.8.8また、うまく動作します(もちろん、2行の出力が生成されますtcpdump)。

私も確認しましたhttps://dnsleaktest.com、これは多くの172.253.xxサーバーが私がWebブラウザに入力したドメイン名を解決するように求められていることを伝えます。そのIPはGoogleが所有しているようです。

では、これはどういう意味ですか?このシステムで進行中の(DNSSECではない)クエリはありますか?

どんな洞察力でも感謝します!

答え1

dnscrypt-proxyandをすべてsystemd-resolved使用している場合、これは発生しません127.0.0.1:53systemd-resolved推奨事項に従って無効にする必要があります。dnscrypt - プロキシ Wiki/etc/resolv.confをクリックし、ネットワーク管理者が行った変更をロックします。したがって、ステップは次のようになります。

  • 障害があるsystemd-resolved
sudo systemctl stop systemd-resolved
sudo systemctl disable systemd-resolved
  • address:port:とdnscrypt-proxy同じペアを使用する他のものがあることを確認してくださいsudo ss -lp 'sport = :domain'。存在する場合は無効にします。

  • dnscrypt-proxy受信している127.0.0.1:53場合は、エントリ(DNSセキュリティ拡張を有効にするために必要です)の下に追加して、次のようにします。resolv.confnameserver 127.0.0.1options edns0nameserverresolv.conf

nameserver 127.0.0.1
options edns0
  • /etc/resolv.conf変更のためのファイルロック:sudo chattr +i /etc/resolv.conf
  • 再起動することもできますdnscrypt-proxy

全体的に、ポイントは以下を確認することです。

  • ただdnscrypt-proxy使用中127.0.0.1:53
  • resolv.conf同じ住所を持っているdnscrypt-proxy
  • resolv.conf他のソフトウェア(ネットワーク管理者など)の変更に影響されません。

また、dnsleakテストの結果、Google IPが表示されても、そのDNS ResolverサービスがGoogleで動作するわけではありません。これらのサーバーはGoogleが所有していますが、他の法人が運営する場合があります。必要でない場合は、別のパーサーを選択できますdnscrypt-proxy 公開確認者リストdnssec選択したパーサーがそれをサポートしていることを確認してください。私は個人的にログなし、フィルタなし、Google以外のdnssecサポートdnscrypt.euリゾルバを使用します。

引用:

関連情報