Dns 附加部分中的CNAME记录

RFC 1034+1035说明CNAME记录不应导致额外的节处理。但是我看到越来越多的服务，如wordpress发送CNAME链，其中一部分在附加部分。因此，如果不解析附加部分，就无法解码DNS响应

例如：

;; QUESTION SECTION:
;after12.failblog.org.      IN  A

;; ANSWER SECTION:
after12.failblog.org.   3600    IN  CNAME   chzallnighter.wordpress.com.
vip-lb.wordpress.com.   300 IN  A   72.233.104.123
vip-lb.wordpress.com.   300 IN  A   76.74.255.117
vip-lb.wordpress.com.   300 IN  A   74.200.247.187
vip-lb.wordpress.com.   300 IN  A   74.200.247.59
vip-lb.wordpress.com.   300 IN  A   76.74.255.123
vip-lb.wordpress.com.   300 IN  A   72.233.127.217

;; AUTHORITY SECTION:
wordpress.com.      14400   IN  NS  ns1.wordpress.com.
wordpress.com.      14400   IN  NS  ns2.wordpress.com.
wordpress.com.      14400   IN  NS  ns3.wordpress.com.
wordpress.com.      14400   IN  NS  ns4.wordpress.com.
wordpress.com.      14400   IN  NS  ns5.wordpress.com.
wordpress.com.      14400   IN  NS  ns6.wordpress.com.

;; ADDITIONAL SECTION:
chzallnighter.wordpress.com. 300 IN CNAME   vip-lb.wordpress.com.
ns1.wordpress.com.  14400   IN  A   72.233.69.14
ns2.wordpress.com.  14400   IN  A   76.74.159.137
ns3.wordpress.com.  14400   IN  A   64.34.177.159
ns4.wordpress.com.  14400   IN  A   72.233.104.98
ns5.wordpress.com.  14400   IN  A   69.174.248.140
ns6.wordpress.com.  14400   IN  A   64.34.174.135

注意chzallnighter.wordpress.com。300在CNAME vip-lb.wordpress.com。在附加部分，如果没有它，您将无法访问答案中的记录

---

为什么提供商使用这样的策略？它真正为他们购买了什么？

您正在谈论的服务器恰好对这两个域都具有权威性，并为您提供它所拥有的一切。智能客户端可以优化这种类型的响应，避免往返。其中一个扩展了规范“使网络更快”类型的东西

---

天真的客户端可能不会注意到服务器对CNAMEd域具有权威性，丢弃额外的数据并重新查询-确保得到正确、安全的结果。智能客户端可以短接第二个查询，方法是注意到它已向服务器X请求原始域，并且服务器X也在CNAMEd域的权威服务器列表中。因此，附加部分中的CNAME是可信的。

这只是一个例子，wordpress上托管的任何博客都具有相同的分辨率，以及一组选定的CDN。MaraDNS因此修复了一个bug，BIND允许将其作为有效响应。我对RFC的解读是否不正确，或者这不是一个无效的响应？您是否可以引用RFC中的章节和诗句，使您认为这可能是非法的？您没有指定要查询的NS以进行dig。它应该是dig“@”ns1.wordpress.com，否则您只会从您的解析程序获得缓存响应。RFC 1035“CNAME RRs不会导致额外的节处理，但在某些情况下，名称服务器可以选择在规范名称处重新启动查询。”。RFC 2181：“附加部分处理不包括CNAME记录，更不用说可能与源自别名的规范名称相关联的地址记录了。”确切地说，附加部分仅供参考，它们不能成为解析的组成部分。事实上，一些DNS服务器甚至不会缓存额外的记录。我只是不知道为什么这会成为一种可以接受的做法，因为我读了第一个引文——它不排除处理附加部分——只是它不会自动导致这样的处理。第二个引号位于与MX和NS记录相关的一节中，该节以“资源记录不能是别名”开头，但这不适用于记录。