要約

  • RFC 8914のExtended DNS ErrorはEDNS option 15で、16-bit INFO-CODEと任意のUTF-8 EXTRA-TEXTを運ぶ。base RCODEを置き換えず、受信者は従来のRCODE処理を続け、EDEに従う義務もない。
  • EDEは一つのresolverやforwarderが述べる診断であり、end-to-endの因果証明ではない。中継者はoptionを落とすことも作り直すこともでき、UDP size不足では説明が先に削除される。
  • 安全な運用はcode名ではなくprovenanceを保存する。raw bytes、発生hop、RCODE、DNSSEC validation、cache、upstream試行、policy rule、retry、最終的な独立確認を結ばなければならない。

正確な語彙が生む、過剰な確信

従来のSERVFAILは情報が少なすぎた。validatorがsignature expiryを見たのか、authorityへ到達できなかったのか、local policyがanswerを止めたのか、clientには区別しにくい。EDEはこの不足を埋める。

しかし、読みやすさには副作用がある。「DNSSEC Bogus」という表示は、画面上では原因確定のように見える。実際には、手元のresolverがそう判断したという記録にすぎない。時計のずれ、stale cache、異なるtrust anchor、middlebox、壊れたforwarder、別anycast siteの経路差まで除外したとは限らない。

診断は調査を始める権限を持つ。単独でDNSSECを無効化し、別answerを受理し、弱いresolverへ恒久移行し、operatorを公に非難する権限は持たない。この線をpolicyに書かないと、便利なlabelが安全判断を代行する。

Wire formatが約束すること

RFC 8914はEDEをEDNS option code 15として定義する。先頭2 octetのINFO-CODEの後ろに、人が読むためのUTF-8 EXTRA-TEXTを置ける。textは機械的なcontrol inputとしてparseすべきではない。一つのresponseに複数のEDEを入れられ、NOERRORを含むどのRCODEとも組み合わせられる。

重要なのは、base RCODEが主契約のままだという点である。receiverはEDEがあっても通常どおりRCODEを処理する。optionを認識すること、画面に出すこと、logへ保存すること、動作を変えることは別々のlocal decisionである。

IANA registryはcodeを共有語彙にする。RFC 8914が最初に定義した0から24にはDNSSEC failure、stale answer、forged、blocked、censored、filtered、prohibited、network error、authority到達不能などが含まれる。その後の登録は増えている。番号の登録は相互運用のための名前付けであり、そのresponseの分類が正しいという認証ではない。

Hopごとに変わる説明

現実のpathはstubからrecursive resolverへ直結するとは限らない。enterprise forwarder、security filter、service mesh、public resolverを経てauthorityへ至る。RFC 8914ではforwarderが上流EDEを捨ててもよく、自分の処理に基づくEDEを作ってもよい。上流情報を伝えるなら、textでsourceを示すことが望ましい。

この自由はdeployabilityに必要だが、provenanceを曖昧にする。dashboardに最後のcodeだけ残すと、どのprocessが何を直接観測し、何を継承したか消える。最低限、emitter endpoint、software version、node、transport、upstream attemptとpolicy ruleをcodeに結ぶ必要がある。

DNS over an authenticated or encrypted hopは、そのhopで誰と話したかを強くできる。だがpeerが遠方のauthoritative failureを正しく説明した証拠にはならない。普通のUDP/TCPではon-path変更も可能である。channel integrityとdiagnostic truthを同一視してはいけない。

EDEが消える条件も証拠に含める

RFC 6891のEDNSはoption spaceを提供するが、UDP responseにはsize limitがある。RFC 8914では収まらない場合、まずEXTRA-TEXT、次にEDE optionを削り、それでも大きければTCを使う。つまり混雑や大きなDNSSEC responseほど、説明だけが先に消えることがある。

EDEが無いことは診断が無かった証明にならず、EDEがあることも全hopが同じ説明を見た証明にならない。canaryはoption無し、単一・複数code、順序反転、unknown/private code、empty/long text、invalid UTF-8、UDP削除、TCP retry、forwarderのpreserve/drop/recreateを含めるべきだ。

Human-readable textを信用境界の外に置く

EXTRA-TEXTはticketを速くする反面、account identifier、非公開blocklist、customer名、internal address、policy detailを漏らし得る。control characterやbidi sequenceを含むuntrusted inputでもある。RFC 8914自身がprivacy riskを指摘する。

raw evidence storeにはbytesを改変せずアクセス制御付きで置く。analyst viewでは安全にdecodeし、public surfaceでは必要最小限へredactする。文字列からpolicy actionを生成せず、INFO-CODEもそのまま特権入力にしない。保存期間はdiagnostic needに合わせる。

Running codeはEDEをlocal policyへ接続している

UnboundはEDE、serve-expired用の説明、RFC 9567のDNS Error Reportingを設定できる。BINDのRPZはforged、blocked、censored、filtered、prohibitedなどのEDEをpolicy responseへ付けられる。PowerDNS Recursorもextended resolution errorsを送り、Negative Trust Anchorに診断を添えられる。

この実装差はprotocolの弱点ではない。minimum specificationを保ち、将来のdecisionを各運用者へ残す設計である。ただし同じcodeがどのtriggerから出るかはproduct、version、configurationで異なる。RFCの表だけを見た監査ではrunning codeの権限を把握できない。

RFC 8767のstale dataでも同じ分離が要る。EDEはなぜstale answerかを知らせるが、何秒までserveするか、いつ打ち切るか、どのnameを除外するかはlocal policyである。説明がpermissionを作るわけではない。

Resolver情報とerror reportの二つの増幅面

RFC 9606のRESINFOはexterrでsupportするEDE codeを広告できる。capability discoveryには便利だが、anycast nodeやsoftware versionに差があれば広告と実動作がずれる。clientがその情報をどう使うかはlocal selection policyに残される。

RFC 9567はQTYPE、QNAME、EDEを新しいqueryへencodeし、authoritative operatorへvalidation failureを報告できる。早期発見を助ける一方、recursive reporting、traffic cost、privacy riskを作るため、depthとexpenseを制限する必要がある。report channelにはmutual authenticationがなく、TCPやDNS Cookiesでsource confidenceを上げても内容の真実性までは証明しない。

EDEの強みは薄い共通層にある。共通codeとprocessing ruleを共有し、表示、retention、alert、report、fallbackはlocal riskに合わせる。そしてpacket canaryと実測で、想定した構成が本当に動いているか確認する。

参考資料