DoHとDoT — 誰から隠すのか

5本目と6本目で「では暗号化すればよいのでは」という疑問が2度残ったはずです。出発点は1つ。暗号化は、経路全体ではなく区間に効きます。

名前解決の道のりには少なくとも2つの区間があります。スタブリゾルバからフルサービスリゾルバまでと、そのリゾルバから権威まで。DoT と DoH が規定するのは前者の運び方だけです。

第33週『TLS終端 — どこで暗号を解くのか』の形が当てはまります。暗号化された通信はどこかで必ず復号され、そこが保証の切れ目でした。DNS で復号するのはフルサービスリゾルバです。つまりリゾルバは、どの名前が引かれたかを平文で受け取ります。

だから問いはこうなります。誰から隠れたのか。 リゾルバより手前に居た者だけです。

ここが山場です。DNS まわりで並べられる3つの仕組みは、別々の問題に対応していて、どれか1つが他を兼ねません。 RFC 8484 §9 は DoH についてこう述べます。

The HTTPS connection provides transport security for the interaction between the DoH server and client, but it does not provide the response integrity of DNS data provided by DNSSEC. DNSSEC and DoH are independent and fully compatible protocols, each solving different problems. The use of one does not diminish the need nor the usefulness of the other.

同趣旨の一文が RFC 7858 §8 にもあり、そちらは DoT の名前で書かれています。

As noted earlier, DNSSEC and DNS over TLS are independent and fully compatible protocols, each solving different problems. The use of one does not diminish the need nor the usefulness of the other.

2つの規格が、別々に同じ線を引いています。 一方を使っても、他方の必要性も有用性も減らない。

仕組み                何を与えるか              与えないもの
DNSSEC               出所の証明と完全性         機密性(中身は平文)
DoT / DoH            区間の秘匿                出所の証明
ソースポートの無作為化  当たる確率を下げる緩和     完全性も秘匿も

RFC 4033 §4 は DNSSEC の側から書いています。

Accordingly, DNSSEC is not designed to provide confidentiality, access control lists, or other means of differentiating between inquirers.

機密性は設計目標に入っていない、と規格が自分で述べています。逆に RFC 8484 §9 は「DNSSEC が与える応答の完全性は与えない」と書きます。互いに、自分がやらないことを明記しています。

中段の「経路上に居る者」に何が入るかは、規格が決めることではありません。 悪意のある第三者のことも、組織が意図して置いた監視装置のこともあります。仕組みから見れば、どちらも「区間の手前に居た者」です。

なお同じ発想を QUIC の上で行う DoQ が RFC 9250 として定義されています。運び方は変わりますが、どこで復号されるかという構造は同じです。