要約

  • DNS Push では、サーバーが変更通知を届ける責務を引き受けている間、クライアントは対象レコードの TTL を減らさない。その責務は一つの DSO セッション内の受理済み購読に限定される。
  • 接続が閉じれば購読はすべて終わる。TLS の暗号状態を再開できても、DNS Push の状態は新しいセッションに継承されず、改めて SUBSCRIBE と初期状態を取得する必要がある。
  • 「現在の値」という判断は、探索、TLS 認証、DSO、購読応答、PUSH の追加・削除、TTL の停止・再開、実サービス確認を結ぶ証拠があって初めて成立する。

二つの台帳が食い違う瞬間

実在障害ではない、検証用の例を考える。クライアントがサービス探索用 SRV RRset を購読し、TTL 120 秒の宛先を初回 PUSH で得る。購読中は TTL が減らないため、十分後もキャッシュには 120 秒が保存されている。運用者がその宛先を削除した直後、経路上の装置が長時間接続を切る。

クライアントは TLS を素早く再開する。接続台帳には「暗号化済み、相手確認済み」と記録される。ところが購読台帳には新しい SUBSCRIBE 応答がない。以前のサーバーが負っていた削除通知の責務は、古い DSO セッションと共に消えている。それでも TTL を停止したままにすれば、120 秒の公開値をクライアントが無期限の権限へ書き換えたことになる。

RFC 8765 はこの混同を認めない。TLS 接続の終了は DSO セッションを終わらせる。TLS session resumption の後、サーバーは購読状態を持たず、必要な購読をクライアントが再作成する。再開できるのは暗号上の関係であって、変更を届ける契約ではない。

TTL が減らなくなる理由

通常の DNS キャッシュでは、権威側が TTL を付け、キャッシュが時間を減算し、ゼロになれば新鮮な情報としては使わない。更新頻度の高い RRset を短い間隔で問い合わせれば変化を早く見つけられる一方、変更がない時にも recursive と authoritative の双方へ負荷をかける。

DNS Push は問い合わせ回数の代わりに状態を保持する。SUBSCRIBE は一つの NAME、TYPE、CLASS を指定し、サーバーは購読ごとに受理または拒否する。受理時点の回答集合が空でなければ、応答の直後に初回 PUSH が送られる。その後は追加と削除が TLS/TCP の順序付きストリームで非同期に届く。

この責務があるため、追加レコードの TTL は保存しても購読中は減らさない。TTL 自体が変われば更新が届き、レコードが消えれば削除が届くと期待できるからだ。TTL が延長されたわけではない。鮮度の証明方法が、残り時間から生きた通知責務へ移った。

UNSUBSCRIBE は一つの購読を終わらせ、DSO の終了は全購読を終わらせる。その時点から保存 TTL の減算を再開し、ゼロで消す。監査では、この時計を止めたイベントと動かしたイベントが同じ重要度を持つ。

探索、暗号、DSO、購読

最初の依頼先は通常、設定済み recursive resolver の TCP 853 番ポートである。resolver が購読を扱えるなら、上流の購読を代理で保持して結果を中継できる。扱えない場合には _dns-push-tls._tcp.<zone> の探索が関わる。どちらの経路でも、探索応答と TTL、検証状態、観測地点を残す必要がある。

DNS Push には Strict Privacy が要求される。しかし TLS は選ばれた名前と資格情報に対するチャネルの性質を示すにすぎない。SRV が改ざんされれば、誤った名前の正しい証明書を持つ相手へ安全に接続することもあり得る。DNSSEC の結果、target、SNI、証明書または TLSA、実際の peer を一つの「TLS OK」に潰してはならない。

接続後、Keepalive か SUBSCRIBE によって DSO が成立する。SUBSCRIBE は非ゼロの MESSAGE ID を持ち、応答 RCODE がその購読の成否を決める。DSO に対応していても Push に非対応なら DSOTYPENI になり得る。対象名の権威を持たなければ NOTAUTH、上流に到達できなければ SERVFAIL、容量がなければ拒否という判断もある。

この構造は権限を小さくする。接続の存在は購読を作らず、購読の受理は非空データを保証せず、非空の初期状態はサービスの動作を保証しない。それぞれ別の証拠である。

変更レコードはどの範囲で有効か

PUSH はサーバーからの一方向メッセージで、MESSAGE ID はゼロ、クライアント応答はない。通常範囲の TTL は追加、0xFFFFFFFF は個別 RR の削除、0xFFFFFFFE は RDATA を空にした集合削除を表す。TYPE と CLASS により削除範囲が変わる。

クライアントは各変更が同じセッション上の現在有効な購読に一致するか検証しなければならない。UNSUBSCRIBE と入れ違いに到着した PUSH は、一致する購読が既になければ無視できる。この race を許容する設計だからこそ、変更単体では監査証拠にならない。受信時のセッションと購読状態が必要である。

また、PUSH の MESSAGE ID ゼロはシーケンス番号ではない。一つのメッセージに複数購読の変更をまとめることもできる。TCP が保証するのは一つの接続内の順序だけであり、切断前後をまたぐ連続性ではない。新接続で「続きから受け取った」と推測せず、新規購読の初期状態で再同期するのが正しい。

空集合にも注意が要る。受理時に回答が空なら、空を表す偽 RR を送る必要はない。成功応答の後に初回 PUSH がないことは、「購読は有効だが現在値は空」と両立する。メッセージ数だけを見れば、この正常状態を障害と誤認する。

Keepalive と RECONFIRM の限界

DSO の inactivity timeout は、使われていないセッションの保持コストを制御する。keepalive interval は middlebox の状態と相互到達性を保つ。購読が存在するセッションは、更新が長く来なくても idle とは扱われないが、経路確認の Keepalive は続く。

Keepalive 成功が証明するのは接続可能性である。上流購読が維持されていること、削除が一件も欠けていないこと、クライアントのキャッシュ適用が正しいこと、SRV の宛先が稼働していることは証明しない。運用画面でこれらを同じ緑色にまとめると、障害箇所を逆に隠す。

RECONFIRM は Discovery Proxy で特に意味を持つ。到達しないサービスをクライアントが疑うと、proxy が multicast DNS を再確認し、消失が分かれば関係クライアントへ削除 PUSH を送れる。一方、他の DNS server では動作が未定義で、NOERROR でも何もしない場合がある。「再確認済み」という表示は応答コードだけでは作れない。

TLS 0-RTT と購読の再作成

SUBSCRIBE は TLS early data で送れる。レイテンシ削減には役立つが、0-RTT は接続間の一般的な replay 防止を保証せず、同じ要求が別の接続で短命な状態を作る可能性がある。したがって early data の送信を購読受理と同一視せず、実際の DSO セッションで成功応答を受けてから TTL 停止を許可する。

復旧 runbook は状態を順に記録する。古い DSO 終了、TTL 減算再開、新 TCP/TLS、handshake 種別、新 DSO、必要な SUBSCRIBE 全件、各応答、非空なら新初期 PUSH、そして TTL 停止再開である。この列の途中で「復旧」と宣言しない。

購読が作れない時は conventional DNS polling に切り替える。RFC 8765 は、同一 NAME/TYPE/CLASS の再問い合わせを 900 秒または TTL+2 秒の短い方より早く行わず、各 poll 前に Push を再試行するよう勧める。これは負荷制御であって瞬時の鮮度保証ではない。UI は polling の最終時刻と遅延窓を表示すべきだ。

証拠を六つの面に分ける

探索面には QNAME、回答、TTL、DNSSEC、resolver と vantage。TLS 面には target、SNI、peer、証明書/TLSA、full/resumed。DSO 面には開始・終了、Keepalive、inactivity、Retry Delay。購読面には MESSAGE ID、NAME、TYPE、CLASS、要求 bytes、RCODE、受理時刻。

キャッシュ面には PUSH の順序、追加・個別削除・集合削除、RR、保存 TTL、一致した購読、停止/再開した時計。サービス面には authoritative への直接 query と endpoint probe、さらにアプリケーションが行った処理を置く。

この分離により、「DNS は現在だがサービスは停止」「接続は有効だが購読はない」「購読は有効だが空集合」という異なる状態を正しく扱える。

Heng Lu の原則が示す分担

Minimum Initial Specification が担うのは、OPCODE、TLV、メッセージ役割、タイマー、認証、終了という相互運用の最小核である。世界共通の subscription budget やログ期間、health check を規定する必要はない。Localized Future Decision として、容量、再試行、保持、UI、fallback は現場の責任者が選ぶ。

Voluntary Adoption は、RFC と IANA 登録だけでは実装を証明しないという意味を持つ。実際の server admission、client resubscribe、fault injection と wire capture が採用の事実である。Running-code primacy も、実行結果を正当化する言葉ではない。購読が終わった後も TTL を止めるコードが動けば、その動作自体が修正すべき権限逸脱の証拠になる。

最終的な分担は明快だ。publisher が RRset を持ち、探索が候補を示し、TLS が限定されたチャネルを守り、DSO が session を持ち、server が購読を受理し、cache がその責務の間だけ時計を止め、application が別に実サービスを確認する。

出典