[要約] RFC 5782は、DNSブラックリストとホワイトリストに関するガイドラインであり、その目的は、スパムやマルウェアなどの悪意のあるドメインを特定し、それらをブロックまたは許可するための方法を提供することです。
Internet Research Task Force (IRTF) J. Levine
Request for Comments: 5782 Taughannock Networks
Category: Informational February 2010
ISSN: 2070-1721
DNS Blacklists and Whitelists
DNSブラックリストとホワイトリスト
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.
このドキュメントは、インターネット研究タスクフォース（IRTF）の製品です。IRTFは、インターネット関連の研究開発活動の結果を公開しています。これらの結果は、展開に適していない場合があります。このRFCは、インターネット研究タスクフォース（IRTF）の反スパム研究グループのコンセンサスを表しています。IRSGによって公開されたことが承認された文書は、インターネット標準のレベルの候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5782.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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).
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フィードを使用する準備ができていませんでした。RandとVixieは、元のBGP分布よりも急速に人気になったDNSベースの分布スキームを作成しました。他の人は、さまざまなカテゴリのIPアドレスをリストすることにより、RBLと競合するか、それを補完するために、他のDNSベースのブラックリストを作成しました。一部の人々は、すべてのDNSベースのブラックリストを「RBLS」と呼んでいますが、この用語は、元のリストの子孫であるMail虐待防止システム（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も公開しています。ネットワークマネージャーは通常、DNSBLSを使用してトラフィックとDNSWLSをブロックしてトラフィックを優先的に受け入れます。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.
このドキュメントでは、DNSBLSとDNSWLSの構造を定義しています。DNSBLSおよびDNSWLSの構造、操作、および使用について説明しますが、DNSBLSおよび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.
要件表記：キーワードは「必須」、「必須」、「必須」、「shall」、「shall "、" sulld "、" low "of"、 "becommended"、 ""、 "optional"このドキュメントは、DNSXLの技術的相互運用性を改善するための推奨事項に関して、[RFC2119]に記載されているように解釈されます。
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ゾーンにエンコードされていましたが、ホスト名もエンコードされることがあります。ほとんどのDNSXLは引き続き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には、RDNSの構造から適応した構造があります。（RDN、逆DNSは、In-Addr.Arpa [RFC1034]およびIP6.ARPA [RFC3596]ドメインであり、IPアドレスをドメイン名にマッピングするために使用されます。）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: 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"
たとえば、DNSXLがbad.example.comと呼ばれ、リストされるIPv4アドレスが192.0.2.99の場合、DNSエントリの名前は99.2.0.192.bad.example.comになります。DNSXLの各エントリには、Aレコードが必要です。DNSBLSには、エントリの理由を説明する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 "ダイナミックアドレス、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.
一部のDNSXLはすべてのエントリに対して同じTXTレコードを使用しますが、他のDNSXLは、エントリまたは範囲がリストされている理由を説明するエントリごとに異なるTXTレコードを提供します。その理由には、多くの場合、詳細情報が利用可能なWebページの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レコードはあまり役に立ちません。一部のDNSWLには、エントリが存在する理由を文書化するために、とにかく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リストソースを公開する組織は、さまざまなアドレスがリストに含まれる理由を示すことを望む場合があります。マルウェアなどによって侵害されたホストの3番目のリストなど。（この時点で、私たちが認識しているサブリストを持つすべてのDNSXLは、DNSBLSとして使用することを目的としていますが、サブリストのテクニックはDNSWLで等しく使用できます。）
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.
複数のサブリストを持つDNSXLを表す3つの一般的な方法があります：サブドメイン、複数のAレコード、およびビットエンコードされたエントリ。サブリストを持つDNSXLSは、サブドメインと他の方法の1つの両方を使用する必要があります。
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アドレスのレコードエントリは、IPアドレスが表示されるすべてのリストの論理またはビットマスクです。たとえば、2人のサブリストのビットマスクは127.0.0.2および127.0.0.4である可能性があります。その場合、両方のリストのIPアドレスのエントリは127.0.0.6です。
99.2.0.192.bad.example.com A 127.0.0.6
99.2.0.192.bad.example.com A 127.0.0.6
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レコードを使用すると、各サブリストには、127.0.1.1、127.0.1.2などの異なる割り当て値があり、IPアドレスが表示される各サブリストのレコードがあります。
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.
サブリスト名をビットまたは値にマッピングするための広く使用されている慣習はありません。これは、すべての値が127.0.0.0/8の範囲内にある必要があるという慣習を超えて、値が誤ってIPアドレスとして使用されている場合に不要なネットワークトラフィックを防ぐ必要があります。
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レコードを返すDNSXLは、複数のTXTレコードを返すこともありますが、TXTレコードをAレコードに一致させる方法がないため、これらのTXTレコードの有用性が制限されます。他の結合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コンポーネントHEXニブル反転IPv6アドレスでなければなりません。エントリには、AおよびTXTレコードが含まれており、IPv4 DNSXLSと同じように解釈されます。
For example, to represent the address:
たとえば、アドレスを表すには：
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.1.0.0.0.8.0.0.0.0.1.0.0.2。ugly.example.com。127.0.0.2 TXT「Spam Receive」。
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サブリストDNSXLは、IPv4 DNSXLSと同じ方法で表され、IPv4アドレスの4オクテットをIPv6アドレスの32ニブルに置き換えます。
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アドレスの両方を含む可能性があります。これは、異なる長さがあいまいさを防ぐためです。dnsxlが従来のゾーンファイルとワイルドカードを使用して表現されている場合、ワイルドカードが一致する名前の長さを指定する方法はないため、ワイルドカード名は実際にその方法で提供される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.
IPアドレスではなく、いくつかのDNSXLSリストドメイン名。それらは、右側のブラックリストの場合、RHSBLと呼ばれることもあります。エントリの名前には、リストされているドメイン名に続いて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.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 "Phishで使用されるホスト名"
Name-based DNSBLs are far less common than IP address based DNSBLs. There is no agreed convention for wildcards.
名前ベースのDNSBLは、IPアドレスベースのDNSBLSよりもはるかに一般的ではありません。ワイルドカードに合意された慣習はありません。
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は、DNSBLSと同じ方法で作成でき、通常は0-100または0-255スケールで、評判スコアと信頼値を表すAレコードのオクテットの値を持つ単純な評判システムとして使用されています。参照による保証[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のレコードごとの時間とゾーンの更新間隔は、リストの管理ポリシーによって大きく異なります。DNSXLの予想される変化率を反映するために、ライブ（TTL）と更新時間を選択する必要があります。動的に割り当てられたダイヤルアップとDHCPユーザーに割り当てられたIPアドレスのリストは、ゆっくりと変更されると予想されるため、TTLは数日で、ゾーンは1日に1回更新される可能性があります。一方、SPAMの送信が観察されていた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.
複数の値を返すDNSBLSには複数のテストアドレスがある必要があるため、たとえば127.0.0.5を返すことができるDNSBLが127.0.0.5のテストレコードを持つことができます。。
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-Mapped 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".
ドメイン名ベースのDNSXLSには、[RFC2606]予約済みドメイン名「テスト」のエントリを含める必要があり、予約済みドメイン名「Invalid」のエントリを含めてはなりません。
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.
DNSXLSには、Webサーバーを指す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データが含まれていることを確認し、意図的にまたは偶然にすべてのレコードを返すワイルドカードをインストールするDNSXLに対して防御することができます。クエリ。DNSXLクライアントは、適切なテストエントリを定期的にチェックして、使用しているDNSXLがまだ動作していることを確認する必要があります。
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.
DNSXLは、標準のDNSサーバー、またはIPアドレスとクラスレスインタードメインルーティング（CIDR）のリストを受け入れるRBLDNS [RBLDNS]やRBLDNSD [RBLDNSD]などの専門サーバー（CIDR）などから提供でき、適切なDNSレコードを合成します。DNSXLを頻繁に使用する組織は、通常、標準のフルゾーン転送（AXFR）と増分ゾーン転送（IXFR）を使用するか、特殊なサーバーのアドレスとCIDR範囲を含むファイルを取得することにより、DNSXLのプライベートミラーを手配します。A /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エントリを拒否します。この場合は、接続を受け入れます。アドレスがNOリストにまったく表示されている場合（正当なメールの通常のケース）、メールサーバーは接続を受け入れます。別のアプローチでは、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.
メールサーバーは、通常のローカルDNSキャッシュを使用して、DNSXLサーバーへのトラフィックを制限し、最近見たIPアドレスの再テストを高速化します。長期にわたるメールサーバーは、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を確認することです。その場合、テストするIP（s）は通常、メッセージの本文内の「ヘッダーフィールドまたはuris」から抽出されます。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が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.
名前ベースのDNSBLSは、メールヘッダーにある電子メールアドレスとホスト名のドメイン名を確認し、メッセージボディの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を使用するシステムマネージャーは、サーバー管理の一部をリストを実行する当事者に委託しており、リストの管理ポリシーがシステムマネージャーが使用するポリシーと一致していることを確認する必要があります。選択されていないDNSBLSは、システムマネージャーとシステムのユーザーが受信したいメールを送信するアドレスをブロックする場合があります。DNSBLSの管理は時間とともに変化する可能性があります。場合によっては、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アドレスではなくブラックリストおよび/またはホワイトリストのエントリを表しています。クライアントがAレコードをIPアドレスとして使用しようとした場合、たとえばDNSXLエントリ名をWebまたはFTPサーバーとして使用しようとすると、独特の結果が続きます。DNSXLのオペレーターがセクション2.3のアドバイスを無視し、127/8の範囲以外のAレコードに値を置く場合、特異な結果は、ホストが記録を誤用することに限定されない可能性があります。逆に、システムがブラックリストやホワイトリストとしてDNSXLではないゾーンを使用しようとすると、より独特な結果が発生します。この状況は、放棄されたDNSBLドメインが再登録され、新しい所有者がWebサーバーを指すAレコードを備えたワイルドカードをインストールしたときに実際に観察されています。この状況を回避するために、DNSXLSを使用するシステムは、セクション5で説明されているテストエントリをチェックして、ドメインが実際に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サーバーログから近似メールボリューム統計を抽出できます。これは、個々のIPアドレスまたはIPブロックが送信されるメールの量を推定するために、いくつかのインスタンスで使用されています[senderbase] [KSN]。
As with any other DNS-based services, DNSBLs and DNSWLs are subject to various types of DNS attacks, which are described in [RFC3833].
他のDNSベースのサービスと同様に、DNSBLSおよび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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999.
[RFC2606] EastLake、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] Thomson、S.、Huitema、C.、Ksinant、V。、およびM. Souissi、「DNS拡張機能IPバージョン6」、RFC 3596、2003年10月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレス指定アーキテクチャ」、RFC 4291、2006年2月。
[RFC5518] Hoffman, P., Levine, J., and A. Hathcock, "Vouch By Reference", RFC 5518, April 2009.
[RFC5518] Hoffman、P.、Levine、J。、およびA. Hathcock、「保証by Reference」、RFC 5518、2009年4月。
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004.
[RFC3833] Atkins、D。およびR. Austein、「ドメイン名システムの脅威分析（DNS）」、RFC 3833、2004年8月。
[RBLDNS] Bernstein, D., "rbldns, in 'djbdns'", <http://cr.yp.to/djbdns.html>.
[rbldns] Bernstein、D。、 "rbldns、in '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] tokarev、M。、 "rbldnsd：dnsbls for dnsbls for dnsbls"、<http://www.corpit.ru/mjt/rbldnsd.html>。
[SENDERBASE] Ironport Systems, "Senderbase", <http://www.senderbase.org>.
[senderbase] Ironport Systems、 "senderbase"、<http://www.senderbase.org>。
[KSN] Levine, J., "The South Korean Network Blocking List", <http://korea.services.net>.
[KSN] Levine、J。、「韓国のネットワークブロッキングリスト」、<http://korea.services.net>。
Author's Address
著者の連絡先
John Levine Taughannock Networks PO Box 727 Trumansburg, NY 14886
ジョン・レバイン・タウガノックネットワークPOボックス727トルーマンスバーグ、ニューヨーク14886
Phone: +1 607 330 5711
EMail: standards@taugh.com
URI: http://www.taugh.com