要約

  • RESINFOは、QNAME最小化、利用可能なExtended DNS Error、HTTPS診断ページを一つの権威的レコードで申告させる。
  • 認証済み接続またはローカルDNSSEC検証は第三者の偽造を防ぐが、申告された各動作の実施までは検証しない。
  • 評判、クライアントの選択規則、複数インスタンスの整合性、問い合わせ観測、サービス結果は独立した受領証である。

一つのADNから二つの説明が届いた

ある測定点では、認証済み暗号化DNSリゾルバが qnamemin を含むRESINFOを返した。別のネットワークから同じAuthentication Domain Nameへ問い合わせると、そのキーがない。どちらもRD=0、AA=1であり、レコード数は一つ、構文も正しい。

ここで一方を異常として消すと、任播という観測条件を失う。二つのクライアントは同じ名前を認証していても、異なるインスタンスへ経路制御された可能性がある。ロールアウトの途中かもしれない。さらに、どちらの自己申告も実際の権威問い合わせ列を示していない。

RFC 9606 は、共有ADNやanycastアドレスのインスタンスが一貫したRESINFOを示すべきだとする。同時に、暗号化リゾルバが不正確な情報を返し得ることも明記する。したがって、権威的な応答は議論の終点ではなく、比較可能な証拠の出発点になる。

誰が話したかを固める手順

DNRまたはDDRは暗号化リゾルバとADNを発見する。これは候補と認証名の対応を示すが、プライバシー機能や選択結果までは示さない。

クライアントはADNをQNAMEとしてRESINFOを問い合わせる。DDRが resolver.arpa を使う場合は、その特別名を使える。RESINFOはリゾルバ自身の属性なのでRDを0にし、AAが0の応答は破棄する。対応リゾルバのRRsetはちょうど一レコードであり、無効な形式は判断材料にしない。

偽造防止には、発見したリゾルバとの認証済み安全接続か、クライアント自身のDNSSEC検証が必要になる。ただし resolver.arpa には前者だけが適用できる。未対応リゾルバが問い合わせを上流へ渡すと、正規の別リゾルバや攻撃者から肯定応答が返る危険があるからだ。

これらは、応答者、権威形式、構文、転送中の完全性を確かめる。自己申告の意味内容を独立に監査したわけではない。

qnamemin の一語では再現できない

qnamemin は値を持たない存在型属性で、RFC 9156に基づき権威サーバへ送るプライバシー情報を最小化する設定を表す。しかしレコードには、試験名、キャッシュ状態、委任段階、例外、フォールバックがない。

実動作の確認では、管理できる名前空間を用意し、キャッシュ条件を明記し、委任階層ごとの権威側ログを見る。どのリゾルバ・時刻・経路が、各段階でどのラベルを送ったかを保存する。更新後にも同じ試験を繰り返す。

その観測は一回分の証拠にすぎないが、だから弱いのではない。範囲が正確なので強い。自己申告は構成意図、権威側の記録は実行された問い合わせを証言する。

exterr は理由の候補表である

exterr はリゾルバが返し得るExtended DNS Errorコードを列挙する。Blocked、Censored、Filteredがあれば、該当時に理由を説明できるという申告になる。毎回EDEが付くこと、フィルタ判断が正当であること、分類が正しいこと、アプリが表示することまでは含まれない。

RFC 9606 は差分確認の手順を持つ。未掲載のEDEを実際に受けたクライアントはRESINFOを再取得できる。差分が残れば、その自己申告を不正確として破棄できる。実行結果が清書済みの一覧を訂正する仕組みだ。

一方、掲載済みコードを観測しないだけでは結論が出ない。条件が発生していない、別インスタンスに到達した、段階配備中である、試験設計が不十分である可能性が残る。制御した問い合わせと応答、EDE、想定方針、時刻を一組で残す必要がある。

infourl は運用窓口にとどまる

infourl は一般説明や障害報告方法を示す。HTTPS以外は無効であり、RFCはIT担当者の診断用で、エンドユーザー向けではないと位置づける。

HTTPSは指定された情報サーバへの通信を守るが、文章の完全性、最新性、履行を保証しない。申告窓口の存在は解決実績ではなく、フィルタ方針の説明は実行ログではない。自動選択はページの存在を許可票として扱うべきではない。

レジストリは語彙を管理する

RESINFOのキーはIANAレジストリでSpecification Requiredにより調整され、temp- で始まる名前はローカル利用に残される。これにより、同じ概念を異なる私有ラベルで呼ぶ混乱を減らせる。

しかし登録は配備認証ではない。キーの定義、リゾルバの申告、暗号化された取得、観測された挙動、クライアントの選択は、それぞれ別の主体が持つ判断である。一つのIANA行が後続の権限を吸収してはならない。

評判を使うなら出所を記録する

選択時に直接検証できない属性について、RFC 9606 はローカル方針上十分な評判を持つリゾルバだけを対象にするよう勧める。評判はユーザー設定、管理者設定、組み込みリストなどから来る。

そこで必要なのは「評判あり」という無名の印ではない。誰が、どの範囲について、いつまで信頼したかを記録することだ。IANAは語彙を統一し、リゾルバは申告し、安全接続は話者を結び、クライアントが信頼の重みを決める。

Lu Hengの最小仕様とローカル判断の考え方は、この分業を支える。共通形式は比較の費用を下げるが、世界共通のリゾルバ順位表にはならない。動くコードと局所観測が、記号上の権威を現実へ戻す。

出典