5. DNS64 Normative Specification (DNS64 规范性规范)

DNS64 是一种从 A 记录合成 AAAA 记录的逻辑功能.DNS64 功能可以在存根解析器、递归解析器或权威名称服务器中实现.它在这些 DNS 功能内工作, 并在网络上表现为符合 [RFC1034] 和 [RFC1035] 的 "普通" DNS 解析器或名称服务器.

实现应该支持将独立的 IPv4 地址范围映射到独立的 IPv6 前缀以用于 AAAA 记录合成.这允许处理特殊用途的 IPv4 地址 [RFC5735].

DNS 消息包含多个部分.DNS64 更改的 DNS 消息部分是应答部分 (answer section), 这在下面的第 5.1 节中讨论.生成的合成应答与其他部分放在一起, 这创建了作为 DNS 查询的响应实际返回的消息.组装该响应在下面的第 5.4 节中介绍.

DNS64 还响应涉及包含它用于合成 AAAA RRs 的任何 IPv6 前缀的地址的 PTR 查询.

5.1. Resolving AAAA Queries and the Answer Section (解析 AAAA 查询和应答部分)

当 DNS64 接收到对类型为 AAAA 和类为 IN 的 RRs 的查询时, 它首先尝试检索此类型和类的非合成 RRs, 方法是执行查询, 或者在权威服务器的情况下, 检查其自己的结果.如果有本地缓存可用, 查询可能会从本地缓存中得到应答.除 IN 之外的类的 DNS64 操作未定义, 并且 DNS64 必须表现为好像没有配置 DNS64 功能.

5.1.1. The Answer when There is AAAA Data Available (有 AAAA 数据可用时的应答)

如果查询导致应答部分中有一个或多个 AAAA 记录, 则结果按照正常的 DNS 语义返回给请求客户端, 除非任何 AAAA 记录匹配特殊排除前缀集 (如第 5.1.4 节所述).如果有 (非排除的) AAAA 数据可用, DNS64 不应在响应中包含合成的 AAAA RRs (有关不遵守此建议的动机和影响的分析, 请参见附录 A).默认情况下, 当存在真实 AAAA RRs 时, DNS64 实现绝对不能合成 AAAA RRs.

5.1.2. The Answer when There is an Error (有错误时的应答)

如果查询导致 RCODE 不是 0 (无错误条件) 的响应, 则有两种可能性.RCODE=3 (Name Error) 的结果按照正常的 DNS 操作处理 (通常是将错误返回给客户端).此阶段仍在任何合成发生之前, 因此要返回给客户端的响应除了在 DNS 操作中通常发生的之外不需要任何特殊组装.

任何其他 RCODE 都被视为 RCODE 为 0 (参见第 5.1.6 和 5.1.7 节), 应答部分为空.这是因为当部署的名称服务器在没有 AAAA 记录可用时接收到 AAAA 查询时, 它们会产生大量不同的响应 (参见 [RFC4074]).请注意, 这意味着实际上, DNS 中的几种不同的错误类别都被视为好像该所有者名称没有 AAAA 记录可用.

重要的是要注意, 在撰写本文时, 即使该所有者名称有 A 记录可用, 某些服务器也会对 AAAA 查询响应 RCODE=3.这些服务器明显违反了 RCODE 3 的含义, 并且预期随着 IPv6 部署的增加, 它们的使用将会减少.

5.1.3. Dealing with Timeouts (处理超时)

如果查询在超时之前没有收到应答 (这可能是来自每个权威服务器的超时, 具体取决于 DNS64 是否处于递归解析器模式), 则将其视为 RCODE=2 (Server failure).

5.1.4. Special Exclusion Set for AAAA Records (AAAA 记录的特殊排除集)

某些 IPv6 地址实际上不能被 IPv6-only 主机使用.因此, 如果它们作为 AAAA 记录返回给 IPv6-only 查询代理, 则不会实现减少失败模式数量的目标.示例包括在 ::ffff:0:0/96 网络中具有地址的 AAAA 记录, 以及可能 (取决于上下文) 具有站点的 Pref64::/n 或众所周知前缀的 AAAA 记录 (有关众所周知前缀的更多信息, 请参见下文).DNS64 实现应该提供一种机制来指定要被视为好像包含它们的 AAAA 为空应答的 IPv6 前缀范围.实现应该默认在该范围内包含 ::ffff/96 网络.未能提供此功能将意味着查询 DNS64 功能的客户端可能无法与从双栈主机可访问的主机通信.

当 DNS64 执行其初始 AAAA 查询时, 如果它接收到仅包含排除范围内地址的 AAAA 记录的应答, 则它必须将应答视为好像它是空应答, 并相应地继续.如果它接收到至少一个包含任何排除范围之外的地址的 AAAA 记录的应答, 则默认情况下它应该构建一个响应的应答部分, 该应答部分仅包括不包含排除范围内任何地址的 AAAA 记录.该应答部分用于按照第 5.4 节详述的方式组装响应.或者, 它可以将应答视为好像它是空应答, 并相应地继续.它绝对不能将有问题的 AAAA 记录作为响应的一部分返回.

5.1.5. Dealing with CNAME and DNAME (处理 CNAME 和 DNAME)

如果响应包含 CNAME 或 DNAME, 则跟踪 CNAME 或 DNAME 链直到达到第一个终止的 A 或 AAAA 记录.如果对原始 AAAA 查询的响应是没有 AAAA 记录可跟踪的 CNAME 或 DNAME, 这可能需要 DNS64 请求 A 记录.生成的 AAAA 或 A 记录被视为任何其他 AAAA 或 A 情况, 视情况而定.

在组装应答部分时, 任何 CNAME 或 DNAME RRs 链都作为应答的一部分与合成的 AAAA (如果适用) 一起包含.

5.1.6. Data for the Answer when Performing Synthesis (执行合成时应答的数据)

如果查询导致无错误但响应中的应答部分为空, DNS64 尝试检索相关名称的 A 记录, 方法是执行另一个查询, 或者在权威服务器的情况下, 检查其自己的结果.如果这个新的 A RR 查询导致空应答或错误, 则空结果或错误将用作返回给查询客户端的应答的基础.如果查询导致一个或多个 A RRs, DNS64 根据第 5.1.7 节中概述的过程基于 A RRs 合成 AAAA RRs.DNS64 在应答部分中返回合成的 AAAA 记录, 删除构成合成基础的 A 记录.

5.1.7. Performing the Synthesis (执行合成)

合成 AAAA 记录从 A 记录创建如下:

o NAME 字段设置为 A 记录的 NAME 字段.

o TYPE 字段设置为 28 (AAAA).

o CLASS 字段设置为原始 CLASS 字段 1.根据本规范, 除 1 之外的任何 CLASS 的 DNS64 都未定义.

o 生存时间 (Time to Live, TTL) 字段设置为原始 A RR 的 TTL 和查询域的 SOA RR 的最小值.(请注意, 为了获得 SOA RR 的 TTL, DNS64 不需要执行新查询, 但它可以从 AAAA 查询的否定响应中的 SOA RR 记住 TTL.如果 SOA RR 未与 AAAA 查询的否定响应一起传递, 则 DNS64 应该使用原始 A RR 的 TTL 或 600 秒, 以较短者为准.也可以显式查询 SOA RR 并使用该查询的结果, 但这将增加查询负载和解析时间, 而几乎没有额外的好处.) 这与否定缓存 [RFC2308] 中使用的方法一致.

o RDLENGTH 字段设置为 16.

o RDATA 字段设置为来自 A 记录的 RDATA 字段的 IPv4 地址的 IPv6 表示形式.DNS64 必须根据配置的 IPv4 地址范围检查每个 A RR, 并选择相应的 IPv6 前缀用于合成 AAAA RR.有关实现转换的算法的讨论, 请参见第 5.2 节.

5.1.8. Querying in Parallel (并行查询)

为了最小化延迟, DNS64 可以并行执行 AAAA RR 和 A RR 的查询.

注意: 并行查询将导致在不需要 AAAA RR 合成的情况下执行不必要的 A RR 查询.一个可能的折衷是按顺序执行它们, 但它们之间的间隔非常短, 所以如果我们获得快速回复, 我们就避免执行额外的查询.(请注意, 此讨论仅在 DNS64 功能需要执行外部查询来获取 RR 时才相关.如果所需的 RR 信息在本地可用, 如在权威服务器的情况下, 则该问题不再相关.)

5.2. Generation of the IPv6 Representations of IPv4 Addresses (生成 IPv4 地址的 IPv6 表示形式)

DNS64 支持多种算法来生成 IPv4 地址的 IPv6 表示形式.对生成算法施加的约束如下:

o DNS64 必须使用相同的算法从 IPv4 地址创建 IPv6 地址, 该算法用于从原始 A RR 中包含的 IPv4 地址创建要在合成 AAAA RR 中返回的 IPv6 地址, 以及 IPv6/IPv4 转换器必须使用相同的算法从传入 IPv4 数据包的源地址字段中包含的 IPv4 地址创建要包含在传出 IPv6 数据包的源地址字段中的 IPv6 地址.

o 算法必须是可逆的; 即, 必须能够从 IPv6 表示形式派生原始 IPv4 地址.

o 算法的输入必须限于 IPv4 地址; IPv6 表示形式中使用的 IPv6 前缀 (表示为 Pref64::/n); 以及可选地, 一组在 DNS64 和 NAT64 中配置的稳定参数 (例如用作后缀的固定字符串).

对于每个前缀 Pref64::/n, n 必须小于或等于 96.如果通过任何方式 (例如手动配置或本文档中未指定的其他自动方式) 在 DNS64 中配置了一个或多个 Pref64::/n, 则默认算法必须使用这些前缀 (而不是使用众所周知前缀).如果没有可用的前缀, 则算法必须使用 [RFC6052] 中定义的众所周知前缀 64:ff9b::/96 来表示 IPv4 单播地址范围.

DNS64 必须支持 [RFC6052] 第 2 节中定义的用于生成 IPv4 地址的 IPv6 表示形式的算法.此外, 上述算法必须是 DNS64 使用的默认算法.虽然算法的规范性描述在 [RFC6052] 中提供, 但为了说明目的, 在第 7 节中提供了算法的示例描述及其在不同场景中的应用.

5.3. Handling Other Resource Records and the Additional Section (处理其他资源记录和附加部分)

5.3.1. PTR Resource Record (PTR 资源记录)

如果 DNS64 服务器接收到对 IP6.ARPA 域中记录的 PTR 查询, 它必须从 QNAME 中剥离 IP6.ARPA 标签, 根据 [RFC3596] 第 2.5 节中概述的编码方案反转 QNAME 的地址部分, 并检查生成的地址以查看其前缀是否与任何本地配置的 Pref64::/n 或默认的众所周知前缀匹配.DNS64 服务器有两种替代方案来响应此类 PTR 查询.DNS64 服务器必须提供其中之一, 并且除非不同的 IP6.ARPA 区域需要不同类型的应答, 否则不应同时提供两者:

第一个选项是让 DNS64 服务器权威地响应其前缀.如果地址前缀与站点中使用的任何 Pref64::/n 匹配, 无论是 NSP 还是众所周知前缀 (即 64:ff9b::/96), 则 DNS64 服务器可以使用本地适当的 RDATA 应答查询.DNS64 服务器可以对所有应答使用相同的 RDATA.请注意, 要求是匹配站点中使用的任何 Pref64::/n, 而不仅仅是本地配置的 Pref64::/n.这是因为终端客户端可以请求与通过不同 (站点提供的) DNS64 接收的地址匹配的 PTR 记录, 如果此策略有效, 这些查询永远不应发送到全局 DNS.此策略的优点是它使查询客户端清楚前缀是由 (DNS64) 站点操作的, 并且客户端获得的应答是由 DNS64 生成的.缺点是全局 DNS 中可能存在的任何有用的反向树信息对于查询 DNS64 的客户端都不可用.
第二个选项是让 DNS64 名称服务器合成将 IP6.ARPA 命名空间映射到相应 IN-ADDR.ARPA 名称的 CNAME.在这种情况下, DNS64 名称服务器应该确保相应 IN-ADDR.ARPA 名称的 PTR 处有 RDATA, 并且该名称处没有现有的 CNAME.这是为了避免合成使 CNAME 链更长或实际上不指向任何内容的 CNAME.响应的其余部分将是正常的 DNS 处理.如果需要, CNAME 可以即时签名.这种方法的优点是反向树中的任何有用信息对查询客户端都是可用的.缺点是它为 DNS64 增加了额外的负载 (因为必须为匹配 Pref64::/n 的每个 PTR 查询合成 CNAMEs), 并且可能需要即时签名.

如果地址前缀与任何 Pref64::/n 不匹配, 则 DNS64 服务器必须像处理任何其他查询一样处理查询; 即, 递归名称服务器必须尝试像解析任何其他 (非 A/AAAA) 查询一样解析查询, 并且权威服务器必须根据情况权威地响应或使用转介.

5.3.2. Handling the Additional Section (处理附加部分)

绝对不能对合成应答的附加部分中的任何记录执行 DNS64 合成.DNS64 必须不变地传递附加部分.

注意: 可能看起来将合成记录添加到附加部分是可取的, 因为客户端有时使用附加部分中的数据进行而不必重新查询.然而, 一般来说, 没有承诺附加部分将包含所有相关记录, 因此任何依赖于附加部分能够满足其需求 (即无需额外查询) 的客户端必然是损坏的.因此, 如果需要 AAAA 记录的 IPv6-only 客户端在它正在消费的应答的附加部分中找不到这样的记录, 它将发送对必要的 AAAA 记录的查询.对于正确运行的客户端, 如果附加部分为空, 效果将没有什么不同.删除附加部分中的 A 记录并用合成的 AAAA 记录替换它们的替代方案可能会导致 NAT64 后面的主机直接查询不知道相关 NAT64 的名称服务器.在这种情况下, 结果无论如何都会是解析失败, 但在解析操作的后期.禁止在附加部分中使用合成数据减少了但没有消除由于来自 DNS64 后面的缓存 DNS 数据而导致解析失败的可能性.参见第 6 节.

5.3.3. Other Resource Records (其他资源记录)

如果 DNS64 处于递归解析器模式, 则 [DEFAULT-LOCAL-ZONES] 中概述的注意事项可能是相关的.

所有其他 RRs 必须不变地返回.这包括对 A RRs 查询的响应.

5.4. Assembling a Synthesized Response to a AAAA Query (组装对 AAAA 查询的合成响应)

DNS64 使用不同的数据片段来构建返回给查询客户端的响应.

用作合成基础的查询要么导致错误, 要么导致可用作合成基础的应答, 要么导致空的 (权威的) 应答.如果有空应答, 则 DNS64 使用 DNS64 接收到的对原始 (发起方) 查询的应答响应原始查询客户端.否则, 响应按如下方式组装.

头字段根据递归或权威服务器的通常规则设置, 具体取决于 DNS64 所扮演的角色.问题部分从原始 (发起方) 查询复制.应答部分根据第 5.1.7 节中的规则填充.权威和附加部分从 DNS64 执行的最终查询的响应中复制, 并用作合成的基础.

来自 DNS64 的最终响应受所有标准 DNS 规则的约束, 包括截断 [RFC1035] 和 EDNS0 处理 [RFC2671].

5.5. DNSSEC Processing: DNS64 in Validating Resolver Mode (DNSSEC 处理: 验证解析器模式下的 DNS64)

我们考虑执行 DNS64 的递归解析器也具有根据 [RFC4035] 第 5 节中概述的过程验证应答的本地策略的情况.我们将这种一般情况称为 vDNS64.

vDNS64 使用 DO 和 CD 位的存在来做出关于查询发起方需要什么的一些决定, 并可以相应地做出反应:

如果 CD 未设置且 DO 未设置, vDNS64 应该执行验证并根据需要进行合成.有关如何执行验证和合成的规则, 请参见下一项.但是, 在这种情况下, vDNS64 绝对不能在任何响应中设置 AD 位.
如果 CD 未设置且 DO 已设置, 则 vDNS64 应该执行验证.每当 vDNS64 执行验证时, 它必须在继续查询同一名称的 A 记录之前验证 AAAA 查询的否定应答, 以确保互联网上没有合法的 AAAA 记录.未能遵守此步骤将允许攻击者使用 DNS64 作为规避 DNSSEC 的机制.如果否定响应验证通过, 并且对 A 查询的响应验证通过, 则 vDNS64 可以执行合成并应该在对客户端的应答中设置 AD 位.这是可接受的, 因为 [RFC4035] 第 3.2.3 节说, 如果且仅当它认为应答和权威部分中的所有 RRSets 都是真实的时, 安全感知递归名称服务器的名称服务器端才会设置 AD 位.在这种情况下, 名称服务器有理由相信 RRSets 都是真实的, 因此它应该设置 AD 位.如果数据未验证通过, vDNS64 必须响应 RCODE=2 (Server failure).

安全感知的终端可能将 AD 位的存在作为数据有效的指示, 并可能将 DNS (和 DNSSEC) 数据传递给应用程序.当然, 如果应用程序尝试验证合成的数据, 验证将失败.因此, 人们可能会争辩说这种方法是不可取的, 但安全感知的存根解析器绝对不能依赖从解析器接收的数据并代表它们验证的数据, 除非满足 [RFC4035] 第 4.9.3 节建立的某些标准.想要自己执行验证的应用程序应该使用 CD 位.
如果 CD 位已设置且 DO 已设置, 则 vDNS64 可以执行验证, 但绝对不能执行合成.它必须将数据返回给查询发起方, 就像常规的递归解析器一样, 并依赖于客户端自己执行验证和合成.

这种方法的缺点是, 对转换无关但安全感知且验证的终端将无法使用 DNS64 功能.在这种情况下, 终端将不会获得 NAT64 的预期好处.实际上, 这种策略意味着任何希望在 NAT64 上下文中进行验证的终端都必须升级为也具有转换感知能力.