ISPが他の方法でターゲットドメインを見つけることができるのに、なぜDNS over TLS / HTTPSを使用するのですか？
DNS over TLSやDNS over HTTPSなど、DNSを保護する取り組みがあります。 ISPがユーザーが他の方法でアクセスしたドメイン（プレーンHTTPのホストヘッダー、HTTPSを使用したTLSハンドシェイクのSNI）を検出できることを考えると、TLS/HTTPS over DNSが対処している脅威を理解していません。
今日のDNS over TLS/HTTPSの主要なポイントは、有害であると見なされているサイトのDNSベースのブロックをバイパスする可能性が高いです。ほとんどのユーザーは、ISPが提供するDNSサーバーを使用するため、DNSベースのブロックは簡単で安価です。ユーザーが明示的に 別のパブリックDNSサーバー を構成した場合でも、ISPは安価なパケットフィルタールールを作成して、ユーザーがポート53（DNS）へのトラフィックをISPのDNSサーバーで透過的に処理することができます別のものを使用してみました。理論的には、許可されたDNS回答を許可するDNSSecがありますが、ドメインの大部分では使用されません。つまり、クライアントは通常、それを強制しません。
ユーザーが代わりにDNS over TLSまたはHTTPSを使用している場合、ISPにはこれらのTLS接続に対応する証明書がないため、ポート53の単純なリダイレクトは機能しなくなります。 ISPは、クライアントが通常のDNSにフォールバックすることを期待して、ポート853（DNS over TLS）のトラフィックを単にブロックすることができますが、同じポート（443）を使用しているため、深刻な副作用なしにDNS over HTTPSをブロックすることはできません。おそらく、通常のHTTPS Webトラフィックと同じ宛先（コンテンツ配信ネットワーク）です。
つまり、サイトをブロックするために、ISPはDPI（ディープパケットインスペクション）に依存してHostヘッダー（プレーンHTTP）またはTLSハンドシェイク（HTTPS）のSNIから宛先を抽出し、次にブロックする必要があります。トラフィック。これは、単純なレイヤー4（ポートベース）リダイレクトよりもはるかに高価であり、トラフィックのパフォーマンスにも影響します。これにより、ISPのロビーがブロッキングに反対する可能性が高くなります。特に、ISPがすべての追加コスト自体を考えなければならない場合はなおさらです。
さらに 提案された暗号化されたSNI は、DPIでも訪問したサイトを確実に見つけることができないため、ドメイン名に基づいてサイトをブロックすることが確実に機能しないことを意味します。
正直に言うと、プロキシを使用せずにサイトに直接接続すると（たとえば、TORまたはVPNはすべてプロキシですが、安全なプライバシーレベルが異なります）、すべてのプロキシでも安全なDNSを使用する必要があります。
安全なDNSを使用して暗示される脅威は何ですか？
答えは次のとおりです。TLS/ SSLまたはその他の階層化サービスでのWebブラウジングに影響を与えます。
脅威は、使用されるサービスに関連して暗号化されたトラフィックに存在します（実際には、トラフィックを受信接続と送信接続で受け入れる前に、復号化および検証する必要があります）。安全なレベルでの送信セッション：
TLS/SSLは、認証と暗号化プロセスが検証および実行されると、トラフィックの注入を防止する必要があります。これは、最終的にセキュアレイヤーが提供する最も便利な機能です。