要約

  • IESGは2026年9月3日、DNSSDワーキンググループの再チャーター案を公開審査に付し、9月13日まで意見を求めた。公告は、IESGがまだ決定していないと明記する。
  • 案には、SRPで登録された名前をmDNSへ公開する方法と、同じ名前に対する競合更新の処理が含まれる。11月のWGLCを目標とするdraft-ietf-dnssd-tsr-03は古いプロキシコピーを見分けるための作業中の提案であり、認証、秘匿性、サービス成功の証明ではない。

端末がSRP登録先を切り替えたとする。最初のregistrarはmDNS advertising proxyも兼ねており、以前のアドレスをリンク上に残した。ネットワーク分断の後、新しいSRP Updateは別のregistrarへ届く。二番目のproxyは現在のアドレスを広告する。

mDNSから見れば、同じowner nameに二つの異なるRRsetがある。通常の競合処理は、すでに存在する広告を守る。新しい端末が既存のプリンター名を奪う場面なら正しい。だが、この二つは別の所有者ではなく、同じrequesterから生じた新旧のコピーである。古い方を守れば、保護機構が現在の所有者を拒む。

IESGの公告は9月3日、この問題を含むDNSSD再チャーター案への意見募集を開始した。提案チャーターは、単一リンクと複数リンクにまたがるDNS-SD/mDNS、SRP登録名のmDNS公開、同一名への競合更新を対象にする。締切は9月13日で、決定済みではない。

予定表を成果として読んではならない。再チャーター案は承認されたチャーターではない。11月のworking-group last callは将来のマイルストーンである。TSRのDatatrackerにある第03版はStandards TrackのInternet-Draftで、RFCでも配備実績でもない。EDNS codeの要求もIANA割当済みを意味しない。

RFC 6762のmDNSには、ローカル名前空間を一元管理する権威サーバーがない。RFC 1034の委任型DNSとは違い、リンク上でprobeを行い、衝突を解決する。RFC 6763はDNS記録を使ってサービス種類とインスタンスを発見する方法を定義した。

後から範囲を橋渡しする仕組みが加わった。RFC 8766のDiscovery Proxyは、mDNSで得たサービスをunicast DNSで参照可能にする。RFC 9665のSRPでは、requesterが鍵に結び付いた更新をregistrarへ送る。Advertising Proxy草案は、registrarがそのデータをmDNSへ広告する向きを扱う。

この時点で、リンク上の発言者は情報の原作者ではない。requesterが情報源、registrarが受領者、proxyが投影者である。障害や経路変更でrequesterが別のregistrarを選んでも、最初の投影が消えるとは限らない。

TSR第03版は、owner nameごとにTime Since Received EDNS optionを一つ付ける。対象RRを示すindex、requesterの公開鍵に関係するkey checksum、受信からのtime offsetを運ぶ。受信側は自ノードの絶対時刻に変換し、コピーの世代を比較する。

checksumは発信源の連続性、時間は更新順序を扱う。同じ鍵に結び付く二つのproxy広告なら、新しいSRP情報を別の名前主張と誤認しにくくなる。不要なrename、probe、重複answerを減らし、まだ別proxyで有効な記録をgoodbyeで消す事故も避ける。

ただし時計は権威ではない。offsetにはネットワーク遅延が入る。再起動で時刻のepochが変わる。永続化された鍵との関連が失われれば比較根拠も失われる。primary/secondary指定は応答量やgoodbyeを調整するための運用情報で、名称の組織的所有権ではない。

RFC 6891のEDNSは共通拡張形式を提供する。相互運用できる形式があっても、特定製品の時計、cache、永続状態、撤回処理が正しいとは限らない。

セキュリティ境界は草案自身が明示する。同じリンクの悪意あるhostはTSRを使って競合に介入し得る。TSRがなくても、偽の競合記録を広告しprobeへ応答することでDoSを起こせる。mDNSを使うプロトコルは、安全性やprivacyを仮定してはならない。authentication、authorization、secrecyが必要ならapplication layerか、適切なDNSSECベースの発見が別に必要である。

RFC 8882はDNS-SDが機器、サービス、利用状況を露出させる点を扱う。複数リンクへ広げれば観測者も増える。最新で正しいRRsetでも、公開範囲が誤っていればprivacy事故になる。

実装検証では、requester identityと鍵、元のSRP Update、registrar、advertising proxy、owner name、完全なRRset、受信時刻とclock basis、checksum、TSR offset、probe、競合、採用記録、rename、goodbyeを保存する。その後にclientが受け取ったanswer、接続先、transport結果、application認証、ユーザーが見た結果を結ぶ。

採用されたRRsetは競合処理の結果でしかない。endpointの到達性ではない。接続成功は相手のidentityを保証しない。application認証が通っても、別リンクの古いcacheが消えたとは言えない。

撤回は逆向きに追跡する。source登録を止め、registrar stateを削除し、各proxyのwithdrawalを確認し、有効な冗長コピーは維持する。TTLとcache expiry後に旧endpointへのtrafficがなくなったことまで測る。中央画面から消えただけでは終わらない。

Heng Luの最小初期仕様は、コピーを比較するための狭い共通情報を支持する。現実の層は時刻、発信源、identity、サービス結果の混同を防ぐ。running code優先は、最終判断を実際のanswerとapplication動作へ戻す。

DNSSDの論点は、単に遠くのサービスを見つけることではない。proxyを挟むと、古さが継続性を表さなくなる。TSRは世代を整列できるが、正当性まで作れない。名称、更新、信頼、稼働を別々に証明して初めて、古い記録にも新しい記録にも過剰な権限を与えずに済む。

情報源