DNS といえば UDP の 53 番ポートを使用することで知られていますが、それとは別に、DoH (DNS over HTTPS) と呼ばれる方式があります。
DoH の分かりやすい特徴は下記の通りです。
- DoH は DNS を HTTPS でカプセル化します。
- HTTPS であるため TCP での通信になります。また、クエリの内容は暗号化されており、ネットワーク上の盗聴者には解読されません。
- DoH は OS のネットワーク設定ではなく、ブラウザの設定でも DNS を指定できます。つまり、OS の DNS 設定とは独立してアプリケーション単位で名前解決を行います。このため、トラブルシューティングが複雑になることもあるでしょう。
- DoH は DNS サーバーもクライアントも対応している必要があります。
DoH の懸念事項としては下記の通りです(Web プロキシを使う場合はどうなるのかは未調査です)。
- DoH による問題の一つは、特定のセキュリティ関連の機能(例えば問題のある DNS クエリをブロックする機能など)が無効化される可能性があることです。具体的な例としては、セキュリティフィルタリングや保護機能が DoH に適用されず、一部の問題が検知されない場合があります。基本的には何らかの方法で複合化しない限りは DoH 通信を識別することは不可能です(強いて言えば、DoH サーバーを特定できれば良いですがこれもほぼ無理でしょう)。
- DoH はまだ標準化されていないため、将来の展開については不確定ですが、すでに一部の実装が存在しています。したがって、ネットワークのトラブルシューティングなどを行う際には、DoH の存在を考慮する必要があります。標準化の進捗状況や対応策の更新にも注意を払うべきです。
Google Chrome は早期から DoH に対応しており、ちょっと簡単な設定を変更するだけで、DoH が使用されます。このため、いくら社内の DNS クエリをセキュアにしていても、 DoH を使用することで簡単に抜け穴になります。そもそも DNS クエリの制限だけというのは実際とても緩く、それ以外の抜け道もありますね。中途半端なセキュリティというのは、組織内で過信と不安が入り混じり、投資を誤る可能性もあります。どのように統制をとっていくかはかなり重要です。
個人的に思うこととして、通信の暗号化はここ 10 年位で急速に進みました。このため、現在ではネットワークを介した通信はほとんどが暗号化されています。ですが、企業内のセキュリティーはどこに通信しようとしているか、どういう通信内容か、規定外のポート番号を使用してないか、などの観点でネットワークセキュリティを保とうとします。このように両者には矛盾があり、どちらもセキュリティとはいうものの、どのように統制を効かせるかの判断が難しいところです。おそらく落とし所としては、業務環境にアクセスするための通信の途中経路の複合化はやむなしだと思っています。
もう一つの観点として、なぜ DNS を HTTPS に含めてしまうのか?と言う疑問があります。これが一番の元凶だと思っており、少なくとも別のポート番号にしておけば、いろんな問題が解決します。なぜそうしていないかというと、ファイアウォールルールをシンプルにしたいのと、あらゆる通信をブラウザでコントロールしたいと言うことになると推測します。
ちなみに、DNSSEC という仕組みは以前からありますが、これは DNS サーバー間でデータの完全性と信頼性を確保するための仕組みです。DoH は DNS トラフィックを暗号化してプライバシーとセキュリティを向上させることを目的としており、DNSSEC と DoH は目的が異なります。