役割を選択する
Unbound などの再帰リゾルバーと AdGuard Home などのフィルタリングインターフェースは、関連するものの異なる課題を解決します。サービス自体が再帰を行うのか、上流に転送するのかを決め、どちらがクエリを参照するのかを理解してください。
プライベートに保つ
制限のない公開リゾルバーは、リフレクション攻撃に悪用される可能性があります。プライベートネットワークにバインドするか、IPv6を含む認可された送信元のみを許可してください。暗号化されたDNSを使用する場合は、HTTPSによってプライベートになると想定せず、適切に認証するかアクセスを制限してください。
ログ記録ポリシーを設定する
DNS クエリは、機密性の高い閲覧やアプリケーションの活動を明らかにする可能性があります。不要な保持を無効にし、保持する記録を保護し、その範囲をユーザーに説明してください。暗号化された伝送は経路を保護しますが、リゾルバー自体がクエリを見ることを防ぐものではありません。
複数の名前でテスト
有効な場合は DNSSEC の動作、IPv4 と IPv6 の結果、フィルタリングの例外、上流が失敗した場合の復旧を確認してください。修復中のリゾルバーに排他的に依存せずにアクセスを修正する安全な方法を維持してください。
第三者がクエリできないことを証明する
リゾルバーを意図したインターフェースにバインドし、許可されるクライアント範囲を定義し、ファイアウォールを制限してください。再起動前に設定を検証してください。許可されたクライアントからクエリを実行し、次に信頼されたネットワークの外部から繰り返してください。そのリクエストは拒否されるかタイムアウトするはずです。IPv6 を個別に確認してください。任意のインターネットクエリを受け入れるリゾルバーは、悪用の発生源になる可能性があります。
- 変更を適用する前に構成バリデーターを実行する
- 許可されたクライアントと拒否されたクライアントをテストする
- 詳細なクエリ診断は一時的に保つ
unbound-checkconf公式ドキュメント: Unbound アクセス制御設定
暗号化された DNS の主張は正確に
DNS-over-HTTPS または DNS-over-TLS は特定のトランスポートパスを暗号化します。リゾルバーは依然としてクエリを受信し、フォワーディングリゾルバーはそれを別のオペレーターに渡すことができます。上流の選択と保持期間を確認してください。暗号化されたリゾルバーエンドポイントを公開する場合は、通常の DNS ポートと同様に、そのアクセスポリシーを意図的に設計してください。
ポートを開く前にリゾルバーチェーンを選択する
有用なプライベート設計は、VPN クライアントが AdGuard Home にクエリし、AdGuard がループバック上の Unbound に転送する構成です。Unbound が再帰を実行し、AdGuard がフィルタリングと管理インターフェースを追加します。より小さなスタックには Unbound のみを使用する方法もあります。各リスナーに異なるアドレス/ポートを割り当て、転送方向を明確にしてください。Unbound を AdGuard に戻すとループが発生します。公開前に、どのプライベートクライアントがサービスを利用できるかを決めてください。
- 特定の認可クライアントポリシーがない限り、公開インバウンド TCP および UDP 53 は閉じたままにしてください。
- フィルタリングインターフェースと DNS リスナーに別々のアクセスルールを設定してください。
- インストール前にポートの所有権を確認してください。既存のシステムリゾルバーがすでに目的のアドレスをバインドしている場合があります。
公式ドキュメント: AdGuard Home のセットアップ
ループバック Unbound の出発点
Unboundがすでにインストールされているシステムでは、次のフラグメントはホスト上でのみ到達可能なバックエンドを示します。パッケージ設定やトラストアンカー管理を上書きするのではなく、ディストリビューションの設定と統合してください。高位ポートにより、別のDNSフロントエンドがポート53を使用できます。有効な完全なファイルを検証してから、インストール済みのサービス管理を通じてリロードしてください。リモートクライアントには別途管理されたトンネルまたはフロントエンドが必要です。このフラグメントは意図的に公開リゾルバーを作成しません。
server:
interface: 127.0.0.1
port: 5335
access-control: 127.0.0.0/8 allow
access-control: 0.0.0.0/0 refuse
access-control: ::0/0 refuse
# Validate the complete installed configuration:
unbound-checkconf公式ドキュメント: Unbound 設定リファレンス
2 つのネットワークから受け入れチェックリストを実行する
まずバックエンドをローカルで照会し、次に通常のクライアント経路で確認します。通常のA/AAAAレコード、意図的に存在しない名前、文書化されたテストドメインを使ったDNSSEC検証を確認してください。許可されたサブネット外のマシンから繰り返します。そのマシンは再帰を受け取ってはなりません。ブラウザが独自の暗号化リゾルバーを使用し、設定されたデバイスのDNSを迂回していないか確認してください。変更中は一時的な独立リゾルバーを利用可能にしておき、DNSの誤りで管理経路が失われないようにしてください。
- ローカル診断: dig @127.0.0.1 -p 5335 example.org A
- UDP と TCP の両方の到達性、および IPv6 リスナーを確認してください。
- フィルタリングの例外を確認し、実際に必要な診断情報のみを記録してください。
タイムアウト、ループ、検証エラーを診断する
ローカルバックエンドは動作しているのにフロントエンドがタイムアウトする場合は、フロントエンドのアドレス、ファイアウォール、転送先を疑います。自己宛クエリが繰り返される場合はループの可能性があります。広範囲にわたるDNSSECの失敗は、システム時刻の誤りやトラストアンカーの保守に関係することがあります。検証を無効のままにせず、原因を修正してください。大きな応答のみが失敗する場合は、TCPフォールバックとネットワーク経路を調査してください。クエリログは一時的に留め、リゾルバーを全デバイスの依存先とする前に再起動と設定の復元をテストしてください。