BINDDNSサーバー開発者が発表 数日前 実験ブランチへの参加9.17、の実装 のサポート テクノロジーのためのサーバー DNS over HTTPS （DoH、DNS over HTTPS）およびDNS over TLS （DoT、DNS over TLS）、およびXFR。
DoHで使用されるHTTP / 2プロトコルの実装 nghttp2ライブラリの使用に基づいています。 これはビルドの依存関係に含まれています（将来、ライブラリをオプションの依存関係に転送する予定です）。
適切な構成により、単一の名前付きプロセスが従来のDNS要求だけでなく、DoH（DNS over HTTPS）およびDoT（DNS over TLS）を使用して送信された要求も処理できるようになりました。
HTTPSクライアント側サポート（dig）はまだ実装されていませんが、 XFR-over-TLSサポートは、着信および発信要求に使用できます。
DoHおよびDoTを使用したリクエストの処理 これは、httpおよびtlsオプションをlisten-onディレクティブに追加することで有効になります。 暗号化されていないDNSover HTTPをサポートするには、構成で「tlsnone」を指定する必要があります。 キーは「tls」セクションで定義されています。 DoTの場合は853、DoHの場合は443、DNS over HTTPの場合は80の標準ネットワークポートは、tls-port、https-port、およびhttp-portパラメーターを介してオーバーライドできます。
機能の中で BINDでのDoH実装の TLSの暗号化操作を別のサーバーに転送することが可能であることに注意してください。 これは、TLS証明書の保管が別のシステム（たとえば、Webサーバーを備えたインフラストラクチャー）で行われ、他の担当者が参加する状況で必要になる場合があります。
へのサポート デバッグを簡素化するために、暗号化されていないDNS overHTTPが実装されています また、内部ネットワークで転送するためのレイヤーとして、これに基づいて暗号化を別のサーバーに配置できます。 リモートサーバーでは、サイトのHTTPSバインディングを編成する方法と同様に、nginxを使用してTLSトラフィックを生成できます。
もうXNUMXつの機能は、一般的なトランスポートとしてのDoHの統合です。 これは、リゾルバーへのクライアント要求を処理する場合だけでなく、サーバー間でデータを交換する場合、権限のあるDNSサーバーを使用してゾーンを転送する場合、および他のDNSトランスポートでサポートされている要求を処理する場合にも使用できます。
DoH / DoTを使用したコンパイルを無効にするか、暗号化を別のサーバーに移動することで補うことができる欠点の中には、 コードベースの一般的な複雑さが強調されています-組み込みのHTTPサーバーとTLSライブラリがコンポジションに追加されます。これらは潜在的に脆弱性を含み、追加の攻撃ベクトルとして機能する可能性があります。 また、DoHを使用すると、トラフィックが増加します。
あなたは覚えておく必要があります DNS-over-HTTPSは、情報漏えいを回避するのに役立ちます。プロバイダーのDNSサーバーを介して要求されたホスト名を処理し、MITM攻撃やDNSトラフィックをスプーフィングし、DNSレベルのブロックを打ち消し、DNSサーバーに直接アクセスできない場合に作業を整理します。
はい、 通常の状況では、DNS要求は直接送信されます システム構成で定義されたDNSサーバーに、次に、 DNS over HTTPS、 ホストのIPアドレスを決定する要求 HTTPSトラフィックにカプセル化され、HTTPサーバーに送信されます。 リゾルバーはWebAPIを介してリクエストを処理します。
「DNSoverTLS」は、「DNS over HTTPS」とは異なり、TLSプロトコルを使用して編成された暗号化通信チャネルにラップされた標準DNSプロトコル（通常はネットワークポート853が使用されます）を使用し、TLS証明書によるホスト検証/証明書によって認証されたSSLを使用します。 権限。
最後に、 DoHは、バージョン9.17.10でテストできます。 DoTサポートは9.17.7から存在しており、安定すると、DoTとDoHのサポートは9.16安定ブランチに移行します。