ICANNの新指標が測るのはDNS観測、措置の時刻ではない

要約

Domain MetricaのTime to Mitigationは、対象となるRBL掲載ドメインについて、最初と最後に観測したアクティブなDNS応答の間を推計する値であり、報告から実際の措置までの正確な時間ではない。
レジストラ、レジストリ、API向けの比較を始める前に、報告、監視開始、最終アクティブ観測、状態確認の四時刻と、除外・期限切れ・帰属不能を併記すべきだ。

センサーは、担当者がボタンを押した瞬間を見ていない。それでも画面に「緩和までの時間」と表示されれば、読み手は人や組織の対応時間だと思いやすい。ICANNが9月3日に公表したDomain Metricaの新機能は、この名称と観測能力の差を丁寧に扱う必要がある。

Time to Mitigation（TTM）は無意味な数字ではない。DNS上で報告対象の名前がどれだけ長くアクティブに見えたかを、一定の方法で示す。問題は、その範囲を越えて誰かの措置を計時した数字として使うことにある。

Domain Metricaは、対応するレピュテーション・ブロックリスト（RBL）から報告を受け取る。ICANNは、掲載だけでセキュリティ事案が確認されたわけではなく、ICANN自身がその活動を独立検証したことにもならないと説明している。

対象となるセカンドレベル・ドメインについては、新規報告を取得してから5分以内に少なくとも95％の監視を始めることが運用目標で、その後は通常5分ごとにDNSを調べる。ただし、報告時刻も監視開始時刻も、そのままTTMの開始にはならない。

公開FAQによる開始点は、最初に観測したアクティブな応答である。Aレコード、またはAがない場合のAAAAレコードが返り、そのアドレスが既知のシンクホールと認識されていないことが条件となる。

この観測はDNSの挙動だけを示す。ウェブサイト、メール、マルウェアのサーバーなどが実際に機能していた証明ではない。監視も連続ではなく、二回の照会の間に起きて元に戻った変化は見逃し得る。リゾルバーの場所、キャッシュ、フィルタリング、障害、レート制限も結果に影響する。

一度もアクティブな応答を捉えなければ、稼働時間は推計できない。推計不能をゼロ時間に置き換えてはならない。

DNSからの削除を理由にMitigatedとするには、NXDOMAINが三回連続して必要になる。通常の間隔なら、最初から三回目まで約10分である。この列が分類を確認する一方、TTMはその前の最後のアクティブな応答で終わる。

シンクホールの場合は、DNS応答が続いていてもMitigatedになり得る。既知のシンクホールではないアドレスへの最後の応答が推計の終点となり、最初に条件を満たしたシンクホール観測は別に記録される。

「Mitigated: Unknown」は、利用可能な証拠で緩和状態を分類したものの、DNS削除かシンクホールかを判断できない場合に使う。何も起きなかったという意味ではない。同時に、誰が何をしたかも示さない。

レジストラ、レジストリ、登録者、DNSやホスティング事業者、セキュリティ組織、公的機関、期限切れなど、観測状態を変える経路は複数ある。TTMだけでは、その主体も理由も、関連する不正利用がすべて終わったかも分からない。

二か月で条件を満たさなければ、「Unmonitored: Aged out」となって監視が終わる。途中の稼働推計があっても、緩和済みの成功例ではない。

ICANNの説明は、短い指標名より慎重である。Domain Metricaの概要も、RBL掲載がDNS不正利用の事案そのものとは限らないとする。統治上の課題は、この個別観測が組織別の比較に移る段階で生じる。

発表は、将来のトップ画面可視化、レジストラとレジストリ向けの専用表示、APIを候補に挙げた。比較するなら、各行にRBL報告の取得時刻、監視開始、最後の非シンクホール・アクティブ応答、分類確認の四時刻を残す必要がある。

さらに、方法の版、データ源、対象名の条件、測定間隔、AとAAAAの扱い、状態理由、推計不能とaged outの件数を示すべきだ。中央値や平均値の分母には、終点を持たない事例がどのように扱われたかが必要になる。

短いTTMは調査の端緒にはなる。レジストラやレジストリが速く措置したとの認定にはならない。同じ対象集団と状態を比べたことを、表示側が証明しなければならない。