要約

  • RFC 8005 の HIP RR は公開鍵である HI、そのハッシュ識別子 HIT、任意の RVS ドメイン名を格納する。これは発見情報であり、生存確認ではない。
  • DNSSEC の成功は DNS データの完全性と真正性を所定の検証連鎖で示し、TTL はキャッシュ再利用の期限を示す。RVS の現在の表や秘密鍵の使用を観測したものではない。
  • 到達性を判断するには、選択した RR、RVS の HIT―アドレス登録、I1 の中継、HI に基づく認証、HIP 関連付け、アプリケーション結果を接続する必要がある。

残り四十八分の「正常」

9 時、リゾルバーは移動ノードの HIP RR を取得した。期待した HI と HIT、RVS 名が入り、DNSSEC 検証は成功、TTL は一時間だった。監視画面はこれを「本人確認済み、到達可能」という一つの緑色表示にした。

9 時 12 分、ノードが別のネットワークへ移動する。新アドレスを RVS に伝える更新は失敗した。DNS の内容は依然として正しい。公開された会合先の名称は同じで、署名も有効、キャッシュも期限内である。9 時 20 分に I1 が送られると、RVS は古いアドレスへ転送した。

これは実在の障害を示す話ではなく、分析用の場面である。DNS は誤答していない。誤りは、公開内容の鮮度から動的な所在地まで推論した画面にある。「レコードが新しい」と「経路が新しい」は両立しない概念ではない。

RR にあるのは公開情報である

2008 年の RFC 5205 は Experimental として HIP DNS 拡張を定義した。2016 年の Standards Track 文書 RFC 8005 がこれを置き換えた。タイプ 55 の RR は、鍵対の公開部分である HI、そこから得る HIT、そして必要なら RVS 名を運ぶ。

HI を先に得ることは、応答側の識別情報を知らずに機会的交換へ入る危険を減らす。しかし DNS 応答には秘密鍵がなく、問い合わせ時点でその鍵を使えることを示す署名もない。

RFC 8005 は、DNS から取得した HIT だけを根拠に相手を認証すべきではなく、HI に基づく認証を使うべきだと述べる。HIT の発見と、現在のプロトコル交換で対応鍵を使った事実は別の段階である。

資産台帳が HIT の解決直後に authenticated を設定すれば、仕様が求める認証段階を消してしまう。秘密鍵が停止中でも、公表された公開情報は正常に残り得る。

DNSSEC は狭い主張を強くする

保護されていない HIP RR が改変されれば、公開鍵材料や I1 の送り先を置き換えられる。そこで RFC 8005 は完全性と真正性を備えた安全な経路を推奨し、DNSSEC を挙げる。

同時に範囲も明記する。DNSSEC が保証するのは、ゾーンを公開する DNS サーバーから HIP ノードまでのデータである。ゾーン公開者そのものが信頼に値するとは保証しない。HIP RRset の RRSIG を、所有者名と HI/HIT を結ぶ証明書と解釈してはならない。

したがって secure は強いが限定された結果である。信頼アンカー、アルゴリズム、時刻、検証方針、対象バイトとともに保存すべきだが、そこに端末の電源、秘密鍵保管庫、RVS 登録、IP 経路、アプリケーション状態を追加することはできない。

署名の強さは声明の幅ではない。狭い事実を確実に守ることと、あらゆる後続状態を保証することは違う。

TTL はキャッシュの時計である

RFC 8005 は、取得後の経過時間が HIP RR の TTL を超えたら無効として削除し、通信開始に必要なら新たに問い合わせるよう求める。これは DNS データの再利用規則である。

TTL はノードの稼働契約ではない。RVS の表領域を予約せず、ロケーターを固定せず、秘密鍵のオンライン状態も約束しない。期限まで十分快残っていても、実行系は変化できる。

期限後に再問い合わせして同じ署名済み RR を得ても、RVS の登録が古いままなら経路は直らない。新しい DNS 証拠が更新するのは DNS 層だけである。

TTL は手元で計算できるため、自動化はこれをサービス監視の代わりに使いたくなる。しかし cacheAge < ttl が示すのは「この DNS データを再利用できる」であり、「相手がオンラインである」ではない。

RVS 名と RVS 内部の登録は別物だ

移動ノードは比較的安定した RVS 名を DNS に載せ、現在の IP アドレスは別途 RVS に通知する。RFC 8004 の RVS は I1 を中継する前に、その時点の登録を調べる。

したがって RVS 名が正しく解決しても、対象 HIT の登録が失効している場合がある。サーバー自体が応答しても、表には古いロケーターしかないかもしれない。中継が行われても、終端が受信したとは限らない。

証拠は次の順序を保つべきである。

HIP RR 公開 → DNSSEC 検証 → TTL 内 → RVS 選択 → 登録有効 → I1 中継 → HI 認証 → 関連付け完了 → アプリ結果。

各矢印は権限と観測点をまたぐ。次の欄が未観測なら、前の緑をコピーせず「不明」とする。

複数 RR は組み合わせを保存させる

同一名に複数の HIP RR が存在でき、選択方法は RFC 8005 の範囲外である。RVS 情報が異なる場合もあり、利用する RVS が選んだ HI と関連していることを確認しなければならない。

HI 一覧と RVS 一覧を別々に抽出して直積を作れば、ゾーンが一度も公開していない組を生む。鍵更新中に新旧レコードが並ぶと、この誤りは特に見つけにくい。

運用記録は RR 単位で HI、HIT、RVS、アルゴリズム、TTL、応答指紋、選択理由を保持する必要がある。失敗時に「どの組を使ったか」を再現できなければ、原因はプロトコルではなく投影処理かもしれない。

到達性のための記録

最初に問い合わせ名、タイプ、リゾルバー、権威サーバー、時刻、パケット指紋を記録する。RRset 全体と組み合わせ、DNSSEC のアンカーと方針、取得時刻、キャッシュ年齢、TTL、期限後の再問い合わせを続ける。RVS の A/AAAA には別の TTL と検証結果がある。

実行側では、登録 ID、対象 HIT、ロケーター、更新、期限、取消し、設定世代を保存する。さらに I1 の送信、RVS 受信、表検索、中継、終端受信を関連付け、HI 認証の記録と双方の関連状態を残す。ペイロードとアプリケーション結果はさらに別の証拠である。

RFC 8005 は ECDSA 対応、TTL 後の再問い合わせ、複数 RR、複数 RVS の形式を明確化した。文書の発行は、稼働バイナリが移行した証明ではない。実装バージョン、ビルド、設定、実パケットが必要になる。

HIP RR の役割を限定しても、その価値は減らない。正しい画面なら「RR は安全、TTL 内、RVS 登録は未確認、到達性は不明」と表示する。単一の緑より地味だが、次に確認すべき場所を正しく示す。

出典