1.1.1.1 を動かしているのは誰か？信頼する前に DNS アドレスを確かめる
VPN と一緒に使う DNS アドレスが、必ずしもその VPN によって運営されているとは限らない。リゾルバを特定し、経路とプライベート名のポリシーを別々に確認する。
1.1.1.1 を VPN の DNS 欄に貼り付け、ページが開き、チュートリアルは確認済みに見える。その観察は感じられるより狭い：アプリケーションの挙動は変わり、この変更はまだ、誰が問い合わせに答えたのか、なぜ以前の設定が失敗したのかを何も語っていない。コピーされたチュートリアルは、よく知られた公開アドレスを「VPN の DNS」と呼ぶが、それは到達性ではなく所有についての主張だ。アドレスが何を表すかを確かめるのに五分かかり、誤った理由による恒久的な変更を防げる。
動く設定は身元ではない
設定欄のアドレスは一つの端点であり、端点には運営者がいる。この二つの事実は別であり、人が飛ばすのは二つ目だ。最もよくコピーされる組について、答えは公開されている：Cloudflare は 1.1.1.1 と 1.0.0.1 を自社リゾルバのアドレスとして公表し、自社の 公式アドレス参照 に載せている。だから運営者の名前はアドレスの隣に置くべきで、別のチュートリアルに置くものではない。
トンネルが上がっている状態でその組を入力しても、VPN 会社がその運営者になるわけではなく、通信が匿名になるわけでもない。問い合わせはあなたの機械を離れて、そのアドレス範囲を公表している会社へ向かうが、その会社は評判がよくても、チュートリアルが示唆した当事者ではないことがある。手順書のラベルと現実の運営者は別の主張だ。どちらも、その間のネットワーク経路を誰が動かしているかは語らない。
アドレスの組や暗号化された端点を確かめるには、リゾルバ自身が公表している参照を使う。別のベンダーの推薦が正当なこともあるが、「誰が推薦したか」「何を経由して届くか」「誰が運営するか」は今も三つの別の関係だ。
記録に必要な三つを比べる
レビューに耐える記録は、三つの問いを分ける：誰が問い合わせを受け取るのか、やり取りが平文か暗号化か、どの経路がそれを運ぶのか。プロバイダ名では二つ目も三つ目も埋まらず、国名のラベルではどれも埋まらない。変更の前に三つの項目を書き出し、後で突き合わせる。それらは互換ではなく、一つとして扱うことが、推測を文書に変えてしまうやり方だ。
動く設定を記録された決定に変えるのは、この突き合わせだ。それがなければ、次の人は理由の付かないアドレスを引き継ぐ。まず下の表の三列目を読むとよい、自信のある説明の多くが実際そこで止まるからだ。
| Entry | What it records | What it cannot tell you |
|---|---|---|
| Recipient | Which resolver should answer | Who operates the path to it |
| Transport | Plain DNS or an encrypted variant | Whether names stay private |
| Path | Which interface carries the query | Which upstream answers last |
表はわざと短い。各項目が別の問いに答え、どの一つの欄も三つすべてを埋めない、というのが要点だ。
ローカルの転送役は本当の上流を隠す
ルータを DNS として使うよう設定された機器は、転送役を指している。そのアドレスが示すのは問い合わせの次の受け手であり、最終的に答えるリゾルバではない。ローカルのスタブリゾルバは同じ余分な段を一つ加え、しかもどの状態出力にも現れるため本物と取り違えやすい。
スタブは、同じ出力にも並ぶ上流へ、たいていはもっと下にあるものへ転送する。運営者について何かを結論づける前に鎖全体を読むこと、最初の行が答えの全部ではないからだ。そうでなければ、受付を会社と呼んでいることになる。
resolvectl status | grep -A4 'Current DNS Server'
dig +short CH TXT whoami.cloudflare @1.1.1.1
dig example.com | grep -E '^;; SERVER'二つ目のコマンドは、運営者が公開していればリゾルバのエコー名を使い、それが見る送信元アドレスを報告する。三つ目は答えたサーバを名指しするが、それは設定したアドレスではないことが多い。運営者を書き留める前に、三つの出力をすべて比べる。
暗号化 DNS が変えるのは見えるもの、誰が見るかではない
DNS over HTTPS と DNS over TLS は、クライアントとリゾルバの間のやり取りを守る。リゾルバは、答えることが仕事なので、問われた名前を今もすべて読む。変わるのは、そのやり取りを誰が観察できるかであり、ローカルネットワークが見るのは一つの端点への接続で、平文クエリの流れではない。
変わらないのは信頼の関係で、それはその端点を運営する組織を指したままだ。独自の安全な DNS 設定を持つブラウザは、OS のリゾルバを完全に迂回することがある。両者は食い違う可能性のある二つの設定として扱うべきで、同じ設定を二度適用したものと見なすべきではない。
プライベート名には、また別の決定が要る。仕事のトンネルが選んだドメインを組織のリゾルバへ振り向けることがあり、それを公共サービスに置き換えると内部の名前解決が壊れたり、内部名が誤った相手に漏れたりする。アダプタ全体の設定を置き換える前に、ドメインポリシーを確認すること。
観察は狭く保つ
比べるときは古い設定を保存し、一度に一つの設定だけを変える。アプリケーション、操作、リゾルバのポリシー、そして再接続後に公開名と許可されたプライベート名がまだ解決するかを記録する。二つの変更を含む比較は、どちらも証明しない。結果は次の人が見つけられる場所、設定そのものの隣に書く。
resolvectl query intranet.corp.example
resolvectl domain
dig +short @1.1.1.1 example.comアプリケーションが動き出したら、証拠が許す範囲で主張を小さく保つ。その変更は一つの試験を助けただけで、以前のリゾルバが悪意で動いていたか、トンネルが壊れていたか、別の機器にも同じ置き換えが要るかは何も語らない。長く残る成果は、運営者と目的を説明できる設定だ。