[要約] RFC 6471は、DNSBLの運用に関する最善の実践についての概要を提供しています。その目的は、メール送信者がスパムや悪意のあるメールをブロックするための効果的なDNSBLの運用方法を理解することです。
Internet Research Task Force (IRTF) C. Lewis
Request for Comments: 6471 Nortel Networks
Category: Informational M. Sergeant
ISSN: 2070-1721 Symantec Corporation
January 2012
Overview of Best Email DNS-Based List (DNSBL) Operational Practices
Best Email DNSベースのリスト（DNSBL）運用慣行の概要
Abstract
概要
The rise of spam and other anti-social behavior on the Internet has led to the creation of shared DNS-based lists (DNSBLs) of IP addresses or domain names intended to help guide email filtering. This memo summarizes guidelines of accepted best practice for the management of public DNSBLs by their operators as well as for the proper use of such lists by mail server administrators (DNSBL users), and it provides useful background for both parties. It is not intended to advise on the utility or efficacy of particular DNSBLs or the DNSBL concept in general, nor to assist end users with questions about spam.
インターネット上でのスパムの台頭とその他の反社会的行動により、電子メールのフィルタリングをガイドするのに役立つIPアドレスまたはドメイン名の共有DNSベースのリスト（DNSBL）が作成されました。このメモは、オペレーターによるパブリックDNSBLの管理のための受け入れられたベストプラクティスのガイドラインと、メールサーバー管理者（DNSBLユーザー）によるそのようなリストの適切な使用のために、両当事者に有用な背景を提供します。特定のDNSBLまたはDNSBLの概念のユーティリティまたは有効性についてアドバイスすることも、スパムに関する質問でエンドユーザーを支援することも意図していません。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the Anti-Spam Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネット研究タスクフォース（IRTF）の製品です。IRTFは、インターネット関連の研究開発活動の結果を公開しています。これらの結果は、展開に適していない場合があります。このRFCは、インターネット研究タスクフォース（IRTF）の反スパム研究グループのコンセンサスを表しています。IRSGによって公開されたことが承認された文書は、インターネット標準のレベルの候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6471.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6471で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書の公開。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. DNS-Based Reputation Systems . . . . . . . . . . . . . . . 3
1.2. Guidance for DNSBL Users . . . . . . . . . . . . . . . . . 5
1.3. Requirements Language . . . . . . . . . . . . . . . . . . 7
1.4. Background . . . . . . . . . . . . . . . . . . . . . . . . 7
2. DNSBL Policies . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Transparency . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.1. Listing/Delisting Criteria SHOULD Be Easily
Available . . . . . . . . . . . . . . . . . . . . . . 8
2.1.2. Audit Trail SHOULD Be Maintained . . . . . . . . . . . 8
2.1.3. The Scope and Aggressiveness of Listings MUST Be
Disclosed . . . . . . . . . . . . . . . . . . . . . . 8
2.2. Listings and Removals . . . . . . . . . . . . . . . . . . 9
2.2.1. Listings SHOULD Be Temporary . . . . . . . . . . . . . 9
2.2.2. A Direct Non-Public Way to Request Removal SHOULD
Be Available . . . . . . . . . . . . . . . . . . . . . 10
2.2.3. Response SHOULD Be Prompt . . . . . . . . . . . . . . 11
2.2.4. A Given DNSBL SHOULD Have Similar Criteria for
Listing and Delisting . . . . . . . . . . . . . . . . 12
2.2.5. Conflict of Interest . . . . . . . . . . . . . . . . . 12
3. Operational Issues . . . . . . . . . . . . . . . . . . . . . . 13
3.1. DNSBL Query Root Domain Name SHOULD be a Subdomain . . . . 13
3.2. DNSBLs SHOULD Be Adequately Provisioned . . . . . . . . . 13
3.3. DNSBLs SHOULD Provide Operational Flags . . . . . . . . . 14
3.4. Shutdowns MUST Be Done Gracefully . . . . . . . . . . . . 15
3.5. Listing of Special and Reserved IP Addresses MUST Be
Disclosed . . . . . . . . . . . . . . . . . . . . . . . . 16
3.6. Considerations for DNSBLs Listing Insecure Hosts . . . . . 17
3.6.1. DNSBLs MUST NOT Scan without Provocation . . . . . . . 17
3.6.2. Re-Scan Periods SHOULD Be Reasonable . . . . . . . . . 17
3.6.3. Scans MUST NOT Be Destructive . . . . . . . . . . . . 17
3.7. Removals SHOULD Be Possible in Absence of the DNSBL
Operator . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.8. Protect against Misconfiguration/Outages . . . . . . . . . 18
3.9. Error Handling . . . . . . . . . . . . . . . . . . . . . . 19
4. Security Considerations . . . . . . . . . . . . . . . . . . . 19
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.1. Normative References . . . . . . . . . . . . . . . . . . . 20
5.2. Informative References . . . . . . . . . . . . . . . . . . 20
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 21
Due to the rising amount of spam and other forms of network abuse on the Internet, many community members and companies began to create, publish and maintain DNS-based reputation systems (DNS-based lists or DNSBLs) of IP addresses or domain names and make reputation suggestions or assertions about email sourced from these IP addresses or domain names.
インターネット上のスパムやその他の形態のネットワーク乱用の量が増加しているため、多くのコミュニティメンバーや企業は、IPアドレスまたはドメイン名のDNSベースの評判システム（DNSベースのリストまたはDNSBL）を作成、公開、維持し始めました。これらのIPアドレスまたはドメイン名からソースされた電子メールに関する評判の提案またはアサーション。
The first DNSBLs were almost exclusively intended to be used (by email administrators) as lists of abusive IP addresses to block; however, the DNS publication method has proven to be so robust, popular, and simple to use that it has been extended for use in many different ways, far beyond the imaginings of the designers of DNS or DNS-based blocking IP lists. For example, today, the same basic DNS-based listing technology is commonly used for:
最初のDNSBLは、ブロックする虐待的なIPアドレスのリストとして（電子メール管理者によって）使用されることをほとんど意図していました。ただし、DNSの出版方法は非常に堅牢で人気があり、使いやすいことが証明されているため、DNSまたはDNSベースのブロッキングIPリストのデザイナーの想像をはるかに超えて、さまざまな方法で使用するために拡張されています。たとえば、今日、同じ基本的なDNSベースのリスティングテクノロジーが一般的に使用されます。
DNSWL: listings of well-behaving email source IP/domain addresses (whitelist).
DNSWL：目立った電子メールソースIP/ドメインアドレス（ホワイトリスト）のリスト。
RHSBL: listings of well/ill-behaving email source domain names (often applied against the domain name part (RHS = Right Hand Side) of the originating email address or DNS PTR (reverse IP) lookups)
rhsbl：井戸/不適切な電子メールソースドメイン名のリスト（多くの場合、ドメイン名パーツ（rhs =右側）またはdns ptr（reverse ip）lookupsの右側に適用されます）
URIBL: listings of well/ill-behaving web link domain names or host names used in email
uribl：電子メールで使用されている井戸/不正なWebリンクドメイン名またはホスト名のリスト
Further, the DNSBL user doesn't have to use a listing as a pass/fail binary decision -- it can use a listing as one factor in email filters that make decisions based on scoring multiple factors together.
さらに、DNSBLユーザーは、リストをパス/失敗のバイナリ決定として使用する必要はありません。複数の要因を採点することに基づいて決定を下す電子メールフィルターの1つの要因としてリストを使用できます。
The DNS-based list technology has even been extended to purely informational purposes. For example, there are implementations that return results based on what geographic region an IP/domain is putatively allocated in, implementations that translate an IP/domain address into an Autonomous System Number (ASN) and/or allocation block, implementations that indicate whether the queried domain name is registered through a given domain registrar, implementations that return aggregate numeric reputation for an IP address or domain name from another system's email system, and so on. The possibilities are virtually endless.
DNSベースのリストテクノロジーは、純粋に情報提供の目的にまで拡張されています。たとえば、IP/ドメインがどの地理的領域に割り当てられているかに基づいて結果を返す実装があり、IP/ドメインアドレスを自律システム番号（ASN）および/または割り当てブロックに変換する実装、Queriedドメイン名は、特定のドメインレジストラ、別のシステムの電子メールシステムからIPアドレスまたはドメイン名の集約数値評判を返す実装などを介して登録されます。可能性は事実上無限です。
DNS-based listing technology has also been used in areas other than email filtering, such as Internet Relay Chat (IRC), web access control, and transaction verification.
DNSベースのリスティングテクノロジーは、インターネットリレーチャット（IRC）、Webアクセス制御、トランザクションの確認など、電子メールフィルタリング以外の領域でも使用されています。
As the terminology in this area has never been well formalized, often overlaps, and lacks precision, this document has been written to use the term "DNSBLs" to refer to DNS-based lists generally, not just DNS-based block (or black) lists. This document is not applicable to some DNSBLs in some areas (mentioned as appropriate), but it is the authors' belief that most of the practices are applicable to almost all DNSBLs.
この分野の用語は、正式に正式化されていないため、しばしば重複し、精度が欠けているため、このドキュメントは「DNSBLS」という用語を使用して、DNSベースのブロック（または黒）だけでなく、一般的にDNSベースのリストを参照するように書かれています。リスト。このドキュメントは、一部の領域の一部のDNSBLには適用されません（必要に応じて言及）が、ほとんどのプラクティスはほぼすべてのDNSBLに適用できるという著者の信念です。
DNSBLs may be either public or private. A public DNSBL makes its data available to any party seeking information about data on the list, while a private DNSBL is used solely by an organization for its own use, and the data is not made available publicly. There are also commercial DNSBLs, available for a fee. Furthermore, some are free yet require a fee for higher numbers of queries or certain classes of DNSBL users.
DNSBLSは、パブリックまたはプライベートのいずれかです。パブリックDNSBLは、リスト上のデータに関する情報を求めている当事者がデータを利用できるようにしますが、プライベートDNSBLは独自の使用のために組織のみが使用し、データは公開されません。コマーシャルDNSBLもあり、有料で利用できます。さらに、一部は無料ですが、より多くのクエリまたは特定のクラスのDNSBLユーザーに対して料金が必要です。
The first publicly available DNSBL using the Domain Name System (DNS) for distributing reputation data about email senders emerged in 1997, shortly after spam became a problem for network operators and email administrators. This pioneer DNSBL focused on identifying known spam sources situated at static (unchanging) IP/domain addresses. Due to the broad adoption of this DNSBL, it had a major impact on static spam sources. Consequently, abusers found other methods for distributing their spam, such as relaying messages through unsecured email servers or flawed formmail scripts on web pages. Additional DNSBLs were developed by others in order to address these changing tactics, and today more than 700 public DNSBLs are known to be in operation.
SPAMがネットワークオペレーターと電子メール管理者の問題になった直後に、1997年に出現した、電子メール送信者に関する評判データを配布するためにドメイン名システム（DNS）を使用した最初の公開DNSBLが使用されました。このパイオニアDNSBLは、静的（不変）IP/ドメインアドレスに位置する既知のスパムソースの識別に焦点を当てました。このDNSBLの幅広い採用により、静的スパムソースに大きな影響がありました。その結果、虐待者は、無担保電子メールサーバーを介してメッセージを中継したり、Webページで欠陥のあるフォームメールスクリプトを介してメッセージを中継するなど、スパムを配布する他の方法を見つけました。これらの変化する戦術に対処するために、追加のDNSBLが他のDNSBLによって開発されましたが、今日では700を超える公共のDNSBLが稼働していることが知られています。
These DNSBLs vary widely in purpose for which the list was intended, the method the list uses to achieve the purpose, the integrity of those overseeing the method, and the stability of the technology used to create and distribute the data. Listing criteria can sometimes be quite controversial; therefore, this document deliberately does not discuss the rightness or wrongness of any criteria. We assert that DNSBL operators are free to choose whatever listing criteria they wish, as long as those criteria are clearly and accurately communicated. It is the responsibility of the DNSBL user to ensure that the listing criteria and other aspects of a DNSBL meets their needs.
これらのDNSBLは、リストが意図されている目的、リストが目的を達成するために使用する方法、メソッドを監督するものの整合性、およびデータの作成と配布に使用されるテクノロジーの安定性を目的とする目的が大きく異なります。リスト基準は非常に議論の余地がある場合があります。したがって、このドキュメントでは、意図的に基準の正しさや誤りについては議論していません。これらの基準が明確かつ正確に伝達されている限り、DNSBLオペレーターは、希望するリスト基準を自由に選択できると主張します。DNSBLユーザーの責任は、DNSBLのリスト基準とその他の側面がニーズを満たすことを保証することです。
This document is intended to provide guidance to DNSBL operators so that they may be able to identify what features users would be interested in seeing as part of a high-quality, well-managed DNSBL --
このドキュメントは、DNSBLオペレーターにガイダンスを提供することを目的としているため、ユーザーが高品質で適切に管理されたDNSBLの一部として見ることに興味がある機能を特定できるようにすることを目的としています。
for example, a clear listing and delisting policy to which the DNSBL operator adheres strictly. This document is intended to be normative rather than prescriptive: it seeks to characterize the features of a well-managed DNSBL rather than setting out rules for how DNSBLs should be operated.
たとえば、DNSBLオペレーターが厳密に順守する明確なリスティングと登録ポリシー。このドキュメントは、規範的ではなく規範的であることを目的としています。DNSBLの操作方法に関するルールを設定するのではなく、適切に管理されたDNSBLの機能を特徴付けることを目指しています。
This document is not intended as a protocol specification of DNSBL queries. (See [RFC5782].)
このドキュメントは、DNSBLクエリのプロトコル仕様として意図されていません。（[RFC5782]を参照してください。）
The DNS has been the most popular distribution method for DNSBLs due to its ubiquity and its good scaling and performance characteristics. It is also common to make private arrangements to distribute DNSBL data in bulk to high-volume users, typically by rsync [RSYNC] [RSYNCTHESIS]. The data is the same in either case; the recommendations in this document apply, regardless of distribution method, other than the ones in Sections 3.1 and 3.2 that specifically refer to DNS distribution.
DNSは、その遍在性と優れたスケーリングとパフォーマンスの特性により、DNSBLSの最も一般的な分布方法です。また、DNSBLデータを大量のユーザーにバルクで配布するためのプライベートアレンジメントを行うことも一般的です。通常、RSYNC [RSYNC] [rsyncthesis]によって。どちらの場合でもデータは同じです。このドキュメントの推奨事項は、分布方法に関係なく、DNS分布を特に参照するセクション3.1および3.2のもの以外に適用されます。
When choosing to adopt a DNSBL, a DNSBL user SHOULD keep the following questions in mind:
DNSBLを採用することを選択する場合、DNSBLユーザーは次の質問を念頭に置いておく必要があります。
1. What is the intended use of the list?
1. リストの使用は何ですか？
2. Does the list have a web site?
2. リストにはWebサイトがありますか？
3. Are the list's policies stated on the web site?
3. リストのポリシーはWebサイトに記載されていますか？
4. Are the policies stated clearly and understandably?
4. ポリシーは明確かつ理解できるように述べられていますか？
5. Does the web site function properly, e.g., hyperlinks?
5. Webサイトは適切に機能しますか？たとえば、ハイパーリンク？
6. Are web pages for removal requirements accessible and working properly?
6. 削除要件のためのWebページは、適切にアクセスでき、適切に機能していますか？
7. How long has the list been in operation?
7. リストはどのくらい稼働していますか？
8. What are the demographics and quantity of the list's user base? In other words, do other sites like my own use this DNSBL?
8. リストのユーザーベースの人口統計と数量は何ですか？言い換えれば、私のような他のサイトはこのDNSBLを使用していますか？
9. Are comparative evaluations of the list available? Note: all such evaluations depend on the mail mix used as well as local policy. DNSBL users SHOULD consider trial periods and/or ongoing local monitoring of DNSBL suitability.
9. リストの比較評価は利用できますか？注：そのような評価はすべて、使用されるメールミックスとローカルポリシーに依存します。DNSBLユーザーは、試用期間および/またはDNSBL適合性の継続的なローカル監視を考慮する必要があります。
10. What do your peers or members of the Internet community say about the list? DNSBLs can sometimes be quite controversial and sometimes considerable misinformation is spread. Ensure that the opinions are knowledgeable and reflect similar goals to yours.
10. あなたの仲間やインターネットコミュニティのメンバーはリストについて何を言っていますか？DNSBLSは非常に物議を醸す場合があり、時にはかなりの誤った情報が広がっている場合があります。意見が知識が豊富であることを確認し、あなたに同様の目標を反映してください。
11. Does the DNSBL have a mailing list for announcing changes, outages, etc.?
11. DNSBLには、変更、停止などを発表するためのメーリングリストがありますか？
DNSBLs can, and have, ceased operation without notice. DNSBL users SHOULD periodically check the correct operation of the DNSBL, and cease using DNSBLs that are working incorrectly. See Section 3.3.
DNSBLSは、予告なく操作を停止することができます。DNSBLユーザーは、DNSBLの正しい操作を定期的にチェックし、誤って動作しているDNSBLSを使用して停止する必要があります。セクション3.3を参照してください。
The DNSBL user MUST ensure that they understand the intended use of the DNSBL. For example, some IP address-based DNSBLs are appropriate for assessment of only the peer IP address of the machine connecting to the DNSBL user's mail server, and not other IP addresses appearing in an email (such as header Received lines or web links) or IRC connections, etc. While a DNSBL user may choose to ignore the intent of the DNSBL, they SHOULD implement any variance in compliance with the DNSBL usage instructions.
DNSBLユーザーは、DNSBLの意図した使用を理解していることを確認する必要があります。たとえば、一部のIPアドレスベースのDNSBLは、DNSBLユーザーのメールサーバーに接続するマシンのピアIPアドレスのみの評価に適しており、メール（ヘッダー受信ラインまたはWebリンクなど）に表示される他のIPアドレスや他のIPアドレスはありません。IRC接続など。DNSBLユーザーはDNSBLの意図を無視することを選択できますが、DNSBLの使用手順に準拠して差異を実装する必要があります。
For example, one of the requirements of some DNSBLs is that if the DNSBL is used contrary to the usage instructions, then the DNSBL user should not identify the DNSBL being used. Furthermore, it is the DNSBL user's responsibility to mitigate the effect of the listing locally.
たとえば、一部のDNSBLSの要件の1つは、DNSBLが使用命令に反して使用される場合、DNSBLユーザーが使用されているDNSBLを特定しないことです。さらに、リストがローカルでの効果を軽減するのは、DNSBLユーザーの責任です。
It is the responsibility of the system administrators who adopt one or more DNSBLs to evaluate, understand, and make a determination of which DNSBLs are appropriate for the sites they administer. If you are going to allow a third party's information to guide your filtering decision-making process, you MUST understand the policies and practices of those third parties because responsibility for filter decisions remains ultimately with you, the postmaster.
1つまたは複数のDNSBLSを採用して、どのDNSBLが管理するサイトに適切であるかを評価、理解、および決定するのは、システム管理者の責任です。フィルタリングの意思決定プロセスをガイドするためにサードパーティの情報を許可する場合は、フィルターの決定の責任が最終的にポストマスターに残っているため、これらの第三者のポリシーと慣行を理解する必要があります。
A DNSBL without DNSBL users does not block (or otherwise impair) email or any other Internet service. A DNSBL user voluntarily uses the DNSBL data to guide their decisions, and the DNSBL user therefore MUST assume responsibility for dealing with the consequences.
DNSBLユーザーのないDNSBLは、電子メールやその他のインターネットサービスをブロック（または損なう）ことはありません。DNSBLユーザーはDNSBLデータを自発的に使用して決定をガイドします。したがって、DNSBLユーザーは、結果に対処する責任を負う必要があります。
DNSBL operators are expressing an opinion through the publication of a DNSBL. However, it is through abiding by the guidelines set forth in this document that the operators of a DNSBL may gain the trust of their users.
DNSBLオペレーターは、DNSBLの公開を通じて意見を表明しています。ただし、DNSBLのオペレーターがユーザーの信頼を得ることができるのは、このドキュメントに記載されているガイドラインに従っています。
These guidelines address only public DNSBLs and do not apply to private-access DNSBLs; however, implementers and users of private-access DNSBLs may wish to use these guidelines as a starting point of things to consider.
これらのガイドラインは、公開DNSBLのみに対処しており、プライベートアクセスDNSBLSには適用されません。ただし、Private-Access DNSBLSの実装者とユーザーは、これらのガイドラインを考慮すべき出発点として使用することをお勧めします。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
The Anti-Spam Research Group (ASRG) was chartered to address the spam problem. The ASRG charter includes:
スパム研究グループ（ASRG）は、スパムの問題に対処するためにチャーターされました。ASRGチャーターには以下が含まれます。
"codification of best current practices in spam management"
「スパム管理における最良の現在の慣行の成文化」
This note falls within that category by listing guidelines for management of public DNSBLs.
このメモは、パブリックDNSBLSの管理に関するガイドラインをリストすることにより、そのカテゴリに該当します。
NOTE: This document is a product of the Anti-Spam Research Group (ASRG) of the IRTF.
注：このドキュメントは、IRTFのスパム研究グループ（ASRG）の製品です。
A DNSBL SHOULD carefully describe the criteria for adding and the criteria for removing an entry from the list. Such listing and delisting criteria SHOULD be presented in a clear and readable manner easily accessible to the public on the DNSBL's web site. A DNSBL MUST abide by its stated listing and delisting criteria. Entries that do not meet the published criteria MUST NOT be added to the DNSBL.
DNSBLは、追加の基準と、リストからエントリを削除する基準を注意深く説明する必要があります。このようなリストと上場基準は、DNSBLのWebサイトで一般に簡単にアクセスできる明確で読みやすい方法で提示する必要があります。DNSBLは、指定されたリストと上場基準を順守する必要があります。公開されている基準を満たさないエントリは、DNSBLに追加してはなりません。
In other words, be direct and honest and clear about the listing criteria, and make certain that only entries meeting the published criteria are added to the list. For example, some DNSBL operators have been known to include "spite listings" in the lists they administer -- listings of IP addresses or domain names associated with someone who has insulted them, rather than actually violating technical criteria for inclusion in the list. There is nothing inherently wrong with this practice so long as it is clearly disclosed -- and thus becomes part of the published criteria. For example, a DNSBL described as only listing open relays MUST NOT include IP addresses for any other reason. This transparency
言い換えれば、リスト基準について直接的かつ正直かつ明確にし、公開された基準を満たすエントリのみがリストに追加されることを確認します。たとえば、一部のDNSBLオペレーターは、それらが管理するリストに「不意のリスト」を含めることが知られています - リストに含めるための技術的基準に実際に違反するのではなく、それらをs辱した人に関連するIPアドレスまたはドメイン名のリスト。明確に開示されている限り、このプラクティスには本質的に間違ったものは何もありません。したがって、公開された基準の一部になります。たとえば、オープンリレーのみをリストすると説明されているDNSBLは、他の理由でIPアドレスを含めてはなりません。この透明性
principle does not require DNSBL operators to disclose the precise algorithms and data involved in a listing, but rather the intent behind choosing those algorithms and data.
原則では、DNSBLオペレーターは、リストに含まれる正確なアルゴリズムとデータを開示する必要はなく、それらのアルゴリズムとデータの選択の背後にある意図を必要としません。
Furthermore, the DNSBL documentation SHOULD be clear on the intended use of the DNSBL -- whether it be intended for peer addresses of email, IRC, etc.
さらに、DNSBLのドキュメントは、DNSBLの使用意図について明確にする必要があります。
Availability of documentation concerning a DNSBL SHOULD NOT be dependent on the continued operation of DNS for DNSBL queries.
DNSBLに関するドキュメントの可用性は、DNSBLクエリ用のDNSの継続的な操作に依存してはなりません。
In other words, if the DNSBL documentation is at "http://dnsbl.example.com", the documentation for the web site should not become unavailable if the DNSBL query name servers are not available (or shut down). See Section 3.1.
言い換えれば、DNSBLのドキュメントが「http://dnsbl.example.com」にある場合、DNSBLクエリ名サーバーが使用できない（またはシャットダウン）場合、Webサイトのドキュメントは利用できないようになりません。セクション3.1を参照してください。
Listing and delisting criteria for DNSBLs SHOULD be easily available and SHOULD be located in a place clearly marked in its own section of the web site affiliated with the DNSBL.
DNSBLのリストと上場基準は簡単に入手できる必要があり、DNSBLに所属するWebサイトの独自のセクションに明確にマークされた場所に配置する必要があります。
DNSBLs often publish their listing criteria along with additional technical information about using the DNSBL. This additional technical information can confuse end users, so a separate page, section, or query function on its own SHOULD be dedicated to detailing why a specific entry appears in the DNSBL.
DNSBLSは、多くの場合、DNSBLの使用に関する追加の技術情報とともに、リスト基準を公開します。この追加の技術情報はエンドユーザーを混乱させる可能性があるため、別のページ、セクション、またはクエリ機能は、DNSBLに特定のエントリが表示される理由を詳述することに専念する必要があります。
A DNSBL SHOULD maintain an audit trail for all listings, and it is RECOMMENDED that it is made publicly available in an easy to find location, preferably on the DNSBL's web site. Please note that making data about an audit trail public does not entail revealing all information in the DNSBL operator's possession relating to the listing. For example, a DNSBL operator MAY make the audit trail data selectively accessible in such a way as to not disclose information that might assist spammers, such as the location or identity of a spam trap.
DNSBLは、すべてのリストの監査証跡を維持する必要があります。また、簡単にDNSBLのWebサイトで、簡単に見つけやすい場所で公開されることをお勧めします。監査証跡に関するデータを公開しても、リストに関連するDNSBLオペレーターの所有物のすべての情報が明らかになることはないことに注意してください。たとえば、DNSBLオペレーターは、スパムトラップの場所やIDなどのスパマーを支援する可能性のある情報を開示しないように、監査証跡データを選択的にアクセスできるようにすることができます。
Some DNSBLs have adopted policies of listing entries that are broader in scope than they have evidence of being involved in abuse. Similarly, some DNSBLs list entries that are "mixed", in that the entry may be behaving in a manner that is both abusive and non-abusive. This is inherent to the techniques that many DNSBLs use.
一部のDNSBLは、虐待に関与している証拠よりも範囲が広いエントリをリストするポリシーを採用しています。同様に、一部のDNSBLSは、「混合」のエントリをリストしています。エントリは、虐待的で非出来事の両方で動作している可能性があります。これは、多くのDNSBLが使用する手法に固有のものです。
Examples: Some DNSBLs will list IP address ranges if there is reason to believe that abusive behavior seen from a few IP addresses within the range is (or will be) reflected in the rest of the range. Some DNSBLs utilize scoring to list IP addresses, IP ranges, or domain names that have abusive behavior above some threshold -- often meaning that some of the email corresponding to the listing is not abusive. Even an entry demonstrably infected with email spam or virus-emitting malware may emit non-abusive email.
例：一部のDNSBLSは、範囲内のいくつかのIPアドレスから見られた虐待的な動作が範囲の残りの部分に反映される（またはそうなる）と信じる理由がある場合、IPアドレス範囲をリストします。一部のDNSBLSは、スコアリングを利用して、IPアドレス、IP範囲、または虐待的な動作を何らかのしきい値を超えているドメイン名をリストします。多くの場合、リストに対応する電子メールの一部が虐待的ではないことを意味します。電子メールスパムまたはウイルス放射マルウェアに明らかに感染したエントリでさえ、攻撃的でないメールを発する可能性があります。
Inevitably, some of these listings may impact non-abusive email. This has resulted in some labeling of such practices by the emotionally loaded term "collateral damage". No filtering technique is perfect, and an occasional mistake is inevitable no matter what is used, DNSBLs or otherwise.
必然的に、これらのリストのいくつかは、違反のない電子メールに影響を与える可能性があります。これにより、感情的にロードされた用語「付随的損害」によるそのような慣行のラベル付けが生じました。フィルタリング技術は完璧ではなく、DNSBLSなどを使用しても、時折の間違いは避けられません。
There is nothing wrong with this practice (of having "collateral damage") because mail server administrators may wish to implement such policies or use them in combination with other techniques (such as scoring). However, a diligent administrator needs information about these policies in order to make an informed decision as to the risk and benefit of using any particularly DNSBL, and to guide them in how to use it for results best reflecting the DNSBL user's requirements.
メールサーバー管理者は、そのようなポリシーを実装したり、他のテクニック（スコアリングなど）と組み合わせて使用したりすることを望む場合があるため、この慣行には何の問題もありません（「副次的損害」）。ただし、勤勉な管理者は、特にDNSBLを使用することのリスクと利益について情報に基づいた決定を下し、DNSBLユーザーの要件を最適な結果に使用する方法についてガイドするために、これらのポリシーに関する情報を必要としています。
Therefore, DNSBL listing policies MUST include statements as to the scope and aggressiveness of listings and include, as appropriate, whether the DNSBL operator intends the listings to be used in scoring or other techniques.
したがって、DNSBLリストポリシーには、リストの範囲と攻撃性に関するステートメントを含める必要があり、必要に応じて、DNSBLオペレーターがスコアリングまたはその他のテクニックで使用することを意図しているかどうかを含めてください。
In many cases, listings can exist for long periods of time past the conditions leading to the listing's creation, and/or listings can exist after the listed entity has putatively changed ownership.
多くの場合、リスティングの作成につながる条件を過ぎて、リスティングが長期間存在する可能性があります。
Generally speaking, listings SHOULD be considered temporary and should expire on their own at some point in the future, unless reasons for listing still exist.
一般的に言えば、リスティングは一時的なものと見なされるべきであり、リストの理由がまだ存在しない限り、将来のある時点で自分で期限切れになるはずです。
Expiration intervals SHOULD be chosen to be reasonable for the type of listing. For example:
有効期限間隔は、リストのタイプに合理的であるように選択する必要があります。例えば：
1. It does not make sense to remove entries from DNSBLs where the existence of an entry does not have a direct meaning, that is, DNSBLs that return information in addition to just existence/ non-existence. For example: entries in DNSBLs that return
1. エントリの存在が直接的な意味を持たないDNSBLSからエントリを削除することは意味がありません。つまり、存在/存在のみに加えて情報を返すDNSBLSです。例：返品するDNSBLSのエントリ
geographic or assignment information on where the IP address or domain name is located or owned, or DNSBLs that return flow statistics from the DNSBL operator that are intended for the DNSBL user to interpret, need not ever be removed, just kept reasonably current.
IPアドレスまたはドメイン名がどこにあるかまたは所有されている場所、またはDNSBLユーザーが解釈することを目的としたDNSBLオペレーターからフロー統計を返すDNSBLSに関する地理的または割り当て情報、削除する必要はありません。
2. DNSBLs based on relatively static information, such as block assignment or domain names of demonstrably bad actors, MAY have very long expiration intervals or be removed only upon request after verification that the removal criteria have been met.
2. ブロック割り当てや明らかに悪い俳優のドメイン名などの比較的静的な情報に基づいたDNSBLSは、非常に長い有効期限間隔があるか、削除基準が満たされていることを確認した後の要求に応じてのみ削除される可能性があります。
3. Automated DNSBLs with highly effective detection and fast listing mechanisms can benefit from very short expiration intervals. Many of the things that these DNSBLs look for are of relatively short duration, and even if they do expire, a resumption of the behavior will be caught quickly by the DNSBL's detection mechanisms and relisted. By utilizing a short expiration interval, after reassignment/problem correction, the listing will automatically expire in short order without manual intervention.
3. 非常に効果的な検出と高速リストメカニズムを備えた自動化されたDNSBLは、非常に短い有効期限間隔から利益を得ることができます。これらのDNSBLSが求めるものの多くは比較的短い期間であり、たとえそれらが期限切れになったとしても、行動の再開はDNSBLの検出メカニズムによって迅速に捕まえられ、再リストされます。短い有効期限間隔を利用することにより、再割り当て/問題修正の後、リストは手動介入なしに短期間で自動的に期限切れになります。
4. Manually created DNSBL entries SHOULD be periodically reviewed in some manner.
4. 手動で作成されたDNSBLエントリは、何らかの方法で定期的にレビューする必要があります。
It is RECOMMENDED that DNSBL operators publish in general terms their expiration policy, even if it's only "delist on request" or "no expiration is performed". In information-only lists, a method for users requesting corrections to the information (if appropriate) SHOULD be published. Abusers may be able to "game" policy that is too explicit; on the other hand, many DNSBL users wish to have an idea of how "current" the DNSBL is. It is the authors' experience that some automated DNSBLs have increasingly higher error rates as the "last detection date" gets older.
DNSBLオペレーターは、「リクエストに応じて廃止」または「有効期限が実行されない」場合でも、満了ポリシーを一般的に公開することをお勧めします。情報のみのリストでは、情報の修正を要求するユーザーの方法（必要に応じて）を公開する必要があります。虐待者は、明示的すぎるポリシーを「ゲーム」できる場合があります。一方、多くのDNSBLユーザーは、DNSBLがどれほど「現在」であるかを知りたいと考えています。「最後の検出日」が古くなるにつれて、一部の自動化されたDNSBLがますます高いエラー率を持っている著者の経験です。
Note that listings being temporary does not mean that all listings will expire after the initial time-out period. If the DNSBL operator determines that the conditions triggering listing still exist, then the timer for determining time outs can be renewed.
一時的なリストは、すべてのリストが初期タイムアウト期間後に期限切れになることを意味しないことに注意してください。DNSBLオペレーターがリストをトリガーする条件がまだ存在すると判断した場合、タイムアウトを決定するためのタイマーは更新できます。
Discussions about whether a DNSBL should remove an entry MAY include activity in a public forum. Methods for processing removal requests through private, direct exchanges, such as person-to-person email or a combination of web page requests and email responses, SHOULD be available. As a minimum, the DNSBL SHOULD have a web page that has a removal request function (separate from the page describing listing criteria as per Section 2.1.1). The DNSBL SHOULD also make available an email address to handle issues other than blocking issues.
DNSBLがエントリを削除すべきかどうかについての議論には、パブリックフォーラムでのアクティビティが含まれる場合があります。個人から人への電子メールやWebページのリクエストや電子メールの応答の組み合わせなど、プライベート、直接交換を介した削除要求の処理方法が利用可能です。少なくとも、DNSBLには、削除要求関数があるWebページが必要です（セクション2.1.1に従ってリスト基準を説明するページとは別）。また、DNSBLは、問題をブロックする以外の問題を処理するための電子メールアドレスを利用できるようにする必要があります。
The DNSBL operator MUST NOT use the list in question in such a way that removal requests would be blocked; and moreover, the operator SHOULD make mailboxes available in order to allow affected users to submit their requests. In some cases, it is impractical not to filter email to accounts due to the amount of spam those mailboxes receive. If filtering should be necessary in such circumstances, filtering methods with as low false positive rate as practical SHOULD be chosen.
DNSBLオペレーターは、削除要求がブロックされるように問題のリストを使用してはなりません。さらに、オペレーターは、影響を受けるユーザーがリクエストを送信できるようにするために、メールボックスを利用できるようにする必要があります。場合によっては、メールボックスが受信するスパムの量のために、アカウントにメールをフィルタリングしないことは非現実的です。このような状況でフィルタリングが必要な場合は、実用的な偽陽性率が低いフィルタリング方法を選択する必要があります。
DNSBL operators SHOULD be prepared to provide alternate means of contact in case of system failure due to DDoS (distributed denial-of-service) attack or other reasons.
DNSBLオペレーターは、DDO（分散拒否）攻撃またはその他の理由によるシステム障害の場合に、代替の接触手段を提供する準備をする必要があります。
A response to removal requests or queries about a listing SHOULD be prompt. A DNSBL operator SHOULD respond within 2 days and MUST respond within 7 days, except in the case that the DNSBL operator has deemed that further discussion of the issue will not result in meeting the conditions for removal and has notified the requestor of that decision.
リストに関する削除要求またはクエリへの応答は迅速です。DNSBLオペレーターは2日以内に応答する必要があり、DNSBLオペレーターがこの問題のさらなる議論が削除条件を満たさず、その決定の要求者に通知した場合を除き、7日以内に応答する必要があります。
Consequent removals (if the conditions for removal are met) should be similarly prompt.
結果の撤回（除去の条件が満たされている場合）も同様に迅速です。
A DNSBL MAY impose restrictions on who (e.g., a network operator's representative or domain name owner) may make valid removal requests. However, in many DNSBLs, this is inadvisable because it requires impractical amounts of effort; hence, it is NOT RECOMMENDED in most cases.
DNSBLは、WHO（たとえば、ネットワークオペレーターの代表者またはドメイン名の所有者）に有効な削除リクエストを行うことができる人に制限を課す場合があります。ただし、多くのDNSBLでは、非現実的な量の努力が必要であるため、これはめったにありません。したがって、ほとんどの場合、推奨されません。
Many DNSBLs (especially those with highly effective detection and fast listing mechanisms) greatly benefit from a "no questions asked" removal policy.
多くのDNSBL（特に非常に効果的な検出と高速リストメカニズムを備えたもの）は、「質問なしで尋ねられた」削除ポリシーから大きな恩恵を受けています。
Although this approach allows people to submit a request and have any listed IP address/domain name removed immediately, it does not prevent the DNSBL operator from relisting the IP address/domain name at a later time.
このアプローチにより、人々はリクエストを送信し、リストされたIPアドレス/ドメイン名をすぐに削除することができますが、DNSBLオペレーターが後でIPアドレス/ドメイン名を再作成することを妨げません。
Many DNSBLs can effectively use a "no questions asked" removal policy because by their very nature they will redetect or relist problems almost immediately. They can mitigate more organized attempts to "game" the system by performing elementary checking and rate-limiting procedures, increasing lockout periods, executing re-scans, etc. Furthermore, a adding or removing a few IP addresses usually does not
多くのDNSBLSは、「質問なし」の削除ポリシーを効果的に使用できます。なぜなら、それらの性質上、ほとんどすぐに問題を再検出または再リストするからです。彼らは、基本的なチェックとレート制限手順を実行し、ロックアウト期間を増やし、再装飾を実行するなど、より組織化された試みをシステムの「ゲーム」しようとすることができます。さらに、通常、いくつかのIPアドレスを追加または削除することはできません。
make a significant difference in the overall effectiveness of a DNSBL. Moreover, a "no questions asked" removal policy provides the huge benefit of a swift reaction to incorrect listings.
DNSBLの全体的な有効性に大きな違いをもたらします。さらに、「質問なし」の削除ポリシーは、誤ったリストに対する迅速な反応の大きな利点を提供します。
As an example, one popular DNSBL uses a "no questions asked" removal policy, but does perform rate-limiting and malicious removal detection and mitigation.
例として、1つの一般的なDNSBLは、「質問なし」の削除ポリシーを使用しますが、レート制限および悪意のある除去の検出と緩和を実行します。
Another important consideration supporting a "no questions asked" self-removal policy is that it forestalls many conflicts between DNSBL operators and organizations whose IP addresses/domain names have been listed. Such a policy may be an effective measure to prevent small issues from becoming big problems.
「質問なし」をサポートする別の重要な考慮事項は、自己回収ポリシーでは、DNSBLオペレーターとIPアドレス/ドメイン名がリストされている組織との間の多くの競合を未然に防ぐことです。このような政策は、小さな問題が大きな問題になるのを防ぐための効果的な手段かもしれません。
2.2.4. A Given DNSBL SHOULD Have Similar Criteria for Listing and Delisting
2.2.4. 与えられたDNSBLには、リストと上場のための同様の基準が必要です
The criteria for being removed from a DNSBL SHOULD bear a reasonable relationship to the factors that were the cause of the addition to the DNSBL. If a listed entity fulfills all published requirements for removal from a DNSBL, then the DNSBL operator SHOULD NOT impose any additional obstacles to remove a given entry from the DNSBL. There SHOULD NOT be any extra rules for delisting other than the ones listed in the published listing criteria.
DNSBLから削除される基準は、DNSBLに追加された原因である要因と合理的な関係を築く必要があります。リストされたエンティティがDNSBLから削除するために公開されたすべての要件を満たしている場合、DNSBLオペレーターは、DNSBLから特定のエントリを削除するための追加の障害を課すべきではありません。公開されているリスティング基準にリストされているもの以外に、上場廃止するための追加のルールはありません。
Some DNSBLs used for blocking/negative reputation have had a practice of requiring fees or donations to charities from the listee for delisting.
ブロッキング/ネガティブな評判に使用される一部のDNSBLは、上場廃止のためにリスティーから慈善団体に手数料または寄付を要求する慣行がありました。
It is generally considered entirely appropriate for a DNSBL to charge for access to it by its users -- the definition of a commercial DNSBL.
一般に、DNSBLがユーザーからアクセスできるように請求することは完全に適切であると考えられています - 商用DNSBLの定義。
However, the practice of requiring a listee to pay for delisting from a negative-connotation DNSBL steers perilously close to notions of extortion, blackmail, or a "protection racket". Even when such accusations are entirely unjustified, the practice causes uproar and damage to the DNSBL's reputation, if not the DNSBL mechanism as a whole.
ただし、否定的な接続DNSBLスターからの廃止の支払いをリストに要求する慣行は、恐tor、恐mail、または「保護ラケット」の概念に近いものです。そのような告発が完全に不当である場合でも、この実践は、DNSBLメカニズム全体ではないにしても、DNSBLの評判に騒動と損害を与えます。
Therefore, negative-connotation DNSBLs MUST not charge fees or require donations for delisting or "faster handling", and it is RECOMMENDED that such DNSBLs that do charge fees or require donations not be used.
したがって、否定的な接続DNSBLは、料金を請求したり、上場廃止または「より速い処理」に寄付を要求してはなりません。また、料金を請求したり、寄付を必要としないようなDNSBLを使用することをお勧めします。
By virtue of using domain names, a DNSBL is a hierarchy with a root anchored in the global Internet. The DNSBL "query root" SHOULD be below the registered domain name, so that the DNSBL information is not conflated with domain name housekeeping information (e.g., name server or MX records) for the domain name. By using this approach, DNSBL queries would take the form of "<query>.dnsbl.example.com" rather than "<query>.example.com". Further, this sub-tree should have its own name servers. Thus, the DNSBL query root has its own zone file containing the DNSBL information, and the registered domain name has its own name servers containing the information (MX records, etc.) for the domain name. This approach facilitates clear delineation of function as well as orderly DNSBL shutdown because the DNSBL name server records can be specified separately from the domain name's principal name servers.
ドメイン名を使用することにより、DNSBLはグローバルインターネットに固定されたルートを持つ階層です。DNSBLの「クエリルート」は、ドメイン名のドメイン名ハウスキーピング情報（名前サーバーまたはMXレコードなど）と混同されないように、登録済みドメイン名を下回る必要があります。このアプローチを使用することにより、DNSBLクエリは、「<Query> .example.com」ではなく「<Query> .dnsbl.example.com」の形を取得します。さらに、このサブツリーには独自の名前サーバーが必要です。したがって、DNSBLクエリルートには、DNSBL情報を含む独自のゾーンファイルがあり、登録ドメイン名には、ドメイン名の情報（MXレコードなど）を含む独自の名前サーバーがあります。このアプローチは、DNSBL名サーバーレコードをドメイン名の主要な名前サーバーとは別に指定できるため、機能の明確な描写と秩序あるDNSBLシャットダウンを容易にします。
Many DNSBLs support more than one logical zone (DNSBL entries with different meanings) that DNSBL users may wish to treat differently (or even ignore). It is RECOMMENDED that, even if there is a single DNSBL zone with entry type distinguished by return code, separate subdomain names (of the query root) consist only of the corresponding entries. For example, entry types "A" and "B" might return 127.0.0.2 and 127.0.0.3 from the consolidated zone (e.g., dnsbl.example.com), but there should also be zones typeA.dnsbl.example.com and typeB.dnsbl.example.com that contain their respective types only. See also Section 3.3.
DNSBLユーザーは、DNSBLユーザーが異なる扱いを希望する（または無視する）複数の論理ゾーン（異なる意味のあるDNSBLエントリ）をサポートしています。エントリタイプが戻りコードで区別される単一のDNSBLゾーンがある場合でも、（クエリルートの）個別のサブドメイン名が対応するエントリのみで構成されることをお勧めします。たとえば、エントリタイプ「A」と「B」は、連結ゾーン（例：dnsbl.example.com）から127.0.0.2および127.0.0.3を返す可能性がありますが、Zones typea.dnsbl.example.comおよびTypebもある必要がありますそれぞれのタイプのみを含む.dnsbl.example.com。セクション3.3も参照してください。
The DNSBL SHOULD have sufficient name server capacity to handle the expected loading and have sufficient redundancy to handle normal outages.
DNSBLは、予想される負荷を処理するのに十分な名前サーバー容量を持ち、通常の停止を処理するのに十分な冗長性を持つ必要があります。
Name servers SHOULD provide appropriate glue records, possibly in different Top-Level Domains (TLDs) to protect against single-TLD issues.
名前サーバーは、単一TLDの問題から保護するために、おそらく異なるトップレベルドメイン（TLD）で適切な接着剤レコードを提供する必要があります。
If the DNSBL offers zone transfers (in addition to or instead of standard DNSBL query mechanisms), it SHOULD be sufficiently provisioned to handle the expected loading.
DNSBLがゾーン転送を提供する場合（標準のDNSBLクエリメカニズムに加えてまたはその代わりに）、予想される負荷を処理するために十分にプロビジョニングする必要があります。
Note that some DNSBLs have been subject to DDoS attacks. Provisioning SHOULD take the likelihood of this into account and include plans for dealing with it.
一部のDNSBLはDDOS攻撃の対象となっていることに注意してください。プロビジョニングは、この可能性を考慮に入れ、それを扱う計画を含める必要があります。
Most IP address-based DNSBLs follow a convention of query entries for IP addresses in 127.0.0.0/8 (127.0.0.0-127.255.255.255) to provide online indication of whether the DNSBL is operational. Many, if not most, DNSBLs arrange to have a query of 127.0.0.2 return an A record (usually 127.0.0.2) indicating that the IP address is listed. This appears to be a de facto standard indicating that the DNSBL is operating correctly. See [RFC5782] for more details on DNSBL test entries.
ほとんどのIPアドレスベースのDNSBLSは、127.0.0.0.0/8（127.0.0.0.0-127.255.255.255）のIPアドレスのクエリエントリの慣習に従い、DNSBLが動作しているかどうかをオンラインで示しています。ほとんどではないにしても、DNSBLSは127.0.0.2のクエリにAレコード（通常は127.0.0.2）を返し、IPアドレスがリストされていることを示すように手配します。これは、DNSBLが正しく動作していることを示す事実上の標準であるように見えます。DNSBLテストエントリの詳細については、[RFC5782]を参照してください。
If this indicator is missing (query of 127.0.0.2 returns NXDOMAIN), or any query returns an A record outside of 127.0.0.0/8, the DNSBL should be considered non-functional.
このインジケータが欠落している場合（127.0.0.2のクエリがNxDomainを返します）、または任意のクエリが127.0.0.0/8以外のAレコードを返します、DNSBLは非機能と見なされる必要があります。
There does not appear to be a de facto standard for test entries within domain-name-based DNSBLs. A number of domain-name-based DNSBLs use the same 127.0.0.2 query test mechanism as IP-address-based DNSBLs, and others use a variety of domain-name-based test entries. Due to the way many domain-name-based DNSBLs are used (e.g., hostname parts of URIs in email bodies), using anything likely to appear in a legitimate email message is a bad idea (e.g., http://example.com), especially considering that some email readers will transform bare IP addresses or domain names appearing in the body of an email into links. So, even 127.0.0.2 may be problematic. But a common testing method is desirable.
ドメイン名ベースのDNSBLS内のテストエントリの事実上の標準はないようです。多くのドメイン名ベースのDNSBLSは、IPアドレスベースのDNSBLと同じ127.0.0.2クエリテストメカニズムを使用しており、その他はさまざまなドメイン名ベースのテストエントリを使用しています。多くのドメイン名ベースのDNSBLSが使用される方法により（Email BodiesのURIのホスト名部分など）、正当な電子メールメッセージに表示される可能性のあるものを使用することは悪い考えです（http://example.comなど）、特に、一部の電子メールリーダーが、電子メールの本文にリンクに表示される裸のIPアドレスまたはドメイン名を変換することを考慮してください。したがって、127.0.0.2でさえ問題があるかもしれません。しかし、一般的なテスト方法が望ましいです。
In the absence of new emerging standards, it is RECOMMENDED that domain-name-based DNSBLs use a test entry of "test". This is chosen because it is a reserved TLD.
新しい新興標準がない場合、ドメイン名ベースのDNSBLSが「テスト」のテストエントリを使用することをお勧めします。これは予約されたTLDであるために選択されます。
Note: In Section 3.4, it is noted that some DNSBLs have shut down in such a way to list all of the Internet. Further, in Section 3.5, DNSBL operators MUST NOT list 127.0.0.1. Therefore, a positive listing for 127.0.0.1 SHOULD indicate that the DNSBL has started listing the world and is non-functional. Similarly, a domain-based DNSBL SHOULD NOT ever list the reserved domain INVALID, and a positive listing for INVALID SHOULD indicate that the DNSBL is non-functional.
注：セクション3.4では、一部のDNSBLがすべてのインターネットをリストするような方法でシャットダウンしていることに注意してください。さらに、セクション3.5では、DNSBLオペレーターが127.0.0.1をリストしてはなりません。したがって、127.0.0.1の肯定的なリストは、DNSBLが世界のリストを開始し、非機能であることを示す必要があります。同様に、ドメインベースのDNSBLは、予約されたドメインが無効になっていることをリストしてはならず、無効な肯定的なリストはDNSBLが機能していないことを示す必要があります。
Other results, such as 127.0.0.3, may have different meanings. This operational flag usage and meaning SHOULD be published on the DNSBL's web site, and the DNSBL user SHOULD periodically test the DNSBL.
127.0.0.3などの他の結果には、意味が異なる場合があります。この運用フラグの使用と意味は、DNSBLのWebサイトに公開される必要があり、DNSBLユーザーはDNSBLを定期的にテストする必要があります。
Some mail systems are unable to differentiate between these various results or flags, however, so a public DNSBL SHOULD NOT include opposing or widely different meanings -- such as 127.0.0.23 for "sends good mail" and 127.0.0.99 for "sends bad mail" -- within the same DNS zone.
一部のメールシステムは、これらのさまざまな結果またはフラグを区別できないため、パブリックDNSBLには、「良いメールを送信する」の場合は127.0.0.0.23や127.0.0.99などの反対または大きく異なる意味を含めるべきではありません。" - 同じDNSゾーン内。
A number of DNSBLs have shut down operations in such a way as to list the entire Internet, sometimes without warning. These were usually done this way to force DNSBL users (mail administrators) to adjust their DNSBL client configurations to omit the now inoperative DNSBL and to shed the DNS query load from the registered domain name servers for the DNSBL. Popular DNSBLs are used by tens of thousands of sites, yet, the correct operation of the DNSBLs are not well monitored by their users. The DNSBL query clients are often not compliant with DNSBL query conventions (e.g., they will treat any A record returned as being "listed", instead of specific 127/8 A record returns), hence shutdowns (or even ordinary domain name expiration) can be quite destructive to all email flow if not done properly.
多くのDNSBLは、インターネット全体をリストするような方法で操作をシャットダウンしています。これらは通常、DNSBLユーザー（メール管理者）にDNSBLクライアントの構成を調整して、現在の動作的なDNSBLを省略し、DNSBLの登録ドメイン名サーバーからDNSクエリ負荷を削減するように強制するために行われました。人気のあるDNSBLは数万のサイトで使用されていますが、DNSBLの正しい操作はユーザーによって十分に監視されていません。DNSBLクエリクライアントは、DNSBLクエリコンベンションに準拠していないことがよくあります（たとえば、特定の127/8 Aレコードリターンではなく、「リストされている」ものとして返されるレコードを扱います）。適切に行われない場合、すべての電子メールフローを非常に破壊してください。
The DNSBL operator MUST issue impending shutdown warnings (on the DNSBL web site, appropriate mailing lists, newsgroups, vendor newsletters, etc.), and indicate that the DNSBL is inoperative using the signaling given in Section 3.3.
DNSBLオペレーターは、差し迫ったシャットダウン警告を発行する必要があります（DNSBL Webサイト、適切なメーリングリスト、ニュースグループ、ベンダーニュースレターなど）。
Only after these warnings have been issued for a significant period of time (RECOMMENDED: one or more months), should the DNSBL operator finally shutdown the DNSBL.
これらの警告がかなりの期間発行された後にのみ（推奨：1か月以上）、DNSBLオペレーターが最終的にDNSBLをシャットダウンする必要があります。
The shutdown procedure should have the following properties:
シャットダウン手順には、次のプロパティが必要です。
1. MUST NOT list the entire Internet
1. インターネット全体をリストしてはなりません
2. SHOULD shed the DNSBL query load from the DNSBL name servers, permitting the registered domain name to continue being usable.
2. DNSBL名サーバーからDNSBLクエリ負荷を削減し、登録されたドメイン名が使用可能であることを許可する必要があります。
3. SHOULD, perhaps through increased delays, indicate to the mail administrator that the DNSBL is no longer functional.
3. おそらく遅延を増やして、DNSBLが機能しなくなったことをメール管理者に示します。
4. Name server or query lookups MUST NOT be aimed at third parties unrelated to DNSBL operation. Such behavior is similar to inflicting a DDoS attack.
4. 名前サーバーまたはクエリの検索は、DNSBL操作とは関係のない第三者を対象としてはなりません。このような動作は、DDOS攻撃を与えることに似ています。
5. The base domain name SHOULD be registered indefinitely, so as to prevent the domain name from being a "booby trap" for future owners, and/or to prevent a new owner from maliciously listing the entire Internet.
5. ベースドメイン名は、ドメイン名が将来の所有者にとって「ブービートラップ」になるのを防ぐために、および/または新しい所有者がインターネット全体を悪意を持ってリストすることを防ぐために、無期限に登録する必要があります。
One way of satisfying points 1-4 above is to change the DNS name servers for the DNSBL to point at "TEST-NET" addresses (see [RFC5735]). The below suggested [BIND] declarations will cause a DNSBL query to query non-existent name servers in TEST-NET addresses, which will result in a significant delay (usually more delay as the number of non-existent TEST-NET name servers is increased), but will not return any A records except in very unusual circumstances.
上記のポイント1-4を満たす1つの方法は、DNSBLのDNS名サーバーを変更して「テストネット」アドレスを指すことです（[RFC5735]を参照）。以下の提案された[BIND]宣言により、DNSBLクエリがTest-Netアドレスで存在しない名前サーバーをクエリすることができます。これにより、大幅な遅延が発生します（通常、存在しないTest-Net名前サーバーの数が増加するにつれて遅延が大きくなります。）、しかし、非常に異常な状況を除いて記録を返しません。
BIND-equivalent DNS declarations for DNSBL shutdown.
DNSBLシャットダウンのバインド等価DNS宣言。
dnsbl.example.com. 604800 IN NS u1.example.com. u1.example.com. 604800 IN A 192.0.2.1
dnsbl.example.com。NS U1.example.comの604800。u1.example.com。192.0.2.1の604800
dnsbl.example.com. 604800 IN NS u2.example.com. u2.example.com. 604800 IN A 192.0.2.2
dnsbl.example.com。NS U2.example.comの604800。u2.example.com。192.0.2.2の604800
dnsbl.example.com. 604800 IN NS u3.example.com. u3.example.com. 604800 IN A 192.0.2.3
dnsbl.example.com。ns u3.example.comの604800。u3.example.com。192.0.2.3の604800
... [as many NS/A record pairs as you like]
... [好きなように多くのns/aレコードペア]
This example assumes that the DNSBL is named "dnsbl.example.com". Replace "example.com" and "dnsbl.example.com" as appropriate for the DNSBL.
この例では、DNSBLに「DNSBL.EXAMPLE.COM」という名前が付けられていることを前提としています。DNSBLに適した「Example.com」と「DNSBL.Example.com」を置き換えます。
NOTE: Of course, the above shutdown procedure cannot be implemented if Section 3.1 is not followed.
注：もちろん、セクション3.1が守られていない場合、上記のシャットダウン手順は実装できません。
The DNSBL MAY list loopback, [RFC1918], LINK-LOCAL class [RFC3927], class D/E, and any other permanently reserved or special-use IP addresses [RFC5735] (and [RFC5156] for IPv6). Such use MUST be disclosed in the documentation related to the DNSBL.
DNSBLは、Loopback、[RFC1918]、Link-Local Class [RFC3927]、クラスD/E、およびIPV6のその他の永続的に予約されたまたは特別使用IPアドレス[RFC5735]（および[RFC5156]をリストする場合があります。このような使用は、DNSBLに関連するドキュメントで開示する必要があります。
As additional insurance against listings of space that should not be listed through testing or other unforeseen events, DNSBL operators SHOULD consider implementing facilities to prevent them. At least one popular automated DNSBL has implemented permanent exclusions for such addresses.
テストやその他の予期せぬイベントを通じてリストされるべきではないスペースのリストに対する追加の保険として、DNSBLオペレーターは、それらを防ぐために施設を実装することを検討する必要があります。少なくとも1つの一般的な自動化されたDNSBLは、このようなアドレスの永続的な除外を実装しています。
A functioning DNSBL MUST NOT list 127.0.0.1. There are a number of mail server implementations that do not cope with this well, and many will use a positive response for 127.0.0.1 as an indication that the DNSBL is shut down and listing the entire Internet.
機能するDNSBLは、127.0.0.1をリストしてはなりません。これにはうまく対処しない多くのメールサーバーの実装があり、DNSBLがシャットダウンしてインターネット全体をリストしていることを示すために、127.0.0.1に対して肯定的な応答を使用します。
Some DNSBLs list IP addresses of hosts that are insecure in various ways (e.g., open relays, open proxies). The following recommendations for such DNSBLs may not be relevant to other types of DNSBLs.
一部のDNSBLSは、さまざまな方法で安全でないホストのIPアドレスをリストします（例：オープンリレー、オープンプロキシ）。そのようなDNSBLに関する以下の推奨事項は、他のタイプのDNSBLには関係ない場合があります。
The practice of scanning for vulnerabilities can represent a risk in some jurisdictions. The following recommendations for such DNSBLs MAY help alleviate this risk.
脆弱性をスキャンする慣行は、一部の管轄区域のリスクを表すことができます。このようなDNSBLに関する以下の推奨事項は、このリスクを軽減するのに役立つ場合があります。
DNSBLs MUST NOT automatically probe for insecure hosts without provocation. There is little agreement in the community as to whether or not such activity should be allowed, so this document errs on the side of caution.
DNSBLSは、挑発せずに、安全でないホストのために自動的にプローブしてはなりません。コミュニティでは、そのような活動が許可されるべきかどうかについてはほとんど合意されていないため、この文書は注意を払っています。
Therefore, scanning MUST be targeted, rather than broad-based, where a given scan is motivated by a specific reason to have concern about the address being scanned. Examples of such reasons include delivery of an email, delivery to a spam trap address, receipt of a user complaint, or periodic testing of an address that is already listed.
したがって、スキャンは、特定の理由により、特定の理由により、アドレスがスキャンされていることを懸念する特定の理由により、スキャンをターゲットにする必要があります。このような理由の例には、電子メールの配信、スパムトラップアドレスへの配信、ユーザーの苦情の受信、またはすでにリストされている住所の定期的なテストが含まれます。
If the DNSBL operator re-scans a host in order to determine whether the listing SHOULD time out or not, the re-scan period SHOULD be reasonable. Automated scanning SHOULD NOT occur more often than once every 24 hours.
DNSBLオペレーターが、リスティングがタイムアウトする必要があるかどうかを判断するためにホストを再スキャンする場合、再スキャン期間は妥当でなければなりません。自動スキャンは、24時間ごとに1回以上発生することはありません。
It is RECOMMENDED that automated re-scanning should cease within a reasonable period of the vulnerability no longer existing and of the targeting conditions no longer being met.
自動化された再スキャニングは、脆弱性の合理的な期間内に存在しなくなり、ターゲティング条件が満たされなくなることをお勧めします。
In the past, some scanning mechanisms have proven to adversely impact the scanned host, sometimes in severe fashion. Scanning methodologies MUST NOT negatively impact the scanned host.
過去には、一部のスキャンメカニズムは、スキャンされたホストに悪影響を与えることが証明されています。スキャン方法論は、スキャンされたホストに悪影響を及ぼしてはなりません。
If removals cannot be automated (e.g., via robot re-testing or self-removal), then the DNSBL SHOULD have multiple administrators so that a removal request can be processed if the principal list administrator is on vacation or otherwise unavailable.
削除を自動化できない場合（たとえば、ロボットの再テストや自己除去を介して）、DNSBLには複数の管理者がいる必要があり、プリンシパルリスト管理者が休暇中またはその他の方法で利用できない場合に削除要求を処理できるようにします。
It is not altogether uncommon for DNSBL users to configure their systems improperly for DNSBL queries. The consequences of an error can range from undue (or even damaging) load on the DNSBL servers to accidentally blocking all incoming email.
DNSBLユーザーがDNSBLクエリ用にシステムを不適切に構成することは完全に珍しくありません。エラーの結果は、DNSBLサーバーの過度の（または損傷している）負荷から、すべての入っている電子メールを誤ってブロックするまでの範囲です。
DNSBL users MUST test their initial DNSBL configurations to ensure that they're working correctly and SHOULD periodically recheck the status of the DNSBLs they use and adjust their configuration as necessary.
DNSBLユーザーは、初期のDNSBL構成をテストして、使用しているDNSBLのステータスを定期的に再確認し、必要に応じて構成を調整する必要があります。
Common types of misconfigurations include:
誤解の一般的なタイプは次のとおりです。
1. Using wrong (sub-)zones for querying (e.g., 4.3.2.1.example.com or 4.3.2.1.dnsbl.exmple.cm instead of 4.3.2.1.dnsbl.example.com).
1. クエリに間違った（サブ）ゾーンを使用します（例：4.3.2.1.dnsbl.exmple.cmの代わりに4.3.2.1.dnsbl.exmple.cmなど）。
2. Downloading a local mirror of the data, but failing to set up the local name server infrastructure appropriately, and thus continuing to query the public name servers.
2. データのローカルミラーをダウンロードしますが、ローカルネームサーバーインフラストラクチャのセットアップを適切に設定できないため、パブリックネームサーバーの照会を継続します。
3. Downloading a local mirror of the data, but misconfiguring the local name server infrastructure to query a locally invented zone name (4.3.2.1.dnsbl.local) at the public name servers.
3. データのローカルミラーをダウンロードしますが、ローカルネームサーバーインフラストラクチャを誤解して、パブリックネームサーバーでローカルに発明されたゾーン名（4.3.2.1.dnsbl.local）を照会します。
4. Misconfiguring local name servers to not do meaningful caching, thus heavily increasing load on the public name servers.
4. ローカルネームサーバーに意味のあるキャッシュを行わないように誤解しているため、パブリックネームサーバーの負荷が大幅に増加します。
5. Using the DNSBL query root domain name as the name server for queries.
5. DNSBLクエリルートドメイン名をクエリの名前サーバーとして使用します。
6. Using the DNSBL incorrectly, e.g., some DNSBLs are suitable only for certain types of filtering. Improper use may result in excessive incorrect filtering.
6. DNSBLを誤って使用すると、たとえば、一部のDNSBLは、特定の種類のフィルタリングにのみ適しています。不適切な使用により、過度の誤ったフィルタリングが発生する可能性があります。
While in many cases it can be difficult to detect such situations, to protect against such misconfiguration, it is RECOMMENDED that DNSBL operators make design decisions to mitigate the impact of such mistakes and make efforts to contact administrative contacts to remedy the situation where appropriate. But the DNSBL operator SHOULD also prepare to take appropriate steps to protect the operational infrastructure (e.g., have the ability to block abusive users from causing further damage).
多くの場合、そのような状況を検出することは困難な場合がありますが、そのような誤解から保護するために、DNSBLオペレーターは、そのような間違いの影響を軽減し、必要に応じて状況を改善するために管理連絡先に連絡する努力をするために設計上の決定を下すことをお勧めします。しかし、DNSBLオペレーターは、運用インフラストラクチャを保護するための適切な措置を講じる準備もする必要があります（たとえば、虐待的なユーザーがさらなる損害を引き起こすことをブロックする能力を持っています）。
Appropriate use of the DNSBL SHOULD be documented on the web site.
DNSBLの適切な使用は、Webサイトに文書化する必要があります。
From time to time, DNSBLs have encountered operational data integrity or data collection problems that have resulted in improper listings. For example: data corruption, erroneous restoration of resolved listings, or grossly misfiring detection heuristics. This often results in great consternation over what appear to be nonsensical listings or listings for previously resolved issues.
DNSBLSは、不適切なリストをもたらした運用データの整合性またはデータ収集の問題に遭遇しています。例：データの破損、解決されたリストの誤った復元、またはひどく失敗した検出ヒューリスティック。これにより、以前に解決された問題の無意味なリストまたはリストと思われるものについて、多くの場合、大きな驚きをもたらします。
Many DNSBLs have implemented policies and procedures whereby such situations result in the purging of even slightly doubtful entries, disconnection of untrustworthy components until the entries' validity or correct operation of the component can be verified or corrected, as well as notification of the issue on the DNSBL's web pages.
多くのDNSBLは、そのような状況により、エントリのエントリの有効性またはコンポーネントの正しい操作が検証または修正されるまで、わずかに疑わしいエントリのパージ、信頼できないコンポーネントの切断をもたらすポリシーと手順を実装しています。DNSBLのWebページ。
As an example, one popular DNSBL has a demonstrated track record of disabling faulty data collection mechanisms, purging all listings generated by the faulty mechanism, and publishing a brief description of the problem and course of remediation.
例として、1つの一般的なDNSBLには、故障したデータ収集メカニズムの無効化、故障したメカニズムによって生成されたすべてのリストのパージ、問題と修復コースの簡単な説明を公開する実績が実証されています。
Therefore, DNSBLs SHOULD have policies and procedures in place to treat operational problems conservatively, be prepared to mass purge dubious entries, prevent future erroneous entries, and notify their users by the DNSBL's web page.
したがって、DNSBLには、保守的に運用上の問題を扱うためのポリシーと手順が整っている必要があります。疑わしいエントリを大量にパージし、将来の誤ったエントリを防ぎ、DNSBLのWebページでユーザーに通知する準備をしてください。
Any system manager that uses DNSBLs is entrusting part of his or her server management to the parties that run the lists. A DNSBL manager that decided to list 0/0 (which has actually happened) could cause every server that uses the DNSBL to reject all mail. Conversely, if a DNSBL manager removes all of the entries (which has also happened), systems that depend on the DNSBL will find that their filtering doesn't work as they want it to.
DNSBLSを使用するシステムマネージャーは、リストを実行する当事者にサーバー管理の一部を委託しています。0/0（実際に発生した）をリストすることを決定したDNSBLマネージャーは、DNSBLを使用するすべてのサーバーにすべてのメールを拒否する可能性があります。逆に、DNSBLマネージャーがすべてのエントリ（これも発生している）を削除した場合、DNSBLに依存するシステムは、フィルタリングが必要に応じて機能しないことがわかります。
If a registered domain name used for a DNSBL is allowed to lapse, or the DNSBL user spells the DNSBL domain name incorrectly, the system manager's server management is now subject to an entirely different party than was intended. Further, even if there is no malicious intent, some DNSBL query clients will interpret any A record being returned as being listed. DNSBL users SHOULD be prepared to periodically test the DNSBLs they use for correct operation.
DNSBLに使用される登録ドメイン名が失効することが許可されている場合、またはDNSBLユーザーがDNSBLドメイン名を誤って綴る場合、システムマネージャーのサーバー管理は、意図したものとはまったく異なるパーティの対象となります。さらに、悪意のある意図がない場合でも、一部のDNSBLクエリクライアントは、リストされていると返されるレコードを解釈します。DNSBLユーザーは、正しい操作に使用するDNSBLを定期的にテストする準備をする必要があります。
Like all DNS-based mechanisms, DNSBLs are subject to various threats outlined in [RFC3833].
すべてのDNSベースのメカニズムと同様に、DNSBLは[RFC3833]で概説されているさまざまな脅威の影響を受けます。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、Moskowitz、R.、Karrenberg、D.、Groot、G。、およびE. Lear、「Private Internetsのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, May 2005.
[RFC3927] Cheshire、S.、Aboba、B。、およびE. Guttman、「IPv4 Link-Localアドレスの動的構成」、RFC 3927、2005年5月。
[BIND] Internet Systems Corporation, "ISC BIND", <http://www.isc.org/software/bind>.
[Bind] Internet Systems Corporation、「ISC Bind」、<http://www.isc.org/software/bind>。
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004.
[RFC3833] Atkins、D。およびR. Austein、「ドメイン名システムの脅威分析（DNS）」、RFC 3833、2004年8月。
[RFC5156] Blanchet, M., "Special-Use IPv6 Addresses", RFC 5156, April 2008.
[RFC5156] Blanchet、M。、「Special-Use IPv6アドレス」、RFC 5156、2008年4月。
[RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", BCP 153, RFC 5735, January 2010.
[RFC5735] Cotton、M。およびL. Vegoda、「Special Use IPv4アドレス」、BCP 153、RFC 5735、2010年1月。
[RFC5782] Levine, J., "DNS Blacklists and Whitelists", RFC 5782, February 2010.
[RFC5782] Levine、J。、「DNSブラックリストとホワイトリスト」、RFC 5782、2010年2月。
[RSYNC] Tridgell, A., "rsync", <http://rsync.samba.org/>.
[rsync] Tridgell、A。、 "rsync"、<http://rsync.samba.org/>。
[RSYNCTHESIS] Tridgell, A., "Efficient Algorithms for Sorting and Synchronization", <http://samba.org/~tridge/phd_thesis.pdf>.
[rsyncthesis] Tridgell、A。、「ソートと同期のための効率的なアルゴリズム」、<http://samba.org/~tridge/phd_thesis.pdf>。
We would like to thank John R. Levine, Alan Murphy, and Dave Crocker for their insightful comments.
ジョン・R・レヴァイン、アラン・マーフィー、デイブ・クロッカーに洞察に富んだコメントをしてくれたことに感謝します。
We would also like to thank Yakov Shafranovich and Nick Nicholas for editing draft versions of this document.
また、このドキュメントのドラフトバージョンを編集してくれたYakov ShafranovichとNick Nicholasにも感謝します。
Authors' Addresses
著者のアドレス
Chris Lewis Nortel Networks
クリス・ルイス・ノーテルネットワーク
EMail: clewisbcp@cauce.org
Matt Sergeant Symantec Corporation
マット軍曹シマンテックコーポレーション
EMail: matt@sergeant.org