要約
- RFC 9665 の FCFS Naming は、未使用名を最初に受理された SIG(0) 鍵へ結びつける。同じ鍵の所持は示せても、組織上の権限や安全なサービスまでは示さない。
NoErrorの後には、hidden primary から配信権威、再帰リゾルバ、エンドポイント認証、実際のアプリケーション取引までを別のレシートで追う必要がある。
監視画面には登録成功と表示されていた。クライアントも SRV とアドレスを引けた。それでも接続先は期待したプロトコルを話さず、業務トランザクションは一度も成立しなかった。
SRP に矛盾はない。DNS-SD の登録は「ここにこのサービスがある」という発見情報を公開する仕組みであり、アプリケーションの健全性証明ではない。RFC 9665 が強くしたのは、誰でも同じ名前を書き換えられないようにする鍵継続性である。公開内容が現実のサービスと一致するかは別の観測になる。
最初の署名者が得るもの
通常の DNS Update を大量の自動機器に使うには、共有秘密や事前登録済み公開鍵の配布が重い。SRP は、機器固有の鍵を生成し、最初の空き名に対する更新へ KEY と SIG(0) を含める。レジストラが受理すると、その KEY のリース中は別鍵が同じホスト名やサービスインスタンス名を更新できない。
この FCFS は、現在の更新が最初の占有者と同じ秘密鍵に由来することを示す。会社名、製品所有者、利用者、メーカー、アプリケーションの正当性は示さない。ネットワークへ入った不適切な機器でも、未使用名を最初に取れば暗号学的に一貫した占有者になり得る。
鍵は安定ストレージへ保存し、機器ごとに一意とする。工場出荷状態へのリセットや所有者変更で鍵を消すと、新鍵は旧名を継承できない。旧 KEY-LEASE が生きていれば競合し、別名を選ぶか期限を待つ。リセット設計には、鍵だけでなく命名と資産移管の設計が必要である。
一つの更新に収めても、現実は一段ではない
SRP Update は、ちょうど一つの Host Description と、複数の Service Description/Service Discovery 命令を一つの DNS Update にまとめる。明示的な RFC 2136 の prerequisite は置かず、レジストラが構造、参照関係、共通 KEY、SIG(0)、リース、名前競合を暗黙に検証する。途中まで書き込むことはない。
しかし、その原子性は入口の範囲である。レジストラは問い合わせに答えない hidden primary かもしれない。データはジャーナル、署名、ゾーン転送、セカンダリを経由して初めて利用者に見える。NoError はその後段を観測していない。
さらに、DNS 回答は到達性を観測しない。SRV が示すポートへ TCP 接続できても、相手の証明書やアプリケーション資格を確認しなければ本人性は不明である。最後に必要なのは、安全な読み取りなど、明示したアプリケーション取引の結果だ。
サービスは消えても名前は残る
SRP は通常のサービス RR と KEY に異なる寿命を与える。PTR、SRV、A、AAAA、TXT の LEASE は典型的に約二時間、KEY-LEASE は典型的に十四日である。電源を切った機器のサービス表示は早く消しつつ、短い停止で他機器に名前を奪われないようにする。
運用状態は最低でも「サービス公開」と「名前予約」に分ける必要がある。KEY が残ることを、死んだサービスが配信され続ける問題と混同してはならない。逆に、別鍵のサービス RR が見えれば、通常更新経路との競合を疑うべきである。
TTL も独立している。リース失効後、権威は RR を返してはならないが、すでに再帰キャッシュへ入った応答は残り TTL の間使われ得る。権威の期限、キャッシュの期限、実体の稼働を一つの時刻へ潰せない。
署名の向きとネットワークの境界
SIG(0) はレジストラが requester を検証する仕組みである。基本仕様は requester がレジストラ応答を検証する方法を定義していない。レジストラは TLS を提供し、対応 requester は使うべきだが、鍵の自動検証がなければ機会的プライバシーであり、レジストラ本人確認ではない。
SRP の権限意味論は FCFS だけなので、管理ドメイン外からの更新を止めるのはネットワーク境界である。TCP の三者ハンドシェイク、TCP Fast Open の扱い、制約ネットワークでの UDP 送信元/受信インターフェース検査を記録する。署名が正しくても、入場資格が正しいとは限らない。
ゾーン境界も同じである。組織の apex に SRP を開けば、自動機器が www や mail を先取りできる。専用 discovery subdomain と禁止名が必要になる。通常の DNS Update 資格が SRP 所有 RR を上書きできる設計も避けるべきだ。
service.arpa. はローカルに提供される名前であり、世界共通の信頼ラベルではない。ローカルリゾルバを使わない端末は解決できないか、別の文脈の応答を見る可能性がある。PKI による一意なグローバル本人性の代わりにはならない。
証拠を一本の鎖にする
レシートには、ネットワーク参加、送信元インターフェース、登録ドメイン、レジストラ発見、輸送、TLS 検証状態、更新の生バイト、KEY fingerprint、署名結果、競合、要求/付与リースを残す。
続いて hidden primary の処理、配信ノードごとの応答、再帰観測と TTL、エンドポイント認証、アプリケーション取引を同じ登録 ID へ結ぶ。各段階が独立しているからこそ、障害箇所を説明できる。
出典
- IETF、RFC 9665 — Service Registration Protocol
- IETF、RFC 9664 — DNS Update Lease
- IETF、RFC 2136 — DNS Update
- IETF、RFC 2931 — SIG(0)
- IETF、RFC 6763 — DNS-SD
- IETF、RFC 7858 — DNS over TLS
- IETF、RFC 8945 — TSIG
- IANA、Locally-Served DNS Zones
- IETF Datatracker、RFC 9665 公開履歴
- RFC Editor、RFC 9665 metadata
- RFC Editor、RFC 9665 errata
- RFC Editor、RFC 9665 canonical text
- RFC Editor、RFC 9665 XML
- IETF、RFC 3007 — Secure DNS Dynamic Update
- IETF、RFC 4035 — DNSSEC protocol modifications
- IETF、RFC 6761 — Special-Use Domain Names
- IETF、RFC 8766 — Discovery Proxy
- Heng Lu、Minimum Initial Specification
- Heng Lu、Reality Layers
- Heng Lu、Running Code Primary
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加

