Internet Research Task Force (IRTF) J. Levine
Request for Comments: 5782 Taughannock Networks
Category: Informational February 2010
ISSN: 2070-1721
DNS Blacklists and Whitelists
Abstract
抽象
The rise of spam and other anti-social behavior on the Internet has led to the creation of shared blacklists and whitelists of IP addresses or domains. The DNS has become the de-facto standard method of distributing these blacklists and whitelists. This memo documents the structure and usage of DNS-based blacklists and whitelists, and the protocol used to query them.
インターネット上でスパムやその他の反社会的行動の上昇は、IPアドレスまたはドメインの共有ブラックリストとホワイトリストの作成につながっています。 DNSは、これらのブラックリストとホワイトリストを配布の事実上の標準的な方法となっています。このメモは、構造およびDNSベースのブラックリストとホワイトリストの使用方法、およびそれらを照会するために使用されるプロトコルについて説明します。
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/rfc5782.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5782で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 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 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
Table of Contents
目次
1. Introduction ....................................................2
2. Structure of an IP Address DNSBL or DNSWL .......................3
2.1. IP Address DNSxL ...........................................3
2.2. IP Address DNSWL ...........................................4
2.3. Combined IP Address DNSxL ..................................4
2.4. IPv6 DNSxLs ................................................5
3. Domain Name DNSxLs ..............................................6
4. DNSxL Cache Behavior ............................................7
5. Test and Contact Addresses ......................................7
6. Typical Usage of DNSBLs and DNSWLs ..............................8
7. Security Considerations .........................................9
8. References .....................................................10
8.1. Normative References ......................................10
8.2. Informative References ....................................10
In 1997, Dave Rand and Paul Vixie, well-known Internet software engineers, started keeping a list of IP addresses that had sent them spam or engaged in other behavior that they found objectionable. Word of the list quickly spread, and they started distributing it as a BGP feed for people who wanted to block all traffic from listed IP addresses at their routers. The list became known as the Real-time Blackhole List (RBL).
1997年、デイブ・ランドとポール・ヴィクシー、よく知られているインターネット・ソフトウェア・エンジニアは、彼らにスパムを送信したり、彼らが不快見つけた他の行動に従事していたIPアドレスのリストを保持し始めました。リストの言葉が急速に普及し、彼らは、ルータに掲載されているIPアドレスからのすべてのトラフィックをブロックしたい人のためのBGPフィードとして、それを配布し始めました。リストは、リアルタイムブラックホールリスト（RBL）として知られるようになりました。
Many network managers wanted to use the RBL to block unwanted e-mail, but weren't prepared to use a BGP feed. Rand and Vixie created a DNS-based distribution scheme that quickly became more popular than the original BGP distribution. Other people created other DNS-based blacklists either to compete with the RBL or to complement it by listing different categories of IP addresses. Although some people refer to all DNS-based blacklists as "RBLs", the term properly is used for the Mail Abuse Prevention System (MAPS) RBL, the descendant of the original list. (In the United States, the term RBL is a registered service mark of Trend Micro [MAPSRBL].)
多くのネットワーク管理者は、不要な電子メールをブロックするためにRBLを使用していたが、BGPフィードを使用する準備ができていませんでした。ランドといるVixieはすぐに元BGP分布よりも人気になったDNSベースのディストリビューション・スキームを作成しました。他の人々はRBLと競争したり、IPアドレスの異なるカテゴリをリストすることによって、それを補完するためにいずれかの他のDNSベースのブラックリストを作成しました。一部の人々は、「いるRBL」など、すべてのDNSベースのブラックリストに言及しているが、この用語は、適切にメール乱用防止システム（MAPS）RBL、元のリストの子孫のために使用されています。 （米国では、用語RBLは[MAPSRBL]トレンドマイクロの登録サービスマークです。）
The conventional term is now DNS blacklist or blocklist, or DNSBL. Some people also publish DNS-based whitelists or DNSWLs. Network managers typically use DNSBLs to block traffic and DNSWLs to preferentially accept traffic. The structure of a DNSBL and DNSWL are the same, so in the subsequent discussion we use the abbreviation DNSxL to mean either.
従来の用語は現在、DNSブラックリストまたはブロックリスト、またはDNSBLです。一部の人々はまた、DNSベースのホワイトリストまたはDNSWLsを公開します。ネットワーク管理者は、通常、優先トラフィックを受け入れるようにトラフィックとDNSWLsをブロックするためのDNSBLを使用しています。 DNSBLとDNSWLの構造は同じなので、その後の議論では、我々は、いずれかを意味する略語DNSxLを使用しています。
This document defines the structure of DNSBLs and DNSWLs. It describes the structure, operation, and use of DNSBLs and DNSWLs but does not describe or recommend policies for adding or removing addresses to and from DNSBLs and DNSWLs, nor does it recommend policies for using them. We anticipate that management policies will be addressed in a companion document.
この文書では、のDNSBLとDNSWLsの構造を定義します。それはのDNSBLとDNSWLsの構造、操作、および使用が記載されているが、記述したりするとのDNSBLとDNSWLsからアドレスを追加または削除するポリシーをお勧めしません。また、それらを使用するためのポリシーをお勧めしません。私たちは、経営方針が仲間ドキュメントで対処されることを期待しています。
This document is a product of the Anti-Spam Research Group (ASRG) of the Internet Research Task Force. It represents the consensus of the ASRG with respect to practices to improve interoperability of DNS-based blacklists and whitelists.
このドキュメントはインターネットリサーチタスクフォースのアンチスパム研究グループ（ASRG）の製品です。これは、DNSベースのブラックリストとホワイトリストの相互運用性を向上させるための実践に関してASRGのコンセンサスを表しています。
Requirements Notation: 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], with respect to recommendations for improving technical interoperability of DNSxLs.
要件表記：キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "べきではありません"、 "推奨"、 "すべきである" "ないものと"、 "MAY"、および "オプション" でこのドキュメントは[RFC2119]に記載されているようにDNSxLsの技術的相互運用性を改善するための推奨事項に関して、解釈されるべきです。
A DNSxL is a zone in the DNS [RFC1034] [RFC1035]. The zone containing resource records identifies hosts present in a blacklist or whitelist. Hosts were originally encoded into DNSxL zones using a transformation of their IP addresses, but now host names are sometimes encoded as well. Most DNSxLs still use IP addresses.
DNSxLはDNS [RFC1034]、[RFC1035]でゾーンです。リソースレコードを含むゾーンは、ブラックリストまたはホワイトリスト中に存在するホストを識別する。ホストは、もともと自分のIPアドレスの変換を使用してDNSxLゾーンにエンコードされたが、今のホスト名は、時にはとしてもエンコードされています。ほとんどのDNSxLsはまだIPアドレスを使用します。
An IPv4 address DNSxL has a structure adapted from that of the rDNS. (The rDNS, reverse DNS, is the IN-ADDR.ARPA [RFC1034] and IP6.ARPA [RFC3596] domains used to map IP addresses to domain names.) Each IPv4 address listed in the DNSxL has a corresponding DNS entry. The entry's name is created by reversing the order of the octets of the text representation of the IP address, and appending the domain name of the DNSxL.
IPv4アドレスDNSxLはDNS逆のものから適合構造を有しています。 （DNS逆に、DNSの逆、IN-ADDR.ARPA [RFC1034]であり、ドメイン名にIPアドレスをマッピングするために使用IP6.ARPA [RFC3596]ドメイン。）DNSxLにリストされた各IPv4アドレスは、対応するDNSエントリを有しています。エントリの名前は、IPアドレスのテキスト表現のオクテットの順序を逆にし、DNSxLのドメイン名を追加することによって作成されます。
If, for example, the DNSxL is called bad.example.com, and the IPv4 address to be listed is 192.0.2.99, the name of the DNS entry would be 99.2.0.192.bad.example.com. Each entry in the DNSxL MUST have an A record. DNSBLs SHOULD have a TXT record that describes the reason for the entry. DNSWLs MAY have a TXT record that describes the reason for the entry. The contents of the A record MUST NOT be used as an IP address. The A record contents conventionally have the value 127.0.0.2, but MAY have other values as described below in Section 2.3. The TXT record describes the reason that the IP address is listed in the DNSxL, and is often used as the text of an SMTP error response when an SMTP client attempts to send mail to a server using the list as a DNSBL, or as explanatory text when the DNSBL is used in a scoring spam filter. The DNS records for this entry might be:
例えば、DNSxLがbad.example.comと呼ばれ、IPv4アドレスをリストする場合は、DNSエントリの名前が99.2.0.192.bad.example.comになり、192.0.2.99です。 DNSxLの各エントリはAレコードを持っていなければなりません。 DNSBLは、エントリの理由を説明するTXTレコードを持っているべきです。 DNSWLsは、エントリの理由を説明するTXTレコードを持っているかもしれません。 Aレコードの内容は、IPアドレスとして使用してはいけません。レコードの内容は、従来値127.0.0.2を有するが、2.3節で以下に説明するように他の値を有することができます。 TXTレコードは、IPアドレスがDNSxLに記載されていることを理由を説明し、SMTPクライアントはDNSBLとして、または説明テキストとしてリストを使用してサーバーにメールを送信しようとしたとき、多くの場合、SMTPエラー応答のテキストとして使用されていますDNSBLは、スコアリングスパムフィルタで使用されている場合。このエントリのDNSレコードは次のようになります。
99.2.0.192.bad.example.com A 127.0.0.2 99.2.0.192.bad.example.com TXT "Dynamic address, see http://bad.example.com?192.0.2.99"
99.2.0.192.bad.example.com A 127.0.0.2 99.2.0.192.bad.example.com TXT "ダイナミックアドレス、http://bad.example.com?192.0.2.99を参照してください"
Some DNSxLs use the same TXT record for all entries, while others provide a different TXT record for each entry or range of entries that describes the reason that entry or range is listed. The reason often includes the URL of a web page where more information is available. Client software MUST check the A record and MAY check the TXT record.
他のエントリまたは範囲が表示されていることを理由を説明するエントリの各エントリまたは範囲について異なるTXTレコードを提供しながら、いくつかのDNSxLsは、すべてのエントリに対して同じTXTレコードを使用します。その理由は、多くの場合、より多くの情報が利用可能であるウェブページのURLを含んでいます。クライアントソフトウェアは、Aレコードをチェックしなければなりませんし、TXTレコードをチェックすることができます。
If a range of addresses is listed in the DNSxL, the DNSxL MUST contain an A record (or a pair of A and TXT records) for every address in the DNSxL. Conversely, if an IP address is not listed in the DNSxL, there MUST NOT be any records for the address.
アドレスの範囲をDNSxLにリストされている場合、DNSxLはDNSxL内のすべてのアドレスのAレコード（またはAおよびTXTレコードのペア）を含まなければなりません。 IPアドレスがDNSxLに記載されていない場合は逆に、アドレスのすべてのレコードがあってはなりません。
Since SMTP has no way for a server to advise a client why a request was accepted, TXT records in DNSWLs are not very useful. Some DNSWLs contain TXT records anyway to document the reasons that entries are present.
SMTPは、要求が受け入れられた理由を、サーバがクライアントに助言するための方法がないので、DNSWLsでTXTレコードは非常に有用ではありません。いくつかのDNSWLsは、エントリが存在しているの理由を文書化するために、とにかくTXTレコードが含まれています。
It is possible and occasionally useful for a DNSxL to be used as a DNSBL in one context and a DNSWL in another. For example, a DNSxL that lists the IP addresses assigned to dynamically assigned addresses on a particular network might be used as a DNSWL on that network's outgoing mail server or intranet web server, and used as a DNSBL for mail servers on other networks.
DNSxL一のコンテキストでDNSBL別にDNSWLとして使用することが可能であり、時には有用です。たとえば、動的に特定のネットワーク上のアドレスを割り当てられたために割り当てられたIPアドレスを表示しますDNSxLは、そのネットワークの送信メールサーバーやイントラネットWebサーバー上DNSWLとして使用されるかもしれない、と他のネットワーク上のメールサーバーのDNSBLとして使用します。
In many cases, an organization maintains a DNSxL that contains multiple entry types, with the entries of each type constituting a sublist. For example, an organization that publishes a DNSBL listing sources of unwanted e-mail might wish to indicate why various addresses are included in the list, with one sublist for addresses listed due to sender policy, a second list for addresses of open relays, a third list for hosts compromised by malware, and so forth. (At this point, all of the DNSxLs with sublists of which we are aware are intended for use as DNSBLs, but the sublist techniques are equally usable for DNSWLs.)
多くの場合、組織は、サブリストを構成する各タイプのエントリと、複数のエントリタイプを含むDNSxLを維持します。たとえば、不要な電子メールのソースをリストDNSBLを公開する組織力は、送信者のポリシーに記載されているアドレスのための1つのサブリスト、オープンリレーのアドレスのための第二のリスト、Aで、さまざまなアドレスがリストに含まれている理由を示すことを望むかもしれません等マルウェアによって損なわ、およびホストの第3のリスト。 （この時点で、我々は認識している部分リストとDNSxLsのすべてのDNSBLとしての使用のために意図されているが、サブリスト技術はDNSWLsにも同様に使用可能です。）
There are three common methods of representing a DNSxL with multiple sublists: subdomains, multiple A records, and bit-encoded entries. DNSxLs with sublists SHOULD use both subdomains and one of the other methods.
サブドメイン、複数のAレコード、およびビット・エンコードされたエントリ：複数のサブリストでDNSxLを代表する3つの一般的な方法があります。サブリストでDNSxLsは、両方のサブドメインや他の方法のいずれかを使用すべきです。
Sublist subdomains are merely subdomains of the main DNSxL domain. If for example, bad.example.com had two sublists 'relay' and 'malware', entries for 192.0.2.99 would be 99.2.0.192.relay.bad.example.com or 99.2.0.192.malware.bad.example.com. If a DNSxL contains both entries for a main domain and for sublists, sublist names MUST be at least two characters and contain non-digits, so there is no problem of name collisions with entries in the main domain, where the IP addresses consist of digits or single hex characters.
サブリストのサブドメインは、単にメインDNSxLドメインのサブドメインです。例えば、bad.example.comは2つのサブリスト「リレー」と「マルウェア」を持っていた場合は、192.0.2.99のエントリは99.2.0.192.relay.bad.example.comまたは99.2.0.192.malware.bad.example.comだろう。 DNSxLがメインドメインのためにとサブリストのための両方のエントリが含まれている場合は、サブリストの名前には、少なくとも2つの文字で、数字以外が含まれているので、IPアドレスは数字で構成メインドメイン内のエントリ、との名前の衝突の問題はありませんしなければなりませんまたは単一の六角文字。
To minimize the number of DNS lookups, multiple sublists can also be encoded as bit masks or multiple A records. With bit masks, the A record entry for each IP address is the logical OR of the bit masks for all of the lists on which the IP address appears. For example, the bit masks for the two sublists might be 127.0.0.2 and 127.0.0.4, in which case an entry for an IP address on both lists would be 127.0.0.6:
DNSルックアップの数を最小限にするために、複数のサブリストは、ビットマスクまたは複数のAレコードとして符号化することができます。ビットマスクを使用すると、各IPアドレスのAレコードエントリは、IPアドレスが表示されるリストのすべてのための論理ORビットマスクです。例えば、二つのサブリストのビットマスクは両方のリスト上のIPアドレスのエントリが127.0.0.6になり、その場合には127.0.0.2と127.0.0.4、次のようになります。
With multiple A records, each sublist has a different assigned value such as 127.0.1.1, 127.0.1.2, and so forth, with an A record for each sublist on which the IP address appears:
複数のAレコードでは、各サブリストは、IPアドレスが表示される各サブリストのレコードでは、そのような等々127.0.1.1、127.0.1.2、およびなど、さまざま割り当てられた値があります。
99.2.0.192.bad.example.com A 127.0.1.1 99.2.0.192.bad.example.com A 127.0.1.2
99.2.0.192.bad.example.com A 127.0.1.1 99.2.0.192.bad.example.com A 127.0.1.2
There is no widely used convention for mapping sublist names to bits or values, beyond the convention that all A values SHOULD be in the 127.0.0.0/8 range to prevent unwanted network traffic if the value is erroneously used as an IP address.
すべての値は、値が誤ってIPアドレスとして使用される場合、不要なネットワークトラフィックを防ぐために、127.0.0.0/8範囲でなければならない規則を超えビットまたは値にマッピングするサブリストの名前には広く使用されている規則は、存在しません。
DNSxLs that return multiple A records sometimes return multiple TXT records as well, although the lack of any way to match the TXT records to the A records limits the usefulness of those TXT records. Other combined DNSxLs return a single TXT record.
AレコードにTXTレコードに一致する方法の欠如は、これらのTXTレコードの有用性を制限しているが、複数のAレコードが時々、同様に複数のTXTレコードを返す返すDNSxLs。その他の組み合わせDNSxLsは、単一のTXTレコードを返します。
The structure of DNSxLs based on IPv6 addresses is adapted from that of the IP6.ARPA domain defined in [RFC3596]. Each entry's name MUST be a 32-component hex nibble-reversed IPv6 address suffixed by the DNSxL domain. The entries contain A and TXT records, interpreted the same way as they are in IPv4 DNSxLs.
IPv6アドレスに基づいてDNSxLsの構造は、[RFC3596]で定義さIP6.ARPAドメインのものから適合されています。各エントリの名前はDNSxLドメインサフィックス32成分の六角ニブル反転IPv6アドレスでなければなりません。エントリはAとTXTレコードが含まれ、彼らがIPv4 DNSxLsであると同じように解釈。
For example, to represent the address:
たとえば、アドレスを表すために：
2001:db8:1:2:3:4:567:89ab
2001：DB8：1：2：3：4：567：89ab
in the DNSxL ugly.example.com, the entry might be:
DNSxLのugly.example.comに、エントリは次のようになります。
b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.8.b.d.0.1.0.0.2. ugly.example.com. A 127.0.0.2 TXT "Spam received."
b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.8.b.d.0.1.0.0.2。 ugly.example.com。 127.0.0.2 TXT「迷惑メールを受信しました。」
Combined IPv6 sublist DNSxLs are represented the same way as IPv4 DNSxLs, replacing the four octets of IPv4 address with the 32 nibbles of IPv6 address.
合わせたIPv6のサブリストDNSxLsは、IPv6アドレスの32ニブルでIPv4アドレスの4つのオクテットを置き換える、IPv4のDNSxLsと同じように表現されます。
A single DNSxL could in principle contain both IPv4 and IPv6 addresses, since the different lengths prevent any ambiguity. If a DNSxL is represented using traditional zone files and wildcards, there is no way to specify the length of the name that a wildcard matches, so wildcard names would indeed be ambiguous for DNSxLs served in that fashion.
異なる長さは、任意の曖昧さを防ぐため単一DNSxLは、原則的に、IPv4およびIPv6アドレスの両方を含むことができます。 DNSxLsはそのやり方で提供していますためDNSxLは、伝統的なゾーンファイルとワイルドカードを使用して表現されている場合は、ワイルドカードが一致する名前の長さを指定する方法はありませんので、ワイルドカードの名前は確かにあいまいになります。
A few DNSxLs list domain names rather than IP addresses. They are sometimes called RHSBLs, for right-hand-side blacklists. The names of their entries MUST contain the listed domain name followed by the name of the DNSxL. The entries contain A and TXT records, interpreted the same way as they are in IPv4 DNSxLs.
いくつかのDNSxLsリストのドメイン名ではなくIPアドレス。彼らは時々右手側のブラックリストのために、RHSBLsと呼ばれています。そのエントリの名前がDNSxLの名前に続いて記載されているドメイン名を含まなければなりません。エントリはAとTXTレコードが含まれ、彼らがIPv4 DNSxLsであると同じように解釈。
If the DNSxL were called doms.example.net, and the domain invalid.edu were to be listed, the entry would be named invalid.edu.doms.example.net:
DNSxLがdoms.example.netと呼ばれ、ドメインinvalid.eduが記載されていることがあった場合は、エントリがinvalid.edu.doms.example.net次のような名前になります
invalid.edu.doms.example.net A 127.0.0.2 invalid.edu.doms.example.net TXT "Host name used in phish"
invalid.edu.doms.example.net A 127.0.0.2 invalid.edu.doms.example.net TXT「フィッシングに使用されるホスト名」
Name-based DNSBLs are far less common than IP address based DNSBLs. There is no agreed convention for wildcards.
名前ベースのDNSBLは、IPアドレスベースのDNSBLよりもはるかに少ない共通しています。ワイルドカードには合意された規則はありません。
Name-based DNSWLs can be created in the same manner as DNSBLs, and have been used as simple reputation systems with the values of octets in the A record representing reputation scores and confidence values, typically on a 0-100 or 0-255 scale. Vouch By Reference [RFC5518] is a certification system similar in design and operation to a name-based DNSWL.
名前ベースDNSWLsはのDNSBLと同様にして作成することができ、典型的には0-100又は0-255スケールで、レピュテーションスコアおよび信頼値を表すレコードのオクテットの値を持つ単純な評判システムとして使用されてきました。参考文献[RFC5518]で保証名ベースDNSWLに設計及び動作が類似認証システムです。
The per-record time-to-live and zone refresh intervals of DNSBLs and DNSWLs vary greatly depending on the management policy of the list. The Time to Live (TTL) and refresh times SHOULD be chosen to reflect the expected rate of change of the DNSxL. A list of IP addresses assigned to dynamically allocated dialup and DHCP users could be expected to change slowly, so the TTL might be several days and the zone refreshed once a day. On the other hand, a list of IP addresses that had been observed sending spam might change every few minutes, with comparably short TTL and refresh intervals.
あたりのレコードの生存時間のDNSBLとDNSWLsのゾーンリフレッシュ間隔が大幅リストの経営方針によって異なります。 （TTL）のライブと時間をリフレッシュする時間がDNSxLの変化期待収益率を反映するように選択すべきです。動的にダイヤルアップおよびDHCPユーザーを割り当てられるために割り当てられたIPアドレスのリストは、ゆっくりと変化することが期待できるので、TTLは数日と一日一回リフレッシュゾーンかもしれません。一方、スパムを送信観察されたIPアドレスのリストは、比較的短いTTLで、数分ごとに変更し、間隔をリフレッシュすることがあります。
IPv4-based DNSxLs MUST contain an entry for 127.0.0.2 for testing purposes. IPv4-based DNSxLs MUST NOT contain an entry for 127.0.0.1.
IPv4ベースDNSxLsは、テスト目的のために127.0.0.2のエントリが含まれていなければなりません。 IPv4ベースDNSxLsは、127.0.0.1のエントリを含めることはできません。
DNSBLs that return multiple values SHOULD have multiple test addresses so that, for example, a DNSBL that can return 127.0.0.5 would have a test record for 127.0.0.5 that returns an A record with the value 127.0.0.5, and a corresponding TXT record.
例えば、127.0.0.5を返すことができDNSBLが値127.0.0.5でレコードを返す127.0.0.5ためのテスト記録、および対応するTXTレコードを持っているでしょう、ように複数の値を返すのDNSBLは、複数のテストアドレスを持つべきです。
IPv6-based DNSxLs MUST contain an entry for ::FFFF:7F00:2 (::FFFF: 127.0.0.2), and MUST NOT contain an entry for ::FFFF:7F00:1 (::FFFF: 127.0.0.1), the IPv4-Mapped IPv6 Address [RFC4291] equivalents of the IPv4 test addresses.
IPv6ベースDNSxLsがため:: FFFFエントリを含まなければなりません：7F00：2（:: FFFF：127.0.0.2）とのための:: FFFFエントリを含んでいてはならない：7F00：1（:: FFFF：127.0.0.1） IPv4マップIPv6アドレス[RFC4291] IPv4検査用アドレスの同等物。
Domain-name-based DNSxLs MUST contain an entry for the [RFC2606] reserved domain name "TEST" and MUST NOT contain an entry for the reserved domain name "INVALID".
[RFC2606]の項目を含まなければならないドメイン名に基づくDNSxLsは、ドメイン名「TEST」を予約し、予約されたドメイン名を「無効」のエントリを含めることはできません。
DNSxLs also MAY contain A and/or AAAA records at the apex of the DNSxL zone that point to a web server, so that anyone wishing to learn about the bad.example.net DNSBL can check http://bad.example.net.
bad.example.netのDNSBLについて学習したい人はhttp://bad.example.netを確認することができるようにDNSxLsも、ウェブサーバーを指すDNSxLゾーンの頂点にAおよび/またはAAAAレコードを含むかもしれません。
The combination of a test address that MUST exist and an address that MUST NOT exist allows a client system to check that a domain still contains DNSxL data, and to defend against DNSxLs that deliberately or by accident install a wildcard that returns an A record for all queries. DNSxL clients SHOULD periodically check appropriate test entries to ensure that the DNSxLs they are using are still operating.
存在しなければなりませんテストアドレスの組み合わせが存在してはならないアドレスは、クライアントシステムがドメインがまだDNSxLデータが含まれていることを確認するために、故意または事故により、すべてのAレコードを返すワイルドカードをインストールDNSxLsを防御することができますクエリ。 DNSxLクライアントは定期的に、彼らが使用しているDNSxLsがまだ動作していることを確認するために、適切なテスト項目をチェックする必要があります。
DNSxLs can be served either from standard DNS servers, or from specialized servers like rbldns [RBLDNS] and rbldnsd [RBLDNSD] that accept lists of IP addresses and Classless Inter-Domain Routing (CIDR) ranges and synthesize the appropriate DNS records on the fly. Organizations that make heavy use of a DNSxL usually arrange for a private mirror of the DNSxL, either using the standard Full Zone Transfer (AXFR) and Incremental Zone Transfer (IXFR) or by fetching a file containing addresses and CIDR ranges for the specialized servers. If a /24 or larger range of addresses is listed, and the zone's server uses traditional zone files to represent the DNSxL, the DNSxL MAY use wildcards to limit the size of the zone file. If for example, the entire range of 192.0.2.0/24 were listed, the DNSxL's zone could contain a single wildcard for *.2.0.192.bad.example.com.
DNSxLsは[RBLDNS]標準のDNSサーバから、またはrbldnsのような専用サーバのいずれかから提供し、IPアドレスのリストとクラスレスドメイン間ルーティング（CIDR）範囲を受け入れて、その場で適切なDNSレコードを合成すること[RBLDNSD] rbldnsdすることができます。 DNSxLを多用する組織は、通常、標準完全ゾーン転送（AXFR）と増分ゾーン転送（IXFR）を使用して、またはアドレスとCIDRは、専門的なサーバー用の範囲を含むファイルをフェッチすることによって、DNSxLのプライベートミラーを手配します。アドレスの/ 24以上の範囲が表示されている場合は、ゾーンのサーバはDNSxLを表現するために、伝統的なゾーンファイルを使用して、DNSxLは、ゾーンファイルのサイズを制限するために、ワイルドカードを使用するかもしれません。例えば、192.0.2.0/24の全範囲が表示されていた場合は、DNSxLのゾーンは* .2.0.192.bad.example.comのための単一のワイルドカードを含めることができます。
DNSBL clients are most often mail servers or spam filters called from mail servers. There's no requirement that DNSBLs be used only for mail, and other services such as Internet Relay Chat (IRC) use them to check client hosts that attempt to connect to a server.
DNSBLクライアントは、ほとんどの場合、メールサーバから呼び出されたサーバーやスパムフィルタを郵送しています。そこだけメールに使用することのDNSBL必要はないのです、そして、インターネットリレーチャット（IRC）などの他のサービスでは、サーバーに接続しようとクライアントホストを確認するためにそれらを使用しています。
A client MUST interpret any returned A record as meaning that an address or domain is listed in a DNSxL. Mail servers that test combined lists most often handle them the same as single lists and treat any A record as meaning that an IP address is listed without distinguishing among the various reasons it might have been listed. DNSxL clients SHOULD be able to use bit masks and value range tests on returned A record values in order to select particular sublists of a combined list.
クライアントは、任意のアドレスまたはドメインがDNSxLに記載されていることを意味するものとしてレコードを返さ解釈する必要があります。テスト組み合わせリストは、ほとんどの場合、単一のリストとしてそれらを同じに扱うとIPアドレスは、それが記載されている可能性のあるさまざまな理由の中で区別せずにリストされていることを意味するものとして任意のレコードを処理するメールサーバ。 DNSxLクライアントは、組み合わされたリストの特定のサブリストを選択するために、返されたレコードの値にビットマスク及び値範囲テストを使用することができるべきです。
Mail servers typically check a list of DNSxLs on every incoming SMTP connection, with the names of the DNSxLs set in the server's configuration. A common usage pattern is for the server to check each list in turn until it finds one with a DNSBL entry, in which case it rejects the connection, or one with a DNSWL entry, in which case it accepts the connection. If the address appears on no list at all (the usual case for legitimate mail), the mail server accepts the connection. In another approach, DNSxL entries are used as inputs to a weighting function that computes an overall score for each message.
メールサーバーは通常、サーバの設定で設定されDNSxLsの名前で、すべての着信SMTP接続でDNSxLsのリストを確認してください。それが接続を受け入れる場合には、それが接続を拒否した場合にDNSBLエントリ、を有するもの、又はDNSWLエントリを持つものを、見つかるまでサーバは順番に各リストを確認するための一般的な使用パターンです。アドレスは全くリスト（正当なメールのための通常の場合）に表示された場合は、メールサーバーが接続を受け付けます。別のアプローチでは、DNSxLエントリは、各メッセージの全体的なスコアを計算する重み関数への入力として使用されます。
The mail server uses its normal local DNS cache to limit traffic to the DNSxL servers and to speed up retests of IP addresses recently seen. Long-running mail servers MAY cache DNSxL data internally, but MUST respect the TTL values and discard expired records.
メールサーバは、DNSxLサーバへのトラフィックを制限するために、最近見たIPアドレスの再テストをスピードアップするために、通常のローカルDNSキャッシュを使用しています。長時間実行されるメールサーバーは、内部DNSxLデータをキャッシュしてもよいが、TTL値を尊重し、期限切れのレコードを捨てなければなりません。
An alternate approach is to check DNSxLs in a spam filtering package after a message has been received. In that case, the IP(s) to test are usually extracted from "Received:" header fields or URIs in the body of the message. The DNSxL results can be used to make a binary accept/reject decision, or in a scoring system.
別のアプローチは、メッセージを受信した後に、スパムフィルタリングパッケージにDNSxLsをチェックすることです。メッセージの本体内のヘッダフィールド又はURIを：その場合は、試験にIP（複数可）は、通常、「受信」から抽出されます。 DNSxL結果は、バイナリを受け入れる/決定を拒否し、またはスコアリングシステムにするために使用することができます。
Packages that test multiple header fields MUST be able to distinguish among values in lists with sublists because, for example, an entry indicating that an IP address is assigned to dialup users might be treated as a strong indication that a message would be rejected if the IP address sends mail directly to the recipient system, but not if the message were relayed through an ISP's mail server.
例えば、IPアドレスがユーザーをダイアルアップに割り当てられていることを示すエントリがIP場合、メッセージは拒否されることを強く示すものとして扱われるかもしれない、ため複数のヘッダフィールドをテストパッケージは、サブリストとリスト内の値を区別できなければなりませんアドレスは、受信者のシステムに直接メールを送信しますが、メッセージはISPのメールサーバを経由して中継されたされていない場合。
Name-based DNSBLs have been used both to check domain names of e-mail addresses and host names found in mail headers, and to check the domains found in URLs in message bodies.
名前ベースのDNSBLは、メールヘッダで見つかった電子メールアドレスとホスト名のドメイン名を確認するために、そしてメッセージ本文中のURLで見つかったドメインをチェックするために、両方を使用されています。
Any system manager that uses DNSxLs is entrusting part of his or her server management to the parties that run the lists, and SHOULD ensure that the management policies for the lists are consistent with the policies the system manager intends to use. Poorly chosen DNSBLs might block addresses that send mail that the system manager and the system's users wish to receive. The management of DNSBLs can change over time; in some cases, when the operator of a DNSBL has wished to shut it down, he has either removed all entries from the DNSBL or installed a wildcard to list 0/0, which would produce unexpected and unwanted results for anyone using the DNSBL.
DNSxLsを使用するすべてのシステム管理者は、リストを実行する当事者に自分のサーバ管理の一部を委託され、リストの経営方針は、システム管理者が使用しようとする政策と一致していることを確認する必要があります。不十分な選択のDNSBLは、システム管理者およびシステムのユーザーが受信したいメールを送信するアドレスをブロックする可能性があります。 DNSBLの管理は、時間の経過とともに変化することができます。 DNSBLのオペレータがそれをシャットダウンすることを望んだたいくつかのケースでは、彼はDNSBLからすべてのエントリを削除またはDNSBLを使用して誰のための予期しない、不要な結果を生み出す0/0を、一覧表示するには、ワイルドカードをインストールしましたか。
The A records in a DNSxL zone (other than the ones at the apex of the zone) represent blacklist and/or whitelist entries rather than IP addresses. Should a client attempt to use the A records as IP addresses, e.g., attempt to use a DNSxL entry name as a web or FTP server, peculiar results would ensue. If the operator of the DNSxL were to disregard the advice in Section 2.3 and put values in the A records outside of the 127/8 range, the peculiar results might not be limited to the host misusing the records. Conversely, if a system attempts to use a zone that is not a DNSxL as a blacklist or whitelist, yet more peculiar results will ensue. This situation has been observed in practice when an abandoned DNSBL domain was re-registered and the new owner installed a wildcard with an A record pointing to a web server. To avoid this situation, systems that use DNSxLs SHOULD check for the test entries described in Section 5 to ensure that a domain actually has the structure of a DNSxL, and SHOULD NOT use any DNSxL domain that does not have correct test entries.
（ゾーンの頂点における以外）DNSxLゾーン内のAレコードはブラックリストおよび/またはホワイトリストエントリはなくIPアドレスを表します。クライアントの試みが、例えばIPアドレス、ウェブやFTPサーバなどDNSxLエントリ名を使用しようとする試みとして、Aレコードを使用する必要があり、独特の結果は結果として起きるでしょう。 DNSxLのオペレータは、2.3節でのアドバイスを無視し、8分の127範囲外のAレコードに値を入れていた場合には、独特の結果は、レコードを悪用ホストに限定されないことがあります。逆に、システムがブラックリストまたはホワイトリストとしてDNSxLないゾーンを使用しようとし、さらにより特有の結果は、続いて起こるかどう。放棄されたDNSBLドメインが再登録されたとき、この状況は、実際に観測されており、新しい所有者は、Webサーバーを指すAレコードでワイルドカードをインストールしました。この状況を回避するには、第5節に記載された試験項目をチェックする必要がありDNSxLsを使用するシステムでは、ドメインが実際にDNSxLの構造を有していることを確実にするために、正しいテストエントリを持たない任意のDNSxLドメインを使用しないでください。
Since DNSxL users usually make a query for every incoming e-mail message, the operator of a DNSxL can extract approximate mail volume statistics from the DNS server logs. This has been used in a few instances to estimate the amount of mail individual IP addresses or IP blocks send [SENDERBASE] [KSN].
DNSxLユーザーは通常、すべての受信電子メールメッセージのクエリを作るので、DNSxLのオペレータは、DNSサーバーのログからおおよそのメールの量の統計情報を抽出することができます。これは、[SENDERBASE] [KSN]送信メールの個々のIPアドレスやIPブロックの量を推定するために、いくつかのインスタンスで使用されてきました。
As with any other DNS-based services, DNSBLs and DNSWLs are subject to various types of DNS attacks, which are described in [RFC3833].
他のDNSベースのサービスと同様に、のDNSBLとDNSWLsは、[RFC3833]に記載されているDNS攻撃、様々なタイプの対象となっています。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034] Mockapetris、P.、 "ドメイン名 - 概念と設備"、STD 13、RFC 1034、1987年11月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P.、 "ドメイン名 - 実装及び仕様"、STD 13、RFC 1035、1987年11月。
[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月。
[RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999.
[RFC2606]イーストレイク、D.とA. Panitz、 "予約トップレベルDNS名"、BCP 32、RFC 2606、1999年6月。
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003.
[RFC3596]トムソン、S.、のHuitema、C.、Ksinant、V.、およびM. Souissi、RFC 3596、2003年10月 "DNSの拡張機能は、IPバージョン6をサポートします"。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] HindenとR.とS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 4291、2006年2月。
[RFC5518] Hoffman, P., Levine, J., and A. Hathcock, "Vouch By Reference", RFC 5518, April 2009.
[RFC5518]ホフマン、P.、レヴァイン、J.、およびA. Hathcock、 "保証することでリファレンス"、RFC 5518、2009年4月。
[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月。
[RBLDNS] Bernstein, D., "rbldns, in 'djbdns'", <http://cr.yp.to/djbdns.html>.
【RBLDNS】バーンスタイン、D.、 "rbldns、 'djbdnsを' に"、<http://cr.yp.to/djbdns.html>。
[MAPSRBL] "MAPS RBL+", <http://mail-abuse.com/>.
【MAPSRBL "MAPSのRBL +"、<http://mail-abuse.com/>。
[RBLDNSD] Tokarev, M., "rbldnsd: Small Daemon for DNSBLs", <http://www.corpit.ru/mjt/rbldnsd.html>.
【RBLDNSD】トカレフ、M.、 "rbldnsd：のDNSBL用小型デーモン"、<http://www.corpit.ru/mjt/rbldnsd.html>。
[SENDERBASE] Ironport Systems, "Senderbase", <http://www.senderbase.org>.
[SENDERBASE]アイアンポートシステムズ、 "Senderbase"、<http://www.senderbase.org>。
[KSN] Levine, J., "The South Korean Network Blocking List", <http://korea.services.net>.
[KSN]レヴァイン、J.、 "韓国のネットワークブロックリスト"、<http://korea.services.net>。
Author's Address
著者のアドレス
John Levine Taughannock Networks PO Box 727 Trumansburg, NY 14886
ジョン・レヴァインTaughannockネットワーク私書箱727 Trumansburgに、NY 14886
Phone: +1 607 330 5711 EMail: standards@taugh.com URI: http://www.taugh.com
電話：+1 607 330 5711 Eメール：standards@taugh.com URI：http://www.taugh.com