次の設定を使用して、システムでDNSSECを完全に有効にしようとしました。
dnscrypt-proxy
127.0.0.1でのインストール、起動、実行require_dnssec = true
- systemdの解析は次のように実行されます
DNSSEC=yes
。DNS=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.conf
8.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
私のインターフェースセクションに(なぜ?)
tcpdump
Webブラウザ、発掘、またはその他の一般的な使用を使用すると、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-proxy
andをすべてsystemd-resolved
使用している場合、これは発生しません127.0.0.1:53
。systemd-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.conf
nameserver 127.0.0.1
options edns0
nameserver
resolv.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リゾルバを使用します。
引用: