この点で、このようなメカニズムは企業組織の安全とセキュリティに害を及ぼさないと考えています。次に、DoTとDoHを詳細に説明し、DNSクライアントのセキュリティを解決するために提案する方法を説明します。
DNS over TLS（DoT）およびDNS over HTTPS（DoH）の操作について説明します。
DNSセキュリティ拡張機能（DNSSEC）が認証およびデータ整合性チェックメカニズムにDNSを追加すると、DNSクライアントのセキュリティは通常無視されます。この時点で、ローカルDNSサーバーはDNSSEC検証を実行し、そのデータの信頼性と整合性を確立し、結果をDNSクライアントに送信しますが、この最終プロセスは「なりすまし」攻撃を受ける可能性があります。
IETFの「DPRIVE」（DNS PRIVate Exchange）ワーキンググループは、DNSの「ラストマイル」に対処する2つの新しいメカニズムを開発しました。TLSover DNS（DoTと呼ばれ、RFC7858に記録）とDNS over HTTP（DoH） RFC8484に文書化されています。
DoTとDoHは両方とも重要な機能を提供します.DoTまたはDoHを使用してDNSクライアントとDNSサーバー間の通信を暗号化してデータの機密性と整合性を提供し、DNSクライアントは任意のプロトコルを使用してDNSサーバーを実行することを選択できます本人確認。
DoTはTCPポート853のみを使用しますが、DoHはHTTPSトラフィックを使用します。これは443が使用するポートと同じです。したがって、DoHと他のHTTPSトラフィックを区別することは困難です。
長い間、お客様は内部IPとインターネット間の直接通信をブロックすることを推奨してきました。この手順により、DNSChangerなどの一部の種類のマルウェアを防ぎ、内部ホストがITによって管理されるDNSデバイス（内部DNSデバイス）を使用するように強制できます。 「応答ポリシーゾーン（RPZ）」などの名前解決ポリシーを使用できます。ただし、DoHを使用して、内部ホストがインターネット上のDNSサーバーを照会するのを防ぐことは困難です。 （DoTは853ポートのみを使用するため、簡単にブロックできます。）
DoHをサポートする一部のアプリケーションは、MozillaのFirefoxなど、クライアント側で設定されたローカルDNSを意図的にバイパスする場合がありますこのバージョンでは、DoHリスクをサポートします。サーバー側のDNS設定は、DNSクエリをHTTPS経由でCloudflareに直接送信します。これにより、ローカルセキュリティメカニズムがバイパスされ、組織がDNS解決に対して不透明になります。 Firefoxなどのアプリケーションは、DNS名前解決において他のアプリケーションとは異なり、DNSの問題の複雑さも増します。
DoH開発者の動機に疑問はありません。彼らの目標は、DNSトラフィックのスヌーピングやDNSメカニズムの使用からインターネットを保護することでもありますが、企業ネットワークでの使用に適しているかどうかは疑問です。
DoTおよびDoHの使用に関するInfobloxの推奨事項：
インターネット上の社内IPサーバーとDNSサーバー（Cloudflareを含む）間の直接DNS送信（DoTおよびDoHを含む）をブロックすることをお勧めします。この方法により、ユーザーは社内DNSを使用し、ITをITにすることができます。組織はDNS解決ポリシーを適用して、問題をトラブルシューティングできます。
内部Iおよび外部の標準DNSおよびDoT送信をブロックするのは非常に簡単です。たとえば、内部DNSホストのみが53ポートへのアクセスを許可され、DNSホストを除く内部IPは内部および外部の53および853ポートトラフィックをブロックします。
DoHのブロックはより困難で、ファイアウォールの場合、DoHとHTTPSの両方を使用することは困難であり、DNS 443と、CloudflareやGoogleなどのDNSサービスを提供する他のIPをブロックできます。
内部DNSセキュリティメカニズムを回避することは悪い考えであると考えていますが、InfobloxはDNSの「ラストマイル」問題を解決することは非常に重要で価値があると考えています。 DoTはNIOSでサポートされています。
ソース：https://blogs.info blox.com/company/dot-doh-and-the-dns-last-mile-security-problem/
