要約

  • ISCはAPNIC 62で、ゾーン一覧とシリアル不一致の検出をStorkの現行DNS機能として紹介した。確認した資料は、APNICでの本番導入や実際の古いゾーン事故を示していない。
  • 不一致は、Storkが発見し取得できたサーバー、ビュー、ゾーン設定についての証拠である。不一致がないという表示を全体へ広げるには、取得失敗、未対応ビュー、除外、キャッシュの経過時間も必要になる。
  • 比較結果には、製品とデーモンの版、期待範囲と観測範囲、取得状態、SOAシリアルの生値、観測時刻、鮮度上限、取得不能項目の処置を束ねた受領記録が要る。

差分がない画面ほど、母集団を説明しなければならない

不一致が一件あれば、その行は調査の入口になる。同じゾーン名が二つのDNSサーバーで異なるSOAシリアルを持つなら、少なくともその二つの観測値が揃っていないことは分かる。難しいのは、不一致が一件もないときだ。全てが一致したのか、比較対象に入らなかったものがあるのかは、色だけでは区別できない。

APNIC 62の発表資料で、ISCのMarcin Siodelskiはゾーンの一覧・絞り込み、ゾーンビューアー、シリアル不一致検出を「現在」のDNS機能として示した。APNICのセッション報告も、複数サーバー間のシリアル差分を見つける機能を取り上げている。多数の権威サーバーを個別に開く代わりに、一つの画面で比較できること自体に意味がある。

ただし、Storkが見るのは組織のDNS全体という抽象物ではない。エージェントが検出したデーモン、読めた設定、接続できたインターフェース、そしてStorkサーバーが取得を求めたゾーン情報である。そこに入らなかった行は、不一致にも一致にもならない。

Stork 2.4.1のDNS文書では、BIND 9エージェントが実行中のnamedから使用中の設定ファイルを探す。設定を見つけられなければ、そのデーモンは検出済み一覧に出ない。ゾーンビューアーにはstatistics channelも必要で、設定済みのビューとゾーンはそこから得られる。PowerDNSでは、設定ファイルとWeb APIが別の入口になる。

見えないことは故障の証明ではない。監視対象外に置いたサーバーかもしれず、権限を意図的に絞った結果かもしれない。結論の範囲を狭くするだけである。「観測できた行は一致した」と「権威系全体が一致した」は、同じ文ではない。

時刻も分母の一部だ。Storkのゾーン一覧は、最初は空である。利用者がFetch Zonesを実行すると、エージェントが集めた一覧がStorkのデータベースに保存される。性能上、この一覧は自動更新されず、新しい状態を見るには再取得が要る。失敗はFetch Statusで確認できる。したがって、画面が正しくても、その画面が示す時点を省くことはできない。

文書は二つの数を分けている。Zone Configs Countは設定数であり、同じゾーン名が複数ビューにあれば複数回数える。Distinct Zonesは名前を一度だけ数える。一つはビューを含む運用面、もう一つは名前の集合を示す。どちらかだけを残すと、観測範囲の変化を復元できない。

ビューは同名ゾーンの意味を変える。BIND 9の非デフォルトビューから詳細なゾーン内容をAXFRで取得する場合、StorkはBINDが対象ビューを判別できるTSIG鍵を必要とする。match-clientsとallow-transferの設定がその選択に関わる。一方、Stork 2.4.1はPowerDNS 5.0で導入されたDNSビューに未対応だと明記している。未対応ビューは一致した行ではなく、観測集合の外側である。

ここで、一覧と内容を混ぜてはいけない。ゾーン一覧とシリアルは各DNSサーバーの統合機能から取得され、Fetch Zones後に保存される。レコードの中身はShow Zoneを選んだときにAXFRで取得され、既存のキャッシュがあればRefresh from DNSまで古い写しが使われることがある。AXFRに失敗してレコードを開けなくても、一覧にシリアルが残る場合はある。シリアルが見えるだけで完全な内容取得を証明することもできない。

転送監視はさらに別の機能だ。発表資料はXFR Monitoringを開発版2.5.1の新機能として示す。2.5.1エージェントマニュアルによれば、BIND専用のログ追跡は既定で無効で、明示的な有効化が必要であり、syslogにしか残らない転送は追跡できない。ISCのStorkページでは2.4.1が安定版、2.5.1が開発版である。版を記録しなければ、異なる世代の可視性を一つの結果に混ぜてしまう。

SOAシリアルの大小も通常の整数比較ではない。RFC 1912は、セカンダリがプライマリのシリアルを見て更新データを要求する流れを説明する。RFC 1982は32ビット空間の循環比較を定める。値は折り返し、ちょうど半周離れた組み合わせには順序が定義されない。

確認できたStork資料が保証するのは、不一致を検出できることまでだ。全ての組み合わせでどちらを新しいと表示するかは確認できない。したがって受領記録には二つの生値を残し、前後関係を示す場合は比較規則と判定も残すべきである。「異なる」は観測であり、「このセカンダリが遅れている」は役割と時刻を含む追加判断だ。

同じシリアルでも、全レコードが同一、DNSSECが有効、利用者が期待する応答を受ける、といったことまでは証明しない。それらには別の検証が必要である。本稿の境界はその前にある。等しい値の意味を論じる前に、等しいはずの全ての行が比較に参加したかを確認する。

必要な受領記録は大きくない。Stork serverとagentの版、DNS実装とデーモンの版、機械・デーモン・ゾーン・クラス・ビューの識別子、期待範囲とその責任者、取得開始・終了時刻とデーモン別状態、二種類のゾーン数、明示的除外と未対応ビュー、生のSOA値、観測・キャッシュ時刻と鮮度上限、結果、警報処置、訂正履歴を保存すればよい。鍵や内部構成の秘密を公開する必要はない。

その記録があれば、状態を「宣言範囲で完全」「欠落があり部分的」「鮮度切れ」「集合変更のため比較不能」に分けられる。部分集合で見つかった不一致にも価値はある。ただし、部分集合で不一致がなかったという結果は、その外側を緑に塗らない。

これはStorkの価値を否定する話ではない。分散したDNS情報を中央で結合できるからこそ、観測集合を明示する意味が生まれる。ソフトウェアが実際の集合を作り、運用者が期待集合を管理する。両者を結びつけて初めて、画面の差分は再現可能な判断資料になる。

出典