要約

  • RFC 7646は、訓練を受けた技術者が攻撃ではなく設定不備だと確認した後、リゾルバー運用者が指定した枝のDNSSEC検証を停止できる仕組みを定めている。
  • この例外はローカルかつ一時的で、範囲を限定しなければならない。対象の応答は未署名ゾーンのものとして扱われ、ADビットは付かず、ゾーンの復旧後は速やかに検証へ戻す。

分析

DNSSECの下で、再帰リゾルバーは単なる問い合わせの中継点ではない。署名されたDNSデータから、設定済みの少なくとも一つのトラストアンカーまで認証の連鎖を組み立てる検証者になる。その結果はSecure、Insecure、Bogus、Indeterminateという状態で区別される。認証できたデータにはADビットを付けられる一方、自ら検証しないスタブに対してBogusなデータを通常の回答として渡すのではなく、一般には失敗として返す。

DNSSECが守るのはデータの出所と完全性であり、秘密性ではない。この保護は実際の執行点も作る。署名が正しければ、リゾルバーは利用者に検証済みという保証を与える。署名の期限切れ、委任の不整合、その他の検証不備が認証の連鎖を壊せば、同じ制御が回答を利用不能にする。署名済みゾーンを直す責任はゾーン運用者に残るが、障害はまずリゾルバーの利用者に現れる。

RFC 7646が定義するネガティブトラストアンカー（NTA）は、この局面に限って使う例外である。ある名前にNTAを設定すると、リゾルバーはその地点からDNSSEC検証を停止し、その枝の上流応答を未署名ゾーンからの応答のように扱う。ADビットも付けない。ゾーンの署名や委任は書き換わらず、壊れた設定も修復されない。変わるのは、ひとつの管理境界内にある再帰リゾルバーの方針である。

制御がどこにあるかは重要だ。通常のトラストアンカーが認証の起点を与えるのに対し、NTAはDNS上に別の事実を配布するものではない。必要とする組織がローカルに設定し、その管理境界の外へ配布することも想定されていない。同じ名前を同じ時刻に引いても、一方のリゾルバーは失敗を維持し、NTAを持つ別のリゾルバーは認証されていないデータを返し得る。差を生むのはゾーンではなく、リゾルバー側の例外である。

可用性の悪化だけでは、この例外を正当化できない。NTAを使う前に、訓練を受けた技術者が、原因は攻撃ではなく設定不備だと確認しなければならない。ドメインが意図的に壊された状態ではないことも確認し、ドメイン所有者への合理的な連絡も試みるべきだとされる。したがってNTAは、検証失敗を検知したソフトウェアが自動で選ぶフォールバックではない。

ここには明確な証拠の境界がある。RFCは仕組みと利用条件を示すが、個別の障害が無害な設定ミスだとは証明しない。凍結された情報源からは、特定のリゾルバー運用者が現在NTAを許可または利用しているか、どれほど停止時間を短縮できるか、ある本番環境で利用者が得る便益や負う危険がどの程度かも分からない。特定事案への適用は、追加の運用証拠に基づく別の判断である。

第二の制御は名前の範囲だ。例外は、壊れているドメインまたはサブドメインそのものに限定する。親の名前にまで引き上げたり、無関係な枝の検証を無効にしたりしてはならない。証拠が一つのサービス名しか裏付けないのに、上位の名前へNTAを置けば、認証なしで受け入れるDNSデータの集合が根拠以上に広がる。

第三の制御は時間である。NTAには有効期間を設定し、期限が来たら自動的に失効させなければならない。RFC 7646は、一週間を超えて維持すべきではないとしている。有効期間中も実装は定期的に検証を再試行し、検証が成功した時点で直ちに例外を削除するのが望ましい。削除時には対象ノード以下のキャッシュも消し、例外中に受け入れたデータを認証の復旧後まで残さないようにする。

これは「安全か可用性か」という抽象的な二者択一ではない。利用者とサービス責任者は、壊れた枝への到達性を取り戻せる。その代わり、例外が有効な間、その枝についてリゾルバーが提供していたDNSSEC保証を失う。対象外の正しく運用されているゾーンは引き続き検証されるべきだ。仕組みとしての交換条件は明確だが、実際の便益と損失を数量化するには、個別ネットワークのトラフィック、依存関係、インシデントデータが要る。

透明性が最後の支柱になる。RFC 7646は、現在および過去のNTAについて、設定時刻と削除時刻を含めて公開することを推奨している。当初の仕組みには、NTAの利用を直接示す専用のDNS応答コードがなかった。ADビットがないことは認証保証がないと示すだけで、どの方針によりそうなったのかまでは説明しない。

RFC 8914は後に拡張DNSエラーを定義し、DNSSEC IndeterminateやDNSSEC Bogusなどの診断情報を追加した。これらは障害の調査には役立つが、プロトコル処理そのものを変えない。また、運搬するDNSトランザクションが保護されていなければ、EDEにも認証はない。EDEは調査の手掛かりであって、設定不備を確定する証拠でも、NTAを承認する権限でもない。

例外を拒む反実仮想にも費用がある。NTAを使わなければ検証方針は守られるが、壊れた署名済みの枝は到達不能のままになり得る。検証を全面的に止めたり、利用者を非検証リゾルバーへ移したりすれば、より多くの到達性を戻せるかもしれないが、保証を失う範囲ははるかに大きい。狭いNTAは、その中間で一つの依存先だけを回復し、残りのDNSツリーでは検証を維持する。

RFCは全組織に共通する承認系統を指定していない。しかし、その制約から監査可能な記録に必要な要素は導ける。承認者、設定不備と判断した証拠、最小の対象名、設定と期限の時刻、ドメイン所有者への連絡、再検証の履歴、最終削除、キャッシュ消去である。これは標準の制御から導いた運用上の推論であり、特定事業者が現にこの手順を採用しているという事実ではない。

危険を説明するために、誰かを非難する必要はない。NTAが強力なのは、壊れた署名済みゾーンを変更せずにサービスを回復できるからだ。診断が正しければ継続性を守る一方、診断を誤るか一時例外を常態化すれば、利用者を未認証データにさらし得る。結論は限定的でなければならない。NTAは、責任者と証拠が明らかで、期限と公開性を備え、自動失効し、削除を検証できる真正性の例外としてのみ扱うべきである。

出典