ドメインネームシステムのブロックリスト

ドメインネームシステムブロックリスト、ドメインネームシステムベースのブラックホールリスト、ドメインネームシステムブラックリスト（DNSBL）、またはリアルタイムブラックホールリスト（RBL ）は、ドメインネームシステム（ DNS ）クエリを介して、送信ホストのIPアドレスが電子メールスパムのブラックリストに登録されているかどうかを確認するメールサーバーの操作サービスです。^[1]ほとんどのメールサーバーソフトウェアは、このようなリストをチェックするように設定でき、通常はこのようなサイトからのメッセージを拒否またはフラグ付けします。

DNSBL は、特定のリストやポリシーではなく、ソフトウェア メカニズムです。DNSBL は数十種類存在します。^[2] DNSBLは、アドレスをリスト化したりリストから削除したりするために、さまざまな基準を使用します。これには、スパムの送信に使用されているゾンビ コンピューターやその他のマシン、スパマーを積極的にホストしているインターネット サービス プロバイダー (ISP)、またはハニーポットシステムにスパムを送信したアドレスのリスト化が含まれる場合があります。

^{1998年に最初のDNSBLが設立されて以来、これら}のリストの運用とポリシーは、インターネット擁護団体の間で、また時には訴訟の種にもなり、頻繁に議論を呼んでいる。多くの電子メールシステムの運営者とユーザー^[5]は、DNSBLをスパムの発信元に関する情報を共有する貴重なツールとみなしているが、著名なインターネット活動家を含む他の人々は、DNSBLを検閲の一形態として反対している。^{[6] [7] [8] [9]}さらに、少数のDNSBL運営者は、リストの閉鎖を求めるスパマーから訴訟の標的となっている。^[10]

最初の DNSBL は、1997 年にPaul VixieによってBorder Gateway Protocol (BGP) フィードとして作成されたリアルタイム ブラックホール リスト (RBL) でした。その後、Eric Ziegast によって Vixie のMail Abuse Prevention System (MAPS)の一部として DNSBL として作成されました。Abovenet の Dave Rand が最初の加入者でした。^[11] RBL の最初のバージョンは DNSBL として公開されたのではなく、加入者が所有するルーターに BGP 経由で送信されるネットワークのリストであり、ネットワーク オペレーターは、スパムの送信や、Web サイトなどのスパム対応サービスのホストに使用されるマシンのすべてのTCP/IPトラフィックをドロップできました。後に DNSBL と呼ばれるようになったこの技術の発明者は、Vixie Enterprises に勤務していた Eric Ziegast でした。

「ブラックホール」という用語は、ネットワークのブラックホールを指し、ネットワーク上のリンクが、着信トラフィックを通常どおりに転送するのではなくドロップすることを意味します。RBL の目的は、これを使用するサイトが、スパムを積極的に送信するなど、スパムをサポートするサイトからのトラフィックを拒否することでした。アドレスが RBL に掲載される前に、ボランティアと MAPS スタッフは、そのアドレスの責任者に連絡して問題を修正するよう繰り返し試みました。このような努力は、すべてのネットワーク トラフィックをブラックホール化する前に非常に重要であると考えられていましたが、そのような議論が続く間、スパマーとスパムをサポートする ISP が RBL に掲載されるのを長期間遅らせることも意味しました。

その後、RBL は DNSBL 形式でもリリースされ、Paul Vixie はsendmailやその他のメール ソフトウェアの作者に、クライアントに RBL サポートを実装するよう奨励しました。これにより、メール ソフトウェアは RBL を照会し、すべてのトラフィックをブラックホール化するのではなく、メール サーバーごとにリストされたサイトからのメールを拒否できるようになりました。

RBL の登場後すぐに、他の人たちも異なるポリシーを持つ独自のリストを作成し始めました。最初の 1 つは、Alan Brown のOpen Relay Behavior-modification System (ORBS) です。これは、自動テストを使用して、オープン メール リレーとして実行されているメール サーバーを検出し、リスト化します。オープン メール リレーは、スパマーがスパムを運ぶために悪用できるものです。当時、ORBS は物議を醸しました。なぜなら、多くの人がオープン リレーの実行は許容できると考え、インターネットでオープン メール サーバーをスキャンするのは不正行為になる可能性があると感じていたからです。

2003 年、多数の DNSBL がサービス拒否攻撃(DOS)を受けました。これらの攻撃を認めた当事者も、責任を問われた当事者もいないため、その目的は推測の域を出ません。しかし、多くの観察者は、これらの攻撃は DNSBL の運用を妨害したり、停止に追い込むためにスパマーによって実行されたと考えています。2003 年 8 月、SPEWSデータ セットに基づくものを含む複数の DNSBL を運営するOsirusoft社は、数週間にわたるほぼ継続的な攻撃を受けた後、リストを閉鎖しました。

DNSBLの技術仕様は比較的遅れてRFC5782で発表されました。^[12]

Uniform Resource Identifier (URI) DNSBL は、スパムの本文に含まれる「クリック可能な」リンクに含まれるドメイン名と、場合によっては IP アドレスもリストする DNSBL ですが、通常、正当なメッセージ内には見つかりません。

URI DNSBL は、スパム送信 IP アドレスが最初に使用されてから、その送信 IP アドレスが主要な送信 IP ベースの DNSBL に初めてリストされるまでの短い期間に、大量のスパムがスパム フィルターを通過したことが判明したときに作成されました。

多くの場合、このような見つけにくいスパムのリンクには、以前に検出されたスパムですでに発見されている URI や、非スパム電子メールでは見つからない URI を含むドメイン名または IP アドレス (総称して URI と呼ばれます) が含まれています。

したがって、スパム フィルターがメッセージからすべての URI を抽出し、それらを URI DNSBL と照合すると、そのスパムの送信元 IP がどの送信元 IP DNSBL にもまだリストされていない場合でも、スパムをブロックできます。

3つの主要なURI DNSBLのうち、最も古く、最も人気のあるのはSURBLです。^[13] SURBLが作成された後、SURBLのボランティアの一部が2番目に大きなURI DNSBLであるURIBLを開始しました。^[14] 2008年には、別の長年のSURBLボランティアが別のURI DNSBLであるivmURIを開始しました。^[15] Spamhausプロジェクトは、 Spamhausドメインブロックリスト（DBL）を提供し、彼らはこれを「スパムメッセージで見つかった」ドメインと説明しています。^[16] DBLはURIBLとRHSBLの両方を目的としており、メッセージのエンベロープ内のドメインと、メッセージ本文のURLのヘッダーとドメインの両方に対してチェックされます。他のURIBLとは異なり、DBLはドメイン名のみをリストし、IPアドレスはリストしません。これは、SpamhausがIPアドレスの別のリストを提供しているためです。

URI DNSBL は、RHSBL (右側の BL) とよく混同されます。しかし、これらは異なります。URI DNSBL は、メッセージの本文にあるドメイン名と IP をリストします。RHSBL は、電子メールの「送信元」または「返信先」アドレスで使用されるドメイン名をリストします。多くのスパムは偽造された「送信元」アドレスを使用するか、「送信元」アドレスに @gmail.com、@yahoo.com、@hotmail.com などの一般的なフリーメール ドメイン名が含まれているため、RHSBL の有効性は議論の余地があります。URI DNSBL は RHSBL よりも広く使用されており、非常に効果的で、大多数のスパム フィルターで使用されています。

DNSBL を運用するには、ホストするドメイン、そのドメインのネームサーバー、公開するアドレスのリストの 3 つが必要です。

汎用DNS サーバー ソフトウェアを使用して DNSBL を提供することは可能です。ただし、これは通常、多数のアドレスを含むゾーン、特にクラスレス インター ドメイン ルーティング ネットブロック全体をリストする DNSBL では非効率的です。ドメイン ネーム サーバーの役割として設計されたソフトウェアを使用すると大量のリソースが消費されるため、DNS ブラックリストの役割を持つサーバー専用に設計された役割固有のソフトウェア アプリケーションがあります。

DNSBL の運用で難しいのは、そこにアドレスを入力することです。一般の使用を目的とした DNSBL には通常、リストの意味に関する具体的な公開ポリシーがあり、一般の信頼を獲得または維持するためにはそれに従って運用する必要があります。

メール サーバーがクライアントからの接続を受信し、そのクライアントを DNSBL (たとえば、dnsbl.example.net ) と照合する場合、おおよそ次の処理が行われます。

1. クライアントの IP アドレス (たとえば、192.168.42.23 ) を取得し、オクテットの順序を逆にすると、23.42.168.192になります。
2. DNSBL のドメイン名を追加します: 23.42.168.192.dnsbl.example.net。
3. この名前を DNS でドメイン名 ("A" レコード) として検索します。これにより、クライアントがリストされていることを示すアドレス、またはクライアントがリストされていないことを示す "NXDOMAIN" ("そのようなドメインはありません") コードが返されます。
4. オプションとして、クライアントがリストされている場合は、名前をテキスト レコード (「TXT」レコード) として検索します。ほとんどの DNSBL は、クライアントが TXT レコードとしてリストされている理由に関する情報を公開しています。

DNSBL でアドレスを検索する方法は、逆 DNS で検索する方法と似ています。違いは、DNSBL 検索では「PTR」レコード タイプではなく「A」レコード タイプが使用され、特別な逆ドメインin-addr.arpaではなく、順方向ドメイン (上記のdnsbl.example.netなど) が使用されることです。

一致する DNSBL クエリによって返されるアドレスには、非公式のプロトコルがあります。ほとんどの DNSBL は、127.0.0.0/8 IPループバックネットワーク内のアドレスを返します。アドレス 127.0.0.2 は、一般的なリストを示します。このブロック内の他のアドレスは、リストに関する特定の何か (オープン リレー、プロキシ、スパマー所有のホストなど) を示している可能性があります。詳細については、RFC 5782 を参照してください。

URI DNSBL クエリ (および RHSBL クエリ) は非常に簡単です。クエリするドメイン名は、次のように DNS リスト ホストの先頭に追加されます。

example.net.dnslist.example.com

ここで、dnslist.example.comは DNS リスト ホストであり、example.net は照会されたドメインです。通常、A レコードが返された場合は、名前がリストされます。

DNSBL ごとにポリシーが異なります。DNSBL ポリシーは次の 3 つの点で異なります。

• 目標。DNSBLは何をリスト化しようとしているのでしょうか? オープンリレー メール サーバーまたはオープン プロキシのリストでしょうか? それとも、スパムを送信することが知られている IP アドレスのリストでしょうか? あるいは、スパマーをかくまっている ISP に属する IP アドレスのリストでしょうか?
• 指名。DNSBL はどのようにしてリストするアドレスを見つけるのでしょうか? ユーザーによって送信された指名を使用するのでしょうか? スパムトラップ アドレスまたはハニーポットを使用するのでしょうか?
• リストの有効期間。リストはどのくらいの期間存続しますか? 自動的に期限切れになりますか、それとも手動でのみ削除できますか? リストされているホストの運営者は、ホストをリストから削除するために何ができますか?

リストされているエンティティの種類が異なること (従来の DNSBL の場合は IP アドレス、RHSBL の場合はホスト名とドメイン名、URIBL の場合は URI) に加えて、リストの意味に関してリスト間で幅広い意味の違いがあります。リスト管理者自身も、リストを客観的な事実の記述と見なすべきか主観的な意見と見なすべきか、またリストをどのように使用するのが最善かという問題で意見が分かれています。その結果、DNSBL の明確な分類法は存在しません。ここで定義されている名前の一部 (「Yellow」や「NoBL」など^[17] ) は、あまり広く使用されていない変種であるため、名前自体も広く使用されていませんが、多くのスパム制御の専門家に認識されているはずです。

ホワイトリスト / 許可リスト

リストは本質的に絶対的な信頼の肯定的な表示です

ブラックリスト/ブロックリスト

リストは本質的に絶対的な不信感の否定的な兆候である

グレーリスト

最も頻繁に使用される単語は 1 つ (greylist または greylisting) で、DNSBL を直接的に含むものではなく、よく知られていないソースからのメールを一時的に延期して、公的な評判 (DNSBL リストなど) を高めたり、速度重視のスパムを阻止したりします。リストが明確な非絶対的なレベルと信頼または不信頼の形式を示す、実際の DNSBL を指すために使用されることもあります。

イエローリスト

リストには、ソースがスパムと非スパムの混合を生成することが知られており、他の DNSBL のチェックが役に立たない程度であることを示します。

NoBLリスト

リストは、ソースがスパムを送信しないと考えられており、ブラックリスト テストの対象とすべきではないが、ホワイトリストに登録されたソースほど信頼できないことを示します。

• ほとんどのメッセージ転送エージェント(MTA) ^{[注 1]}は、DNSBL リストに基づいて電子メールを完全にブロックするか、(あまり一般的ではありませんが) 受け入れるように設定できます。これは、DNSBL の最も古い使用形式です。特定の MTA によっては、MTA が複数の DNSBL を処理する方法によって、Yellow や NoBL などのリスト タイプが有用または無意味になる設定の微妙な違いがあります。ほとんどの MTA で直接 DNSBL サポートを使用する欠点は、どのリストにも含まれていないソースでは、使用されているすべての DNSBL を確認する必要があり、否定的な結果をキャッシュするユーティリティが比較的少ないことです。場合によっては、これによりメール配信が大幅に遅くなることがあります。一部の MTA では、White、Yellow、および NoBL リストを使用して一部の検索を回避することで、この問題を軽減できます。
• DNSBL は、各 DNSBL が独自のルールを持つSpamassassinなどのルール ベースのスパム分析ソフトウェアで使用できます。各ルールには特定の正または負の重みがあり、他の種類のルールと組み合わせて各メッセージをスコアリングします。これにより、(特定のソフトウェアで使用可能な基準に従って) ルールを使用して、DNSBL リストまたは他のルールによって拒否されるはずのメールを「ホワイトリスト」に登録できます。また、DNS ルックアップの負荷が高く、有用な結果が得られないという問題もありますが、スコアリングによって、フィルタがメッセージを他のルールと照合している間に、ルックアップを並行して非同期に実行できるため、メールの遅延はそれほど大きくならない可能性があります。
• いくつかのツールセットでは、バイナリテストと重み付けルールのアプローチを組み合わせることが可能です。これを行う方法の 1 つは、最初にホワイト リストをチェックし、ソースがホワイト リストに含まれている場合はメッセージを受け入れ、他のすべてのテスト メカニズムをバイパスすることです。Junk Email Filter ^[18]によって開発された手法では、イエロー リストと NoBL リストを使用して、ブラック リストが適切に管理されていないときに日常的に発生する誤検知を軽減します。
• 一部の DNSBL は、スパムメールをフィルタリングする以外の目的で作成されており、デモンストレーション、情報提供、修辞、テスト制御の目的で作成されています。例としては、「No False Negatives List」、「Lucky Sevens List」、「Fibonacci's List」、GeoIP 情報をエンコードするさまざまなリスト、別のリストの範囲に合わせてスケールされたランダム選択リストなどがあります。これは、そのリストの効果がランダム拒否と区別できるかどうかを判断するための制御として役立ちます。

一部のエンドユーザーや組織は、DNSBL の概念や、DNSBL の作成方法や使用方法の詳細に関して懸念を抱いています。批判の一部は次のとおりです。

• 共有メールサーバーからのスパムとともに正当なメールもブロックされる。ISPの共有メールサーバーにスパムを送信する1台以上の侵害されたマシンがある場合、DNSBLにリストされる可能性があります。同じ共有メールサーバーに割り当てられたエンドユーザーは、そのようなDNSBLを使用する受信メールサーバーによってメールがブロックされていることに気付く場合があります。^[19] 2016年5月、SORBSシステムはオーストラリア最大のインターネットサービスプロバイダーであるTelstra AustraliaのSMTPサーバーをブロックしていました。これは驚くことではありません。なぜなら、いつでも、スパムを送信するゾンビ型ウイルスに感染したこのメールサーバーに接続された何千ものコンピューターがあるからです。その結果、Telstra Australiaシステムのユーザーからの正当なメールはすべて遮断されました。
• 動的IPアドレスのリスト。このタイプのDNSBLは、ISPが動的として提出したIPアドレスをリストするため、電子メールを直接送信するにはおそらく不適切です。 ^[7]エンドユーザーは、すべての電子メール送信にISPのメールサーバーを使用することになっています。しかし、これらのリストには、中小企業の所有者や他のエンドユーザーが小規模な電子メールサーバーをホストするために合法的に使用できる静的アドレスも誤って含まれる可能性があります。^[20]
• MAPS RBL などの「スパム支援オペレーション」を含むリスト。^[21]スパム支援オペレーションとは、直接スパムを送信しないが、スパムで宣伝されている Web サイトのホスティングなど、スパマーに商用サービスを提供するサイトです。スパム支援オペレーションからのメールを拒否することは、スパマーと同じサイトを使用する非スパマーに不便をかけることを犠牲にして、そのようなサイトがスパマーとの取引をやめるように促すボイコットとして意図されています。
• 一部のリストでは掲載基準が明確でなく、リストからの削除が自動的に行われなかったり、すぐに行われない場合があります。一部のDNSBL運営者は支払い（例：uceprotect.net）^[22]または寄付（例：SORBS）を要求します。多くの掲載/削除ポリシーの一部は、DNSブラックリストの比較の記事で見つけることができます。
• リストにはIPアドレスやURIを追加するさまざまな方法があるため、送信者がDNSBLにリストされないようにシステムを適切に構成することが難しい場合があります。たとえば、UCEProtect DNSBLは、スパムメッセージが配信されなくても、受信者アドレスを検証するかTCP接続を確立すると、IPアドレスをリストするようです。^[23]

批判はあるものの、メール受信サイトが不要なメールを体系的に拒否できるべきという原則に反対する人はほとんどいない。反対する人の 1 人は、意図的にオープン メール リレーを運営しているジョン ギルモア氏だ。ギルモア氏は DNSBL 運営者が独占禁止法に違反していると非難している。

ジョー・ブロウが電子メールを拒否することは合法である（ただし、これは「メッセンジャーを撃つ」のと同じで、悪いポリシーである）。しかし、ジョーと1000万人の友人が結託してブラックリストを作った場合、彼らは違法な独占力を行使していることになる。^[24]

電子フロンティア財団やピースファイアなど、多くの団体がISPによるDNSBLの使用について懸念を表明している。EFFとピースファイアを含む団体が出した共同声明では、ISPが顧客に通知せずにDNSBLやその他のスパムブロック技術を使用する「ステルスブロッキング」について言及している。^[25]

スパマーは同様の理由で DNSBL 運営者に対して訴訟を起こしています。

• 2003年、EMarketersAmerica.orgはフロリダの裁判所にDNSBL運営者数社を相手取って訴訟を起こした。スパマーのエディ・マリンの支援を受けた同社は、電子メールマーケティング業者の業界団体であると主張し、DNSBL運営者のSpamhausとSPEWSは取引制限に関与していると主張した。訴訟は最終的に訴訟当事者資格がないとして却下された。^{[26] [27]}
• 2006年、米国の裁判所はスパムハウスに対し、スパマーのe360 Insight LLCに1170万ドルの損害賠償を支払うよう命じた。この命令は、英国に拠点を置くスパムハウスが裁判所の管轄権を認めず、 e360の訴訟で自らを弁護しなかったため、欠席判決となった。2011年、この判決は米国第7巡回区控訴裁判所によって覆された。^[28]

• エイブル
• ＣＢＬ
• にゃぶる
• SORBS  – スパム行為を助長する疑いのある電子メールサーバーのリストリダイレクト先の簡単な説明を表示するページ
• ダイナブロック

• インターネットフィルター
• メールスパム

• ブラックリスト モニター - 特定のブラックリストの成功率と失敗率の週次統計
• DNSBL の作成方法 - DNSBL (DNS ブラック リスト) の作成方法に関するチュートリアル