Destroylistの脅威フィードをDNS運用へ組み込む

PrimaryとCommunityを分けて読む

phishdestroy/destroylist の README はプロジェクトを「Real-time phishing & scam domain blocklist - 208k+ curated threats, 1M+ community, free API, multiple formats」と説明しています。ここではリポジトリで確認できる事実だけを整理します。star 数やバッジは注目度の手掛かりであり、品質の証明ではありません。「Quick Start」には次の説明があります。Add to Pi-hole or AdGuard Home in one click , paste this URL into your blocklist settings:。これは範囲の説明であり、本番検証の結果ではありません。

Destroylistは、単一の巨大なテキストを貼るだけのリストではありません。READMEはPrimaryをキュレーション済み、Communityを13以上のソースから集約したフィードとして分け、Primary LiveとCommunity LiveにはDNS検証を付けています。収集経路と検証状態が違うので、遮断の強さと更新遅延を同じものとして扱わないことが重要です。

DNS検証とHTTP検証の時間差

README の「 Phase 1: Pre-emptive Discovery & Ingestion」にある内容から、用途が合うかを先に判断できます。Infrastructure Analysis: Leveraging dnstwist and typosquatting detection to catch look-alike domains targeting established brands。目的が違うなら、人気だけで採用する理由にはなりません。プロジェクト名やコマンドは原文のまま残し、一次資料へ戻って用語を確認できるようにしています。 README には次の確認可能な項目もあります。Advanced Heuristics: Continuous monitoring of Google Ads (Malvertising), SEO-manipulated search results, and trending social media campaigns on Twitter (X), YouTube, and Telegram。初回テストの材料にはなりますが、実際の環境での確認を省略する理由にはなりません。

更新間隔はフィードごとに異なります。Primaryはリアルタイム、Communityは2時間、DNS検証済みは24時間、Primary Contentは12時間、Community Contentは24時間とREADMEの表にあります。これは配信の目安で、DNSキャッシュや利用側の更新周期は別です。取得時刻と適用時刻をログに残し、古いリストを現行値だと見なさないようにします。

HostsからRPZまでの配布形式

動作の説明は「Live Statistics」など複数の箇所に分かれています。確認できる情報は次の通りです。| Primary | Primary Live | Community | Community Live | |:-------:|:------------:|:---------:|:--------------:| | |。書かれていない構成、性能、セキュリティを推測で補いません。導入時はディレクトリ、設定ファイル、release 履歴を確認してください。

Pi-holeとAdGuard HomeのQuick Startでは、jsDelivrのprimary_active/hosts.txtを貼るURLが示されています。TXT、Hosts、AdBlock、Dnsmasq、Unbound、RPZなどの形式も用意されています。利用するDNS機器が期待する構文と、localhostや社内ドメインの扱いを小さな検証環境で確認してから全利用者へ広げます。

jsDelivrとRaw GitHubの使い分け

初回導入は README の入口から始めます。確認できるコマンドは次の通りです。

curl "https://api.destroy.tools/v1/check?domain=suspicious-site.xyz"

実行可能なコマンドがない場合は手順を作らず、「Quick Start」で依存関係、待受ポート、初回設定を確認します。

READMEはRaw GitHubのミラーが高負荷時に429を返す可能性を説明し、jsDelivrを推奨しています。CDNを使うと取得経路が変わるため、URLの内容、更新時刻、TLS、障害時の代替取得を監視対象にします。CDNがあることは、リスト内容の正確性や自分の環境での可用性を保証するものではありません。

APIの正規化と件数差

日常運用は公式文書の範囲に限ります。「Live Statistics」には| Primary Content | Community Content | |:---------------:|:-----------------:| | |とあります。設定、環境変数、権限、データ保存先は明記されたものだけを扱います。未記載の既定値は隔離環境で確認し、戻せる設定を保存してください。 同じ資料にはCommunity Intelligence: Real-time ingestion of community-reported threats via our Telegram Bot and partner intelligence feedsともあります。

Live Statisticsのバッジはフィードエントリー数で、APIはURL、www、重複を正規化した一意ドメイン数を返すため、値が低くなる場合があります。READMEはdns/metrics.jsonを定義の参照先にしています。件数を安全性のスコアに変換せず、正規化前後と対象フィードを分けて記録します。

Allowlistと復旧手順

制約も確認が必要です。現在の資料からは、phishdestroy/destroylist の互換表、性能基準、サービス保証、長期サポートを確認できません。README の記載は「| | Today | Week | Month | |:--|:-----:|:----:|:-----:| | Primary | |」です。不明点は採用記録の検証項目として残し、断定に変えないでください。

Allowlistは誤検知から守るための手動フィードとして表にあります。遮断された正当なドメインを復旧する経路、申立ての扱い、社内許可リストとの優先順位を自分のDNS構成で決める必要があります。READMEのAppeals Processが示す手順も読み、無条件に削除して済ませる運用にしません。

Pi-holeで最小範囲を検証する

ライセンスはメタデータと LICENSE に基づき、SPDX は MIT です。再配布や改変の条件を確認する情報であり、安全審査の代わりではありません。認証情報、公開範囲、ログ、依存ライブラリの扱いは別途確認が必要です。

導入前はprimary_active/hosts.txtを一台のPi-holeへ登録し、業務で使う正当なドメイン、既知のテスト用ドメイン、DNS失敗時の挙動を確認します。次に同じ候補をlist.json、active_domains.json、blocklist.jsonで比較し、取得時刻、件数、Allowlistによる除外を保存します。遮断ログを見て誤検知を修正できることが採用条件です。

遮断を強くするほど誤検知の復旧が重要になります。検証用DNSでフィードを更新する前後の名前解決、Allowlistの適用、キャッシュ期限を確認し、利用者から申告されたドメインを一時的に戻せる手順を用意します。フィードの取得成功だけでは遮断ルールの反映を証明できません。

編集部の結論

Destroylistの脅威フィードをDNS運用へ組み込むは、READMEに示された構成を自分の環境で検証できる開発者やチームに向きます。文書だけで性能、互換性、運用上の安全性まで保証されたと考える利用者には向きません。導入前に、この記事で挙げた固有のコマンドと入力を小さな隔離環境で実行し、ログ、出力、失敗時の状態を記録してから対象範囲を広げてください。

公式情報源

1. Official documentation
2. Official README
3. Project repository
4. Release notes