要約

  • IESGは10月8日、DNS-SD Extensions作業部会の憲章改訂版02を承認し、広い目標を具体的なプロトコル・文書作業へ落とし込んだ。
  • 作業部会は単一リンクと複数リンクのサービス発見を扱う一方、一般DNSの変更や他のゼロ設定型命名プロトコルとの統合は担当しない。

DNS-SDの新憲章は、作業対象を単一リンクから複数リンクへ広げると同時に、作業部会が担う項目を以前より具体的にした。Internet Engineering Steering Group（IESG）は10月8日に改訂版02を承認した。これは標準化と技術文書の作業計画を認める決定であり、新しいプロトコルを承認したものでも、異なるネットワーク間でサービス発見がすでに安定して動くことを示すものでもない。

旧版との比較に変化が表れる。前の承認済み憲章は「拡張可能なDNS-SDの解決策」を開発することを掲げ、ローカルのゼロ設定型命名とグローバルDNSの共存問題を記録する一方、解決は作業部会の範囲外としていた。新憲章は作業を分け、Service Registration Protocol（SRP）で登録された名前をMulticast DNS（mDNS）に公開すること、DNS-SDやmDNSの効率・可用性・有効性を高めること、同じ名前への競合更新を解決または回避する方法を定めることを列挙した。

技術的な背景から、各項目を分ける理由が分かる。DNS-Based Service DiscoveryとmDNSは家庭やオフィスのような単一リンク内で広く使われるが、mDNSは離れたリンク上のサービスを発見できない。SRPはサーバーがユニキャストDNSでサービスを登録できるようにし、Discovery ProxyはmDNSで見つけたサービスをユニキャストDNSの名前空間へ追加できる。これらの部品で広域の発見は可能になるが、名前、更新、到達範囲、可視性の扱いは別途定める必要がある。

憲章は成果物の種類も区別する。標準化文書では、SRP登録名のmDNSへの公開、発見機構の改善、名前の競合への対処が扱われる。情報提供文書またはBest Current Practiceでは、mDNSクライアントとSRPクライアントの双方が同一のDNS-SDサービスを利用できるよう、各部品をどう組み合わせるかを説明できる。RFC 8882のプライバシー・セキュリティ要件を考慮し、必要に応じてSNACや他のDNS作業部会、外部組織と連携することも定めている。

除外項目は作業一覧と同じくらい重要だ。作業部会はDNS-SDをUniversal Plug and PlayやLink-Local Multicast Name Resolutionなど別のゼロ設定型命名プロトコルと統合したり、それらとの競合を処理したりする役割を持たない。一般DNSプロトコルの更新も対象外である。憲章は問題をどこで扱うべきかを示して作業計画を検証可能にするが、問題自体を解決するものではない。

ネットワーク運用者や機器メーカーにとって、これは導入の節目ではなく、初期段階のガバナンス上のシグナルだ。既存のDNS-SD／mDNS展開との後方互換性は「強く望ましい」とされるが、保証ではない。次に見るべき証拠は草案、レビュー記録、そして承認済みの作業項目と結び付く標準である。新しい権限付与を、リンク間相互運用の完成、一般DNSの変更、または特定の展開に対する安全判断と読み替えてはならない。

出典