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
ベストメール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.
この文書はインターネットResearch Task Force（IRTF）の製品です。 IRTFはインターネット関連の研究開発活動の成果を公表しています。これらの結果は、展開に適していない可能性があります。このRFCはインターネットResearch Task Force（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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2012 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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
この文書では、BCP 78との日に有効な（http://trustee.ietf.org/license-info）IETFドキュメントに関連IETFトラストの法律の規定に従うもの
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.
スパムやインターネット上のネットワーク虐待の他の形態の上昇量に、多くのコミュニティのメンバーと企業は、作成、公開およびDNSベースのレピュテーションシステム（DNSベースのリストやのDNSBL）IPアドレスまたはドメイン名を維持して作るようになりましたこれらの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：（多くの場合、元の電子メールアドレスまたはDNS PTR（IPを逆に）検索のドメイン名部分（RHS =右辺）に対して適用される）だけでなく/が悪い振る舞い電子メールの送信元ドメイン名のリスト
URIBL: listings of well/ill-behaving web link domain names or host names used in email
URIBL：電子メールで使用されるよく/悪い振る舞いウェブリンクドメイン名またはホスト名のリスト
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のユーザーがパスとしてリストを使用する必要はありません/バイナリ決定を失敗する - それは一緒に複数の要因を得点に基づいて意思決定を行うメールフィルターに一つの要因としてリストを使用することができます。
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 /ドメインの推定に割り振られる地理どの領域に基づいて結果を返す実装、実装自律システム番号（ASN）および/または割当ブロックにIP /ドメインアドレスを変換する、実装が存在します照会ドメイン名が与えられたドメインレジストラ、その上の別のシステムの電子メールシステムから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.
この分野での専門用語がよく形式化されていないとして、多くの場合、この文書は、一般的にDNSベースのリストにないだけでDNSベースのブロック（または黒）を参照するために用語「のDNSBL」を使用するように書かれている、オーバーラップし、かつ高精度に欠けますリスト。この文書は、（必要に応じて言及した）一部の地域では、いくつかの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.
DNSBLは、パブリックまたはプライベートのいずれであってもよいです。プライベート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.
電子メールの送信者に関する評判データを配布するためのドメインネームシステム（DNS）を使用して、最初に公に利用可能なDNSBLは、スパムがネットワーク事業者と電子メール管理者にとって問題となった直後に、1997年に登場しました。静的（不変）IP /ドメインのアドレスに位置する既知のスパムソースを識別することに焦点を当てたこのパイオニアDNSBL。これによってDNSBLの広範な採用に、それは静的なスパムソースに大きな影響を与えました。その結果、乱用者は、このようなセキュリティで保護されていない電子メールサーバやWebページ上の欠陥formmailスクリプトを通じてメッセージを中継としてのスパムを配信するための他の方法を見つけました。追加の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 -- 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演算子は、厳密に準拠しています。この文書は、むしろ規範より規範的であることを意図している：それはかなりの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は、その普遍性とその優れたスケーリングとパフォーマンスの特性に起因するのDNSBLのための最も人気の配布方法でした。典型的には、[RSYNC] [RSYNCTHESIS]のrsyncによって、また、大量のユーザーに一括でDNSBLデータを配信するために、民間手配をするのが一般的です。データは、いずれの場合においても同様です。この文書に記載されている推奨事項は、具体的にはDNS分布を参照し、セクション3.1および3.2に以外の配信方法、にかかわらず、適用されます。
When choosing to adopt a DNSBL, a DNSBL user SHOULD keep the following questions in mind:
DNSBLを採用することを選択すると、DNSBLのユーザーが念頭に置いて、次の質問を保つ必要があります。
6. Are web pages for removal requirements accessible and working properly?
6.アクセスし、正常に動作し除去の要件については、Webページはありますか？
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.あなたの同僚やインターネットコミュニティのメンバーがリストについて何を言うのですか？ DNSBLは時々かなり物議を、時にはかなりの誤報が広がっていることができます。意見が精通しているとあなたと同様の目標を反映していることを確認してください。
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.
、そして持つことができるのDNSBLは、予告せずに操作を中止しました。 DNSBLユーザーは、定期的にDNSBLの正しい動作を確認して、間違って働いているのDNSBLを使用して中止すべきです。 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アドレスの評価のために適切である、といない（例えば、ヘッダReceived行やWebリンクなど）、電子メールに登場する他の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.
例えば、いくつかのDNSBLの要件の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.
これは、評価を理解し、そしてのDNSBLは、彼らが管理するサイトに適しているかの決定を行うために、1つ以上のDNSBLを採用し、システム管理者の責任です。あなたは、フィルタリングの意思決定プロセスを案内する第三者の情報をできるようにしようとしている場合は、フィルタの決定のための責任は、あなたと一緒に最終的にはpostmaster残るので、あなたはそれらの第三者の方針や慣行を理解する必要があります。
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に対処し、プライベート・アクセスのDNSBLには適用されません。しかし、プライベート・アクセスのDNSBLの実装とユーザーが考慮すべき事柄の出発点として、これらのガイドラインを使用することもできます。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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.
このノートでは、公共のDNSBLの管理のためのガイドラインを一覧表示することで、そのカテゴリ内にあります。
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のウェブサイト上の公衆へ簡単にアクセス明確かつ読みやすい形で提示されるべきです。 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 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.
言い換えれば、上場基準に関する直接的かつ正直で明確にし、公表基準を満たす唯一のエントリがリストに追加されていることを確認してください。それらを侮辱ではなく、実際には、リストに含めるための技術的基準に違反している誰かに関連付けられたIPアドレスのリストまたはドメイン名 - たとえば、いくつかのDNSBLオペレータは、それらが管理するリストで「にもかかわらずリスト」を含むことが知られています。したがって、公表された基準の一部となります - この練習で、本質的には何も問題は、それが明確に開示されているようにはありません。たとえば、唯一のオープンリレーをリストとして記述DNSBLは、他の理由でIPアドレスを含めることはできません。この透過性の原則は、正確なアルゴリズムとデータのリストに関わるのではなく、これらのアルゴリズムとデータを選択するの背後にある意図を開示する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.
それは、電子メールのピアアドレス、IRCなどのために意図するかどうか - さらに、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と提携したウェブサイトの独自のセクションにマークの場所に配置する必要があります。
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.
DNSBLは、多くの場合、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のウェブサイト上で、場所を見つけることは容易で公開されていることが推奨されます。監査証跡公共に関するデータを作成することは上場に関連するDNSBLオペレータの保有するすべての情報を明らかに伴わないことに注意してください。例えば、DNSBLオペレータは、このようなスパムトラップの場所や身元などスパマーを助けるかもしれない情報を開示しないような方法で監査証跡データを選択的にアクセスできるようにするかもしれません。
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は、彼らが虐待に関与しているの証拠を持っているよりも範囲が広いですエントリをリストの政策を採用しています。同様に、「混合」されているいくつかのDNSBLリストエントリは、そのエントリには、不正および非乱用の両方であるように振る舞うことができます。これは、多くの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.
例：範囲の残りの部分に反映さの範囲内で、いくつかのIPアドレスから見た虐待行動がある（または予定）と考えられる理由がある場合、一部のDNSBLは、IPアドレスの範囲を一覧表示されます。いくつかのDNSBLは、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.
必然的に、これらのリストの一部は、非虐待的な電子メールに影響を与える可能性があります。これは感情的にロードされた用語「巻き添え被害」により、このような慣行のいくつかのラベルをもたらしました。いいえフィルタリング技術は完璧ではありません、そして時折間違いは、関係なく使用されているもののDNSBLか、そうでない場合は避けられません。
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 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.
1.これは、エントリの存在は直接的な意味を持っていないのDNSBLからエントリを削除しても意味がありません、それは、ただの存在/非存在に加えて、情報を返すのDNSBLです。例：IPアドレスまたはドメイン名がありますか所有している場所の地理的または割り当ての情報を返すのDNSBLのエントリ、または解釈するのDNSBLのユーザーのために意図されているDNSBLオペレータからのフロー統計情報を返すのDNSBLは、削除され、これまで必要はありません、単に合理的に現在のまま。
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のDNSBLは、非常に長い有効期限の間隔を有していてもよいか、除去基準が満たされていることを確認した後にのみ、要求に応じて削除されます。
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は、非常に短い有効期限の間隔の恩恵を受けることができます。これらのDNSBLが求めていること、物事の多くは、比較的短期のものである、と彼らは有効期限が切れても、行動の再開が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は（2.1.1項に従って上場基準を記述したページとは別の）削除要求機能を持つWebページを持っているべきです。 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オペレータが原因のDDoS（分散サービス拒否）攻撃または他の理由により、システム障害が発生した場合に接触の代替手段を提供するために準備されるべきです。
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は、（例えば、ネットワークオペレータの代表者やドメイン名の所有者）の有効な除去の請求をすることができる人に制限を課すことができます。それは努力の非現実的な量を必要とするためしかし、多くの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アドレス/ドメイン名を持つことができますが、それは後でIPアドレス/ドメイン名を再出品からDNSBL演算子を防ぐことはできません。
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 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は、効果的に、彼らが再検出またはほとんどすぐに問題を再出品しますので、その性質上、「何の質問が尋ねた」削除ポリシーを使用することができます。彼らは通常、大きな違いはありませんいくつかのIPアドレスを追加または削除、さらに、基本チェックとレート制限の手順を実行するロックアウト期間を増やし、再スキャンを実行することによって、「ゲーム」システムに、より組織の試みなどを軽減することができます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.
自己削除ポリシー「何の質問尋ねない」を支えるもう一つの重要な考慮事項は、それがIPアドレス/ドメイン名が記載されているDNSBL事業者や組織の間に多くの紛争を未然にということです。このような政策は大きな問題になってから、小さな問題を防止するための有効な対策かもしれません。
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は上場廃止のためのlisteeから慈善団体への手数料や寄付金を必要とする練習を持っていました。
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から上場廃止の支払いにlisteeを必要とするの実践は、危険なほど近くに恐喝、恐喝、または「保護ラケット」の概念に操縦します。こうした非難は全く不当なときでも、実際には、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「クエリルートは、」ドメイン名、登録されたドメイン名未満であるべきです。このアプローチを使用することにより、DNSBLクエリはなく、「<問い合わせ> .dnsbl.example.com」「<問い合わせ> .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を返すかもしれませんが、また、ゾーン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は、予想されるロードを処理するのに十分なネームサーバの能力を持っており、通常の停止を処理するのに十分な冗長性を持つべきである（SHOULD）。
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アドレスベースのDNSBLはDNSBLが動作しているかどうかのオンライン表示を提供するために、127.0.0.0/8（127.0.0.0-127.255.255.255）でのIPアドレスのクエリエントリの規則に従ってください。ほとんど、のDNSBLは127.0.0.2のクエリを持つように手配していない場合、多くは、返すレコード（通常は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の外レコードを返す場合、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.
ドメイン名ベースのDNSBL内のテスト項目のデファクトスタンダードがあるように表示されません。ドメイン名ベースのDNSBLの数は、IPアドレスベースのDNSBL同じ127.0.0.2クエリテスト機構を使用し、そして他のものは、ドメイン名ベースのテストエントリのさまざまな使用します。多くのドメイン名ベースのDNSBLが使用されている方法（電子メール体中の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.
新興の規格が存在しない場合には、ドメイン名ベースのDNSBLは、「テスト」のテストエントリを使用することをお勧めします。それは予約済みの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は、今までに予約したドメインが無効なリストではありません必要があり、INVALIDのためのポジティブリストが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のウェブサイト上で公開されるべきである、と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.99「良いメールを送信する」ための127.0.0.23などを「悪いメールを送信「 - 同じ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の登録ドメインネームサーバからのDNSクエリの負荷を流すために彼らのDNSBLクライアントの設定を調整するDNSBLユーザー（メール管理者）を強制するために、この方法を実施しました。人気のDNSBLはのDNSBLの正しい動作はよく自分のユーザーによって監視されていない、サイトの数万人が使用し、まだされています。 DNSBLクエリクライアントは、多くの場合、DNSBLクエリ規則に準拠していない（例えば、彼らが扱うレコードが代わりに特定の8分の127で、「記載されている」されていると返されたレコードを返します）、したがって、シャットダウン（あるいは通常のドメイン名の有効期限）することができます適切に行われていない場合、すべてのメールフローに非常に破壊的で。
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のウェブサイト上で、適切なメーリングリスト、ニュースグループ、ベンダーのニュースレターなど）差し迫ったシャットダウン警告を発行し、DNSBLは3.3節で与えられたシグナリングを使用して動作不能であることを示す必要があります。
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:
シャットダウン手順は、次の特性を持っている必要があります。
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のいずれかの方法は、「TEST-NET」アドレス（[RFC5735]を参照）をポイントするDNSBLのDNSネームサーバを変更することです。下の[BIND]宣言は存在しないTEST-NETのネームサーバの数が増加すると大幅な遅延（通常より遅れにつながるれ、TEST-NETアドレスに存在しないネームサーバを照会するためのDNSBLクエリが発生します示唆しました）が、非常に特殊な状況を除き、任意のAレコードを返しません。
BIND-equivalent DNS declarations for DNSBL shutdown.
DNSBLのシャットダウンのためのBIND相当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、IN 604800。 u1.example.com。 192.0.2.1、IN 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、IN 604800。 u2.example.com。 192.0.2.2、IN 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、IN 604800。 u3.example.com。 192.0.2.3、IN 604800
... [as many NS/A record pairs as you like]
... [あなたが好きなように多くのNS /レコードペアとして]
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 MAYリストループバック、[RFC1918]、リンクローカルクラス[RFC3927]、クラスD / E、および他の永続的予約または特殊用途のIPアドレス[RFC5735]（およびIPv6の[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オペレータは、それらを防止するための機能を実装することを検討すべきです。少なくとも一つの人気のある自動化された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.
さまざまな方法（例えば、オープンリレー、オープンプロキシ）に安全ではないホストのいくつかのDNSBLリスト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.
DNSBLは自動的に挑発することなく、安全でないホストをプローブしてはなりません。そこコミュニティにはほとんど合意は、このような活動は許可すべきか否かであるので、この文書では、注意の側面にERRS。
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.example.com又は代わり4.3.2.1.dnsbl.example.comの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の適切な使用は、ウェブサイト上の文書化されなければなりません。
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.
時々、のDNSBLは、不適切なリストをもたらした運用データの整合性やデータ収集の問題に遭遇しました。たとえば、次のようにデータの破損、解決リストの誤修復、または肉眼的に検出ヒューリスティックを失火。これは、多くの場合、以前に解決された問題のために無意味なリストやリストのように見えるものをかけて大きな驚愕になります。
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は、保守的に運用上の問題を治療するための場所でのポリシーと手順を持つべきである（SHOULD）質量パージ怪しげなエントリに調製することが、将来の誤入力を防止し、かつ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.
DNSBLを使用するすべてのシステム管理者は、リストを実行する当事者に自分のサーバ管理の一部を委託しています。 （実際に起こっている）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.、モスコウィッツ、R.、Karrenberg、D.、グルート、G.、およびE.リア、 "個人的なインターネットのための配分"、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]チェシャー、S.、Aboba、B.、およびE.ガットマン、 "IPv4のリンクローカルアドレスの動的構成"、RFC 3927、2005年5月。
[BIND] Internet Systems Corporation, "ISC BIND", <http://www.isc.org/software/bind>.
[BIND]インターネットシステムズ株式会社、 "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]アトキンス、D.とR. Austeinと、RFC 3833 "ドメインネームシステム（DNS）の脅威分析"、2004年8月。
[RFC5156] Blanchet, M., "Special-Use IPv6 Addresses", RFC 5156, April 2008.
[RFC5156]ブランシェ、M.、 "特殊用途のIPv6アドレス"、RFC 5156、2008年4月。
[RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", BCP 153, RFC 5735, January 2010.
[RFC5735]コットン、M.およびL. Vegoda、 "特別の使用のIPv4アドレス"、BCP 153、RFC 5735、2010年1月。
[RFC5782] Levine, J., "DNS Blacklists and Whitelists", RFC 5782, February 2010.
[RFC5782]レヴァイン、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>。
Appendix A. Acknowledgements
付録A.謝辞
We would like to thank John R. Levine, Alan Murphy, and Dave Crocker for their insightful comments.
私たちは、彼らの洞察に満ちたコメントにジョンR. Levine氏、アラン・マーフィー、とDaveクロッカーに感謝したいと思います。
We would also like to thank Yakov Shafranovich and Nick Nicholas for editing draft versions of this document.
また、この文書の草案を編集するためのヤコフShafranovichとニック・ニコラスに感謝したいと思います。
Authors' Addresses
著者のアドレス
Chris Lewis Nortel Networks
クリス・ルイスノーテルネットワークス
EMail: clewisbcp@cauce.org
メールアドレス：clewisbcp@cauce.org
Matt Sergeant Symantec Corporation
マット軍曹シマンテックコーポレーション
EMail: matt@sergeant.org
メールアドレス：matt@sergeant.org