要約

  • draft-ietf-dnssd-uld-00 は、リンクごとにクライアントを一つの優先ULDサーバーへ収束させ、別のサーバーへ移る際には自らの全サービスを再登録するよう求めている。
  • 選挙の成功だけでは継続性を証明できない。引き継ぎ記録には旧・新サーバー、変更理由、再登録予定の集合、受付・拒否・競合・リース、プロキシの両側から見た可視性、IPv4/IPv6別の結果、フォールバックを結び付ける必要がある。

「ほぼ全部戻った」が最も見えにくい

完全停止なら検知は容易だ。DNS問い合わせが続けてタイムアウトし、SRPリース更新もDNS Pushセッションも失われれば、異常は明確になる。厄介なのは、一部だけが欠ける場合である。四つのサービスのうち三つは新しい登録先へ戻り、残る一つは名前競合で拒否された。ネットワーク全体は稼働し、利用者の多くは変化に気付かない。

2026年8月18日付のdraft-ietf-dnssd-uld-00は、IETF DNSSDワーキンググループの作業文書である。Unicast Local Discovery（ULD）は、ローカルリンク上のサービス登録と探索を単一宛先のSRPとDNSで行いながら、mDNSを使う機器とも相互運用する仕組みを提案する。文書はStandards Trackを意図し、承認されればRFC 6762を更新するが、現時点ではRFCではない。Security Considerations、SNACルーター、IANA割当てには未完の記述が残る。

一台のULDサーバーには、SRPレジストラー、権威DNSサーバー、.localゾーン、mDNS側から情報を取り込むDiscovery Proxy、SRP登録をmDNS側へ広告するAdvertising Proxyという五つの論理要素がある。共有レコードへの回答は、ゾーンとDiscovery Proxyの情報を原則として合わせたものになる。

したがって、DNSの応答があることはカタログの完全性を示さない。新サーバーのゾーンは正しくても、Advertising Proxyから見たmDNS側に一部が出ていないことがある。逆に、Discovery Proxyが持つ古いキャッシュによって、消えたはずの項目が一時的に見えることもあり得る。確認すべき対象はサーバーの生存だけではなく、利用者が見るサービス集合である。

優先順位は決められても、状態は運ばれない

ULDサーバーはDNS-SD広告にpriを載せ、値の小さい候補が優先される。インフラサーバーは0、有線の非制約アドホックサーバーは100、Wi-Fiは200、制約のある候補は1000または65535となる。同順位なら、数値として最小のIPv6リンクローカルアドレスが選ばれる。

インフラサーバーはIPv6 Router AdvertisementにもULDオプションを含める。IPv6クライアントは、それを使ってインフラサーバーを見つけるか、DNS-SDで知ったインフラ指定を検証しなければならない。草案は、その指定を守る手段としてRA Guardを挙げる。

管理ネットワークでは、事業者がインフラ指定を明示的に有効化し、同じリンクで二台以上がULD RAオプションを広告しないようにする。家庭のような非管理環境では、すでにデフォルトゲートウェイとして動くCEルーターがその役割を初期設定で名乗り得る。主ゲートウェイと明確に判断できない機器は、設定なしに名乗ってはならない。

クライアントはまずインフラ候補を探し、なければアドホック候補を比較し、使えるサーバーがなければmDNSへ戻る。ULDを使い始めたリンクでは、自らの直接的なmDNS参加を止め、.local処理を選択先へ任せることが推奨される。

ただし選択は継続的である。DNS失敗、SRPリース更新失敗、DNS Push切断が続けば再探索する。アドホック候補を使うクライアントは、より優先されるサーバーの出現も監視する。現行サーバーが壊れた場合も、後からインフラサーバーが現れた場合も、クライアントは移行し、新しいサーバーへ全サービスを再登録しなければならない。

附属書Cは、この設計がサーバー間レプリケーションではなく決定的なクライアント収束を選んだ理由を説明する。独立した複数のSRPレジストラーが同じ名前を受理すると、競合は後からmDNS層で現れ、クライアントへ正しく返らないおそれがある。一つの候補へ集めれば分裂は避けやすい。一方で、旧サーバーの登録状態が新サーバーへ自動的に移るとは限らない。

過去のSRP Replication草案は別の考え方を示している。複数のサーバーが状態を共有し、停止時にも登録を保ち、切替え時の競合を抑えることを目標にしていた。この文書は失効済みで、ULD 00の構成要素ではない。現在のULDで問うべきなのは、各クライアントが変化を認識し、所有する登録を漏れなく再作成したかどうかである。

引き継ぎ記録は何を照合するか

最初に固定すべきなのは範囲だ。ULDのインスタンスと.localゾーンはリンクごとに分かれる。複数インターフェースを持つ端末は、片方でULD、もう片方でmDNSを使うこともある。「端末の移行完了」という一つのフラグでは足りない。リンク、インターフェース、アドレスファミリー、観測期間を明記する。

次に、旧・新サーバーのリンクローカルアドレス、pri、インフラまたはアドホックという区分、同順位時の比較値を記録する。変更の引き金も、持続的障害、リース更新失敗、Push切断、高優先候補の出現、運用者の操作に分ける。

インフラを名乗る根拠も必要だ。管理環境なら承認済み設定、家庭ならゲートウェイとしての役割を参照できる。ULD RAオプションの受信やRA Guardポリシーは重要な観測だが、それだけをサーバー認証と呼んではならない。ULD草案は自己署名証明書を許し、クライアントに拒否しないよう勧め、この文脈のTLSはサーバー認証を目的としないと明記している。

中心となるのはサービス集合の差分である。移行前に、クライアントが再登録すべき正規化済み記述のダイジェストを作る。移行後、各項目について受理、拒否、競合、タイムアウト、与えられたリース、再試行を記録する。新サーバーのゾーン側ダイジェストと照合し、さらに単一宛先の回答、Discovery Proxyの入力、Advertising ProxyからmDNSへの出力を別々に確かめる。

IPv4-onlyクライアントはサーバー探索にmDNSを使い、IPv4で優先サーバーへ到達できなければmDNSへフォールバックする。そのため、IPv6でのインフラ指定と正常な問い合わせだけではデュアルスタック全体を代表しない。アドレスファミリー別の確認が必要である。

意図的なサービス撤去、競合後の改名、リース待ち、フォールバックは同じ「失敗」ではない。しかし、いずれも例外として残さなければ、成功率の中に消えてしまう。

サービス一覧を監視台帳にしない

ローカル名は、部屋、人、機器の種類、生活時間まで示すことがある。完全な一覧を中央へ永続保存すれば、継続性の証明を超えてしまう。

必要なのは最小限の証拠である。正規化した記述にソルトを加えたダイジェスト、粗いサービスタイプ別の数、例外コードを使える。照合用の全データとソルトは、端末または保護された運用領域に短期間だけ置く。長期には移行ID、前後の件数、差分、所要時間、事後改変を検知できるコミットメントを残せばよい。

保存期間はリースやキャッシュが入れ替わり、遅れて障害が報告され得る期間に合わせる。その後は不要な名称を削除する。目的は一回の引き継ぎを検証することで、ローカル機器の履歴を作ることではない。

草案から導ける範囲

現行文書は、サーバー選択と全サービスの再登録が別の動作であることを明確にしている。しかし、ここで述べた引き継ぎ記録はDaniel Kadeによる分析であり、IETF仕様ではない。実装間の復旧時間や欠落率を示す測定結果も、今回の資料にはない。

RA GuardにはRFC 7113が示す実装上の限界がある。SRPの公開鍵とSIG(0)は登録の所有を守るが、二台のサーバー間で全体集合が一致したことを証明しない。ULDの権威性はリンク内の.localに限られ、公開DNSの委任権限ではない。

引き継ぎ完了とは、新サーバーが選ばれた瞬間ではない。期待された各サービスが戻るか、意図的に撤去されるか、検証可能な例外として残った時点である。その基準がなければ、正しい選挙の陰で小さな喪失が見えなくなる。

参照資料

  1. ULDワーキンググループ草案
  2. 文書履歴
  3. 固定版00 HTML
  4. 固定版00テキスト
  5. Datatracker文書API
  6. DNSSD作業リポジトリ
  7. IETF 126 ULD発表資料
  8. DNSSDワーキンググループ憲章
  9. RFC 6762 — Multicast DNS
  10. RFC 6763 — DNS-Based Service Discovery
  11. RFC 9665 — Service Registration Protocol
  12. RFC 8766 — Discovery Proxy
  13. RFC 8765 — DNS Push Notifications
  14. RFC 8490 — DNS Stateful Operations
  15. RFC 6105 — RA Guard
  16. RFC 7113 — RA Guard実装上の助言
  17. RFC 4861 — IPv6 Neighbor Discovery
  18. Advertising Proxy草案
  19. Time Since Received草案
  20. 失効済みSRP Replication草案