DNSリゾルバのログとVPN接続のログ：それぞれが何を保持するか
リゾルバは答えるよう求められた名前を記録し、VPNは自らの実装からトンネルの出来事を記録する。一方の保存方針が他方を覆うことはない。
DNSリゾルバのログとVPN接続のログは、どちらもネットワークの記録であり、どちらも有用で、互いに代用できるものではない。リゾルバは、答えるよう求められた名前を受け取る。VPNの終端点はトンネル接続を扱い、その実装が記録すると決めた内容を記録する。両者は同じ建物にあり、同じチームが運用し、同じプライバシー通知の対象であっても、異なる識別子と異なる保存期間を持つ異なる出来事を記述している。一方を他方のように読むことが、調査が迷走する道筋である。
二つのログ、二つの出来事
リゾルバの項目は名前解決についての問いに答える。このクライアントがこの時刻にこの名前を求め、答えはこれだった。VPNの項目は接続性についての問いに答える。このピアがトンネルを確立または喪失し、このアドレスを割り当てられ、消える前にこれだけの量のデータを転送した。どちらもHTTPSセッションの内部で利用者が何をしたかの記録ではなく、どちらも他方を置き換えない。
この区別は約束事に対して実際的な帰結を持つ。VPN事業者がトンネルの活動を記録しないという表明は、それが配布するリゾルバについて何も語らず、リゾルバの保存方針は、誰がトンネルに接続したかについて何も語らない。どの主張も、それ自身の運営者とシステムに属する。
どちらのログを読む前でも、まず問いの経路をたどる
問いがリゾルバに届くのは、経路が実際にそのリゾルバに尋ねた場合だけである。アプリケーションはOSのリゾルバを使うことも、独自の暗号化DNSクライアントを動かすことも、キャッシュされた答えを読んで何も送らないこともある。したがって、何も表示しないリゾルバのログは、その名前が一度も使われなかった証拠ではなく、このリゾルバに問い合わせがなかった証拠である。
resolvectl status
dig @127.0.0.53 build.corp.example +qr
journalctl -u systemd-resolved -n 20 --no-pager最後のコマンドはローカルリゾルバ自身のジャーナルを読むもので、上流サーバのログとは同じではない。問いがDNS over HTTPSで事業者へ出ていく場合、ローカルのスタブには何も出ずに、事業者側には完全な記録が残っていることがあり、その事業者は別の方針を持つ別の運営者である。
各記録が示せることと示せないこと
| Record | Typically shows | Does not show |
|---|---|---|
| Resolver log | Queried name, client address, time, response | Which page was fetched, or what the tunnel did |
| VPN connection log | Peer identity, assigned address, connect and disconnect times, volume | Which name the application asked for |
| Application or proxy log | Requests, status codes, sometimes full URLs | Resolved addresses for every dependency |
両者を突き合わせることが本当の作業であり、突き合わせが常に可能とは限らない。クライアントのアドレスを記録するリゾルバは、既知のプールからアドレスを割り当てるVPNと比較でき、その比較は問い合わせた名前とトンネルの間にもっともらしい結び付きを生むが、それは二つの記録の間の結び付きのままで、人物の記録ではない。
暗号化DNSが変えるのは輸送であって、終端点での可視性ではない。リゾルバは答える問いを今も受け取る。RFC 8484が明らかにしているとおりで、そのリゾルバでの保存は方針の決定であって、プロトコルの性質ではない。
分割DNSとキャッシュが話を混乱させるところ
複数のリゾルバは正常である。分割DNSの設計では、内部名は内部サーバへ、それ以外はすべて公開サーバへ送られるので、一つの調査が、組み合わせることを想定していなかった二つのログと、比較することを想定していなかった二つの保存設定に関わることになる。両方に問いが見えることは、設計が機能している証拠であり、漏えいの証拠ではない。
キャッシュは逆方向に働く。よく使われる名前は何時間もキャッシュから答えられ、リゾルバの記録には最初の問いだけが残ってその後は何も出ないが、利用者のアプリケーションは同じ名前を問題なく解決し続ける。ある時点以降に項目がないことは、その時点以降に誰もその名前を使わなかったことを意味しない。
背景トラフィックが第三の歪みである。起動時にテレメトリの名前を解決する携帯電話、検索候補のドメインを解決するブラウザ、毎時チェックインする更新プログラムは、どれも実際に気にしている名前の隣にリゾルバのログとして現れる。そのログの量は注意ではなく、問いを数えることは訪問を数えることではない。リゾルバのログは問いの記録であり、問いは安く作れる。
保存についての問いは別々に立てる
システムごとに三つの問いを立てる。誰が収集するのか、何が収集されるのか、そしてどれだけの間保持されるのか。次に、誰がそれを読めるのか、どの手続きによるのかを問う。DNS over HTTPSに関するRFC 8484の議論は、暗号化された輸送が終端点をなくすわけではないことの良い念押しであり、事業者自身の文書だけが、その終端点が何を保持するかについての信頼できる表明である。
プライバシーについて「VPN」という主張がなされるときは、受け入れる前に構成要素へ分ける。トンネルの運営者、トンネルが配布するリゾルバ、その問いが届く上流のリゾルバ、端末上のアプリケーションである。それぞれに独自の答えがあり、一つについて正確な主張が、四つすべてを覆うかのように繰り返される。
トラブルシューティングには同じ分割を使う。どのアプリケーションが問いを出し、どのリゾルバが答えたのかを確かめ、そのうえでその出来事を実際に所有するログを見る。もう一方のログから推測すると、一分を節約して午後を失う。