要約
- 従来の DNS RCODE は多様な原因を少数の結果へ圧縮する。RFC 8914 は EDNS オプション 15 に登録済み
INFO-CODEと任意のEXTRA-TEXTを収め、結果を増やさず診断を増やした。 - EDE は
SERVFAIL、NXDOMAIN、REFUSEDだけでなくNOERRORにも添付でき、複数個を同居させられる。それでもアプリケーションは元の RCODE の仕様に従い、EDE を新しい処理命令として扱ってはならない。 - 説明にも来歴が要る。フォワーダーは転送・抑止・再生成を選べ、パケットが大きすぎれば EDE は先に落とされる。自由文は機密を漏らし、保護されない診断は偽造され得る。
運用画面に二つの失敗が並んでいる。どちらの応答も SERVFAIL だ。一方ではすべての権威サーバーが沈黙している。もう一方では権威からデータを得たものの、検証リゾルバが成立すべき署名の鎖を構築できない。
最初の案件なら経路、権威の可用性、再送間隔を調べる。二番目なら鍵、DS、署名期間、時刻、欠けた DNSSEC レコードを調べる。二番目を非検証リゾルバへ回してアドレスが返っても、障害が直ったとは限らない。証明要件を外しただけかもしれない。
RCODE は両者を同じ失敗として正しく扱う。欠けていたのは、失敗を成功へ変えずに修理先を示す語彙だった。
小さな結果欄には多くの原因が入らなかった
RFC 1035 の応答ヘッダーは、成功、書式エラー、サーバー失敗、名前不存在、未対応、拒否といった大分類を共有した。この簡潔さにより、クライアントはサーバー内部の実装を知らなくても同じ第一判断を行える。
しかし SERVFAIL は、起動直後、権威到達不能、検証失敗、失敗キャッシュ、内部データ不良を区別しない。REFUSED も、権威ではない、クライアントに権限がない、運用ポリシーで止めた、といった枝を一つにする。
これは設計ミスというより役割分担である。RCODE は相互運用可能な結果であり、事故報告書ではない。内部原因をすべて基礎コードへ昇格させれば、古い実装と中継装置が無限に増える結果語彙を理解しなければならない。
必要だったのは、結果とは別に伸ばせる補助面だった。
OPT の中に診断だけを置いた
RFC 6891 の EDNS(0) は、OPT 擬似 RR とオプション番号空間を用意した。OPT は DNS メッセージに載るが、ゾーンが公開する通常の資源レコードではない。通信条件や追加情報を運ぶための外枠である。
2020 年の RFC 8914 は、Extended DNS Error に EDNS オプション番号 15 を割り当てた。内容の先頭は 16 ビットの INFO-CODE、続く部分は任意の UTF-8 EXTRA-TEXT である。
番号は IANA レジストリを参照し、機械が安定した分類として扱える。自由文は具体的な鍵や上流、運用事情を説明できるが、人が読むためのものだ。自動解析用の文法ではなく、末尾のゼロも仮定できない。長さはオプションの長さ欄から取る。
問い合わせに OPT があれば、EDE は SERVFAIL、NXDOMAIN、REFUSED、NOERROR など、どの応答種別にも入り得る。一つの応答に複数の EDE を置くこともできる。受信側は受け入れられなければならないが、すべてへ反応する義務はない。
そして RCODE の処理は変わらない。DNSSEC Bogus を伴う SERVFAIL は失敗のまま、Stale Answer を伴う NOERROR は答えを返すが、期限切れという来歴を持つ。説明は結果の生成条件を示し、結果そのものを再採決しない。
Bogus と Indeterminate は責任判定ではない
RFC 4035 は DNSSEC 検証に異なる状態を定める。Bogus は、信頼の鎖を作れるはずの RRset について、署名失敗や必要データ欠落により鎖を作れない状態である。攻撃を示す場合もあれば、設定ミスや破損の場合もある。
Indeterminate は別だ。必要な DNSSEC RR を取得できず、その RRset が署名されるべきかどうかを判断できない。証明に失敗した状態と、証明要件を確定できない状態は同じではない。
EDE は両者に別番号を与え、さらに未対応 DNSKEY アルゴリズム、未対応 DS ダイジェスト、期限切れ署名、まだ有効でない署名、DNSKEY・RRSIG・NSEC の欠落、Zone Key ビット欠落を区別した。
番号は修理の入口を狭めるが、犯人を決めない。親ゾーン、子ゾーン、レジストラ、時計、ソフトウェア、経路のいずれが原因かは追加証拠が必要だ。別の検証リゾルバは比較対象になるが、非検証リゾルバの成功は Bogus 判定を反証しない。
正常応答にも時間の警告を添えられた
再帰リゾルバが権威から新しいデータを得られないとき、期限を少し過ぎたキャッシュを障害よりましと判断することがある。RFC 8767 は、その stale serving を条件と時間の下へ置いた。EDE 3 は古い正答、EDE 19 は古い NXDOMAIN を示す。
この場合、応答は NOERROR でもよい。RCODE は今回返した結果を表し、EDE はその結果がどの時間状態から来たかを説明する。継続提供を選んでも TTL が巻き戻るわけではなく、権威が直近に内容を確認したことにもならない。
EDE 4 Forged Answer も、回答を返しつつポリシーで内容を変えた場合の説明である。回答そのものを返さない場合、Blocked はリゾルバ運営者の内部方針、Censored は外部から課された要件、Filtered はクライアントが依頼したフィルタを示す。Prohibited は許可されないクライアントへの拒否を注記できる。
これらは制度的な違いを可視化するが、法的根拠や分類の正しさを認証しない。コードを発した主体と通信の保護状態を失えば、ラベルだけが一人歩きする。
同じ失敗を何度も新しい証拠にしない
失敗のたびに権威探索を最初から行えば、停止中の上流へ負荷を集中させる。RFC 9520 は DNS 解決失敗を短くキャッシュする扱いを明確にした。
EDE 13 Cached Error は、今回の SERVFAIL が新しい探索ではなく失敗キャッシュから来たことを示す。権威データになるわけでも、元の障害が今も続くと証明するわけでもない。観測の出所を示すだけである。
この違いがなければ、千回のクライアント再試行が千回の独立した上流失敗に見える。実際には一度の失敗を同じキャッシュから千回読んだだけかもしれない。運用者は期限を待つ、別の制御されたリゾルバを見る、権威へ直接試験する、といった新しい証拠を作る行動を選べる。
フォワーダーは説明者の顔を変える
スタブの相手は通常、手元の再帰リゾルバだ。そのリゾルバが企業内フォワーダーや外部上流を使えば、最後に見える EDE の最初の作者は別の装置かもしれない。
RFC 8914 は中継を実装判断にした。受信 EDE を捨ててもよく、意味を渡してもよく、新しい EDE を生成してもよい。ただし上流の説明を渡すなら、クライアントからは直近リゾルバの発言に見えるため、EXTRA-TEXT で出所を示すべきだとする。
複数 EDE は層を残せる。上流検証失敗、本地失敗キャッシュ、出口ポリシーという三つの事情を一つの番号へ潰さずに済む。一方で、受信者が順序と出所を保存しなければ、原因の列は責任の列にならない。
自由文は出所を補えるが、安定した機械契約ではない。番号だけ転送し説明者を落とすと、診断は残って証言者だけが消える。
混雑したパケットでは説明が先に消える
長い EXTRA-TEXT は、依頼側が提示した UDP ペイロード上限を超えさせる。RFC 8914 は、サイズ超過時に他の応答データより先に EDE を落とし、落とした場合は truncation bit を立てるよう求める。
この優先順位は補助情報の立場を明瞭にする。診断は便利だが、答えと検証材料より優先されない。EDE がないから原因認識もなかった、とは推論できない。サイズ、中継方針、実装対応のいずれでも消える。
監視側は生成、受信、再生成、抑止、サイズによる除去を別々に記録する必要がある。詳しい文章を大量に添えるほど説明責任が高まるとは限らない。長文が原因で診断自体が最初に切り落とされることもある。
詳しい言葉にも認証は宿らない
「署名期限切れ」「外部要件による遮断」という文は、単なる SERVFAIL より確からしく見える。しかし具体性は暗号的な証明ではない。
RFC 8914 は、認証された DNS 取引または安全な DNS トランスポートがなければ EDE は未認証だと警告する。経路上で EDE を挿入できる攻撃者は、RCODE や通常の A・AAAA レコードも改変できるかもしれない。ゆえに EDE は診断にとどまり、DNS 処理を変えてはならない。
自由文には情報漏えいもある。アカウント番号、内部上流、ブロックリスト登録、利用者が知らなかったポリシーが露出し得る。説明は多ければよいのではなく、次の試験と担当面を選べる最小限であるべきだ。
IANA DNS Parameters はオプション 15 と拡張される INFO-CODE を記録する。そこから分かるのは番号と参照文書であり、導入率、転送忠実度、保護状況、画面表示、分類精度ではない。
EDE は失敗を強い命令へ変えなかった。結果と説明を別のまま運べるようにした。RCODE が処理を支配し、EDE が原因の手掛かりを持つ。この非対称こそ、可用性のために検証条件を捨てず、より速く修復するための境界だった。
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加
