要約

  • RFC 9567では、権威応答がEDNSのReport-Channelを要求なしに載せ、監視エージェントのドメインを告知できる。対応する検証リゾルバーは、自ら観測したExtended DNS Errorを別のTXT問い合わせへ変換する。元の応答が修正されるわけではない。
  • 報告リゾルバーとエージェントの間にエンドツーエンド認証はない。TCPやDNS Cookieは送信元アドレスの偽装を難しくするが、診断の正しさは証明せず、キャッシュや名前長も到達する報告を左右する。

一台の権威サーバーが、期限切れのRRSIGを含むゾーンを配っているとする。サーバーから見れば、問い合わせを受け、RRsetを返す処理は完了している。異常が現れるのは、別の場所にいる検証リゾルバーが署名を検査した後だ。修復できる者と、失敗を最初に確定できる者が離れている。

RFC 9567は、この断絶に小さな帰路を設ける。権威応答はEDNSオプション18、Report-Channelに完全修飾されたエージェントドメインを入れられる。このオプションは問い合わせ側から要求されない。問い合わせに入れてはならず、権威側が一方的に「報告するならここへ」と示す。

機能を実装し、報告を有効にしたリゾルバーが失敗をExtended DNS Errorとして分類すると、別のDNS問い合わせを作る。broken.testのAレコードをEDE 7で拒否した例なら、_er.1.broken.test.7._er.a01.agent-domain.exampleというQNAMEでTXTを問う。失敗した型、名前、診断コードは問い合わせ名そのものにある。

報告は、失敗した応答を送り返して訂正を求める仕組みではない。新しい名前を別の権威へ解決する通常のDNS取引である。RFC 9567はTXTのRDATAに意味を定めない。肯定応答は、問い合わせを終え、TTLによって同じ報告の連打を抑えるために使われる。

返送先を選ぶ者と、異常を認定する者

元の権威運用者はエージェントドメインを選ぶ。リゾルバーは検証を実行し、EDEを選び、報告方針を適用する。監視エージェントは受信した問い合わせの由来を評価し、重複をまとめる。ゾーン運用者は署名や委任を変更する。Report-Channelは、この四者を一つの指揮系統にはしない。

IANAのDNS Parametersは、18がReport-Channelであり、TXT用の_erが登録済みであることを示す。これはコード点の衝突を防ぐ証拠であって、実装、設定、到達、修復の証拠ではない。

EDEにも境界がある。RFC 8914は、追加情報がRCODEの処理を変えないと定める。RFC 9567は、何をエラーとするかを一律に決めず、全リゾルバーに全コードを実装させない。報告が表すのは「このリゾルバーが、この名前と型にこのコードを付けた」という観測である。

DNSSEC検証では、期限切れ署名やDSとDNSKEYの不一致を独立に再現できる場合がある。一方、古いローカルトラストアンカーが原因なら、誤っているのは報告側かもしれない。エージェントは報告をゾーンの自白として扱わず、別の視点から検証鎖を組み直さなければならない。

QNAMEに収めた障害記録

報告名は、先頭の_er、十進表記のQTYPE、失敗したQNAME、十進表記のEDEコード、二つ目の_er、エージェントドメインで構成される。通常のRCODEとDNSクラスは含まれない。先頭の印は、QNAME minimisationの途中で見えた短い名前ではなく完全な報告であることを示す。後ろの印は、障害部分と返送先を分ける。

DNS名の255オクテット上限を超える報告は送ってはならない。さらに、エージェント名の解決そのものが失敗して別の報告を生む可能性があるため、リゾルバーは深さまたは費用を制限する。報告一件を捨てるほうが、障害を自己増殖させるより安全だ。

エージェントドメインは、報告対象ドメインの配下に置いてはならない。同じ故障が帰路まで壊すからである。短いエージェント名は、元の長いQNAMEを収める余裕も増やす。命名位置は運用品質を左右する。

到達可能性と診断の真実は別の証拠

RFC 9567には、報告リゾルバーを監視エージェントへ認証する規定がない。UDPの送信元は偽装でき、実在する送信元でも判断を誤り得る。そこで、DNS Cookie、DNS over TCP、または別のコネクション指向トランスポートが推奨される。CookieのないUDPを受けたエージェントはTCを返し、TCPでの再問い合わせを求める。

これらが強めるのは、送信元アドレスへ返送できるという確信である。組織の身元、トラストアンカーの鮮度、EDEの正しさまでは証明しない。既知の大規模リゾルバーなら重みを上げてもよいが、その問い合わせにゾーン変更権限を与えてはならない。

自動処理は段階化できる。CookieなしUDPは観測を作る。CookieまたはTCPの往復は優先度を上げる。独立した複数リゾルバーと再現可能な検証失敗がそろって初めて、インシデントになる。ゾーン変更には、さらに所有者の承認とロールバックが必要だ。

キャッシュは負荷を減らし、観測も減らす

エージェントは肯定的なTXT応答を返すことが推奨される。そのTTLにより、同じリゾルバーは同一問題を毎回報告しない。軽量さはこの抑制で得られるが、受信件数を利用者数や失敗回数へ換算できなくなる。

NXDOMAINは危険である。RFC 8020の下位名への効力と、RFC 2308の否定キャッシュが組み合わさると、異なる報告名まで止める。監視対象にはNXDOMAINを返してはならず、肯定的なワイルドカードが一つの実装方法になる。

エージェントゾーンを署名すると、RFC 8198に基づき、検証済みNSECまたはNSEC3から後続の否定応答がローカル合成される場合がある。問い合わせはエージェントに届かない。RFC 9567は、この負担を避けるため未署名のエージェントドメインを選ぶ案を示すが、リゾルバーは通常どおり応答を検証し、実際には署名済みの被害ドメインを未署名と決めつけてはならない。

報告が止まった理由は一つではない。修復、TTL、否定合成、エージェント停止、機能無効化、濫用対策のいずれでも沈黙は起こる。回復の証拠は、独立した検証が再び成功することだ。

フィードバック先は攻撃先にもなり得る

報告QNAMEは、失敗した名前、型、EDEコードをエージェントへ開示する。古いローカルトラストアンカーのようなリゾルバー側の誤りも見える。QNAME minimisationは途中の権威への開示を減らすが、最終エージェントには完全な報告が届く。

攻撃者は意図的に壊れたゾーンを作り、無関係な被害者をエージェントドメインに指定できる。オープンリゾルバーや世界規模の測定点が、被害者へ追加問い合わせを送る。大量の偽報告で本当の障害を埋めることもできる。レート制限、送信元の段階評価、対象ゾーンとの関係確認、外部からの再検証が不可欠だ。

TXT応答も信頼入力ではない。内容は標準化されておらず、ログへ保存するなら悪意ある文字列として扱う必要がある。固定値を返し、QNAMEの定められたラベルだけを解析するほうが安全である。

Heng Luが区別する稼働コード、最小仕様と局所的決定、現実の層は、この帰路の読み違いを防ぐ。RFCは宛先と文法を定める。権威が告知し、リゾルバーが観測し、ネットワークが運び、エージェントが評価し、ゾーン運用者が直す。利用者の検証成功は、その後に測る別の事実だ。

監査では、元応答、DNSSEC状態、告知されたドメイン、生成した報告名、破棄理由、トランスポートとCookie、エージェント応答とTTL、独立再現、変更内容、変更後の検証を別々に残す。新しい問い合わせは有力な手掛かりになれるが、最終判定にはなれない。