DNSSECとVPN、DNSクエリを隠すのはどちらか

二つの仕組みが同じ仕事を担うと見なされているが、どちらもその仕事をしていない。DNSSECが答えるのは、受け取ったデータが本当にそれを公開しているゾーンから来たかどうかであり、VPNが決めるのはパケットがどの経路を通るかである。どちらも、尋ねた名前をあらゆる場合に隠すわけではなく、隠すはずに見える設定の多くは検証ではなく転送や経路制御に関わるものだ。まず層の名前を付ければ、漠然としたプライバシーの疑問は具体的な問いになる。

一つにまとめられる三つの主張

真正性とは、応答がゾーンの公開したものであり、途中で改変されていないという主張だ。機密性とは、経路上の誰も問い合わせも応答も読めないという主張だ。経路制御とは、パケットが自分で選んだ経路を通るという主張であり、トンネルが提供するのはまさにそれである。

DNSSECは一つ目を扱い、残りの二つについては何も言わない。DoTとDoHはリゾルバまでの区間について二つ目を扱う。VPNは三つ目を扱い、二つ目にも影響し得るが、それはトラフィックの行き先の副作用にすぎない。

アプリケーションの通信は四つ目の場合だ。HTTPSはクライアントとサイトの間のウェブのやり取りを保護し認証するもので、どのDNS層もその代わりにはならない。

署名検証にできることとできないこと

検証するリゾルバは、ゾーンから設定されたトラストアンカーまでの署名の連鎖を確認し、検証が成功すると認証済みデータのフラグを立てた応答を返す。そのフラグはデータについての証拠であり、接続や宛先の意図についての証拠ではない。

信頼すべきでないサービスについて、正当なゾーン所有者が真正なレコードを公開するのを止めることはできない。侵害されたドメインからの正しく署名された応答は依然として正しく署名されており、そのドメインが自分の資格情報に値するかどうかにDNSSECは関与しない。

何も隠しもしない。問い合わせと応答は、別の層が転送を保護しない限り、リゾルバとその経路上のあらゆる観測者が読める形でネットワークを通過する。署名された応答と私的な応答は別の性質であり、配備はどちらか一方だけを持つこともある。どちらかが重要なら両方を試すとよい。

機密性は実際どこから来るのか

暗号化されたリゾルバへの転送はDNSのやり取りをTLSで包むので、リゾルバは問いを依然として見るが、自分とリゾルバの間の経路は見ない。これは信頼を除くのではなく移すことになる。リゾルバをより信頼し、ローカルネットワークをより信頼しなくなる。

VPNは問い合わせを反対側のリゾルバまで運ぶことができ、経路とそれを見るリゾルバの両方が変わる。これはプライバシー上の帰結を伴う経路制御の判断であり、管理されたネットワークでは内部名に答えられるのは内部リゾルバだけかもしれない。

人が実際に望む組み合わせは、通常、同時に三つだ。検証を有効にし、自分で選んだリゾルバへの暗号化された転送を使い、宛先ではアプリケーションのTLSを使う。それぞれ独立しており、一つを飛ばせば別の隙間が残る。

検証と転送を別々に確認する

二つの試験でほとんどの混乱は解ける。一つ目はリゾルバが応答を検証したかを問い、二つ目は転送が保護されていたかを問う。失敗の仕方は異なり、どちらかが他方を意味するわけではない。

これらのコマンドは、検証する問い合わせのフラグを表示し、検査を無効にして問い合わせを繰り返し、ローカル検証を delv で実行する:

dig +dnssec example.com | grep flags
dig +cd example.com | grep status
delv example.com

認証済みデータのフラグと署名がある応答は、そのリゾルバでの検証を示す。 delv での検証失敗は、ゾーンとトラストアンカーの間のどこかで連鎖が途切れていることを示す。これはトンネルの問題ではなく公開側の問題だ。フラグが一つもないままのタイムアウトは転送や到達性の問題であり、署名の失敗として扱うと間違った層へ向かう。

VPNが名前解決を壊したときにすること

トンネルの前は解決できていて、後で止まるなら、 経路ごとに使うリゾルバを比べる。分割トンネリング、トンネル経由でしか届かない内部リゾルバ、リゾルバ設定を書き換えるクライアントは、いずれもDNSSECに触れずに応答を変える。

検証を全体で無効にするのは誤った第一手だ。改ざんを報告する唯一の仕組みを外すうえ、到達できないリゾルバを直せない。まず不具合を絞る。解決、転送、検証、そして方針の順だ。三つ目だけがDNSSECに属し、二つ目だけが暗号化された転送に属する。