[要約] RFC 4095は、Solicitation Class Keywordsに意味を付けるための方法を提案している。その目的は、異なるプロトコル間でのキーワードの一貫性を確保し、効果的な通信を促進することである。
Network Working Group C. Malamud
Request for Comments: 4095 Memory Palace Press
Category: Standards Track May 2005
Attaching Meaning to Solicitation Class Keywords
勧誘クラスのキーワードに意味を添付します
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
Abstract
概要
This document proposes a mechanism for finding a URI associated with a solicitation class keyword, which is defined in RFC 3865, the No Soliciting SMTP Service Extension. Solicitation class keywords are simple labels consisting of a domain name that has been reversed, such as "org.example.adv". These solicitation class keywords are inserted in selected header fields or used in the ESMTP service extension, including a new "No-Solicit:" header, which can contain one or more solicitation class keywords inserted by the sender.
このドキュメントでは、RFC 3865で定義されているSMTPサービス拡張機能のNOであるRFC 3865で定義されている勧誘クラスキーワードに関連付けられたURIを見つけるメカニズムを提案しています。勧誘クラスのキーワードは、「org.example.adv」などのドメイン名で構成される単純なラベルです。これらの勧誘クラスのキーワードは、選択したヘッダーフィールドに挿入されているか、ESMTPサービス拡張機能に使用されます。
This document specifies an application based on the Dynamic Delegation Discovery System (DDDS) described in RFC 3401 and related documents. An algorithm is specified to associate a solicitation class keyword with a URI which contains further information about the meaning and usage of that solicitation class keyword. For example, the registrant of the "example.org" domain could use this mechanism to create a URI which contains detailed information about the "org.example.adv" solicitation class keyword.
このドキュメントは、RFC 3401および関連ドキュメントで説明されている動的委任ディスカバリーシステム（DDDS）に基づくアプリケーションを指定します。アルゴリズムは、勧誘クラスのキーワードをURIに関連付けるために指定されています。これには、その勧誘クラスのキーワードの意味と使用に関するさらなる情報が含まれています。たとえば、「example.org」ドメインの登録者は、このメカニズムを使用して、「org.example.adv」勧誘クラスキーワードに関する詳細情報を含むURIを作成できます。
Table of Contents
目次
1. Solicitation Class Keywords .....................................2
1.1. Terminology ................................................3
2. The No-Solicit NAPTR Application ................................3
3. Example .........................................................5
4. DDDS Application Specification ..................................7
5. Acknowledgements ................................................8
6. Security Considerations .........................................8
7. IANA Considerations .............................................9
8. References ......................................................9
8.1. Normative References .......................................9
8.2. Informative References ....................................10
[RFC3865] defines the concept of a "solicitation class keyword", which is an arbitrary string or label which can be associated with an electronic mail message and transported by the ESMTP mail service as defined in [RFC2821] and related documents. Solicitation class keywords are formatted like domain names, but reversed. For example, the zone administrator of "example.com" might specify a particular solicitation class keyword such as "com.example.adv" that could be inserted in a "No-Solicit:" header by the message sender or in a trace field by a message transfer agent (MTA). This solicitation class keyword is inserted by the sender of the message, who may also insert a variety of other solicitation class keywords as defined by the sender or by other parties.
[RFC3865]は、電子メールメッセージに関連付けられ、[RFC2821]および関連文書で定義されているESMTPメールサービスによって輸送される任意の文字列またはラベルである「Solicitation Classキーワード」の概念を定義します。勧誘クラスのキーワードはドメイン名のようにフォーマットされますが、逆転します。たとえば、「example.com」のゾーン管理者は、「com.example.adv」などの特定の勧誘クラスのキーワードを指定する場合があります。メッセージ転送エージェント（MTA）によって。この勧誘クラスのキーワードは、メッセージの送信者によって挿入されます。メッセージは、送信者または他の関係者によって定義されているように、他のさまざまな勧誘クラスのキーワードを挿入することもあります。
[RFC3865] explicitly places discovery of the meaning of a solicitation class keyword as outside of the scope of the basic ESMTP service extension. For the purposes of message transport, these solicitation class keywords are opaque. However, if RFC 3865 becomes widely used, a mail message might contain a large number of solicitation class keywords. The "No-Solicit:" header has keywords inserted by the sender of the message, which might include the sender's own keywords, as well as those mandated by regulatory authorities or recommended by voluntary industry associations. Likewise, the "received:" trace fields might contain a large number of keywords produced by message transfer agents, filtering software, forwarding software in the message user agent (MUA), or any other system in the chain of delivery.
[RFC3865]は、基本的なESMTPサービス拡張の範囲外として、勧誘クラスのキーワードの意味を明示的に発見します。メッセージトランスポートの目的のために、これらの勧誘クラスのキーワードは不透明です。ただし、RFC 3865が広く使用されている場合、メールメッセージには多数の勧誘クラスキーワードが含まれている場合があります。「no-solicit：」ヘッダーには、メッセージの送信者によって挿入されたキーワードがあります。これには、送信者自身のキーワード、および規制当局によって義務付けられているもの、または自発的な産業協会によって推奨されるものが含まれます。同様に、「受信：トレースフィールドには、メッセージ転送エージェント、フィルタリングソフトウェア、メッセージユーザーエージェント（MUA）の転送ソフトウェア、または配信チェーン内の他のシステムが生成する多数のキーワードが含まれている場合があります。
As the number of keywords employed grows, it will be important to find a method for discovering the meaning behind the various solicitation class keywords. This document specifies such a mechanism, associating a solicitation class keyword with a URI which contains further information by using the DNS NAPTR Resource Record, which is defined in [RFC3403]. An explicit design goal is to keep the system as simple as possible. Approaches such as defining an XML-based structure that would contain specific meta-data about the solicitation class keyword or other approaches that define the format of the explanation were ruled out. Instead, the goal is to simply to associate a solicitation class keyword with a URI, which in turn contains an explanation of the keyword.
採用されているキーワードの数が増えるにつれて、さまざまな勧誘クラスのキーワードの背後にある意味を発見する方法を見つけることが重要です。このドキュメントは、[RFC3403]で定義されているDNS NAPTRリソースレコードを使用して、勧誘クラスのキーワードをURIに関連付けてURIに関連付けて、このようなメカニズムを指定します。明示的な設計目標は、システムを可能な限りシンプルに保つことです。勧誘クラスのキーワードまたは説明の形式を定義する他のアプローチに関する特定のメタデータを含むXMLベースの構造を定義するなどのアプローチが除外されました。代わりに、目標は単に勧誘クラスのキーワードをURIに関連付けることです。これには、キーワードの説明が含まれています。
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 BCP 14, [RFC2119].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、BCP 14、[RFC2119]に記載されているように解釈される。
The DDDS framework of [RFC3401] and related documents provides a powerful set of mechanisms that can yield sophisticated applications such as ENUM as specified in [RFC3761]. There is a simplification of the DDDS framework called the Straightforward-NAPTR (S-NAPTR) application as specified in [RFC3958]. Unfortunately, S-NAPTR does not permit the use of the "U" flag for terminal lookups and does not support the regular expression field of the NAPTR RR. Since a replacement field in a NAPTR record must contain only a domain name, and our goal is to find a URI, this document does not use the S-NAPTR mechanism.
[RFC3401]および関連ドキュメントのDDDSフレームワークは、[RFC3761]で指定された列挙などの高度なアプリケーションを生成できる強力なメカニズムのセットを提供します。[RFC3958]で指定されているように、Starnforward-NAPTR（S-NAPTR）アプリケーションと呼ばれるDDDSフレームワークの簡素化があります。残念ながら、S-Naptrは端子検索に「U」フラグの使用を許可せず、Naptr RRの正規表現フィールドをサポートしていません。NAPTRレコードの交換フィールドにはドメイン名のみが含まれている必要があり、私たちの目標はURIを見つけることであるため、このドキュメントはS-NAPTRメカニズムを使用しません。
This document uses the NAPTR RR to do a single lookup from solicitation class keyword to URI. The character "." is first substituted for any instances of the character ":" and then the solicitation class keyword is reversed, using the character "." as the delimiter. This becomes the domain name lookup key. For example, "org.example:ADV" becomes "ADV.example.org".
このドキュメントでは、NAPTR RRを使用して、勧誘クラスのキーワードからURIまでの1つのルックアップを行います。キャラクター "。"最初に文字 "："の任意のインスタンスに置き換えられます。次に、文字を使用して勧誘クラスのキーワードが逆になります。」区切り文字として。これがドメイン名のルックアップキーになります。たとえば、「org.example：adv」は「adv.example.org」になります。
Note On Domain Names: RFC3865 states that a solicitation class keyword consists of a valid domain name followed by the ":" character and by additional valid characters. Several points are important to remember for implementors. Since domain names are case insensitive and the ":" character is translated to the "." character, for purposes of this DDDS application, the following solicitation class keywords are syntactically equivalent: "com.example:ADV", "com.Example:adv", and "com:example:ADV".
ドメイン名に関する注：RFC3865は、勧誘クラスのキーワードが有効なドメイン名で構成されていることを示しています。実装者にとって覚えておくべきいくつかのポイントが重要です。ドメイン名はケースの鈍感であり、「：」文字は「」に翻訳されているため。キャラクター、このDDDSアプリケーションの目的のために、次の勧誘クラスのキーワードは、「com.example：adv "、" com.example：adv "、および" com：example：adv "）の構文的に同等です。
In addition, it is important to remember that the resulting string must meet other DNS validity checks. In particular, domain labels are limited to 63 characters in length and the total length of the resulting string must be less than 253 characters. Any non-ASCII characters must be encoded using the Internationalized Domain Names (IDN) specifications in [RFC3490] and related documents. Note that non-ASCII characters may be encoded after the ":" character as well.
さらに、結果の文字列は他のDNS有効性チェックを満たさなければならないことを覚えておくことが重要です。特に、ドメインラベルの長さは63文字に制限されており、結果の文字列の全長は253文字未満でなければなりません。[RFC3490]および関連ドキュメントの国際化ドメイン名（IDN）仕様を使用して、ASCII以外の文字をエンコードする必要があります。非ASCII文字は、「：」文字の後にエンコードされる場合があることに注意してください。
The fields of the NAPTR RR are used as follows:
NAPTR RRのフィールドは次のように使用されます。
o The "ORDER" and "PREFERENCE" fields are to be processed as specified in [RFC3403]: if multiple records are returned, the one(s) with the lowest "ORDER" value that have a matching "SERVICE" field MUST be used. Of those with the lowest ORDER value, those with the lowest "PREFERENCE" SHOULD be used.
o [RFC3403]で指定されているように「順序」と「設定」フィールドを処理する必要があります。複数のレコードが返される場合、一致する「サービス」フィールドを持つ最低の「順序」値を持つ1つを使用する必要があります。注文値が最も低い人のうち、「優先度」が最も低い人のうち、使用する必要があります。
o The "FLAGS" field MUST contain the character "U".
o 「フラグ」フィールドには、文字「u」が含まれている必要があります。
o The "SERVICES" field MUST contain only the string "no-solicit".
o 「サービス」フィールドには、文字列「no-solicit」のみを含める必要があります。
o The "REGEXP" field MUST contain a valid URI as further specified in this section.
o 「regexp」フィールドには、このセクションでさらに指定されている有効なURIを含める必要があります。
o The "REPLACEMENT" field MUST be empty.
o 「交換」フィールドは空でなければなりません。
The "REGEXP" field is defined in [RFC3402] as consisting of a "delim-character", a POSIX Extended Regular Expression, another "delim-character", a replacement value, and a final "delim-character". For this application the following rules apply:
「regexp」フィールドは、[RFC3402]で「デリム文字」、POSIX拡張正規表現、別の「デリム文字」、交換値、最終的な「デリムキャラクター」で構成されるものとして定義されています。このアプリケーションには、次のルールが適用されます。
o The "delim-character" MAY be any valid character as defined in section 3.2 of [RFC3402].
o 「Delim-Character」は、[RFC3402]のセクション3.2で定義されている有効な文字です。
o The extended regular expression MUST be empty.
o 拡張された正規表現は空でなければなりません。
o The replacement value MUST contain a valid URI as specified in [RFC3986].
o 置換値には、[RFC3986]で指定されている有効なURIを含める必要があります。
o The replacement value SHOULD contain a URI limited to the "ftp", "http", and "https" schemes as specified in [RFC3986] and [RFC2660].
o 交換値には、[RFC3986]および[RFC2660]で指定されている「FTP」、「HTTP」、および「HTTPS」スキームに限定されたURIを含める必要があります。
o The document that is retrieved at the URI SHOULD conform to [HTML-4.01], including the Accessibility Guidelines contained therein.
o URIで取得されたドキュメントは、そこに含まれるアクセシビリティガイドラインを含む[HTML-4.01]に準拠する必要があります。
In this example, a set of NAPTR records are added to the "example.com" zone and can be retrieved using "dig" or other DNS utilities:
この例では、NAPTRレコードのセットが「Example.com」ゾーンに追加され、「DIG」または他のDNSユーティリティを使用して取得できます。
[carl@example.com]% dig 2795.example.com naptr
[carl@example.com]％dig 2795.example.com naptr
; <<>> DiG 9.2.3 <<>> 2795.example.com naptr
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY,
status: NOERROR, id: 43494
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 5,
AUTHORITY: 2, ADDITIONAL: 1
;; QUESTION SECTION:
;2795.example.com. IN NAPTR
;; ANSWER SECTION: 2795.example.com. 86400 IN NAPTR 1 1 "U" "iam+invalid" "!!http://invalid.example.com/contact.html!" . 2795.example.com. 86400 IN NAPTR 1 1 "U" "sip+invalid" "!!http://invalid.example.com/contact.html!" . 2795.example.com. 86400 IN NAPTR 1 2 "U" "no-solicit" "!!http://infinite.example.com/keywordinfo.html!" . 2795.example.com. 86400 IN NAPTR 2 1 "U" "no-solicit" "!!http://infinite.example.com/keywordinfo.html!" . 2795.example.com. 86400 IN NAPTR 1 1 "U" "no-solicit" "!!http://infinite.example.com/keywordinfo.html!" .
;;回答セクション：2795.example.com。86400 in naptr 1 1 "u" "iam invalid" "!! http：//invalid.example.com/contact.html！"。2795.example.com。86400 in naptr 1 1 "u" "sip invalid" "!! http：//invalid.example.com/contact.html！"。2795.example.com。86400 in naptr 1 2 "u" "no-solicit" "!! http：//infinite.example.com/keywordinfo.html！"。2795.example.com。86400 in naptr 2 1 "u" "no-solicit" "!! http：//infinite.example.com/keywordinfo.html！"。2795.example.com。86400 in naptr 1 1 "u" "no-solicit" "!! http：//infinite.example.com/keywordinfo.html！"。
A simple utility written in PERL accepts a lookup key and returns a URI using the specifications in this document. This example is non-normative:
Perlで書かれた単純なユーティリティは、ルックアップキーを受け入れ、このドキュメントの仕様を使用してURIを返します。この例は非規範的です：
#!/usr/bin/perl
＃！/usr/bin/perl
# THIS SAMPLE CODE IS NOT NORMATIVE
＃このサンプルコードは規範ではありません
# This program accepts a solicitation class keyword and # returns a URI on success. It dies quietly on failure. use strict;
＃このプログラムは、勧誘クラスのキーワードを受け入れ、＃成功したURIを返します。失敗して静かに死にます。厳格を使用します。
# http://www.net-dns.org/
use Net::DNS;
# reverse the label to create a domain name
$ARGV[0] =~ tr/:/./ ;
my $target = join( ".", reverse( split( /\./, $ARGV[0] ) ) );
# create a resolver
my $res = Net::DNS::Resolver->new;
# find all naptr records
my $query = $res->query( "$target", "NAPTR" ) || exit ;
# Do your DNSSEC checks here, throw away all invalid RRs
＃ここでDNSSECチェックを行い、すべての無効なRRSを捨ててください
# get the answers, strip out non-matching services,
# sort by order, preference
my @rr =
sort {
# sort records numerically by order, preference
$a->order <=> $b->order
|| $a->preference <=> $b->preference
}
grep { $_->service =~ /no-solicit/ } $query->answer;
# print the first qualifying record, strip out the
# regexp markers
my $op = substr( my $answer = $rr[0]->regexp , 0, 1 )
|| exit ;
print split ( $op, $answer ) ; exit ;
Running the sample code gives the following results:
サンプルコードを実行すると、次の結果が得られます。
[carl@example.com]% lynx -source `./discover.pl com.example.2795`
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>About Our Solicitation Class Keyword</title>
</head>
<body>
<center>
<a href="monkey.mp3">
<img alt="bouncy monkey logo"
src="images/monkey_fpo.gif" border="0" />
<br />
</a>
<br />
About com.example.2795:<br />
It has been determined that the content of this
mail message<br />
conforms to the spirit of RFC 2795.
Congratulations?
</center>
</body>
</html>
The following definitions apply to this application:
次の定義がこのアプリケーションに適用されます。
o Application Unique String: The application unique string is a Solicitation Class Keyword as defined in [RFC3865]. o First Well Known Rule: The character "." is substituted for the character ":" and then the Solicitation Class Keyword is reversed in order to produce a valid domain name. For example, "com.example:adv" would become "adv.example.com". o Valid Databases: The DNS _is_ the database. o Expected Output: A URI. o The "SERVICE" field MUST contain the string "no-solicit", the "FLAGS" field MUST contain the string "U", the "REPLACEMENT" field MUST be empty, and the "REGEXP" field MUST be formatted as specified in Section 2.
o アプリケーション一意の文字列：アプリケーション一意の文字列は、[RFC3865]で定義されている勧誘クラスのキーワードです。o最初によく知られているルール：キャラクター「」。キャラクター "："に置き換えられます。そして、有効なドメイン名を作成するために、Solicitationクラスのキーワードが逆になります。たとえば、「com.example：adv」は「adv.example.com」になります。o有効なデータベース：DNS _is_データベース。o予想出力：URI。o「サービス」フィールドには文字列「no-solicit」が含まれている必要があります。「フラグ」フィールドには弦の「u」、「交換」フィールドが空になり、「regexp」フィールドを指定したようにフォーマットする必要があります。第2節。
Wildcards are appropriate for this application, allowing multiple solicitation class keywords that share a common prefix to all point to the same URI. Note that the NAPTR Resource Record is known as a "subtyping" RR, which means that additional selectors are available within the RR to "winnow down" the choices. This means more records are returned than are actually needed, resulting in more traffic.
ワイルドカードはこのアプリケーションに適しており、同じURIをすべてポイントするすべてのポイントに共通の接頭辞を共有する複数の勧誘クラスのキーワードを許可します。NAPTRリソースレコードは「サブタイピング」RRとして知られていることに注意してください。つまり、RR内で追加のセレクターが利用可能であり、選択肢を「winnow」しています。これは、実際に必要なものよりも多くの記録が返され、より多くのトラフィックをもたらすことを意味します。
But, this also means that wildcards may have unintended effects of multiple types of NAPTR resource records are used. Implementors and zone administrators should exercise care in the use of such wildcards in this application.
しかし、これはまた、ワイルドカードが複数のタイプのNAPTRリソースレコードの意図しない効果を持つ可能性があることを意味します。実装者とゾーン管理者は、このアプリケーションでこのようなワイルドカードを使用するためにケアを行使する必要があります。
The author would like to thank the following for their helpful suggestions and reviews of this document: Leslie Daigle, Spencer Dawkins, Arnt Gulbrandsen, Ted Hardie, Scott Hollenbeck, Russ Housley, David Kessens, Peter Koch, Michael Mealling, Pekka Savola, Mark Townsley, and Margaret Wasserman.
著者は、このドキュメントの有益な提案とレビューについて以下に感謝したいと思います：レスリー・ダイグル、スペンサー・ドーキンス、アルント・ガルブランドセン、テッド・ハーディ、スコット・ホレンベック、ラスト・ハウズリー、デビッド・ケッセン、ピーター・コッホ、マイケル・ミーリング、ペッカ・サヴォラ、マーク・タウンズリー、そしてマーガレット・ワッサーマン。
This document specifies an application which depends on the Domain Name System to associate a solicitation class keyword with a URI. Four security considerations are raised by this application:
このドキュメントは、勧誘クラスのキーワードをURIに関連付けるために、ドメイン名システムに依存するアプリケーションを指定します。このアプリケーションによって4つのセキュリティ上の考慮事項が提起されます。
1. If the domain name lookup has been compromised, the application may return a URI with incorrect guidance on the use of a particular solicitation class keyword. In particular, if the application returns a URI with the "https:" scheme, and the DNS Security Extensions as defined in [RFC4033] and related documents are not used, the user would have an unwarranted illusion of authenticity making the possibility of active attacks a serious concern. Even if both DNS Security Extensions and the "https:" scheme are used, the client will need to take additional steps to ensure that the two different digital signature validation contexts are being administered by the same domain owner.
1. ドメイン名のルックアップが損なわれている場合、アプリケーションは、特定の勧誘クラスキーワードの使用に関する誤ったガイダンスを備えたURIを返す場合があります。特に、アプリケーションが[https： "スキーム、および[RFC4033]で定義されているDNSセキュリティ拡張機能を持つURIを返す場合、関連文書は使用されません。深刻な懸念。DNSセキュリティ拡張機能と「HTTPS：」スキームの両方が使用されている場合でも、クライアントは2つの異なるデジタル署名検証コンテキストが同じドメイン所有者によって管理されていることを確認するために追加の手順を実行する必要があります。
2. RFC 3865 bases solicitation class keywords on domain names. However, it does not define whom a user should trust. A sender or an intermediate MTA could insert a solicitation class keyword in a message and then use the application defined in this document to mislead the message recipient. For example, a malicious direct marketer might insert a keyword such as "org.example.certified.message" and use a URI to somehow indicate that the message (wrongly) has some official status. As with any URI, users must take further steps that are outside the scope of this specification to determine what and whom to believe.
2. RFC 3865ドメイン名の勧誘クラスのキーワード。ただし、ユーザーが誰を信頼すべきかを定義するものではありません。送信者または中間MTAは、メッセージに勧誘クラスのキーワードを挿入し、このドキュメントで定義されているアプリケーションを使用してメッセージ受信者を誤解させることができます。たとえば、悪意のある直接マーケティング担当者は、「org.example.certified.message」などのキーワードを挿入し、URIを使用して、メッセージに（誤って）公式ステータスがあることを何らかの形で示します。他のURIと同様に、ユーザーはこの仕様の範囲外のさらなる手順を実行して、何と誰を信じるかを決定する必要があります。
3. Domain names are not persistent identifiers. As with any application that uses domain names, including the World Wide Web, if a domain name or a URI is embedded in an electronic mail message, there is a possibility that in the future the domain name will be controlled by a different zone administrator and that use of the application described in this document will yield different and possibly inconsistent results over time.
3. ドメイン名は永続的な識別子ではありません。World Wide Webを含むドメイン名を使用するアプリケーションと同様に、ドメイン名またはURIが電子メールメッセージに埋め込まれている場合、将来、ドメイン名が別のゾーン管理者によって制御される可能性があります。このドキュメントで説明されているアプリケーションの使用は、時間とともに異なる、おそらく一貫性のない結果をもたらします。
4. A malicious sender could insert a large number of solicitation class keywords or improperly formatted solicitation keywords, thus performing a Denial of Service attack on the recipient's resources through the use of an excessive number of DNS lookups. If such a message is sent to many recipients, this can result in a Denial of Service attack on the provider at a particular URI (e.g., a large number of requests attempting to access a URI such as "http://example.net/index.html"). Improperly formatted solicitation class keywords, particularly those with a non-existent top level or second level domain, could result in a Denial of Service attack on DNS registry providers or the DNS root servers.
4. 悪意のある送信者は、多数の勧誘クラスのキーワードまたは不適切にフォーマットされた勧誘キーワードを挿入する可能性があるため、過剰な数のDNSルックアップを使用して、受信者のリソースに対するサービス拒否攻撃を実行できます。そのようなメッセージが多くの受信者に送信された場合、これにより、特定のURIでプロバイダーに対するサービス拒否攻撃が発生する可能性があります（たとえば、「http://example.net/などのURIにアクセスしようとする多数のリクエストがあります。index.html "）。不適切にフォーマットされた勧誘クラスのキーワード、特に存在しないトップレベルまたは第2レベルのドメインを持つキーワードは、DNSレジストリプロバイダーまたはDNSルートサーバーに対するサービス拒否攻撃をもたらす可能性があります。
There is no central registry maintained by the IANA of values that might appear in the "SERVICE" field of a NAPTR resource record. Thus, no direct IANA actions are required.
NAPTRリソースレコードの「サービス」フィールドに表示される可能性のある値のIANAによって維持される中央レジストリはありません。したがって、直接的なIANAアクションは必要ありません。
However, the IANA does maintain an Application Service Tag Registry, which is used to support the S-NAPTR DDDS application defined in [RFC3958]. The IANA is advised that the "no-solicit" value for the SERVICE field is in use per this document and thus should not be used in the Application Service Tag Registry for other applications.
ただし、IANAは、[RFC3958]で定義されているS-NAPTR DDDSアプリケーションをサポートするために使用されるアプリケーションサービスタグレジストリを維持しています。IANAは、このドキュメントに従って使用されているサービスフィールドの「no-solicit」値が使用されているため、他のアプリケーションのアプリケーションサービスタグレジストリで使用しないでください。
[HTML-4.01] Raggett, D., Hors, A., and I. Jacobs, "HTML 4.01 Specification", W3C REC REC-html401-19991224, December 1999.
[HTML-4.01] Raggett、D.、Hors、A。、およびI. Jacobs、「HTML 4.01仕様」、W3C REC REC-HTML401-1991224、1999年12月。
[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月。
[RFC2660] Rescorla, E. and A. Schiffman, "The Secure HyperText Transfer Protocol", RFC 2660, August 1999.
[RFC2660] Rescorla、E。およびA. Schiffman、「The Secure HyperText Transfer Protocol」、RFC 2660、1999年8月。
[RFC3402] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", RFC 3402, October 2002.
[RFC3402] Mealling、M。、「動的委任発見システム（DDDS）パート2：アルゴリズム」、RFC 3402、2002年10月。
[RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.
[RFC3403] Mealling、M。、「Dynamic Delogation Discovery System（DDDS）パート3：ドメイン名システム（DNS）データベース」、RFC 3403、2002年10月。
[RFC3865] Malamud, C., "A No Soliciting Simple Mail Transfer Protocol (SMTP) Service Extension", RFC 3865, September 2004.
[RFC3865] Malamud、C。、「A Staliting Simple Mail Transfer Protocol（SMTP）Service Extension」、RFC 3865、2004年9月。
[RFC3958] Daigle, L. and A. Newton, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", RFC 3958, January 2005.
[RFC3958] Daigle、L。およびA. Newton、「SRV RRSおよびDynamic Dedegation Discovery Service（DDDS）を使用したドメインベースのアプリケーションサービスの場所」、RFC 3958、2005年1月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「ユニフォームリソース識別子（URI）：ジェネリック構文」、STD 66、RFC 3986、2005年1月。
[RFC2795] Christey, S., "The Infinite Monkey Protocol Suite (IMPS)", RFC 2795, 1 April 2000.
[RFC2795] Christey、S。、「The Infinite Monkey Protocol Suite（IMPS）」、RFC 2795、2000年4月1日。
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[RFC2821]クレンシン、J。、「Simple Mail Transfer Protocol」、RFC 2821、2001年4月。
[RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002.
[RFC3401] Mealling、M。、「動的委任発見システム（DDDS）パート1：包括的なDDDS」、RFC 3401、2002年10月。
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[RFC3490] Faltstrom、P.、Hoffman、P。、およびA. Costello、「アプリケーションの国際化ドメイン名（IDNA）」、RFC 3490、2003年3月。
[RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004.
[RFC3761] Faltstrom、P。and M. Mealling、「E.164へのユニフォームリソース識別子（URI）動的委任ディスカバリーシステム（DDDS）アプリケーション（ENUM）」、RFC 3761、2004年4月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティの紹介と要件」、RFC 4033、2005年3月。
Author's Address
著者の連絡先
Carl Malamud Memory Palace Press PO Box 300 Sixes, OR 97476 US
Carl Malamud Memory Palace Press Po Box 300 Sixes、または97476 US
EMail: carl@media.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。