今天有个读者来信问我，是本域的权威名字服务器，还是上一级名字服务器来权威应答域的NS记录？
这个问题正好借用腾讯DNS的不正确配置来回答。
早前一阵，我发现QQ的DNS配置有点问题，我们执行如下两个dig:
$ dig www.qq.com ns @ns1.qq.com
; <<>> DiG 9.4.2-P2.1 <<>> www.qq.com ns @ns1.qq.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50734
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;www.qq.com. IN NS
;; ANSWER SECTION:
www.qq.com. 86400 IN NS ns-tel1.qq.com.
www.qq.com. 86400 IN NS ns-tel2.qq.com.
;; AUTHORITY SECTION:
qq.com. 86400 IN NS ns4.qq.com.
qq.com. 86400 IN NS ns1.qq.com.
qq.com. 86400 IN NS ns2.qq.com.
qq.com. 86400 IN NS ns3.qq.com.
;; Query time: 7 msec
;; SERVER: 219.133.62.252#53(219.133.62.252)
;; WHEN: Sat Jul 9 08:58:38 2011
;; MSG SIZE rcvd: 144
$ dig www.qq.com ns @ns-tel1.qq.com
; <<>> DiG 9.4.2-P2.1 <<>> www.qq.com ns @ns-tel1.qq.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44393
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;www.qq.com. IN NS
;; AUTHORITY SECTION:
qq.com. 86400 IN SOA ns1.qq.com.
webmaster.qq.com. 1293074536 300 600 86400 86400
;; Query time: 7 msec
;; SERVER: 121.14.73.115#53(121.14.73.115)
;; WHEN: Sat Jul 9 08:59:07 2011
;; MSG SIZE rcvd: 78
首先我们应知道www.qq.com是一个域，而不是一个普通域名。这里有问题的地方在于：
（1）ns1.qq.com是qq.com的权威服务器，为什么它响应子域www.qq.com的NS记录的权威应答？
（2）ns-tel1.qq.com是www.qq.com域的权威服务器，为什么它对NS查询没有返回任何结果？
当时我也不是很确认这个问题，于是在邮件列表上询问如下：
First, why ns1.qq.com (which is the authoritative nameserver for the zone of qq.com, not www.qq.com) returns the authoritative answer for www.qq.com’s NS query? and even includes a AA flag in the response.
Second, why ns-tel1.qq.com (which is the authoritative nameserver for the zone of www.qq.com) returns nothing for this zone’s NS query?
来自BIND开发组织isc.org的Mark对这2个问题作了回答。第一个问题：
Because the nameserver is not RFC compliant. There are lots of broken nameservers out there. Early versions of BIND had this bug but we removed it over a decade ago.
But it isn’t returning a referral when it should (the NS records are in the wrong section) and as it isn’t configured to server www.qq.com the “aa” is wrong.
很明显，qq.com的DNS并不兼容RFC，在查询www.qq.com的NS记录时，ns1.qq.com应该返回一个引用，但是它返回了www.qq.com域的权威NS记录，这是错误的。
第二个问题：
Because it is misconfigured. Instead of serving www.qq.com it is configured to server qq.com which can be seen in all the negative answers it returns. Unfortunately lots of load balancers are similarly misconfigured.
www.qq.com的NS服务器也配置错误，它未响应本域的NS查询是不应该的，而且其SOA记录提供了qq.com的NS服务器信息。这个NS服务器应该是F5的3DNS，它并非标准实现也就可以理解。
所以，总结如下：
（1）域的NS记录的权威解析，一定是本域的权威服务器自身。它的上一级NS也许返回了权威解析（例如把glue记录放在ANSWER部分，并且设置aa flag），但这是不应该的（老的BIND8有这个问题）。客户端解析器，应该使用并缓存权威服务器返回的NS记录。
（2）权威服务器可以且应该返回域的NS记录。它如果不返回，会增加公共DNS和上一级NS的查询压力，是不好的DNS实现。