要約

  • Known-Answer Suppressionでは、mDNSの問い合わせ側がキャッシュ済みレコードを問い合わせのAnswer Sectionに載せる。残存TTLが応答側の正しいTTLの半分以上なら応答は抑制され、半分未満なら更新の回答が必要になる。
  • 問い合わせに含まれるレコードは非権威的であり、別の問い合わせ側はそれをキャッシュしてはならない。応答がなかったという事実だけでは、サービスの不在も、全端末の合意も、レコードの現在性も証明できない。

会議室でプリンターを探すとき、画面には候補が増えていく一方、同じ機器の告知が何度も押し寄せることはない。利用者には自然に見えるこの挙動は、共有リンク上の参加者が「何をもう知っているか」を短時間だけ開示することで成立している。

Multicast DNSは、UDPの5353番ポートを使い、ローカルリンク上でDNSに似た名前解決を行う。.local.の名前はリンクローカルな意味を持ち、別のリンクに同じ文字列があっても同じ対象とは限らない。通常のユニキャストDNSサーバーが全回答を統括する構成ではなく、複数のホストが同じ問い合わせを聞き、それぞれが回答できる。

この仕組みでは、発見を続けるアプリケーションが問題になる。最初のプリンターが見つかった時点で探索を終えれば、後から参加した機器を表示できない。反対に、同じ質問を頻繁に送り、全機器が毎回答えれば、便利な発見機能が継続的なマルチキャスト負荷になる。

RFC 6762の著者欄にはStuart CheshireとMarc Krochmalが並び、Cheshireが先に記載されている。文書が選んだ解決は中央集権でも無制限の発話でもない。問い合わせ側のキャッシュに、重複回答を一度だけ止められる限定的な効力を与え、その効力を時間と権威の境界で切っている。

問い合わせの中に回答を入れる理由

通常のDNSの見方では、質問と回答は別の役割を持つ。そのため、mDNS問い合わせのAnswer Sectionにレコードが入っていると、パケット解析画面は奇妙に見える。

ここでレコードを載せる目的は、ネットワーク全体に事実を宣言することではない。問い合わせ側が「この名前、型、クラス、データについては、まだこれだけの寿命が残るコピーを持っている」と応答候補に伝えるためである。応答側は自分の正しいレコードと比較し、同じ情報を今もう一度送る価値があるかを判断する。

この操作は主にSharedレコードに関係する。複数の機器が同じ名前、型、クラスに対して異なるデータを正当に提供し得るため、問い合わせ側は既知のメンバーを示しても、未知のメンバーからの回答を妨げない。サービス一覧は、新しい参加者を受け入れながら、既知の参加者の反復だけを減らせる。

継続問い合わせにも速度制限がある。最初の二回の間隔は少なくとも一秒で、その後は少なくとも倍に広げる。間隔が一時間に達した後は、一時間に一回まで維持できる。初回には20から120ミリ秒のランダムな遅延を置き、多数の端末が同時に送信する確率を下げる。

Known-Answer Suppressionはこの継続動作の任意の飾りではない。問い合わせを続けながら重複を避けるための必須の規則である。

半分という境界

応答側は、問い合わせに載った一致レコードの残存TTLが、自分が知る正しいTTLの半分以上なら、その回答を送ってはならない。残存TTLが半分未満なら、回答して問い合わせ側のキャッシュを更新しなければならない。問い合わせ側も、半分を下回ったレコードを既知回答として載せるべきではない。

たとえば、正しいTTLが120秒のレコードに70秒残っていれば、同じレコードの再送は抑えられる。50秒しか残っていなければ、応答側は沈黙できない。この比較には二つの値が必要だ。問い合わせに記された残存TTLと、応答側がそのレコードに設定すべきだと知る正規TTLである。

境界の目的は、キャッシュを満了直前まで放置することではない。まだ十分に新しいコピーへの反復を減らしつつ、寿命の後半に入ったコピーには更新機会を与えることにある。沈黙する権利は、時間とともに自動的に失われる。

半分という数字は、レコードが真か偽かを測る確率ではない。信頼度を50パーセントと評価する規則でもない。あくまでキャッシュ寿命と再送判断を結びつける決定点である。運用画面がこれを「信頼スコア」と表示すれば、仕様にない意味を作り出してしまう。

Answer Sectionでも権威は生まれない

RFC 6762は、他の問い合わせ側が、問い合わせに含まれる既知回答をキャッシュしてはならないと明記する。そのレコードは、サービス所有者が今発した主張ではなく、ある端末が以前の観測から保持している信念だからだ。

問い合わせ側の情報は古い可能性がある。元のホストが既にリンクから離れているかもしれない。ネットワーク分断の前に得た記録かもしれない。別の端末がそれを学習すると、一つの古いキャッシュが複数のキャッシュへ増殖し、元の応答がなくても誤りだけが延命される。

したがって、フィールド名がAnswerであることは証拠の種類を変えない。パケットを説明するときは、メッセージが問い合わせか応答か、レコードを誰が載せたか、残存TTLはいくつかを同時に示す必要がある。

沈黙した応答側も、サービスが存在しないと主張しているわけではない。単に、質問者が示した特定レコードについて、今の再送が不要だと判断しただけである。別の質問者が更新を待っていれば、判断は変わる。

複数パケットが作る待ち時間

既知回答が一つのパケットに収まらないとき、問い合わせ側はTCビットを使って後続パケットがあることを示せる。応答側が最初の断片だけを見て即座に回答すると、次の断片に同じレコードが含まれ、不要な応答になるかもしれない。

そのため応答側は、TC付き問い合わせを受けると400から500ミリ秒のランダムな時間を待ち、後続の既知回答を集める。後のパケットで一致レコードが十分なTTLとともに届けば、予定していた回答を取り消せる。

ただし、同じレコードを待つ別の問い合わせ側がいるなら、取り消してはならない。抑制は一人の質問者のキャッシュ状態に基づく局所的な判断であり、同じリンク上の全参加者の必要を消去する投票ではない。

仕様は、TC付きパケットが途切れず続けば応答が理論上長く遅れる可能性も認めている。ここでRFCは、過負荷時の容量保護を即時性より優先する。これは「沈黙は常に成功」という意味ではなく、遅延と負荷のどちらを選んだかを示す設計判断である。

キャッシュ自身も時間を説明する

アクティブなクライアントがレコードを使い続ける場合、RFCは有効期間の80、85、90、95パーセント付近で再確認を試み、各時点に2パーセントのジッターを加える。100パーセントまで新しい回答がなければ、レコードを削除する。

アクティブな利用者がいないレコードを、単にキャッシュに残すためだけに更新してはならない。この差は重要だ。利用中の状態を維持するための通信と、関心のない過去を無期限に延命する通信は同じではない。

Known-Answer Suppressionと能動更新は、同じ時間軸を異なる側から使う。前者は寿命の前半に重複を減らし、後者は実際の関心が続くときに期限切れ前の確認機会を作る。どちらも最終的な失効を消さない。

監視で見るべきなのは総パケット数だけではない。80、85、90、95パーセントの再確認があったか、半TTLを下回った時点で回答が戻ったか、100パーセントで削除されたかを追わなければ、少ない通信が効率なのか壊れた更新なのか分からない。

DNS-SDとの関係

RFC 6763のDNS-Based Service Discoveryは、PTR、SRV、TXTなどDNSの既存レコードを組み合わせ、利用可能なサービスの列挙と接続情報の取得を行う。mDNSはローカルリンクでそのレコードを運ぶ代表的な手段だが、二つの文書の役割は同一ではない。

サービスブラウザーは、一覧を開いている間、新しいインスタンスに関心を持ち続ける。だから継続問い合わせと既知回答抑制が実用上結び付く。既知のプリンターを毎回再送せず、まだ知らないプリンターには発言の余地を残す。

一方で、発見できたことは接続の認証や利用権限を証明しない。サービス名が表示され、SRVとTXTが得られても、その先の通信が安全か、利用者が権限を持つかは別の制御面で判断すべきである。

実装は仕様の約束を検証可能にする

Appleが公開するmDNSResponderのリポジトリは、DNS Service Discovery用のデーモン、ツール、ライブラリを示している。READMEは、デーモンが5353番ポートのマルチキャストを監視し、.local.をmDNSで解決することなどを説明する。

これは実装を調べられる入口があることを示す。すべてのOS版、機器、ベンダー派生、無線最適化、VLAN越境、プロキシ構成が半TTL規則を正しく実行すると証明するものではない。

Stuart Cheshireを仕様だけの人物として扱うと、この点を見落とす。彼の公開プロフィールは多数のRFCへの関与を示し、公開実装は仕様が稼働面を持つことを示す。しかし現在のリンクで正しい沈黙が起きたかは、実際のパケット、コード、設定、インターフェースの観測でしか確かめられない。

Running-Code Primacyは、標準を軽視する考えではない。標準が定めた最小の相互運用条件を、運用中のコードが本当に満たすか問い直す姿勢である。画面にサービス一覧が出たことだけでは、抑制と更新と失効の連鎖は証明されない。

人物への帰属も範囲を越えない

RFC 6762とRFC 6763はいずれも、Stuart CheshireをMarc Krochmalより先に著者として記載する。これにより、CheshireがmDNSとDNS-SDの標準化に深く関与したことは確認できる。

2026年8月30日に確認したIETF Datatrackerの人物ページは、28件のRFCとCongestion Control Working Groupの代表という現行の役割を掲載している。役割と件数は将来変わり得る。

そこから、個人が技術を単独発明した、製品を所有する、すべての実装を支配する、各組織のローカルリンクに責任を負う、という結論は導けない。著者欄は貢献の証拠であって、無制限の権限証書ではない。

この帰属の節度は、Known-Answer Suppressionの設計と似ている。記録された事実には必要な効力を与えるが、それが証明していない範囲まで権威を拡張しない。

出典