要約

  • RPZは、DNSゾーン形式でトリガーと提案動作を配る仕組みである。転送元と版を認証できても、指標の妥当性や全利用者への適用権限までは証明しない。
  • 購読側はゾーン順序、動作の上書き、PASSTHRU、利用者範囲、DNSSEC、TTL、キャッシュ、起動時の挙動、EDEを選ぶ。利用者に届く改変応答の主体はローカル運用者である。

ある名前を危険と判定したとする。NXDOMAINなら「名前が存在しない」と答える。NODATAなら名前の存在は残し、要求された型だけを空にする。DROPなら返事がなく、アプリケーションはタイムアウトを待つ。TCP-onlyなら再試行経路が変わる。ローカルデータなら警告サイトへ向かう。どれも同じ「ブロック」ではない。

この違いこそ、RPZの権限を考える出発点である。フィード発行者が危険指標を示しても、障害の形を選ぶのは購読者である。利用者が目にする結果は、フィードに書かれた文字列だけでなく、ローカル設定と実装の評価順序から生成される。

現在のBIND 9文書は、Response Policy Zoneをオープンでベンダー中立なゾーン形式として説明する。五種類のトリガーと六種類の動作をDNSレコードに符号化し、通常のゾーン転送で共有できる。UnboundとPowerDNS Recursorも、この共通モデルをそれぞれの運用面に実装している。

ただし標準化の地位は別問題である。draft-vixie-dnsop-dns-rpz-00は2018年に失効した個人Internet-Draftで、RFCでもIETFが承認した標準でもない。Datatrackerの履歴は2020年7月にdormantとなったことを記録している。本稿では、実装間で共有される設計を読む資料として扱い、規範的な地位を創作しない。

その草案は、政策データが転送によって購読者へ渡り、購読者の再帰サーバー設定によって初めてローカル制御面へ昇格すると説明する。AXFRやIXFRが正常で、TSIGが相手と転送を認証しても、それは「どの政策オブジェクトを受け取ったか」の証拠である。「この利用者にこの結果を返してよい」という証明ではない。

五つのトリガーは評価対象が違う。Client IPは質問した端末側、QNAMEは名前、RPZ-IPは本来の答えに含まれるアドレス、NSDNAMEとNSIPは権威サーバーの名前またはアドレスをみる。後二者は共有DNS基盤を経由して多数のドメインへ波及し得る。BINDもその影響が広範囲になり得ると警告している。

さらに評価時点が違う。QNAMEは完全な名前解決より前に判定できるが、応答IPは元の答えを得なければ分からない。権威サーバー情報は反復問い合わせの途中で現れる。PowerDNSは、性能とプライバシーの理由から、実装の評価順が仕様の理想的な全比較を厳密には再現しないこと、版によって挙動が変わったことを公開している。同一フィードが必ず同一結果になるとは限らない。

優先順位も購読者が与える。BINDの設定リファレンスでは、複数の規則が一致すると、まず response-policy で先に置かれたゾーンが選ばれる。同一ゾーンではCLIENT-IP、QNAME、IP、NSDNAME、NSIPの順と、名前やプレフィックスの具体性が効く。Unboundも設定順でゾーンを調べ、PASSTHRUを有効な一致として扱うため、それより後のゾーンは適用されない。

BINDが内部RPZを外部フィードより前に置くよう勧める理由は、単なる性能ではない。取引先や重要サービスをPASSTHRUで保護し、将来外部ゾーンに危険な規則が追加されてもローカル例外が先に勝つようにするためである。組織が自分の事情を知る層を先頭に置くことで、結果の権限を保持する。

動作の上書きはさらに明白だ。BINDではゾーン全体をNXDOMAIN、NODATA、DROP、TCP-only、PASSTHRUまたはローカルCNAMEとして扱える。Unboundは外部のトリガーを使いながら、すべてを自社の案内先へ変更できる。PowerDNSはCustom、Drop、NXDOMAIN、NODATA、Truncate、NoActionをローカル既定動作にできる。発行者が一つの動作を書いても、利用者に別の動作を返す主体は購読者である。

試験にも製品差がある。Unboundのdisabledは一致を記録するが有効な一致とはみなさず、次のゾーンを調べる。PASSTHRUは一致として後続を止める。BINDのDISABLEDにも固有の優先規則がある。「無効」と「通過」を同じものとして移植すると、保護したつもりの名前に次のフィードが作用し得る。

DNSSECは、合成応答が権威データの署名を借りられないことを示す。RPZ草案は、方針による結果を再帰サーバーが意図的に生成する「真実ではない」DNS結果と表現する。BINDは通常、クライアントがDNSSEC情報を要求し、元ゾーンに署名データがあればRPZを適用しない。break-dnssec yesなら書き換えるが、その結果は検証不能になる。

RFC 4035では、本来信頼連鎖を作れるはずなのに検証できないRRsetはBogusであり、攻撃、設定ミス、破損のいずれも原因になり得る。再帰サーバーの答えがローカル方針に強く依存することも明記される。DNSSECが認証するのは権威RRsetであって、購読者が作ったNXDOMAINやCNAMEではない。

否定応答はその場限りでもない。RFC 2308はNXDOMAINとNODATAの負のキャッシュを定める。前者は同じ名前とクラス、後者は名前・型・クラスを鍵に再利用される。BINDは政策レコード由来のTTLにローカル上限を設け、PowerDNSも合成TTLとキャッシュ消去を設定できる。フィードから規則が消えても、複数のキャッシュ時計が切れるまで影響が残る。

原因表示にはRFC 8914のEDEが使える。15は運用者内部のセキュリティ方針によるBlocked、16は外部要求によるCensored、17は利用者が求めたFiltered、18は未許可クライアントへのProhibitedである。BINDとPowerDNSはRPZヒットにEDEを付けられる。誰の決定かを区別する点に価値がある。

ただしEDEは診断であり、許可証ではない。RFCはRCODE処理を変更してはならないとし、認証されない可能性や情報漏えいも示す。フィードの版、ローカル方針名、勝ったトリガー、動作、対象クライアント、TTLと結び付いて初めて、運用証拠になる。

鮮度も一つの数値ではない。失効草案は、新しい脅威だけでなく誤った古い方針の撤回にも低遅延を求める。PowerDNSは成功した最新版をdumpし、再起動時のseedとして読み込んでからIXFRできる。BINDはRPZ準備前にSERVFAILを返す選択肢を持つ一方、一部のゾーンだけロードできた状態で応答する場合もある。最大経過時間、部分ロード、復旧版、例外の所有者はローカルで決めなければならない。

Heng Luの動くコードを優先する議論、最小初期仕様と局所的な将来決定、現実の層を当てはめると、共通形式の役割は政策候補を運ぶところまででよい。採用は設定で現実になり、効果は実際の応答で確認される。フィードの正しさを、結果全体の正しさへ拡張してはならない。

監査では、発行者とserial、転送認証、ローカル受入れ、ゾーン順、動作上書き、勝者となった規則、TTL、EDE、そして代表クライアントからの観測を一本につなぐ。元の権威応答との比較も必要だ。そこで初めて「誰が、どの答えを選んだか」が分かる。