DNSが漏洩しています（そして誰もが見ています）
ファイアウォールの強化やSSHキーの更新、WireGuardの設定に何時間も費やしたことがあるでしょう。しかし、スタック内で最も基本的な漏洩箇所であるDNSを無視している可能性があります。何十年もの間、DNSクエリはUDPポート53を介してプレーンテキストでインターネット上を行き来してきました。これは、あなたのLinuxサーバーとリゾルバーの間にいる誰か（ISPや公共Wi-Fiの管理者など）が、あなたがどのドメインにアクセスしているかを正確に把握していることを意味します。
現実には、HTTPSを使用していても、最初のDNSハンドシェイクは丸見えの状態です。このメタデータにより、プロバイダーはあなたの活動に関する不気味なほど正確なプロファイルを作成できてしまいます。過去6ヶ月間、完全な暗号化を施した本番環境を運用した結果、DNSのセキュリティ確保は単なるプライバシーের「あれば嬉しい機能」ではないことが分かりました。それはデータの整合性の問題です。現代のLinuxセキュリティを重視するのであれば、この設定は避けて通れないものです。
盾を選ぶ：DoT vs. DoH
暗号化には主に2つの方式があります。どちらもクエリをTLSレイヤーで包みますが、実際のトラフィックの処理方法は大きく異なります。私のテストに基づいた内訳は以下の通りです。
DNS over TLS (DoT)
DoTは専用ポート（TCP 853）を使用します。ネットワーク管理者が監視やシェーピングを行うのが簡単でクリーンな方式です。また、systemd-resolvedのネイティブな選択肢でもあります。しかし、特定のポートを使用するため、制限の厳しいファイアウォールでは、たった一つのルールでブロックされる可能性があります。私は主に、ネットワークの境界を自分で制御できるバックエンドサーバーでこれを使用しています。
DNS over HTTPS (DoH)
DoH hides your queries inside standard HTTPS traffic on port 443. To any observer, your DNS requests look like normal web browsing. This makes it the ultimate tool for bypassing censorship or strict corporate filters. The trade-off? It’s slightly heavier to implement at the OS level, usually requiring a local proxy like cloudflared.
DoHは、ポート443の標準的なHTTPSトラフィックの中にクエリを隠します。第三者からは、DNSリクエストは通常のウェブブラウジングのように見えます。そのため、検閲や厳しい企業フィルタリングを回避するための究極のツールとなります。妥協点は？OSレベルでの実装が少し重くなり、通常はcloudflaredのようなローカルプロキシが必要になることです。
この半年間のデータによると、サーバーインフラにはDoTが適しています。ワークステーションや「敵対的」なネットワーク内のサーバーにとっては、DoHが身を隠す唯一の信頼できる方法です。
systemd-resolvedでDNS over TLSを有効にする
Ubuntu 22.04、Fedora、またはDebianを使用している場合は、すでにsystemd-resolvedがインストールされています。これが最も簡単な方法です。ここでは、CloudflareとGoogleを暗号化されたアップストリームリゾルバーとして使用するように、私の環境をどのように構成したかを紹介します。
1. 設定ファイルを編集する
設定ファイルを開きます：
sudo nano /etc/systemd/resolved.conf[Resolve]セクションを更新します。単一のIPを追加するだけでなく、冗長性のために複数のプロバイダーを使用してください。
[Resolve]
DNS=1.1.1.1 8.8.8.8 1.0.0.1 8.8.4.4
FallbackDNS=9.9.9.9
DNSOverTLS=yes
DNSSEC=yes2. 適用と監査
新しい設定を読み込むためにサービスを再起動します：
sudo systemctl restart systemd-resolved次に、ステータスを確認します。「active」を確認するのではなく、暗号化フラグを探してください：
resolvectl statusアクティブなインターフェースで+DNSOverTLSが表示されているか確認してください。もしあれば、システムが行うすべてのクエリは、ネットワークに流れる前に暗号化されています。
CloudflaredでDNS over HTTPSをデプロイする
ポート853がブロックされている場合、私はローカルプロキシに切り替えます。cloudflared（Cloudflare製）は、ローカルアプリとDoHエンドポイントの間のブリッジとして機能します。
1. バイナリを取得する
Debianベースのシステムの場合は、最新のリリースを入手してください：
wget https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb
sudo dpkg -i cloudflared-linux-amd64.deb2. プロキシを設定する
設定ファイルを作成します：
sudo mkdir -p /etc/cloudflared
sudo nano /etc/cloudflared/config.yamlDoHエンドポイントを指定します：
proxy-dns: true
proxy-dns-port: 5053
proxy-dns-upstream:
- https://1.1.1.1/dns-query
- https://1.0.0.1/dns-query3. サービスを自動化する
再起動後も動作し続けるように、システムサービスとしてインストールします：
sudo cloudflared service install
sudo systemctl start cloudflared
sudo systemctl enable cloudflared最後に、ネットワーク設定またはresolved.confで、システムのDNSを127.0.0.1に設定します。これで、トラフィックはポート5053のローカルプロキシを経由し、ポート443経由でウェブに送信されます。
疎通確認：実際に動作していますか？
ステータスメッセージを盲信してはいけません。最大の失敗は、システムが静かにポート53にフォールバックしているのに、安全だと思い込んでしまうことです。プレーンテキストのトラフィックが漏れていないことを確認する必要があります。
1つ目のターミナルでtcpdumpを実行し、漏洩を監視します：
sudo tcpdump -ni any port 53次に、2つ目のターミナルでルックアップを実行します：dig google.com。tcpdumpが反応しなければ、暗号化は確実です。もしテキストが流れてきたら、システムはまだクエリを平文で漏らしています。
メリット、デメリット、そしてレイテンシ
半年間の本番環境での運用で、いくつか注意すべき点が見つかりました：
- キャプティブポータルの問題： 空港やホテルのWi-Fiでは、ログインページを表示するためにDNSを乗っ取ることがよくあります。DoTを「Hard（強制）」で有効にしていると、接続できません。私は旅行用に、
DNSOverTLSを「opportunistic（日和見）」に切り替えるクイックエイリアスを用意しています。 - レイテンシの負担： TLSハンドシェイクは無料ではありません。最初のクエリで平均12msから18msの増加を測定しました。しかし、接続が維持されローカルでキャッシュされるようになれば、体感速度は標準的なDNSと同じになります。
- 冗長性が不可欠： 一つのプロバイダーだけに頼らないでください。かつてフランクフルトのノードからCloudflareのDoHにアクセスできず、45分間のダウンタイムが発生したことがありました。Quad9（9.9.9.9）へのフォールバックを設定していたため、クエリが一つも落ちることなくサービスを維持できました。
ISPが広告部門のために私のメタデータを収集していないと知ることで得られる安心感は、些細なハードルを乗り越える価値が十分にあります。機密データを扱うサーバーを管理しているのであれば、暗号化DNSはもはや贅沢品ではなく、必須要件です。
最終結論
今日の環境において、プレーンテキストのDNSは負債です。DoTのネイティブなシンプルさを選ぶか、DoHの隠密性を選ぶかにかかわらず、サーバーの防御における大きな隙間を埋めることになります。まずは1台の開発機でテストし、tcpdumpで確認してから、全環境に展開してください。将来の自分は、この追加の装甲に感謝することでしょう。
