要約

  • RFC 9704では、クライアントがローカルに受け取るサブドメインの申告と、親ゾーンが公開する検証用の値を照合する。承認を確認するために、内部名の一覧を公開DNSへ載せる必要はない。
  • 一方、リゾルバーの認証用ドメイン名は公開レコードの名前に現れる。その名前に事業上の秘密を含めれば、一覧を隠すだけでは保護できない。
  • 内部サービスを一定の子ゾーンにまとめると公開レコードの更新を減らせるが、その配下で将来名前を作成する裁量も広く委ねることになる。

承認した時点では、社内サービスは三つしかなかった。それから用途が増え、別の部署も同じ名前空間を使い始めた。それでも親ゾーン側の承認を変更する必要がないとしたら、最初に承認したのは三つのサービスだったのか。それとも、その場所に今後サービスを置く裁量だったのか。

これは実際の事故を報告する話ではなく、委任の範囲を考えるための仮定である。名前を一つずつ承認する場合と、子ゾーンをまとめて承認する場合では、同じ画面に同じサービスが見えていても、将来の変更権限が違う。

社内DNSの例外を検証するRFC 9704には、この違いを考える手掛かりがある。しかも、その承認は内部サービスの一覧を世界に公表しなくても確認できる。可視性と責任、利便性と委任を、一つの設定値に押し込めずに扱う設計である。

公開するのは一覧ではなく、その承認

社内では、同じドメイン名に外部とは異なる答えを返す必要があることがある。一方、クライアントは日常の問い合わせに外部の暗号化DNSサービスを選んでいるかもしれない。社内サービスを使うために全問い合わせをローカルへ切り替えると、必要な例外より広い範囲を変更してしまう。

逆に、ローカルの情報を一切受け入れなければ、内部向けの名前を意図した形で解決できなくなる。必要な名前だけを、その名前について権限のあるリゾルバーへ送れれば、この二者択一を避けられる。

2025年1月に公開された標準化過程の文書、RFC 9704は、ネットワークと公開親ゾーンの協力によって、この例外を確認する仕組みを定めた。対象はグローバルDNSに根を持つ名前と、認証された暗号化通信に対応するリゾルバーである。複数の解決方法を組み合わせるクライアントを想定しており、常に同じ方法だけを使うクライアント全般の動作を変える規格ではない。

ネットワークがクライアントへ渡す申告には、リゾルバーの認証名、親ゾーン、対象サブドメインの集合、ハッシュアルゴリズム、ソルトが含まれる。親ゾーンの運用者は内容を承認し、正規化した名前の集合とソルトから計算した検証用の値をTXTレコードとして公開する。

クライアントはローカルで受け取った情報から期待値を計算できる。公開レコードには、その計算と照合するための値があればよく、個々の内部名を一覧として書く必要はない。

ここで使われるハッシュを「暗号化した社内名簿」と呼ぶのは正確ではない。後から復号して一覧を取り出すものではなく、ソルトも申告を受け取るクライアントに対して秘密にされるパスワードではない。分かれているのは、必要な情報を渡す相手と、公開DNSで確認可能にする内容である。

IANAのプロビジョニングドメイン登録表にも、splitDnsClaimsと五つの構成項目が記載されている。これは共通の記述方法を示す証拠であって、特定製品の対応状況や企業の導入実績を示す証拠ではない。

外に見える代表名を選ぶ

公開レコードの名前には、リゾルバーの認証用ドメイン名が含まれる。RFC 9704は、その名前自体が機密情報を持つ場合の漏えいを注意点として挙げている。

たとえば、非公開のプロジェクト名をリゾルバーの名前に使えば、内部名の集合を公開しなくても、そのプロジェクトを推測する手掛かりが外に出る可能性がある。これはハッシュ処理の失敗ではなく、外に出す名前の設計による問題である。

したがって、リゾルバーの認証名は、単なる運用上のラベルとして後から決めるべきではない。何の確認に必要な情報なのかを考え、事業内容や部署の内部事情を不必要に語らない名前を選ぶことになる。意味が分からない略号でも、組織の命名規則を知る相手には情報になり得る。

一度外部で観測された名前は、レコードを削除しただけでは回収できない。DNSの設定変更が容易であることと、公開済み情報を元に戻せることは違う。変更手順より前に、開示内容の確認が必要になる理由である。

また、内部の詳細が誰にも見えなくなるわけではない。申告を受け取るクライアントや問い合わせを処理するリゾルバーには情報が渡る。RFC 9463も、暗号化DNSはリゾルバー自身が利用できる情報を減らさないと説明している。通信経路を保護しても、答えを返す相手から問い合わせを隠せるわけではない。

ASDのACSCによるゲートウェイ技術指針は、内部ビューを外部事業者へ提供する前に、信頼関係と脅威モデルを検討するよう求めている。IPアドレスに応じたビューの選択を、それ自体でセキュリティ機構と見なさないようにも注意する。同指針はRFC 9704を参照しているが、これは助言であり、個別導入の安全性や端末の対応率を確認した結果ではない。

ローカルの都合だけでは検証を完結させない

親ゾーンの承認を確認する問い合わせまで、申告したネットワークが自由に書き換えられるなら、公開の確認先を用意した意味が失われる。RFC 9704は、ローカル運用者による干渉を受けない方法で検証レコードを取得することを求める。

一つは、あらかじめ設定された外部の暗号化リゾルバーを利用する方法である。普段適用する受け入れ条件を、この検証のために緩めてはならない。合理的な時間内に応答が得られなければ、検証は失敗となる。

もう一つは、クライアント自身が検証レコードについて完全なDNSSEC検証を行う方法である。Secureなら使用でき、BogusまたはIndeterminateなら拒否する。Insecureの場合は別の方法で再試行することが推奨され、再試行しないなら失敗として扱う。社内アプリケーションを急いで開きたいという事情は、これらの結果を同じ「成功」にまとめる理由にならない。

適用対象にも限界がある。local.などの特殊用途名を、この手順で特定のネットワークのものと認定することはできない。他者のドメインをフィルタリングする権限をネットワークに与える仕組みでもない。対象の親ゾーンによる承認が必要である。

リゾルバーの発見と、その権限の範囲は別々に扱われる。RFC 9463が配る名前、IPアドレス、サービスの情報を使えば、どこへどの方式で接続するかを知ることができる。証明書の照合は、接続相手が与えられた名前に合うかを確認するが、設定を配った経路やネットワーク全体への信頼まで証明しない。RFC 9704は、そのリゾルバーに任せてよい名前の範囲を確認する。

小さく保つには、維持する仕事がいる

RFC 9704は内部名を子ゾーンにまとめることを推奨する。そうすれば、その配下でサービスを追加するたびに公開検証レコードを変更する頻度を減らせる。この構成は、個々の内部名を公開しないための必須条件ではない。

運用負担を減らす利点はある。ただし、子ゾーンを任せることは、その中で将来名前を増やす余地も任せることになる。現時点の一覧だけを見た審査では、その裁量が見落とされやすい。

範囲を細かく指定すれば、変更のたびに複数の管理者が協力する場面が増える。広い範囲にすれば日常運用は進めやすいが、新しい用途も同じ承認に収まる。どちらを選ぶかは、誰にどの仕事を任せたいのかという判断であって、単に設定項目を埋める作業ではない。

更新には順序もある。対応する申告を変える前に新しい公開検証レコードを追加し、古いレコードは関連するDHCPリースまたはプロビジョニングドメインの情報が期限を迎えるまで保つ。検証レコード自体も有効期限の前に再確認される。RFC 8801は、プロビジョニングドメイン情報の期限や更新を別途定めている。公開側とローカル側の変更が同時に全端末へ届くとは限らない。

本稿は文書に基づく分析であり、実装試験、導入率調査、障害統計、費用削減の計測は行っていない。それでも設計から読み取れる点は明確である。狭い例外を維持したければ、その維持に必要な調整の仕事を引き受ける必要がある。人手不足を理由に範囲を広げるなら、それは権限を広げる決定として扱うべきだ。

名前を解決できることは、アプリケーションへのアクセス権ではない。内部名を公開しないことも、アプリケーションの保護の代わりにはならない。RFC 9704が与えるのは、必要なローカルの例外を、余計な一覧公開なしに確認するための道具である。