Network Working Group C. Malamud
Request for Comments: 4095 Memory Palace Press
Category: Standards Track May 2005
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).
版权所有（C）互联网协会（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.
本文提出了一种查找与请求类关键字关联的URI的机制，该关键字在RFC3865（无请求SMTP服务扩展）中定义。请求类关键字是由已反转的域名组成的简单标签，如“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相关联，URI包含有关该请求类关键字的含义和用法的更多信息。例如，“example.org”域的注册人可以使用此机制创建一个URI，其中包含关于“org.example.adv”请求类关键字的详细信息。
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
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邮件服务传输。请求类关键字的格式类似于域名，但格式相反。例如，“example.com”的区域管理员可能会指定一个特定的请求类关键字，例如“com.example.adv”，该关键字可以由邮件发件人插入“No-request:”标头中，也可以由邮件传输代理（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服务扩展的范围之外。出于消息传输的目的，这些请求类关键字是不透明的。但是，如果RFC3865被广泛使用，则邮件消息可能包含大量请求类关键字。“无请求：”标题包含邮件发件人插入的关键字，其中可能包括发件人自己的关键字，以及监管机构授权或自愿行业协会推荐的关键字。同样，“received:”跟踪字段可能包含由消息传输代理、过滤软件、消息用户代理（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,
随着使用的关键字数量的增加，找到一种方法来发现各种征求类关键字背后的含义将非常重要。本文档指定了这样一种机制，通过使用DNS NAPTR资源记录，将请求类关键字与包含进一步信息的URI相关联，
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]。明确的设计目标是使系统尽可能简单。排除了定义基于XML的结构（其中包含关于征求类关键字的特定元数据）或其他定义解释格式的方法。相反，我们的目标是简单地将一个请求类关键字与一个URI相关联，而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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照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]中指定的复杂应用程序，如ENUM。如[RFC3958]所述，DDDS框架简化为直截了当的NAPTR（S-NAPTR）应用程序。不幸的是，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进行从请求类关键字到URI的单个查找。字符“.”首先替换为字符“：”的任何实例，然后使用字符“.”作为分隔符反转请求类关键字。这将成为域名查找键。例如，“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
此外，重要的是要记住，生成的字符串必须满足其他DNS有效性检查。特别是，域标签的长度限制为63个字符，结果字符串的总长度必须小于253个字符。任何非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.
必须使用[RFC3490]和相关文档中的国际化域名（IDN）规范对字符进行编码。请注意，非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]中的规定进行处理：如果返回多条记录，则必须使用“订单”值最低且具有匹配“服务”字段的记录。对于具有最低阶值的，应使用具有最低“偏好”的。
o The "FLAGS" field MUST contain the character "U".
o “标志”字段必须包含字符“U”。
o The "SERVICES" field MUST contain only the string "no-solicit".
o “服务”字段必须仅包含字符串“无请求”。
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:
[RFC3402]中将“REGEXP”字段定义为由“delim字符”、POSIX扩展正则表达式、另一个“delim字符”、替换值和最终“delim字符”组成。对于此应用，以下规则适用：
o The "delim-character" MAY be any valid character as defined in section 3.2 of [RFC3402].
o “delim字符”可以是[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
; <<>> 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
;; 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在NAPTR 1 1“U”iam+无效“！！http://invalid.example.com/contact.html!" . 2795.example.com。NAPTR 1 1“U”中的86400 sip+无效“”！！http://invalid.example.com/contact.html!" . 2795.example.com。86400在NAPTR 1 2“U”中“无请求”！！http://infinite.example.com/keywordinfo.html!" . 2795.example.com。86400在NAPTR 2 1“U”中“无请求”！！http://infinite.example.com/keywordinfo.html!" . 2795.example.com。86400在NAPTR 1 1“U”中“无请求”！！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;
# 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] ) ) );
# 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;
# create a resolver
my $res = Net::DNS::Resolver->new;
# find all naptr records
my $query = $res->query( "$target", "NAPTR" ) || exit ;
# 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;
# 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 ;
# 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>
[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第一条众所周知的规则：字符“.”被替换为字符“：”，然后请求类关键字被反转以生成有效的域名。例如，“com.example:adv”将变成“adv.example.com”。o有效数据库：DNS是数据库。o预期输出：一个URI。o“服务”字段必须包含字符串“无请求”，“标志”字段必须包含字符串“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中有其他选择器可用于“筛选”选项。这意味着返回的记录比实际需要的多，从而导致更多的流量。
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相关联。此应用程序提出了四个安全注意事项：
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:”方案的URI，并且未使用[RFC4033]和相关文档中定义的DNS安全扩展，则用户将产生一种不必要的真实性错觉，从而使主动攻击的可能性成为一个严重问题。即使同时使用DNS安全扩展和“https:”方案，客户端也需要采取额外的步骤，以确保两个不同的数字签名验证上下文由同一域所有者管理。
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. RFC3865基于域名的请求类关键字。但是，它没有定义用户应该信任谁。发件人或中间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
3. 域名不是持久标识符。与使用域名（包括万维网）的任何应用程序一样，如果电子邮件消息中嵌入了域名或URI，则将来该域名有可能由其他区域管理员控制，并且
use of the application described in this document will yield different and possibly inconsistent results over time.
随着时间的推移，使用本文档中描述的应用程序将产生不同且可能不一致的结果。
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（例如，大量请求试图访问URI，如“URL”）处对提供商进行拒绝服务攻击http://example.net/index.html"). 格式不正确的请求类关键字，特别是那些不存在顶级或二级域的关键字，可能会导致对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.
IANA没有维护可能出现在NAPTR资源记录的“服务”字段中的值的中央注册表。因此，不需要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被告知，根据本文件，服务字段的“无请求”值正在使用中，因此不应在其他应用程序的应用程序服务标签注册表中使用。
[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-html401-19991224，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，“安全超文本传输协议”，RFC 2660，1999年8月。
[RFC3402] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", RFC 3402, October 2002.
[RFC3402]Mealling，M.“动态委托发现系统（DDDS）第二部分：算法”，RFC3402，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.“动态委托发现系统（DDDS）第三部分：域名系统（DNS）数据库”，RFC34032002年10月。
[RFC3865] Malamud, C., "A No Soliciting Simple Mail Transfer Protocol (SMTP) Service Extension", RFC 3865, September 2004.
[RFC3865]Malamud，C.，“一个无请求的简单邮件传输协议（SMTP）服务扩展”，RFC3865，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和动态委托发现服务（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.，“无限猴子协议套件（IMPS）”，RFC 27952000年4月1日。
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[RFC2821]Klensin，J.，“简单邮件传输协议”，RFC 28212001年4月。
[RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002.
[RFC3401]Mealling，M.“动态委托发现系统（DDDS）第一部分：综合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 34902003年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.和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
卡尔·马拉默德纪念宫出版社邮政信箱300号，或美国邮政信箱97476号
EMail: carl@media.org
EMail: carl@media.org
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（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秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/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的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。