要約
- IETF Datatrackerは8月18日、
draft-ietf-dnssd-uld-00をDNSSDのワーキンググループ文書として承認した。前身の個人提出文書から技術本文は変わっていない。 - ULDはSRP登録、権威DNS、探索・広告プロキシをリンク上の優先サーバーにまとめる。mDNSの無線負荷を減らす可能性がある一方、Security Considerationsは未執筆のままだ。
文書名の変更は、プロトコルの変更よりも責任主体の変更を示している。
ワーキンググループ版の履歴には、8月18日16時22分50秒UTCに「WG -00 approved」、新版の公開、draft-tlmk-infra-dnssdを置き換える関係の三つが記録されている。名称、日付、期限、リポジトリURL、ページ見出しを除いて比較すると、前身-03と新しい-00は同一である。この日は新機能が追加されたのではなく、DNSSDが今後の開発を引き受けた日だ。
採用までの手順も公開記録から確認できる。前身文書の履歴によると、議長はIETF 126会場での挙手を受けて一度採用扱いにしたが、先にメーリングリストで採用の呼びかけを行うべきだったとして状態を戻した。7月21日に改めて呼びかけ、8月6日に「Adopted by a WG」となった。手続きの誤りを修正できたことは重要だが、最終仕様への合意を意味するものではない。
Unicast Local Discovery草案が扱うのは、家庭やオフィスのWi-Fiにある小さな負担の積み重ねだ。mDNSでは、サービスを公開する各端末がマルチキャスト問い合わせを受信して応答する。Wi-FiのマルチキャストフレームにはMAC層の確認や再送がなく、アクセスポイントはスリープ中の端末向けに保留せず、低い必須速度で送信する。電池端末は頻繁に起きるか、問い合わせを取りこぼすかの選択を迫られる。
ULDは常時動作するサーバーをその間に置く。サーバーはSRP registrarと権威DNS、Discovery Proxy、Advertising Proxyを持つ。対応クライアントはサービスをそこへ登録し、.local問い合わせをユニキャストで送る。サーバーが使えるリンクではクライアント自身の通常のmDNS参加をやめ、サーバーが従来端末との橋渡しを担う。
構成要素はすべて新規ではない。RFC 9665はService Registration Protocolと登録リースを定義している。RFC 8766は、mDNSリンクから得たサービス情報を使ってユニキャストDNSへ応答するDiscovery Proxyを定義する。ULDは、これらを一つの発見可能なローカルサービスとして選び、監視し、切り替える規則を加える。
RFC 6762のMulticast DNSが不要になるわけでもない。ULD文書は承認された場合に同RFCを更新するとしているが、サーバー広告、旧端末との相互運用、利用不能時のフォールバックにはmDNSを残す。移すのはサーバー利用時の通常処理であり、既存方式を一度に撤去する提案ではない。
運用上の核心は優先サーバーの決め方にある。管理ネットワークでは、インフラULDサーバーであることを運用者が明示設定し、同じリンクでULD用Router Advertisementオプションを出す機器は最大一台とする。ほかの機器は低い優先度でアドホックサービスを提供できる。クライアントはより優先されるサーバーを探し続け、故障を検知すれば探索をやり直し、移行時には全サービスを再登録する。
一台への収束には理由がある。別々のサーバーへ同じ名前が登録されると、双方が受理した後にmDNS層で競合し、登録したクライアントへ正しい結果が返らないことがある。草案はサーバー間複製を必須にせず、決定的な優先順位でクライアントを同じ選択へ導く。競合を減らす代わりに、選択、監視、再登録の失敗が見えるようになる。
IPv6では、インフラサーバーがRAオプションでも存在を知らせる。クライアントはその情報で発見するか、DNS-SDで見つけたインフラ指定を検証し、RA Guardで保護できるようにする。IPv4専用クライアントはmDNSでサーバーを探す。サーバー側はIPv4の.local要求を扱う前に、送信元が直結サブネット内にあることを確認しなければならない。
まだ空欄も多い。Security ConsiderationsはTODOだけで、SNACルーターの節も未完成である。IANAへ求めるサービス名はプレースホルダーのままだ。独立実装同士の相互接続、電池消費、無線占有、問い合わせ損失、サーバー切り替え時間を示す公開測定もない。Internet-Draftは変更、置換、廃止があり得る作業文書であり、RFCではない。
DNSSDの設置目的は、リンクローカルのマルチキャストだけではルーティングされた複数リンクへ探索を広げられず、範囲を広げれば安全性とプライバシーの問題も生じると説明する。ULDはまずリンク内にとどまるが、優先サーバーがクライアントの見えるサービス集合に関与する以上、信頼境界は後回しにできない。
今回確定したのは、公開の標準化作業が始まったことだ。性能改善、製品採用、安全性が確定したわけではない。次に問うべきなのは、誰がサーバーを名乗れるのか、誤った選択から何秒で戻れるのか、そしてmDNSより優れるという主張を独立した測定が支えるかである。
情報源
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加

