Google DNS的Mac OS X DNS问题

我正在协助其他用户解决DNS问题和一个大于512字节的golang bug。在我的机器上，DNSparsing远小于512字节，不包括授权部分，但在用户机器上，由于授权部分，它比512字节大得多。什么configuration/软件可能会导致这种差异？据我所知，我们在同一版本的Mac OS X上。

我的挖掘输出

> % dig @8.8.4.4 api.heroku.com ; <<>> DiG 9.8.3-P1 <<>> @8.8.4.4 api.heroku.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37856 ;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;api.heroku.com. IN A ;; ANSWER SECTION: api.heroku.com. 29 IN CNAME midgard.heroku.com. midgard.heroku.com. 449 IN CNAME midgard.herokussl.com. midgard.herokussl.com. 2758 IN CNAME elb082153-1559744486.us-east-1.elb.amazonaws.com. elb082153-1559744486.us-east-1.elb.amazonaws.com. 3 IN A 23.21.149.112 elb082153-1559744486.us-east-1.elb.amazonaws.com. 3 IN A 54.225.188.133 elb082153-1559744486.us-east-1.elb.amazonaws.com. 3 IN A 54.243.105.250 ;; Query time: 76 msec ;; SERVER: 8.8.4.4#53(8.8.4.4) ;; WHEN: Thu Aug 4 09:29:57 2016 ;; MSG SIZE rcvd: 193

用户挖掘输出

 ; <<>> DiG 9.8.3-P1 <<>> @8.8.4.4 api.heroku.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55215 ;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 13, ADDITIONAL: 12 ;; QUESTION SECTION: ;api.heroku.com. IN A ;; ANSWER SECTION: api.heroku.com. 21 IN CNAME midgard.heroku.com. midgard.heroku.com. 441 IN CNAME midgard.herokussl.com. midgard.herokussl.com. 3137 IN CNAME elb082153-1559744486.us-east-1.elb.amazonaws.com. elb082153-1559744486.us-east-1.elb.amazonaws.com. 51 IN A 54.243.105.250 elb082153-1559744486.us-east-1.elb.amazonaws.com. 51 IN A 54.225.188.133 elb082153-1559744486.us-east-1.elb.amazonaws.com. 51 IN A 23.21.149.112 ;; AUTHORITY SECTION: com. 140079 IN NS g.gtld-servers.net. com. 140079 IN NS j.gtld-servers.net. com. 140079 IN NS i.gtld-servers.net. com. 140079 IN NS b.gtld-servers.net. com. 140079 IN NS k.gtld-servers.net. com. 140079 IN NS a.gtld-servers.net. com. 140079 IN NS e.gtld-servers.net. com. 140079 IN NS c.gtld-servers.net. com. 140079 IN NS l.gtld-servers.net. com. 140079 IN NS m.gtld-servers.net. com. 140079 IN NS f.gtld-servers.net. com. 140079 IN NS h.gtld-servers.net. com. 140079 IN NS d.gtld-servers.net. ;; ADDITIONAL SECTION: g.gtld-servers.net. 124660 IN A 192.42.93.30 j.gtld-servers.net. 91373 IN A 192.48.79.30 i.gtld-servers.net. 119024 IN A 192.43.172.30 b.gtld-servers.net. 119025 IN A 192.33.14.30 k.gtld-servers.net. 27063 IN A 192.52.178.30 a.gtld-servers.net. 16745 IN A 192.5.6.30 e.gtld-servers.net. 123106 IN A 192.12.94.30 c.gtld-servers.net. 153632 IN A 192.26.92.30 l.gtld-servers.net. 22933 IN A 192.41.162.30 f.gtld-servers.net. 107336 IN A 192.35.51.30 h.gtld-servers.net. 29637 IN A 192.54.112.30 d.gtld-servers.net. 119025 IN A 192.31.80.30 ;; Query time: 48 msec ;; SERVER: 8.8.4.4#53(8.8.4.4) ;; WHEN: Thu Jul 14 07:37:57 2016 ;; MSG SIZE rcvd: 609

查询和请求标头看起来没有区别。我期望的情况是以下之一：

远程用户networking上的设备正在拦截DNSstream量并重新制定应答。
你打到不同的服务器农场。你们两个都向同一个IP发送请求，但是由于Anycast，你的请求到达了不同的目的地。至于为什么服务器的反应不同，只有谷歌可以回答。

https://developers.google.com/speed/public-dns/faq#anycast

Google Public DNS使用任播路由将所有数据包定向到最近的DNS服务器。有关选播路由的更多信息，请参阅Wikipedia条目。

应该指出，第二次答复所附的“附加”和“授权”部分是不寻常的。当一个recursion服务器返回这些部分，人们会期望看到的heroku.com服务器heroku.com而不是com. TLD。这很可能是服务器软件中意想不到的行为。