要約

  • Structured Error Data for Filtered DNS 第27版はRFC Editor Queueにある。Extended DNS ErrorのEXTRA-TEXTをI-JSONで構造化する提案だが、まだ番号付きRFCではなく、最終コード値も割り当て前である。
  • 認証済みDoT、DoH、DoQが守るのはクライアントと選択済みリゾルバの間である。上流の方針作成者、法的根拠、分類の正確さ、アプリケーションの処置までは証明しない。

読みやすさが権限の空白を隠す

冒頭は分析のために組み立てた場面であり、公表済みの事故ではない。構造化されたエラーには大きな利点がある。利用者は、突然のNXDOMAINや空の応答だけでなく、なぜフィルタリングされたのか、どの窓口に誤判定を申し立てられるのかを知り得る。一方、きれいに並んだ項目は、説明の形式と説明者の権限を混同させやすい。

IETF Datatrackerでは、draft-ietf-dnsop-structured-dns-error-27は2026年7月30日付、8月19日更新で、IESG状態はRFC Ed Queueとされる。目標はProposed Standardで、RFC Editorは編集担当の割り当て待ちである。草案には将来のRFC番号とIANA値の置換箇所が残る。したがって、最終コード、普遍的な実装、展開済みの挙動を前提にしてはならない。

RFC 8914は、Blocked、Filtered、Censored、Forged AnswerなどのExtended DNS Errorを定義している。ただし従来の追加テキストは人間向け診断であり、安定した自動処理の形式ではなかった。新草案では、クライアントが長さゼロのSDE EDNSオプションを問い合わせに入れ、EDEのEXTRA-TEXTにあるI-JSONを理解できると通知する。

定義される情報は小さい。cは誤判定を報告する連絡先、jは人間向け理由、sは登録済みサブエラー整数、oは組織名、lは言語である。項目を分ければ表示や記録は容易になる。しかし組織名は本人確認ではなく、理由文は事実認定ではなく、登録番号は個別判断の正確さを保証しない。

形式への対応表明はフィルターへの同意ではない

SDEオプション自体にはデータがない。クライアントが構造化形式を処理できるという能力表明にすぎず、フィルタリング方針への同意、特定事業者への信頼、連絡先への自動接続を意味しない。ローカル方針は送信しない選択もできる。

サーバはフィルタリング時に、空の回答、NXDOMAIN、あるいは望ましくない偽アドレスを返せる。SDEが提示され、関連EDEを返す場合、設定で抑止されない限り構造化詳細を添えるべきだとされる。草案はNetwork Operator PolicyとDNS Operator Policyを分け、さらに上流DNSサーバによるブロックを示す未割り当てコードを提案する。

この分離は、最終リゾルバだけに原因を押しつけないために役立つ。しかしオンライン上の分類名は委任状ではない。「ネットワーク運用者の方針」という値から、誰が承認したか、雇用契約や学校規則が端末に適用されるか、公的命令が有効か、評判データが最新かは分からない。

sの整数も限定された証拠である。IANA登録により実装間の意味は揃うが、「マルウェア」というコードが、現在の対象に悪性内容があることを実証するわけではない。分類元、観測時刻、根拠、範囲、再評価方法を別に確かめる必要がある。

暗号化は接続の終端までしか届かない

草案は、暗号化されていない応答の追加テキストに基づく行動を禁じる。経路上の攻撃者が書き換えられるからである。暗号化されていても、リゾルバ本人を認証できなければ、利用者を誘導し得るc、j、oは無視しなければならない。列挙値のsは、より狭い条件で処理できる。

認証済みDoT、DoH、DoQは強い証拠を与える。クライアントは意図したリゾルバと話し、その接続中に応答が改変されていないと確認できる。だが、その証明は上流リゾルバの発言、転送器による忠実な保持、記載組織の制度的権限まで遡らない。

EDEはホップ単位である。転送器は上流情報を渡すことも、削ることも、新しいJSONを作ることもできる。どの方式を採るかは実装と運用方針に依存する。最後のTLS接続が完全でも、上流経路が無保護だったり、最終リゾルバが短いコードから独自説明を生成したりし得る。

これは暗号の欠陥ではなく、来歴の境界である。監査可能性が必要なら、DNS応答以外に、選択リゾルバ、上流設定、転送方式、方針版、分類データ源、生成時刻、訂正履歴を残すべきだ。それらがなければ確認できるのは「最後のリゾルバがこう述べた」ことまでである。

古い転送器はさらに危険だ。EDEを理解しなくても、攻撃者が注入したEXTRA-TEXTをそのまま運ぶ場合がある。草案は明示設定したDNSサーバだけから処理する方法や、RFC 9606のリゾルバ情報を使う方法を挙げる。信頼を生むのは設定と検証であり、JSONらしい外観ではない。

問い合わせ先が第二の攻撃面になる

連絡先は誤判定を直すためにある。悪意あるリゾルバは、それを攻撃者の窓口に向け、個人情報の提出や偽の修復手段を促せる。自由記述の理由や組織名は、単なる数値より強く利用者を説得する。

そのため表示権限はクライアント方針に置かれる。連絡先は、管理設定や組み込みリストでリゾルバに十分な評判がある場合に限って検討する。jは、セキュリティ実施やDNS動作を変える自動処理への入力にしてはならない。oはリンクではなく平文で表示し、信頼済み登録名との一致や適切な検査がない場合は見せない。

組織信頼リストの作成と更新は草案の範囲外である。これは重要な節度だ。世界共通のレジストリは、企業、学校、家庭、ISP、公的機関のどれが特定利用者を拘束できるか決定できない。誤ブロックや中断の損失を負う主体が、その関係を管理し、失効手順を持たなければならない。

エラー由来URIへの自動接続も禁止される。許可スキームを狭くすれば、密かな報告、反射、罠を減らせるが、相手の誠実さまでは保証しない。安全な画面は、検証済みリゾルバ、制御されたコード説明、独立設定した支援経路を優先し、未検証の自由文を主要操作から遠ざける。

短いTTLは再質問を早めるだけである

評判や分類は変わる。草案は、訂正を素早く反映するため十秒程度の短いTTLを許容し、変化が少ない場合は三十から六十秒で負荷との均衡を取る考えを示す。しかしキャッシュ期限が切れても、上流の分類元、転送器、全クライアントが訂正済みとは限らない。

DNSキャッシュ、分類フィード更新、方針の承認・撤回、異議申立て処理、端末での初回回復観測は別々の時計である。上流リストが一時間ごと、申立てが数日ごとなら、十秒TTLは全体を十秒で直さない。

訂正の証拠には、問い合わせ名と型、リゾルバ本人、EDEとサブエラー、見える上流、正負TTL、分類版、申立て受領、決定責任者、回復を確認した時刻が必要だ。一度だけ正常応答を見ても、すべての経路の収束は証明できない。

プライバシーも独立した責任である。構造化情報は、フィルタリング組織、内部方針、利用者が探したドメインを明らかにし得る。利用者の認識なしに第三者へ送信・記録してはならない。暗号化DNSで経路から隠した問い合わせを、遠隔分析基盤へ全件送れば、透明性の名で再び露出させることになる。

説明は判断材料であり、最終命令ではない

リゾルバを認証し、安全に使える項目を選んだ後も、アプリケーションには選択が残る。限定説明の表示、ローカル記録、設定済み窓口への案内、TTL後の再試行、許可された別解決経路、現在操作の停止、担当者への上申である。家庭、企業、公共網、重要機器では誤判定の費用が違う。

共通層は狭く保つべきだ。能力表明、項目、登録値、処理順、通信要件、安全上の禁止を共有する。リゾルバの発言を法的判断に変えたり、不可逆なローカル処置を代行したりしてはならない。

本当に問うべきなのは、誰がリゾルバを選び、誰が方針を採用し、誰が分類を供給し、誰が訂正し、誰が結果を引き受けるかである。構造化DNSエラーは、その責任線を見つけやすくする道具である。責任線を消したままなら、未検証の主張に読みやすい権威を与えるだけになる。

Sources