非终端DNS名重定向

1. 介绍

本文会介绍一种新的DNS资源称为"DNAME"，它可以使DNS名字空间的一个子树映射到另一个域中，它与CNAME不同，CNAME只能将树中的一个结点遇到另一域中。

2. 背景

它是为了处理网络重编号时的产生的问题而产生的。在没有DNAME时，如果要进行重新编号，用于地址名字映射的DNS服务器需要重新配置，工作量可是不小，有了DNAME之后，可以建立一个区（zone），这样不用进行什么修改就可以了。当然在别的方面DNAME也有其它用途。

3. DNAME资源记录（RR）

DNAME RR拥有类型代码39，它的格式如下：

<owner> <ttl> <class> DNAME <target>

格式不分级，所有域都需要，RDATA域<target>是<domain-name>。

DNAME的作用是代替记录的<target>，对于区文件中的DNAME来说，有一个无后代（no-descendant）限制：

如果N结点有DNAME RR，可以在N中有数据，但N的子孙（后代）中不能有数据，这条限制应该于与DNAME相同class的记录中。

当DNAME被缓冲时，此限制保证不会产生不可预料的结果。在认证数据加载时一定要注意这一条。和其它限制一起，我们可以知道DNAME和NS记录只能共存于只有一个结点的区的顶结点中。不要对DNAME的RDATA部分进行压缩，除非发送服务器知道接收方可以识别这一格式。对这种压缩的理解属于DNS扩展的一部分。命名环（Naming loop）可以通过DNAME记录或DNAME和CNAME的组合创建。不要把这种环的长度弄得过长。

4. 查询

为了利用DNAME机制，必须对服务器和resolver的算法作一些修改。我们把这个修改称为DNAME替换。

4.1.服务器方

对于DNS中非循环查询中的3.c和4第四步，应该在检查wildcard("*")前检查DNAME，并从区数据和缓冲中返回包括DNAME记录。

DNS客户发送扩展DNS请求，或非扩展请求，在非扩展请求假设不能理解DNAME的语义，所以实现DNAME的服务器在接收到非扩展请求时，应该对每个DNAME加上碰到的CNAME，帮助客户找到正确的DNS数据。如果客户和服务器能够理解扩展请求，传输的版本号大于0。如果提供了一起的CNAME RR，它必须有：

• 和请求QCLASS相同的CLASS
• TTL=0
• 当碰到DNAME RR时有一个和有效QNAME相同的<owner>
• 包括新QNAME的RDATA域，这个新DNAME是由DNAME替换获得的

1. 是不是支持循环查询要看服务器，如果支持，而且需要循环查询，转到第5步；
2. 查询最靠近QNAME祖先的结点所在的区，如果未找到这个区，转第4步；
3. 开始在区内从上到下进行匹配，匹配过程的结束条件有以下几个：

• 如果整个QNAME匹配了，我们就找到了。如果数据所在结果是CNAME，QTYPE不匹配CNAME，复制CNAME RR到响应的应答区，将QNAME改变为CNAME RR中的标准形式后返回第1步；否则复制所有匹配QTYPE的RR到响应的应答区，然后转第6步；
• 如果匹配的结果使我们离开了认证权威，我们就获得一个参照（referral），我们这时会碰到一个带有NS RR的结点，复制NS RR到响应的认证区内，在其它区域随便放上什么地址，如果从认证数据或缓冲内没有获得地址，可以使用关联RR。然后转到第4步；
• 如果在有些标记上，匹配是不可能的，看最近一次匹配中的标记是不是有DNAME记录。如果有DNAME记录，将记录复制到响应区。如果在替换<target>时超过的合法长度，设置RCODE为YXDOMAIN并退出，如果没有超过合法长度，进行替换并继续。如果没有说明能够理解扩展DNS，服务器应该在响应区内包含CNAME记录，返回第1步。
  如果"*"标记不存在，检查我们要查找的名字是不是QNAME，如果名字就是原来的QNAME，在响应中设置错误，否则退出。如果"*"存在，以RR和QTYPE匹配，如果匹配成功，将它们复制到响应中，但设置RR的拥有者（owner）为QNAME，不是带有"*"的结点，然后转到第6步；

1. 在缓冲中进行匹配，如果在缓冲中找到QNAME，将所有和它关联的而且匹配QTYPE的RR复制到响应区，如果没有从认证权威来的授权，可以在缓冲中寻找最好的一个，将它放在认证区内，然后转到第6步；
2. 使用本地resolver响应请求。保存包括中间CNAME在内的结果到应答中。
3. 仅使用本地数据，试着加入其它有用的RR到查询的附加部分。然后退出。

注意：除非区数据违反上面所说的无后代限制，DNAME至多有一个祖先。算法具体实现时，可以利用这一限制在3c或第4步碰到DNAME时停止。

4.2. Resolver

对resolver算法的修改是在原来算法的基础上将4.d变为4.e并加入新的4.d，完整的算法如下：

1. 检查结果是否在本地，如果是则直接返回；
2. 向最合适的服务器查询；
3. 向多个服务器发出请求，直到得到响应；
4. 分析结果：

• 如果响应给出了结果或包含名字错误，缓冲并返回结果给用户；
• 如果响应指出更合适的服务器，缓冲这个结果，转第2步；
• 如果响应显示CNAME，但并不是答案，缓冲CNAME，将SNAME改为CNAME RR中的统一名称，然后转第1步；
• 如果响应显示一个DNAME，但它并不是响应本身，缓冲DNAME。如果对<target>的替换超过了合法范围，返回于一个错误码，否则执行替换，并返回第1步；
• 如果响应显示服务器失败或其它不可识别的内容，从SLIST中删除此服务器，然后转第3步。

5. 例子

5.1. 有组织的重命名

如果FROBOZZ.EXAMPLE变为ACME.EXAMPLE的一部分，可能通过加入下面的语句完成：

frobozz.example. DNAME frobozz-division.acme.example.

MX 10 mailhub.acme.example.

对于www.frobozz.example的扩展循环查询的响应将包括相应的DNAME记录。

5.2. 短前缀无级推荐（delegation）

使用DNAME时，对于in-addr.arpa的推荐机制，它可以被扩展至前缀小于24位。例如前缀192.0.8.0/22可以被表示以下面的记录：

$ORIGIN 0.192.in-addr.arpa.

8/22 NS ns.slash-22-holder.example.

8 DNAME 8.8/22

9 DNAME 9.8/22

10 DNAME 10.8/22

11 DNAME 11.8/22

对一些以192.0.9.33为地址的主机的反向区的通常入口如下：

$ORIGIN 8/22.0.192.in-addr.arpa.

33.9 PTR somehost.slash-22-holder.example.

5.3. 网络重编号支持

如果网络支持重编号，可以使用DNAME代替NS记录进行推荐。

$ORIGIN new-style.in-addr.arpa.
189.190 DNAME in-addr.example.net.

$ORIGIN in-addr.example.net.
188 DNAME in-addr.customer.example.

$ORIGIN in-addr.customer.example.
1 PTR www.customer.example.
2 PTR mailhub.customer.example.

; 等