DNS の 2 種類の保護：DNSSEC は完全性、暗号化 DNS は機密性

DNSSEC と暗号化 DNS は、同じものの 2 段階のように語られます。しかし防ぐ攻撃がまったく違います。DNSSEC は改ざんを、暗号化 DNS は覗き見を防ぎます。片方は偽の答えを検証で落とし、もう片方は正しい答えを経路上の誰にも見せません。コストも違います。片方は署名切れが全解決失敗になり、もう片方は問い合わせログを少数企業に集中させます。切り分けて見て初めて、自分のゾーンに必要なのはどちらかが分かります。

DNSSEC の有効化は、ドメイン全体を一瞬で全訪問者に対して落とせる数少ない DNS 変更です。しかも落ち方は「そのサイトは存在しない」ように見えます。プロトコルは複雑ではありません。複雑なのは運用のほうです。

1. 信頼の連鎖は 4 つのレコード

ゾーンには DNSKEY レコード（公開鍵）があります。ゾーン内の各レコードセットには RRSIG が付き、対応する秘密鍵でそのデータに署名します。親ゾーンは DNSKEY のハッシュである DS レコードを公開し、これがゾーンを全体の連鎖につなぎます。検証リゾルバはルートから降りて DS で DNSKEY を検証し、その鍵で各 RRSIG を検証します。どこか 1 か所でも欠落または期限切れなら、応答は拒否されます。

「存在しない」ことも NSEC または NSEC3 で署名されます。だから DNSSEC は名前が存在しないことまで証明でき、そのせいでワイルドカードや空の非終端の挙動が多くの人の想定と少し変わります。

2. 何に署名するかより、誰が署名するか

署名の置き場所は 2 通りあります。DNS ホストが署名し、あなたがレジストラで DS を公開する。あるいはレジストラが両方を行う。故障の形はいつも同じで、親ゾーンの DS が現在ゾーンに署名している鍵と一致しません。ホストで署名を有効にして DS を忘れる、DNS 事業者を移行して古い DS が残る、鍵ロールオーバーが片側だけで失敗する——いずれもこれです。

何かを有効にする前に、DS の所有者と変更権限を書き出してください。DNS ホストとレジストラが別会社であることは普通で、その場合 2 段階の変更を正しい順序で行う必要があり、管理画面が代行してくれることはありません。

3. 障害の大半を占める 2 つの誤設定

• ゾーンが実際に署名される前に DS を公開する。検証リゾルバは即座に失敗し、今日それはほぼインターネット全体を意味します。順序は逆に。まず署名し、検証リゾルバで確認し、それから DS を公開します。
• 署名の期限を誰も見ていない。有効期間 30 日で自動更新なしのゾーンは、31 日目に、最後の署名を作った時刻に落ちます。アラートは「DNSSEC 有効」ではなく「署名の期限」に付けます。

4. 壊れたときに利用者が見るもの

役に立つエラーページではありません。検証リゾルバは SERVFAIL を返し、ブラウザはそれを一般的な接続失敗に変換します。サポートには「サイトが落ちている」と届きますが、オリジンは健全で、監視は正常と報告します。監視が検証を切っているか、キャッシュを見ているからです。1.1.1.1 や 8.8.8.8 のような検証するリゾルバで確認し、変更のたびに再確認してください。

5. 鍵のロールオーバー、手短に

KSK のロールオーバーは、新しい DNSKEY を公開し、TTL と伝播時間以上待ってから親の DS を差し替えます。この 2 つを同じ分に行うのが典型的な自滅です。ZSK は安価で自動化できるため、多くの運用者は ZSK を自動化し、KSK は計画的に実施します。アルゴリズムも重要で、13（ECDSA P-256）は 8（RSA/SHA-256）より署名が大幅に小さく、対応も広いため、今あえて古いほうを選ぶ理由はほとんどありません。

6. 正直なトレードオフ

DNSSEC が守るのは完全性であり、プライバシーではありません。応答が改ざんされていないことを証明しますが、誰がどの名前を引いたかを見られることには何の効果もありません。代わりに、全体に即座に影響する故障モードが増え、事業者移行では DS も動かす必要があり難度が上がります。可用性が重要なドメインにとっては実費であり、支払う価値はありますが、監視を用意したうえで、です。

平文の DNS は葉書のようなものです。経路上の誰でも宛先を読めますし、接続しているネットワークはあなたが引いたすべてのドメインを見ています。暗号化は明らかな改善です。ただし、人が期待するようなプライバシー保証ではありません。葉書は破棄されず、別の読み手に転送されるだけだからです。

7. DoH と DoT が変えるもの

DNS-over-TLS は 853 番への TLS 接続に問い合わせを包みます。DNS-over-HTTPS は 443 の HTTPS に包み、結果として通常の Web 通信に見え、853 を塞ぐネットワークでも通ります。どちらも端末とリゾルバの間は暗号化されるため、ローカルネットワークの運営者（ホテルの Wi-Fi、ISP、パケットキャプチャをしている同僚）は名前を読めなくなります。

得られるのはそこまでで、それは実際に価値があります。変わらないのは「誰が答えるか」です。リゾルバは問い合わせたすべての名前を見ており、あなたの IP も見ており、両者を関連付けられます。観測者を消したのではなく、選んだのです。

8. 集中の問題

実際には、暗号化 DNS の大半は少数の大手に流れます。ブラウザの既定がそこであり、利用者は既定を変えないからです。暗号化以前は、問い合わせはその時々のネットワークが割り当てた ISP リゾルバに分散していました。以後は、1 社がカフェ・職場・自宅・モバイルをまたいだ 1 人の閲覧の大きな部分を見られます。断片化していた問い合わせログが統合されるわけで、統合こそプライバシーを気にする人が恐れるものです。

9. 誰も教えてくれない副作用

• スプリットホライズン DNS が壊れます。社内だけで解決する名前が、ブラウザが自前の DoH を強制すると解決できず、悪ければ公共の何かに解決されます。
• キャプティブポータルが壊れます。ポータルは DNS を乗っ取ってログイン画面を出す必要がありますが、DoH に固定されたブラウザは「インターネットがない」と表示するだけです。
• VPN の DNS ポリシーが迂回されます。OS やブラウザが独自の暗号化リゾルバを持つと、通信はトンネルを通り問い合わせは別経路へ。文字どおりの DNS 漏洩で、しかも「プライバシー改善」機能が原因です。
• フィルタが消えます。ペアレンタルコントロール、マルウェア遮断、企業ポリシーはいずれも DNS 上で動きます。暗号化 DNS はそれらを無効化するか、証明書検査への移行を強います。後者のほうが悪い選択です。

10. TLS ハンドシェイクは依然としてあなたを明かす

問い合わせが暗号化されても、現在の多くの TLS 接続では ClientHello の SNI に接続先ホスト名が平文で入ります。Encrypted Client Hello はその穴を塞ぎますが対応は限定的で、サーバーとクライアント双方の協力が必要です。加えて多くのネットワークでは、ECH を含む接続を中間装置がリセットします。「どのサイトを開いたか誰にも知られたくない」が目的なら、DNS の暗号化だけでは足りません。

11. 性能面の利点は本物だが、条件付き

DoH は平文 UDP DNS より速く感じることがよくあります。理由は接続の再利用です。問い合わせはブラウザが既に開いている同じリゾルバへの HTTPS 接続に乗るため、追加の往復もコールドスタートの遅延もありません。DoT も TLS セッションを維持すれば同じです。逆に接続が 1 本もない状態では、暗号化 DNS は答える前にハンドシェイクを必要とします。

12. では何を選ぶか

• ベンチマークではなく方針で選ぶ。ISP に渡すか、大手に渡すか、自分で運用するかは異なるトレードオフで、最速が最適とは限りません。
• 公開ポリシー、第三者監査、明確な管轄を持つリゾルバを選ぶ。「ログなし」は主張であり、それを検証した監査報告を探してください。
• 自分が管理するネットワークでは、端末の上流に自前の DoT リゾルバを置く。フィルタと社内名を保ったまま、上流までは暗号化できます。
• フォールバックを残す。ローカルリゾルバ経由しか許さないネットワークは設計ミスではなく、多くはキャプティブポータルかポリシーです。プライバシーは失敗時閉じる、接続性は失敗時開く。

ipbox.one の DNS ツールは DNS-over-HTTPS でレコードを引き、ホームでは実際に問い合わせに応答したリゾルバと、その国が出口と一致するかを示します。前者は DNSSEC の署名が返っているかを見せ、後者は暗号化 DNS があなたの問い合わせを誰に渡したかを見せます。