RFC2317：Classless IN-ADDR.ARPA delegation，March 1998
本备忘录的状态
本文档为 Internet 社区指定了 Internet 最佳当前实践，并请求讨论和改进建议。本备忘录的分发不受限制。
版权声明
版权所有 (C) 互联网协会 (1998)。版权所有。
1、 介绍
本文档描述了一种在非八位字节边界上为覆盖少于 256 个地址的地址空间执行 IN-ADDR.ARPA 委托的方法。因此，所提出的方法应该消除对非八位字节边界上的子网的反对意见之一，但也许更重要的是，可以在比 24 位前缀更小的块中分配 IP 地址空间，而不会失去为相应的IN-ADDR.ARPA映射委托权限的能力。所提出的方法与[1]中指定的原始DNS查找机制完全兼容，即不需要修改所使用的查找算法，也不需要修改任何进行DNS查找的软件。
该文件还讨论了一些操作注意事项，以便为实施此方法提供一些指导。
2、 动机
随着无类路由技术的普及，在非八位字节边界上分配地址空间变得可行。对于只有几台主机的非常小的组织，分配完整的 24 位前缀（传统上称为“C 类网络号”）通常会导致地址空间利用率低下。
分配更长的前缀（更少的地址空间）时遇到的问题之一是，这样的组织似乎不可能自主维护自己的反向（“IN-ADDR.ARPA”）区域。通过使用下面描述的反向授权方法，可以消除对将较长前缀分配给不相关组织的最重要的反对意见。
假设我们已将地址空间分配给三个不同的参与方，如下所示：
192.0.2.0/25 to organization A 192.0.2.128/26 to organization B 192.0.2.192/26 to organization C
在经典方法中，这将导致像这样的单个区域：
$ORIGIN 2.0.192.in-addr.arpa. ; 1 PTR host1.A.domain. 2 PTR host2.A.domain. 3 PTR host3.A.domain. ; 129 PTR host1.B.domain. 130 PTR host2.B.domain. 131 PTR host3.B.domain. ; 193 PTR host1.C.domain. 194 PTR host2.C.domain. 195 PTR host3.C.domain.
这个区域的管理是有问题的。该区域的权限只能委托一次，这通常转化为“该区域只能由一个组织管理”。因此，具有与该区域中的条目相对应的地址空间的其他组织将不得不依赖另一个组织将其地址转换为名称。使用所提出的方法，可以避免这个潜在问题。
3、 无类 IN-ADDR.ARPA 委托
由于单个zone只能被委托一次，我们需要更多的点来进行委托来解决上面的问题。这些额外的委托点可以通过向下扩展 IN-ADDR.ARPA 树来引入，例如通过使用相应地址空间中的首地址或首地址和网络掩码长度（如下所示）来形成区域名称中的第一个组成部分。以下四个区域文件显示了如何使用此方法解决动机部分中的问题。
$ORIGIN 2.0.192.in-addr.arpa. @ IN SOA my-ns.my.domain. hostmaster.my.domain. (...) ;... ; <<0-127>> /25 0/25 NS ns.A.domain. 0/25 NS some.other.name.server. ; 1 CNAME 1.0/25.2.0.192.in-addr.arpa. 2 CNAME 2.0/25.2.0.192.in-addr.arpa. 3 CNAME 3.0/25.2.0.192.in-addr.arpa. ; ; <<128-191>> /26 128/26 NS ns.B.domain. 128/26 NS some.other.name.server.too. ; 129 CNAME 129.128/26.2.0.192.in-addr.arpa. 130 CNAME 130.128/26.2.0.192.in-addr.arpa. 131 CNAME 131.128/26.2.0.192.in-addr.arpa. ; ; <<192-255>> /26 192/26 NS ns.C.domain. 192/26 NS some.other.third.name.server. ; 193 CNAME 193.192/26.2.0.192.in-addr.arpa. 194 CNAME 194.192/26.2.0.192.in-addr.arpa. 195 CNAME 195.192/26.2.0.192.in-addr.arpa.
$ORIGIN 0/25.2.0.192.in-addr.arpa. @ IN SOA ns.A.domain. hostmaster.A.domain. (...) @ NS ns.A.domain. @ NS some.other.name.server. ; 1 PTR host1.A.domain. 2 PTR host2.A.domain. 3 PTR host3.A.domain.
$ORIGIN 128/26.2.0.192.in-addr.arpa. @ IN SOA ns.B.domain. hostmaster.B.domain. (...) @ NS ns.B.domain. @ NS some.other.name.server.too. ; 129 PTR host1.B.domain. 130 PTR host2.B.domain. 131 PTR host3.B.domain.
$ORIGIN 192/26.2.0.192.in-addr.arpa. @ IN SOA ns.C.domain. hostmaster.C.domain. (...) @ NS ns.C.domain. @ NS some.other.third.name.server. ; 193 PTR host1.C.domain. 194 PTR host2.C.domain. 195 PTR host3.C.domain.
对于使用这种方法拆分的每个大小为 256 的块，需要在父区域中增加接近 256 个 CNAME 记录。有些人可能认为这很难看；我们不会争论这一点。但是，如果地址空间的分区方式已知，则很容易在父区域中自动生成CNAME资源记录，一劳永逸。
与处理此问题的其他建议方法相比，此方法的优势在于无需修改任何已部署的软件。特别是，不必修改 DNS 中的查找机制以适应这种将 IPv4 地址的责任拆分为“非点”边界上的名称转换的情况。此外，这种技术已经在许多设施中使用了几年，显然没有不良影响。
像往常一样，像这样的资源记录
$ORIGIN 2.0.192.in-addr.arpa. 129 CNAME 129.128/26.2.0.192.in-addr.arpa.
可以方便地缩写为
$ORIGIN 2.0.192.in-addr.arpa. 129 CNAME 129.128/26
一些 DNS 实现对域名中的特殊字符不友好，例如上面例子中使用的“/”。正如 [3]所明确指出的，这些都是合法的，尽管有些人可能会觉得难看。因为这些不是主机名，[2]的限制不适用。现代客户端和服务器可以选择以自由和正确的方式行事。
这里的例子使用“/”是因为它被认为更明显，而且迂腐的评论者认为“这些不是主机名”的论点需要重复。我们建议您不要那么迂腐，也不要精确复制上述示例，例如将“/”替换为更保守的字符，例如连字符。
4、 操作注意事项
此技术旨在用于委托覆盖少于 256 个地址的地址空间。对于覆盖更大地址块的委托，可以使用传统方法（多个委托）代替。
4.1、 推荐的二级域名服务
如果指向的名称在本地尚未被称为缓存或权威数据，则某些较旧版本的名称服务器软件将不会在 CNAME 记录中查找并返回指向的名称。这可能会导致解析器出现一些混乱，因为响应中只会返回 CNAME 记录。为避免此问题，建议委托区域（包含所有 CNAME 记录的区域）的权威名称服务器都作为通过 CNAME 记录委托和指向的“子”区域的从属（辅助）名称服务器运行。
4.2、 替代命名约定
由于使用此方法，包含实际 PTR 记录的区域的位置不再预定义。这提供了灵活性，这里将提供一些示例。
使用第一个地址或相应地址空间中的第一个地址和网络掩码长度来命名新区域的替代方法是使用其他（非数字）名称。因此，也可以指向 DNS 树的完全不同的部分（即 IN-ADDR.ARPA 树之外）。如果两个组织以某种方式共享相同的物理子网（和相应的 IP 地址空间）而地址没有“整齐”对齐，但仍想管理他们自己的 IN-ADDR.ARPA 映射，则有必要使用这些替代方法之一。
以下简短示例显示了如何指出 IN-ADDR.ARPA 树：
$ORIGIN 2.0.192.in-addr.arpa. @ IN SOA my-ns.my.domain. hostmaster.my.domain. (...) ; ... 1 CNAME 1.A.domain. 2 CNAME 2.A.domain. ; ... 129 CNAME 129.B.domain. 130 CNAME 130.B.domain. ; $ORIGIN A.domain. @ IN SOA my-ns.A.domain. hostmaster.A.domain. (...) ; ... ; host1 A 192.0.2.1 1 PTR host1 ; host2 A 192.0.2.2 2 PTR host2 ;
等等。
通过这种方式，您实际上可以在同一个区域文件中获得名称->地址和（指向）地址->名称映射数据，有些人可能认为这是一个额外的好处，因为反向区域没有单独的辅助数据集是必须的。但是请注意，通过 IN-ADDR.ARPA 树的遍历仍将完成，因此插入到那里的 CNAME 记录需要指向正确的方向才能正常工作。
下图是使用相同解决方案的替代方法：
$ORIGIN 2.0.192.in-addr.arpa. @ SOA my-ns.my.domain. hostmaster.my.domain. (...) ; ... 1 CNAME 1.2.0.192.in-addr.A.domain. 2 CNAME 2.2.0.192.in-addr.A.domain.
$ORIGIN A.domain. @ SOA my-ns.A.domain. hostmaster.A.domain. (...) ; ... ; host1 A 192.0.2.1 1.2.0.192.in-addr PTR host1 host2 A 192.0.2.2 2.2.0.192.in-addr PTR host2
很明显，存在许多可以适应当前情况的特定要求的可能性。
4.3、 其他操作问题
请注意，不能为同一地址空间提供两次 CNAME 引用，即您不能为一个组织分配 /25 前缀，并以这种方式运行 IN-ADDR.ARPA，然后让组织将 /25 子网划分为更长的前缀，并且尝试使用相同的技术让每个子网控制自己的数字空间。这将导致 CNAME 记录指向 CNAME 记录，这可能总体上不太可靠。
不幸的是，流行的 DNS 名称服务器实现 BIND 4.9.3 的一些旧 beta 版本有一个错误，如果在进行反向查找时遇到 CNAME 记录，则会导致问题。所涉及的 beta 版本已经过时，此问题已在已发布的代码中解决。一些软件制造商在他们的产品中包含了有缺陷的测试版代码。在我们知道的少数情况下，制造商的补丁可用或计划替换所涉及的过时的测试版代码。
5、 安全考虑
使用这种方案，“叶子站点”将需要再依赖一个正确运行其 DNS 名称服务的站点，而不是它们拥有自己的 /24 分配，这可能会添加一个需要工作的额外组件可靠的名称解析。
除此之外，作者不知道此机制引入的任何其他安全问题。
6、 结论
建议的方案为在 IN-ADDR.ARPA 域中委托权限提供了更大的灵活性，从而可以更有效地分配地址空间，而不会失去将相应地址的 DNS 权限委托到名称映射的能力。
7、 致谢
Glen A. Herrmannsfeldt 不久前在 comp.protocols.tcp-ip.domains 上描述了这个技巧。Alan Barrett 和 Sam Wilson 对新闻组提供了宝贵的评论。
我们要感谢 Rob Austein、Randy Bush、Matt Crawford、Robert Elz、Glen A. Herrmannsfeldt、Daniel Karrenberg、David Kessens、Tony Li、Paul Mockapetris、Eric Wassenaar、Michael Patton、Hans Maurer 和 Peter Koch 的审阅和建设性意见。
8、 参考文献
[1] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987. [2] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet Host Table Specification", RFC 952, October 1985. [3] Elz, R., and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
9、 完整版权声明
版权所有 (C) 互联网协会 (1998)。版权所有。
本文件及其译文可能会被复制和提供给他人，并且可以全部或部分地准备、复制、出版和分发对其进行评论或以其他方式解释或协助其实施的衍生作品，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文档本身，例如通过删除版权声明或对 Internet 协会或其他 Internet 组织的引用，除非出于制定 Internet 标准的需要，在这种情况下，版权程序定义在必须遵循 Internet 标准流程，或按照要求将其翻译成英语以外的语言。
上述授予的有限权限是永久性的，不会被互联网协会或其继任者或受让人撤销。
本文档和其中包含的信息按“原样”提供，互联网协会和互联网工程工作队不提供所有明示或暗示的保证，包括但不限于任何保证，即使用此处的信息不会侵犯任何有关适销性或特定用途适用性的权利或任何默示保证。
