非官方中文译本声明：本页为 IETF RFC 4034《Resource Records for the DNS Security Extensions》 的非官方中文译本，由 ztpop.net 整理翻译，仅供学习参考。RFC 文档由 IETF 发布、不受版权限制；依据 BCP 78，本译本为署名翻译作品，译文力求忠实但不构成官方版本，权威性以英文原文为准。英文原文见 rfc-editor.org/rfc/rfc4034。

RFC 4034《DNSSEC 资源记录》中文译本

IETF · RFC 4034 · 标准跟踪（Standards Track）· 2005 年 3 月

摘要

本文档是描述 DNS 安全扩展（DNSSEC）的一组文档中的一员。DNS 安全扩展是一组资源记录与协议修改，为 DNS 提供来源认证（source authentication）。本文档定义了公钥（DNSKEY）、委派签名者（DS）、资源记录数字签名（RRSIG）与认证的不存在证明（NSEC）资源记录。本文档详细描述每种资源记录（RR）的用途与格式，并给出每种资源记录的示例。

本文档废弃了 RFC 2535，并纳入了 RFC 2535 所有更新所引入的变更。

1. 引言

DNS 安全扩展（DNSSEC）引入了四种新的 DNS 资源记录类型：DNS 公钥（DNSKEY）、资源记录签名（RRSIG）、下一安全（NSEC）与委派签名者（DS）。本文档定义每种资源记录（RR）的用途、该 RR 的 RDATA 格式及其呈现格式（ASCII 表示）。

1.1. 背景与相关文档

本文档是定义 DNSSEC 的一组文档中的一员，应当把这组文档作为一个整体来阅读。

[RFC4033] 包含 DNSSEC 的介绍与通用术语的定义；假定读者熟悉该文档。[RFC4033] 还列出了被本文档集所更新与废弃的其他文档。

[RFC4035] 定义了 DNSSEC 协议操作。

本文档还假定读者熟悉 [RFC1034]、[RFC1035] 及其后续更新文档中所描述的基本 DNS 概念，特别是 [RFC2181] 与 [RFC2308]。

本文档定义 DNSSEC 资源记录。本文档中给出的所有数值 DNS 类型码均为十进制整数。

1.2. 保留词

本文档中的关键词 "MUST"（必须）、"MUST NOT"（不得）、"REQUIRED"（需要）、"SHALL"（应）、"SHALL NOT"（不应）、"SHOULD"（应当）、"SHOULD NOT"（不应）、"RECOMMENDED"（推荐）、"MAY"（可以）和 "OPTIONAL"（可选）应按照 [RFC2119] 中的描述进行解释。

2. DNSKEY 资源记录

DNSSEC 使用公钥加密来签名并认证 DNS 资源记录集（RRset）。公钥存储在 DNSKEY 资源记录中，并用于 [RFC4035] 所描述的 DNSSEC 认证过程：某区使用私钥对其权威 RRset 签名，并把对应的公钥存储于一条 DNSKEY RR 中。随后解析器即可使用该公钥验证覆盖该区 RRset 的签名，从而对它们进行认证。

DNSKEY RR 并非用于存储任意公钥的记录，不得（MUST NOT）用于存储与 DNS 基础设施没有直接关系的证书或公钥。

DNSKEY RR 类型的类型值为 48。

DNSKEY RR 与类（class）无关。

DNSKEY RR 对生存时间（TTL）没有特殊要求。

2.1. DNSKEY RDATA 线格式

DNSKEY RR 的 RDATA 由 2 字节的 Flags 字段、1 字节的 Protocol 字段、1 字节的 Algorithm 字段以及 Public Key 字段构成。

                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Flags            |    Protocol   |   Algorithm   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                                                               /
   /                            Public Key                         /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.1.1. Flags 字段

Flags 字段的第 7 位是「区密钥」（Zone Key）标志。如果第 7 位值为 1，则该 DNSKEY 记录持有 DNS 区密钥，且该 DNSKEY RR 的 owner name必须（MUST）是某个区的名称。如果第 7 位值为 0，则该 DNSKEY 记录持有其他类型的 DNS 公钥，且不得（MUST NOT）用于验证覆盖 RRset 的 RRSIG。

Flags 字段的第 15 位是「安全入口点」（Secure Entry Point，SEP）标志，在 [RFC3757] 中描述。如果第 15 位值为 1，则该 DNSKEY 记录持有一把旨在用作安全入口点的密钥。此标志仅旨在作为对区签名或调试软件的一个提示，表明该 DNSKEY 记录的预期用途；验证器不得（MUST NOT）在签名验证过程中以任何方式根据此位的设置而改变其行为。这也意味着，设置了 SEP 位的 DNSKEY RR 还必须同时设置区密钥标志，才能合法地生成签名。设置了 SEP 位但未设置区密钥标志的 DNSKEY RR，不得（MUST NOT）用于验证覆盖 RRset 的 RRSIG。

第 0-6 位与第 8-14 位为保留位：这些位在创建 DNSKEY RR 时必须（MUST）为 0，在收到时必须（MUST）被忽略。

2.1.2. Protocol 字段

Protocol 字段必须（MUST）具有值 3，若在签名验证时发现其值为 3 以外的其他值，则该 DNSKEY RR必须（MUST）被视为无效。

2.1.3. Algorithm 字段

Algorithm 字段标识公钥的加密算法，并决定 Public Key 字段的格式。DNSSEC 算法类型列表见附录 A.1。

2.1.4. Public Key 字段

Public Key 字段持有公钥材料。其格式取决于所存储密钥的算法，并在单独的文档中描述。

2.1.5. 关于 DNSKEY RDATA 设计的说明

虽然 Protocol 字段的值始终为 3，但为了与 KEY 记录的早期版本向后兼容，仍然保留了该字段。

2.2. DNSKEY RR 呈现格式

RDATA 部分的呈现格式如下：

Flag 字段必须（MUST）表示为一个无符号十进制整数。鉴于当前已定义的标志，可能的取值为：0、256 与 257。

Protocol 字段必须（MUST）表示为一个取值为 3 的无符号十进制整数。

Algorithm 字段必须（MUST）表示为无符号十进制整数，或表示为附录 A.1 所规定的算法助记符。

Public Key 字段必须（MUST）表示为公钥的 Base64 编码。Base64 文本中允许出现空白字符。Base64 编码的定义参见 [RFC3548]。

2.3. DNSKEY RR 示例

下面这条 DNSKEY RR 为 example.com 存储了一条 DNS 区密钥。

example.com. 86400 IN DNSKEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3
                                         Cbl+BBZH4b/0PY1kxkmvHjcZc8no
                                         kfzj31GajIQKY+5CptLr3buXA10h
                                         WqTkF7H6RfoRqXQeogmMHfpftf6z
                                         Mv1LyBUgia7za6ZEzOJBOztyvhjL
                                         742iU/TpPSEDhm2SNKLijfUppn1U
                                         aNvv4w==  )

前四个文本字段指定 owner name、TTL、Class 与 RR 类型（DNSKEY）。取值 256 表示 Flags 字段中的区密钥位（第 7 位）值为 1。取值 3 是固定的 Protocol 值。取值 5 表示公钥算法。附录 A.1 将算法类型 5 标识为 RSA/SHA1，并指出 RSA/SHA1 公钥字段的格式定义于 [RFC3110]。其余文本是公钥的 Base64 编码。

3. RRSIG 资源记录

DNSSEC 使用公钥加密来签名并认证 DNS 资源记录集（RRset）。数字签名存储在 RRSIG 资源记录中，并用于 [RFC4035] 所描述的 DNSSEC 认证过程。验证器可以使用这些 RRSIG RR 来认证来自该区的 RRset。RRSIG RR只能（MUST only）用于携带保障 DNS 操作的验证材料（数字签名）。

一条 RRSIG 记录包含针对某一具有特定名称、类与类型的 RRset 的签名。RRSIG RR 指定该签名的有效区间，并使用 Algorithm（算法）、Signer's Name（签名者名称）与 Key Tag（密钥标签）来标识一条 DNSKEY RR，验证器可以用该 DNSKEY RR 所含的公钥验证该签名。

由于区中的每个权威 RRset 都必须受到数字签名保护，因此含有 CNAME RR 的名称处必须存在 RRSIG RR。这是对传统 DNS 规范 [RFC1034] 的一项变更——[RFC1034] 规定，如果一个名称处存在 CNAME，则该 CNAME 是该名称处唯一允许的类型。在已签名的区中，与某条 CNAME 资源记录同名的位置，必须（MUST）存在一条 RRSIG 与一条 NSEC（参见第 4 节）。

RRSIG RR 类型的类型值为 46。

RRSIG RR 与类（class）无关。

RRSIG RR必须（MUST）与其所覆盖的 RRset 具有相同的类。

RRSIG RR 的 TTL 值必须（MUST）与其所覆盖的 RRset 的 TTL 值相匹配。这是 [RFC2181] 关于 RRset 内单个 RR 的 TTL 值规则的例外：如果不同的 RRSIG RR 所覆盖的 RRset 具有不同的 TTL 值，那么即便它们的 owner name 相同，其 TTL 值也会不同。

3.1. RRSIG RDATA 线格式

RRSIG RR 的 RDATA 由 2 字节的 Type Covered 字段、1 字节的 Algorithm 字段、1 字节的 Labels 字段、4 字节的 Original TTL 字段、4 字节的 Signature Expiration（签名过期）字段、4 字节的 Signature Inception（签名生效）字段、2 字节的 Key Tag 字段、Signer's Name 字段以及 Signature 字段构成。

                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Type Covered           |  Algorithm    |     Labels    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Original TTL                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Signature Expiration                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Signature Inception                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Key Tag            |                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         Signer's Name         /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                                                               /
   /                            Signature                          /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.1.1. Type Covered 字段

Type Covered 字段标识被该 RRSIG 记录所覆盖的 RRset 的类型。

3.1.2. Algorithm Number 字段

Algorithm Number 字段标识用于创建签名的加密算法。DNSSEC 算法类型列表见附录 A.1。

3.1.3. Labels 字段

Labels 字段指定原始 RRSIG RR owner name 中标签的数量。该字段的重要性在于：验证器使用它来判断应答是否是由通配符合成的。如果是，则可用它来确定生成签名时所使用的 owner name。

要验证签名，验证器需要用于创建签名的原始 owner name。如果原始 owner name 含有通配符标签（"*"），服务器在应答过程中可能已对该 owner name 进行了扩展，在这种情况下，验证器必须重建原始 owner name 以验证签名。[RFC4035] 描述了如何使用 Labels 字段重建原始 owner name。

Labels 字段的值不得（MUST NOT）计入终止 owner name 的空（根）标签，也不得计入通配符标签（若存在）。Labels 字段的值必须（MUST）小于或等于 RRSIG owner name 中的标签数量。例如，"www.example.com." 的 Labels 字段值为 3，而 "*.example.com." 的 Labels 字段值为 2。根（"."）的 Labels 字段值为 0。

虽然通配符标签不计入 RRSIG RR 的 Labels 字段所存储的数量，但在生成或验证签名时，通配符标签是该 RRset owner name 的组成部分。

3.1.4. Original TTL 字段

Original TTL 字段指定被覆盖的 RRset 在权威区中呈现时的 TTL。

Original TTL 字段之所以必要，是因为缓存解析器会递减被缓存 RRset 的 TTL 值。为了验证签名，验证器需要原始 TTL。[RFC4035] 描述了如何使用 Original TTL 字段值重建原始 TTL。

3.1.5. Signature Expiration 与 Inception 字段

Signature Expiration 与 Inception 字段指定签名的有效周期。在生效日期之前，不得（MUST NOT）使用该 RRSIG 记录进行认证；在过期日期之后，不得（MUST NOT）使用该 RRSIG 记录进行认证。

Signature Expiration 与 Inception 字段值以 32 位无符号秒数的形式指定日期与时间，即自 1970 年 1 月 1 日 00:00:00 UTC 起经过的秒数（忽略闰秒），采用网络字节序。该格式在不回绕的情况下所能表达的最长区间约为 136 年。如果过期字段值接近 32 位回绕点，或者签名是长期有效的，那么 RRSIG RR 的 Expiration 字段值在数值上可以小于 Inception 字段值。因此，涉及这些字段的所有比较必须（MUST）使用 [RFC1982] 所定义的「序号算术」（Serial number arithmetic）。直接后果是：这些字段所含的值不能表示过去或将来 68 年以上的日期。

3.1.6. Key Tag 字段

Key Tag 字段包含验证此签名的 DNSKEY RR 的密钥标签值，采用网络字节序。附录 B 解释了如何计算 Key Tag 值。

3.1.7. Signer's Name 字段

Signer's Name 字段值标识验证器应当用来验证此签名的 DNSKEY RR 的 owner name。Signer's Name 字段必须（MUST）包含被覆盖 RRset 所在区的名称。发送方在传输 RRSIG RR 时不得（MUST NOT）对 Signer's Name 字段使用 DNS 名称压缩。

3.1.8. Signature 字段

Signature 字段包含加密签名，该签名覆盖 RRSIG RDATA（不含 Signature 字段）以及由 RRSIG owner name、RRSIG 类与 RRSIG Type Covered 字段所指定的 RRset。该字段的格式取决于所用的算法，这些格式在单独的配套文档中描述。

3.1.8.1. 签名计算

签名覆盖 RRSIG RDATA（不含 Signature 字段），并覆盖由 RRSIG owner name、RRSIG 类与 RRSIG Type Covered 字段所指定的数据 RRset。该 RRset 采用规范形式（参见第 6 节），且集合 RR(1),...RR(n) 按如下方式签名：

         signature = sign(RRSIG_RDATA | RR(1) | RR(2)... ) where

            "|" denotes concatenation;

            RRSIG_RDATA is the wire format of the RRSIG RDATA fields
               with the Signer's Name field in canonical form and
               the Signature field excluded;

            RR(i) = owner | type | class | TTL | RDATA length | RDATA

               "owner" is the fully qualified owner name of the RRset in
               canonical form (for RRs with wildcard owner names, the
               wildcard label is included in the owner name);

               Each RR MUST have the same owner name as the RRSIG RR;

               Each RR MUST have the same class as the RRSIG RR;

               Each RR in the RRset MUST have the RR type listed in the
               RRSIG RR's Type Covered field;

               Each RR in the RRset MUST have the TTL listed in the
               RRSIG Original TTL Field;

               Any DNS names in the RDATA field of each RR MUST be in
               canonical form; and

               The RRset MUST be sorted in canonical order.

有关规范形式与 RRset 排序的细节，参见第 6.2 与 6.3 节。

3.2. RRSIG RR 呈现格式

RDATA 部分的呈现格式如下：

Type Covered 字段表示为 RR 类型助记符。当助记符未知时，必须（MUST）使用 [RFC3597] 第 5 节所描述的 TYPE 表示法。

Algorithm 字段值必须（MUST）表示为无符号十进制整数，或表示为附录 A.1 所规定的算法助记符。

Labels 字段值必须（MUST）表示为无符号十进制整数。

Original TTL 字段值必须（MUST）表示为无符号十进制整数。

Signature Expiration Time 与 Inception Time 字段值必须（MUST）表示为无符号十进制整数（表示自 1970 年 1 月 1 日 00:00:00 UTC 起经过的秒数），或表示为 UTC 的 YYYYMMDDHHmmSS 形式，其中：

YYYY 是年份（0001-9999，但参见第 3.1.5 节）；
MM 是月份号（01-12）；
DD 是当月中的日期（01-31）；
HH 是小时，采用 24 小时制（00-23）；
mm 是分钟（00-59）；
SS 是秒（00-59）。

请注意，这两种格式始终可以区分，因为 YYYYMMDDHHmmSS 格式恰好为 14 位数字，而 32 位无符号整数的十进制表示永远不会超过 10 位。

Key Tag 字段必须（MUST）表示为无符号十进制整数。

Signer's Name 字段值必须（MUST）表示为一个域名。

Signature 字段表示为签名的 Base64 编码。Base64 文本中允许出现空白字符。参见第 2.2 节。

3.3. RRSIG RR 示例

下面这条 RRSIG RR 存储了 host.example.com 的 A RRset 的签名：

host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 (
                                 20030220173103 2642 example.com.
                                 oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr
                                 PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o
                                 B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t
                                 GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG
                                 J5D6fwFm8nN+6pBzeDQfsS3Ap3o= )

前四个字段指定 owner name、TTL、Class 与 RR 类型（RRSIG）。"A" 表示 Type Covered 字段。取值 5 标识用于创建签名的算法（RSA/SHA1）。取值 3 是原始 owner name 中的标签数量。RRSIG RDATA 中的取值 86400 是被覆盖 A RRset 的 Original TTL。20030322173103 与 20030220173103 分别是过期与生效日期。2642 是 Key Tag，example.com. 是 Signer's Name。其余文本是签名的 Base64 编码。

请注意，RRSIG RR 的 owner name、类与 Type Covered 的组合表明：该 RRSIG 覆盖的是 "host.example.com" 的 A RRset。Labels 值为 3 表明未使用通配符扩展。Algorithm、Signer's Name 与 Key Tag 表明：可以使用一条 example.com 区的 DNSKEY RR 对此签名进行认证，该 DNSKEY RR 的算法为 5，密钥标签为 2642。

4. NSEC 资源记录

NSEC 资源记录列出两件彼此独立的事情：下一个 owner name（按该区的规范排序），它包含权威数据或一条委派点 NS RRset；以及该 NSEC RR owner name 上存在的 RR 类型集合 [RFC3845]。区中完整的 NSEC RR 集合指明该区中存在哪些权威 RRset，并在该区中形成一条权威 owner name 链。此信息用于提供 DNS 数据的认证不存在证明（authenticated denial of existence），如 [RFC4035] 所述。

由于区中每个权威名称都必须是 NSEC 链的一部分，因此含有 CNAME RR 的名称处必须存在 NSEC RR。这是对传统 DNS 规范 [RFC1034] 的一项变更——[RFC1034] 规定，如果一个名称处存在 CNAME，则该 CNAME 是该名称处唯一允许的类型。在已签名的区中，与某条 CNAME 资源记录同名的位置，必须（MUST）存在一条 RRSIG（参见第 3 节）与一条 NSEC。

关于区签名者如何精确确定必须在区中纳入哪些 NSEC RR 的讨论，参见 [RFC4035]。

NSEC RR 的类型值为 47。

NSEC RR 与类（class）无关。

NSEC RR应当（SHOULD）具有与 SOA 记录 minimum TTL 字段相同的 TTL 值。这符合消极缓存（negative caching）的精神（[RFC2308]）。

4.1. NSEC RDATA 线格式

NSEC RR 的 RDATA 如下所示：

                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                      Next Domain Name                         /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                       Type Bit Maps                           /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.1.1. Next Domain Name 字段

Next Domain Name 字段包含具有权威数据或包含委派点 NS RRset 的下一个 owner name（按该区的规范排序）；规范排序的解释参见第 6.1 节。该区中最后一条 NSEC 记录的 Next Domain Name 字段值是区顶点（zone apex）的名称（即该区 SOA RR 的 owner name）。这表明该 NSEC RR 的 owner name 是该区规范排序中的最后一个名称。

发送方在传输 NSEC RR 时不得（MUST NOT）对 Next Domain Name 字段使用 DNS 名称压缩。

给定区不具权威性的那些 RRset 的 owner name（例如 glue 记录）不得（MUST NOT）列入 Next Domain Name，除非在相同的 owner name 上至少存在一个权威 RRset。

4.1.2. Type Bit Maps 字段

Type Bit Maps 字段标识在该 NSEC RR 的 owner name 上存在的 RRset 类型。

RR 类型空间被划分为 256 个窗口块，每个窗口块表示 16 位 RR 类型空间的低 8 位。每个至少有一个活动 RR 类型的块，使用一个单字节窗口号（0 到 255）、一个单字节位图长度（1 到 32，表示该窗口块位图所用的字节数）以及至多 32 字节（256 位）的位图进行编码。

各块在 NSEC RR RDATA 中按数值递增的顺序出现。

      Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+

      where "|" denotes concatenation.

每个位图按网络位序编码窗口块内 RR 类型的低 8 位。第一位是位 0。对于窗口块 0，位 1 对应 RR 类型 1（A），位 2 对应 RR 类型 2（NS），依此类推。对于窗口块 1，位 1 对应 RR 类型 257，位 2 对应 RR 类型 258。如果某位被置位，表示该类型的 RRset 存在于该 NSEC RR 的 owner name 处；如果某位被清除，表示该类型的 RRset 不存在于该 NSEC RR 的 owner name 处。

表示伪类型（pseudo-type）的位必须（MUST）被清除，因为它们不会出现在区数据中。若在读取时遇到，必须（MUST）被忽略。

没有类型存在的块必须（MUST NOT）被包含。位图中尾随的零字节必须（MUST）被省略。每个块的位图长度由该 NSEC RR owner name 处存在的 RR 类型集合中、数值最大的类型码所决定。未指定且位于末尾的零字节必须（MUST）被解释为零字节。

委派点处 NSEC RR 的位图需要特别留意。对应委派 NS RRset 的位、以及对应父区具有权威数据的 RR 类型的位必须（MUST）被置位；对应父区不具权威性的任何非 NS RRset 的位必须（MUST）被清除。

区不得（MUST NOT）为仅持有 glue 记录的域名包含 NSEC RR。

4.1.3. NSEC RDATA 中通配符名称的包含

如果区中出现了通配符 owner name，则该通配符标签（"*"）被当作字面符号处理，在生成 NSEC RR 时与任何其他 owner name 同等对待。通配符 owner name 以未扩展的形式出现在 Next Domain Name 字段中。[RFC4035] 描述了通配符对认证不存在证明的影响。

4.2. NSEC RR 呈现格式

RDATA 部分的呈现格式如下：

Next Domain Name 字段表示为一个域名。

Type Bit Maps 字段表示为 RR 类型助记符的序列。当助记符未知时，必须（MUST）使用 [RFC3597] 第 5 节所描述的 TYPE 表示法。

4.3. NSEC RR 示例

下面这条 NSEC RR 标识与 alfa.example.com. 相关联的 RRset，并标识 alfa.example.com. 之后的下一个权威名称。

alfa.example.com. 86400 IN NSEC host.example.com. (
                                A MX RRSIG NSEC TYPE1234 )

前四个文本字段指定名称、TTL、Class 与 RR 类型（NSEC）。条目 host.example.com. 是按规范顺序排在 alfa.example.com. 之后的下一个权威名称。A、MX、RRSIG、NSEC 与 TYPE1234 这些助记符表示：在名称 alfa.example.com. 处存在 A、MX、RRSIG、NSEC 与 TYPE1234 RRset。

上述 NSEC RR 的 RDATA 部分将被编码为：

            0x04 'h'  'o'  's'  't'
            0x07 'e'  'x'  'a'  'm'  'p'  'l'  'e'
            0x03 'c'  'o'  'm'  0x00
            0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03
            0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00
            0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
            0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
            0x00 0x00 0x00 0x00 0x20

假定验证器能够认证这条 NSEC 记录，那么它就可以用来证明 beta.example.com 不存在，或者证明 alfa.example.com. 处没有与之关联的 AAAA 记录。认证不存在证明在 [RFC4035] 中讨论。

5. DS 资源记录

DS 资源记录引用一条 DNSKEY RR，并用于 DNS 的 DNSKEY 认证过程。DS RR 通过存储密钥标签、算法号以及该 DNSKEY RR 的摘要来引用一条 DNSKEY RR。请注意，虽然摘要应当足以识别公钥，但存储密钥标签与密钥算法有助于使识别过程更高效。通过认证 DS 记录，解析器即可认证 DS 记录所指向的 DNSKEY RR。密钥认证过程在 [RFC4035] 中描述。

DS RR 与其对应的 DNSKEY RR 具有相同的 owner name，但它们存储在不同的位置。DS RR 仅出现在委派的上侧（父侧），并且是父区的权威数据。例如，"example.com" 的 DS RR 存储在 "com" 区（父区）中，而不是存储在 "example.com" 区（子区）中。对应的 DNSKEY RR 则存储在 "example.com" 区（子区）中。这简化了 DNS 区管理与区签名，但为 DS RR 引入了特殊的响应处理要求；这些要求在 [RFC4035] 中描述。

DS 记录的类型号为 43。

DS 资源记录与类（class）无关。

DS RR 对生存时间（TTL）没有特殊要求。

5.1. DS RDATA 线格式

DS RR 的 RDATA 由 2 字节的 Key Tag 字段、1 字节的 Algorithm 字段、1 字节的 Digest Type 字段以及 Digest 字段构成。

                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Key Tag             |  Algorithm    |  Digest Type  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                                                               /
   /                            Digest                             /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.1.1. Key Tag 字段

Key Tag 字段列出 DS 记录所引用的 DNSKEY RR 的密钥标签，采用网络字节序。

DS RR 所用的 Key Tag 与 RRSIG RR 所用的 Key Tag 相同。附录 B 描述了如何计算 Key Tag。

5.1.2. Algorithm 字段

Algorithm 字段列出 DS 记录所引用的 DNSKEY RR 的算法号。

DS RR 所用的算法号与 RRSIG 和 DNSKEY RR 所用的算法号相同。附录 A.1 列出了算法号类型。

5.1.3. Digest Type 字段

DS RR 通过包含该 DNSKEY RR 的摘要来引用一条 DNSKEY RR。Digest Type 字段标识用于构造摘要的算法。附录 A.2 列出了可能的摘要算法类型。

5.1.4. Digest 字段

DS 记录通过包含该 DNSKEY RR 的摘要来引用一条 DNSKEY RR。

该摘要是通过把 DNSKEY RR 的完全限定 owner name 的规范形式与该 DNSKEY RR 的 RDATA 相连接，然后应用摘要算法而计算得出的。

     digest = digest_algorithm( DNSKEY owner name | DNSKEY RDATA);

      "|" denotes concatenation

     DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key.

摘要的大小可能因摘要算法与 DNSKEY RR 大小而异。截至本文撰写之时，唯一定义的摘要算法是 SHA-1，它产生 20 字节的摘要。

5.2. 验证响应时 DS RR 的处理

DS RR 在区边界之间链接认证链，因此 DS RR 的处理需要格外小心。DS RR 所引用的 DNSKEY RR必须（MUST）是一条 DNSSEC 区密钥。该 DNSKEY RR 的 Flags必须（MUST）置位第 7 位。如果 DNSKEY 的标志未表明其为 DNSSEC 区密钥，则不得（MUST NOT）在验证过程中使用该 DS RR（及其所引用的 DNSKEY RR）。

5.3. DS RR 呈现格式

RDATA 部分的呈现格式如下：

Key Tag 字段必须（MUST）表示为无符号十进制整数。

Algorithm 字段必须（MUST）表示为无符号十进制整数，或表示为附录 A.1 所规定的算法助记符。

Digest Type 字段必须（MUST）表示为无符号十进制整数。

Digest必须（MUST）表示为一串不区分大小写的十六进制数字。十六进制文本中允许出现空白字符。

5.4. DS RR 示例

下面的示例展示了一条 DNSKEY RR 及其对应的 DS RR。

dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz
                                             fwJr1AYtsmx3TGkJaNXVbfi/
                                             2pHm822aJ5iI9BMzNXxeYCmZ
                                             DRD99WYwYqUSdjMmmAphXdvx
                                             egXd/M5+X7OrzKBaMbCVdFLU
                                             Uh6DhweJBjEVv5f2wwjM9Xzc
                                             nOf+EPbtG9DMBmADjFDc2w/r
                                             ljwvFw==
                                             ) ;  key id = 60485

dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A
                                           98631FAD1A292118 )

前四个文本字段指定名称、TTL、Class 与 RR 类型（DS）。取值 60485 是对应 "dskey.example.com." DNSKEY RR 的密钥标签，取值 5 表示该 "dskey.example.com." DNSKEY RR 所用的算法。取值 1 是用于构造摘要的算法，RDATA 文本的其余部分是以十六进制表示的摘要。

6. 资源记录的规范形式与顺序

本节定义资源记录的规范形式、DNS 名称的规范排序，以及 RRset 内资源记录的规范排序。规范名称排序用于构造 NSEC 名称链。规范 RR 形式与 RRset 内排序用于构造与验证 RRSIG RR。

6.1. 规范 DNS 名称排序

出于 DNS 安全的目的，owner name 的排序是把单个标签视为无符号、左对齐的字节串来进行的。缺失的字节排在取值为零的字节之前，大写 US-ASCII 字母视为小写 US-ASCII 字母。

要计算一组 DNS 名称的规范排序，首先按其最高有效（最右侧）标签对这些名称排序。对于最高有效标签相同的名称，再按其次最高有效标签继续排序，依此类推。

例如，以下名称按规范 DNS 名称顺序排序。最高有效标签是 "example"。在这一层级上，"example" 排在最前，随后是以 "a.example" 结尾的名称，再然后是以 "z.example" 结尾的名称。每一层级内的名称都按相同方式排序。

             example
             a.example
             yljkjljk.a.example
             Z.a.example
             zABC.a.EXAMPLE
             z.example
             \001.z.example
             *.z.example
             \200.z.example

6.2. 规范 RR 形式

出于 DNS 安全的目的，RR 的规范形式是该 RR 的线格式，其中：

RR 中的每个域名都完全展开（不使用 DNS 名称压缩）且完全限定；
RR owner name 中所有大写 US-ASCII 字母都被替换为对应的小写 US-ASCII 字母；
如果 RR 的类型为 NS、MD、MF、CNAME、SOA、MB、MG、MR、PTR、HINFO、MINFO、MX、HINFO、RP、AFSDB、RT、SIG、PX、NXT、NAPTR、KX、SRV、DNAME、A6、RRSIG 或 NSEC，则 RDATA 所含 DNS 名称中的所有大写 US-ASCII 字母都被替换为对应的小写 US-ASCII 字母；
如果 RR 的 owner name 是通配符名称，则该 owner name 采用其原始的未扩展形式，包括 "*" 标签（不做通配符替换）；
该 RR 的 TTL 被设置为其在源权威区中出现时的原始值，或覆盖它的 RRSIG RR 的 Original TTL 字段中的值。

6.3. RRset 内规范 RR 排序

出于 DNS 安全的目的，具有相同 owner name、类与类型的 RR，其排序方式是把每条 RR 规范形式的 RDATA 部分视为一个左对齐的无符号字节序列，其中缺失的字节排在零字节之前。

[RFC2181] 规定，RRset 不允许包含重复记录（即多条具有相同 owner name、类、类型与 RDATA 的 RR）。因此，如果某个实现把 RRset 置为规范形式时检测到重复 RR，必须（MUST）将其视为协议错误。如果该实现选择本着鲁棒性原则（宽容地接受）来处理这一协议错误，那么在计算该 RRset 的规范形式时，必须（MUST）移除重复 RR 中除一条以外的所有重复项。

7. IANA 考虑

本文档不引入新的 IANA 考虑，因为本文档所用的所有协议参数都已被先前的规范分配。然而，由于 DNSSEC 的演化漫长且有些曲折，本节试图描述 IANA 注册表及与 DNSSEC 相关（或曾经相关）的其他协议参数的当前状态。

附加的 IANA 考虑请参见 [RFC4035]。

DNS 资源记录类型：[RFC2535] 将类型 24、25 与 30 分别分配给 SIG、KEY 与 NXT RR。[RFC3658] 将 DNS 资源记录类型 43 分配给 DS。[RFC3755] 将类型 46、47 与 48 分别分配给 RRSIG、NSEC 与 DNSKEY RR。[RFC3755] 还将类型 30（NXT）标记为废弃，并把类型 24（SIG）与 25（KEY）的使用限制于 [RFC2931] 所描述的 "SIG(0)" 事务安全协议，以及 [RFC2930] 所描述的事务密钥资源记录。

DNS 安全算法号：[RFC2535] 创建了 DNSSEC 资源记录 Algorithm 字段号的 IANA 注册表，并分配了取值 1-4 与 252-255。[RFC3110] 分配了取值 5。[RFC3755] 修改了这一注册表，为每个条目加入标志，以说明其与 DNS 安全扩展一起使用的情况。每个算法条目都可以指向一种可被用于区签名、事务安全（参见 [RFC2931]）或两者兼用的算法。取值 6-251 可供 IETF 标准行动分配（[RFC3755]）。截至本文撰写之时 DNS 安全算法号条目的完整列表及其在 DNSSEC 中的使用状态，参见附录 A。

[RFC3658] 创建了 DNSSEC DS 摘要类型的 IANA 注册表，并将取值 0 分配给保留、取值 1 分配给 SHA-1。

KEY 协议值：[RFC2535] 创建了 KEY 协议值的 IANA 注册表，但 [RFC3445] 将除 3 以外的所有值重新分配为保留，并关闭了这一 IANA 注册表。该注册表保持关闭状态，所有 KEY 与 DNSKEY 记录都需要具有取值为 3 的 Protocol 字节。

KEY 与 DNSKEY RR 中的标志位：[RFC3755] 为 DNSSEC KEY 与 DNSKEY RR 的标志位创建了 IANA 注册表。最初，该注册表只包含对第 7 位（ZONE 位）与第 15 位（安全入口点（SEP）标志位；参见 [RFC3757]）的分配。如 [RFC3755] 所述，第 0-6 位与第 8-14 位可供 IETF 标准行动分配。

8. 安全考虑

本文档描述了 DNS 安全扩展所使用的四种 DNS 资源记录的格式，并给出了一种为公钥计算密钥标签的算法。除下述事项外，这些资源记录本身不引入安全考虑。有关使用这些记录的附加安全考虑，请参见 [RFC4033] 与 [RFC4035]。

DS 记录使用密码摘要、密钥算法类型与密钥标签来指向一条 DNSKEY RR。DS 记录旨在标识一条已存在的 DNSKEY RR，但攻击者在理论上有可能生成一条与 DS 记录所有字段都匹配的 DNSKEY。构造出匹配 DNSKEY 的概率取决于所使用的摘要算法类型。目前唯一定义的摘要算法是 SHA-1，工作组认为：构造一把能够匹配给定 DS 记录中算法、密钥标签与 SHA-1 摘要的公钥将是一个足够困难的问题，因此此类攻击在目前并不是一个严重的威胁。

密钥标签用于帮助高效地选择 DNSKEY 资源记录，但它并不能唯一标识单条 DNSKEY 资源记录。两条不同的 DNSKEY RR 有可能具有相同的 owner name、相同的算法类型与相同的密钥标签。仅使用密钥标签来选择 DNSKEY RR 的实现，在某些情况下可能会选错公钥。进一步的细节请参见附录 B。

附录 A 中的算法表和附录 B 中的密钥标签计算算法出于完整性的考虑收录了 RSA/MD5 算法，但正如 [RFC3110] 所解释的，RSA/MD5 算法不被推荐（NOT RECOMMENDED）。

9. 致谢

本文档是根据 DNS 扩展工作组成员及工作组邮件列表的输入与想法编写的。编辑们谨对修订这些安全扩展规范期间收到的评论与建议表示感谢。虽然明确列出 DNSSEC 十年开发历程中每一位作出贡献的人是不可能的，但 [RFC4033] 中包含了一份名单，列出了一些惠予评论这些文档的参与者。

10. 参考文献

10.1. 规范性参考文献

[RFC1034] Mockapetris, P., 《域名——概念与设施》, STD 13, RFC 1034, 1987 年 11 月。
[RFC1035] Mockapetris, P., 《域名——实现与规范》, STD 13, RFC 1035, 1987 年 11 月。
[RFC1982] Elz, R. 与 R. Bush, 《序号算术》, RFC 1982, 1996 年 8 月。
[RFC2119] Bradner, S., 《用于 RFC 中表明要求等级的关键词》, BCP 14, RFC 2119, 1997 年 3 月。
[RFC2181] Elz, R. 与 R. Bush, 《对 DNS 规范的澄清》, RFC 2181, 1997 年 7 月。
[RFC2308] Andrews, M., 《DNS 查询的消极缓存（DNS NCACHE）》, RFC 2308, 1998 年 3 月。
[RFC2536] Eastlake 3rd, D., 《域名系统（DNS）中的 DSA 密钥与签名》, RFC 2536, 1999 年 3 月。
[RFC2931] Eastlake 3rd, D., 《DNS 请求与事务签名（SIG(0)）》, RFC 2931, 2000 年 9 月。
[RFC3110] Eastlake 3rd, D., 《域名系统（DNS）中的 RSA/SHA-1 签名与 RSA 密钥》, RFC 3110, 2001 年 5 月。
[RFC3445] Massey, D. 与 S. Rose, 《限制 KEY 资源记录（RR）的作用范围》, RFC 3445, 2002 年 12 月。
[RFC3548] Josefsson, S., 《Base16、Base32 与 Base64 数据编码》, RFC 3548, 2003 年 7 月。
[RFC3597] Gustafsson, A., 《处理未知的 DNS 资源记录（RR）类型》, RFC 3597, 2003 年 9 月。
[RFC3658] Gudmundsson, O., 《委派签名者（DS）资源记录（RR）》, RFC 3658, 2003 年 12 月。
[RFC3755] Weiler, S., 《委派签名者（DS）的旧解析器兼容性》, RFC 3755, 2004 年 5 月。
[RFC3757] Kolkman, O., Schlyter, J. 与 E. Lewis, 《域名系统密钥（DNSKEY）资源记录（RR）的安全入口点（SEP）标志》, RFC 3757, 2004 年 4 月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D. 与 S. Rose, 《DNS 安全扩展的引言与需求》, RFC 4033, 2005 年 3 月。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D. 与 S. Rose, 《DNS 安全扩展的协议修改》, RFC 4035, 2005 年 3 月。

10.2. 资料性参考文献

[RFC2535] Eastlake 3rd, D., 《域名系统安全扩展》, RFC 2535, 1999 年 3 月。
[RFC2537] Eastlake 3rd, D., 《域名系统（DNS）中的 RSA/MD5 密钥与签名》, RFC 2537, 1999 年 3 月。
[RFC2539] Eastlake 3rd, D., 《域名系统（DNS）中 Diffie-Hellman 密钥的存储》, RFC 2539, 1999 年 3 月。
[RFC2930] Eastlake 3rd, D., 《用于 DNS 的秘密密钥建立（TKEY RR）》, RFC 2930, 2000 年 9 月。
[RFC3845] Schlyter, J., 《DNS 安全（DNSSEC）NextSECure（NSEC）RDATA 格式》, RFC 3845, 2004 年 8 月。

附录 A. DNSSEC 算法与摘要类型

DNS 安全扩展被设计为与底层加密算法无关。DNSKEY、RRSIG 与 DS 资源记录都使用 DNSSEC 算法号来标识该资源记录所使用的加密算法。DS 资源记录还指定一个摘要算法号，以标识构造该 DS 记录所用的摘要算法。目前定义的算法与摘要类型列于下文。随着密码学的进步，将来可以增补额外的算法或摘要类型。

支持 DNSSEC 的解析器或域名服务器必须（MUST）实现所有强制（MANDATORY）算法。

A.1. DNSSEC 算法类型

DNSKEY、RRSIG 与 DS RR 使用 8 位数来标识所用安全算法。这些值存储于资源记录 RDATA 的 "Algorithm number"（算法号）字段中。

有些算法仅可用于区签名（DNSSEC），有些仅可用于事务安全机制（SIG(0) 与 TSIG），还有些两者皆可。可用于区签名的算法可以出现在 DNSKEY、RRSIG 与 DS RR 中。可用于事务安全的算法则出现在 SIG(0) 与 KEY RR 中，如 [RFC2931] 所述。

取值	算法 [助记符]	区签名	参考文献	状态
0	reserved（保留）
1	RSA/MD5 [RSAMD5]	n	[RFC2537]	NOT RECOMMENDED
2	Diffie-Hellman [DH]	n	[RFC2539]	-
3	DSA/SHA-1 [DSA]	y	[RFC2536]	OPTIONAL
4	Elliptic Curve [ECC]		TBA	-
5	RSA/SHA-1 [RSASHA1]	y	[RFC3110]	MANDATORY
252	Indirect [INDIRECT]	n		-
253	Private [PRIVATEDNS]	y	见下文	OPTIONAL
254	Private [PRIVATEOID]	y	见下文	OPTIONAL
255	reserved（保留）
6 - 251	可由 IETF 标准行动分配。

A.1.1. 私有算法类型

算法号 253 保留用于私有使用，永远不会被分配给某个特定算法。DNSKEY RR 中的公钥区与 RRSIG RR 中的签名区以一个线编码的域名开始，该域名不得（MUST NOT）被压缩。该域名指示要使用的私有算法，公钥区的其余部分由该算法决定。实体只应当使用它们所控制的域名来指定其私有算法。

算法号 254 保留用于私有使用，永远不会被分配给某个特定算法。DNSKEY RR 中的公钥区与 RRSIG RR 中的签名区以一个无符号长度字节开始，随后是该长度的 BER 编码对象标识符（ISO OID）。该 OID 指示正在使用的私有算法，该区域的其余部分是该算法所需的任何内容。实体只应当使用它们所控制的 OID 来指定其私有算法。

A.2. DNSSEC 摘要类型

DS 资源记录中的 "Digest Type"（摘要类型）字段标识该资源记录所使用的密码摘要算法。下表列出了目前定义的摘要算法类型。

取值	算法	状态
0	Reserved（保留）	-
1	SHA-1	MANDATORY
2-255	Unassigned（未分配）	-

附录 B. Key Tag 计算

RRSIG 与 DS 资源记录类型中的 Key Tag 字段提供了一种高效选择公钥的机制。在大多数情况下，owner name、算法与密钥标签的组合就能高效地标识一条 DNSKEY 记录。RRSIG 与 DS 资源记录都有与之对应的 DNSKEY 记录。当存在多条候选 DNSKEY RR 时，RRSIG 与 DS 记录中的 Key Tag 字段可用于帮助高效地选择对应的 DNSKEY RR。

然而，必须指出至关重要的一点：密钥标签并不是唯一标识符。理论上，两条不同的 DNSKEY RR 有可能具有相同的 owner name、相同的算法与相同的密钥标签。密钥标签用于缩小候选密钥的范围，但它不能唯一标识一条 DNSKEY 记录。实现不得（MUST NOT）假定密钥标签能唯一标识一条 DNSKEY RR。

除算法 1 之外，所有 DNSKEY 算法类型的密钥标签计算方式相同（算法 1 的密钥标签定义请参见附录 B.1）。密钥标签算法是把 DNSKEY RDATA 的线格式按 2 字节一组分组后的总和。首先，把 RDATA（线格式）视为一系列 2 字节组；然后把各组相加，忽略任何进位。

密钥标签算法的一个参考实现（以 ANSI C 函数的形式给出）如下，其中以 DNSKEY RR 的 RDATA 部分作为输入。不一定要逐字使用下面的参考代码，但 Key Tag 的数值必须（MUST）与参考实现对相同输入所产生的数值完全一致。

请注意，计算 Key Tag 的算法几乎——但不完全——等同于许多其他互联网协议中所用的熟悉的补码校验和（ones-complement checksum）。Key Tag 必须使用这里描述的算法计算，而不能使用补码校验和。

下面的 ANSI C 参考实现计算一个 Key Tag 的值。该参考实现适用于除算法 1 之外的所有算法类型（参见附录 B.1）。输入是 DNSKEY RR 的 RDATA 部分的线格式。该代码是为清晰而非效率而编写的。

   /*
    * Assumes that int is at least 16 bits.
    * First octet of the key tag is the most significant 8 bits of the
    * return value;
    * Second octet of the key tag is the least significant 8 bits of the
    * return value.
    */

   unsigned int
   keytag (
           unsigned char key[],  /* the RDATA part of the DNSKEY RR */
           unsigned int keysize  /* the RDLENGTH */
          )
   {
           unsigned long ac;     /* assumed to be 32 bits or larger */
           int i;                /* loop index */

           for ( ac = 0, i = 0; i < keysize; ++i )
                   ac += (i & 1) ? key[i] : key[i] << 8;
           ac += (ac >> 16) & 0xFFFF;
           return ac & 0xFFFF;
   }

B.1. 算法 1（RSA/MD5）的 Key Tag

出于历史原因，算法 1（RSA/MD5）的密钥标签定义与其他所有算法的密钥标签定义不同。对于算法 1 的 DNSKEY RR，密钥标签被定义为公钥模数最低 24 位中的最高 16 位（换言之，即公钥模数倒数第 4 个与倒数第 3 个字节）。

请注意，算法 1 不被推荐（NOT RECOMMENDED）。

作者地址（Authors' Addresses）

Roy Arends
Telematica Instituut
Brouwerijstraat 1
7523 XC Enschede
NL

EMail: roy.arends@telin.nl

Rob Austein
Internet Systems Consortium
950 Charter Street
Redwood City, CA 94063
USA

EMail: sra@isc.org

Matt Larson
VeriSign, Inc.
21345 Ridgetop Circle
Dulles, VA 20166-6503
USA

EMail: mlarson@verisign.com

Dan Massey
Colorado State University
Department of Computer Science
Fort Collins, CO 80523-1873

EMail: massey@cs.colostate.edu

Scott Rose
National Institute for Standards and Technology
100 Bureau Drive
Gaithersburg, MD 20899-8920
USA

EMail: scott.rose@nist.gov