为什么 dig 命令只返回 google.com 的一个 IP 地址？
Why dig command is returning only one IP address of google.com?
我们知道google有多个IP地址。如果我们使用 https://toolbox.googleapps.com/apps/dig/#A/google.com@8.8.8.8 网站，它会产生多个 google.
的 IP 地址
如果我运行下面的命令那么场景就不同了：
gyan@localhost:~/codes/java/net$ dig google.com
; <<>> DiG 9.10.3-P4-Ubuntu <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11777
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 269 IN A 216.58.220.46
;; Query time: 0 msec
;; SERVER: 10.100.171.1#53(10.100.171.1)
;; WHEN: Fri Nov 04 16:18:07 IST 2016
;; MSG SIZE rcvd: 55
gyan@localhost:~/codes/java/net$
只返回一个IP地址，与上述网站返回的IP地址不一样。该 IP 地址也在不时更改。
但是如果我 运行 为 amazon.com 挖掘命令：
gyan@localhost:~/codes/java/net$ dig amazon.com
; <<>> DiG 9.10.3-P4-Ubuntu <<>> amazon.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55090
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;amazon.com. IN A
;; ANSWER SECTION:
amazon.com. 34 IN A 54.239.26.128
amazon.com. 34 IN A 54.239.17.7
amazon.com. 34 IN A 54.239.25.192
amazon.com. 34 IN A 54.239.25.208
amazon.com. 34 IN A 54.239.25.200
amazon.com. 34 IN A 54.239.17.6
;; Query time: 74 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Fri Nov 04 16:23:17 IST 2016
;; MSG SIZE rcvd: 135
gyan@localhost:~/codes/java/net$
这 6 个 IP 地址在 amazon.com 期间从未改变。网站 https://toolbox.googleapps.com/apps/dig/#A/amazon.com@8.8.8.8 也 returns 相同的 6 个 IP 地址。
我的疑问是 google.com 的 DNS 查找与 amazon.com 有何不同？为什么 google 结果只有一条记录，而不是像 amazon 那样多一条记录？
As we know google has more than one IP addresses.
没错。但这并不意味着客户需要了解其中一个以上。
过去，服务使用多个 IP 地址响应 DNS 查询以执行负载平衡是很常见的。回复通常是随机的，这意味着客户端会从大量表现相同的服务器地址中随机获得几个地址的子集。
基于 DNS 的负载平衡一直是一个 hack。由于缓存存在问题：如果 ISP 的 DNS 解析器正在缓存回复，大量用户将全部连接到那几个 IP 地址，从而降低负载平衡的有效性。解决方法是降低记录的 TTL，以确保条目在缓存中保留一小段时间，然后执行新查询。例如，您发布的挖掘输出中的 amazon.com A 记录的 TTL 设置为 34 秒。
该方法效果不佳。减少 TTL 会进一步导致小型 HTTP 请求的延迟增加。此外，DNS 负载平衡的结果有点不可预测，因为它不能保证服务器将统一处理负载。
但是，如果您有一个在网络级别工作的负载均衡器（将其视为反向 NAT 盒：一个 IP 面向互联网，将流量多路复用到它后面的大量服务器），它可以处理一个很多连接，也有很好的正常运行时间，不需要在 DNS 级别做负载平衡。
因此您连接的 Google 个数据中心可能不使用 DNS 负载平衡，而亚马逊的数据中心使用。
另一个问题是，为什么如果您从工具箱中查询 8.8.8.8 会得到多个地址，而从您的机器中查询时您只会得到一个。
首先，请务必了解，从工具箱进行查询时，发送 DNS 查询的是 Web 服务器，而不是您的计算机。
DNS 服务器不必 return 对不同客户端的相同回复。实际上，根据客户端的地理位置 return 不同的回复是很常见的：例如，如果欧洲的用户查询 google.com，它将获得欧洲数据中心的 IP 地址，而不是美国
在这种情况下，我认为 DNS 地理定位用于某些客户端，而不用于其他客户端。它可能与发送查询的网络大小以及网络负载平衡器的容量有关。例如，如果负载均衡器可以同时处理 1,000,000 个连接，而您发送查询的网络有 100,000 个 IP，则无需进行 DNS 负载均衡。但是如果网络很大（在你的例子中，数据中心的大小 运行 工具箱，网络负载平衡器可能无法处理它，所以启用 DNS 负载平衡并且你从中获得多个随机 IP 地址一个游泳池。
注意："network" 是指全部使用相同 DNS 解析器的一组计算机。
return 多个 IP 地址的另一个原因是进行基于 DNS 的故障转移。当其中一台机器停止工作时，客户端会尝试连接到另一台机器。但这不是进行故障转移的好方法，因为某些应用程序不会存储所有 IP 地址（尽管我认为大多数浏览器都存储），而且 DNS 缓存也会妨碍。
我们知道google有多个IP地址。如果我们使用 https://toolbox.googleapps.com/apps/dig/#A/google.com@8.8.8.8 网站，它会产生多个 google.
的 IP 地址如果我运行下面的命令那么场景就不同了：
gyan@localhost:~/codes/java/net$ dig google.com
; <<>> DiG 9.10.3-P4-Ubuntu <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11777
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 269 IN A 216.58.220.46
;; Query time: 0 msec
;; SERVER: 10.100.171.1#53(10.100.171.1)
;; WHEN: Fri Nov 04 16:18:07 IST 2016
;; MSG SIZE rcvd: 55
gyan@localhost:~/codes/java/net$
只返回一个IP地址，与上述网站返回的IP地址不一样。该 IP 地址也在不时更改。
但是如果我 运行 为 amazon.com 挖掘命令：
gyan@localhost:~/codes/java/net$ dig amazon.com
; <<>> DiG 9.10.3-P4-Ubuntu <<>> amazon.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55090
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;amazon.com. IN A
;; ANSWER SECTION:
amazon.com. 34 IN A 54.239.26.128
amazon.com. 34 IN A 54.239.17.7
amazon.com. 34 IN A 54.239.25.192
amazon.com. 34 IN A 54.239.25.208
amazon.com. 34 IN A 54.239.25.200
amazon.com. 34 IN A 54.239.17.6
;; Query time: 74 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Fri Nov 04 16:23:17 IST 2016
;; MSG SIZE rcvd: 135
gyan@localhost:~/codes/java/net$
这 6 个 IP 地址在 amazon.com 期间从未改变。网站 https://toolbox.googleapps.com/apps/dig/#A/amazon.com@8.8.8.8 也 returns 相同的 6 个 IP 地址。
我的疑问是 google.com 的 DNS 查找与 amazon.com 有何不同？为什么 google 结果只有一条记录，而不是像 amazon 那样多一条记录？
As we know google has more than one IP addresses.
没错。但这并不意味着客户需要了解其中一个以上。
过去，服务使用多个 IP 地址响应 DNS 查询以执行负载平衡是很常见的。回复通常是随机的，这意味着客户端会从大量表现相同的服务器地址中随机获得几个地址的子集。
基于 DNS 的负载平衡一直是一个 hack。由于缓存存在问题：如果 ISP 的 DNS 解析器正在缓存回复，大量用户将全部连接到那几个 IP 地址，从而降低负载平衡的有效性。解决方法是降低记录的 TTL，以确保条目在缓存中保留一小段时间，然后执行新查询。例如，您发布的挖掘输出中的 amazon.com A 记录的 TTL 设置为 34 秒。
该方法效果不佳。减少 TTL 会进一步导致小型 HTTP 请求的延迟增加。此外，DNS 负载平衡的结果有点不可预测，因为它不能保证服务器将统一处理负载。
但是，如果您有一个在网络级别工作的负载均衡器（将其视为反向 NAT 盒：一个 IP 面向互联网，将流量多路复用到它后面的大量服务器），它可以处理一个很多连接，也有很好的正常运行时间，不需要在 DNS 级别做负载平衡。
因此您连接的 Google 个数据中心可能不使用 DNS 负载平衡，而亚马逊的数据中心使用。
另一个问题是，为什么如果您从工具箱中查询 8.8.8.8 会得到多个地址，而从您的机器中查询时您只会得到一个。
首先，请务必了解，从工具箱进行查询时，发送 DNS 查询的是 Web 服务器，而不是您的计算机。
DNS 服务器不必 return 对不同客户端的相同回复。实际上，根据客户端的地理位置 return 不同的回复是很常见的：例如，如果欧洲的用户查询 google.com，它将获得欧洲数据中心的 IP 地址，而不是美国
在这种情况下，我认为 DNS 地理定位用于某些客户端，而不用于其他客户端。它可能与发送查询的网络大小以及网络负载平衡器的容量有关。例如，如果负载均衡器可以同时处理 1,000,000 个连接，而您发送查询的网络有 100,000 个 IP，则无需进行 DNS 负载均衡。但是如果网络很大（在你的例子中，数据中心的大小 运行 工具箱，网络负载平衡器可能无法处理它，所以启用 DNS 负载平衡并且你从中获得多个随机 IP 地址一个游泳池。
注意："network" 是指全部使用相同 DNS 解析器的一组计算机。
return 多个 IP 地址的另一个原因是进行基于 DNS 的故障转移。当其中一台机器停止工作时，客户端会尝试连接到另一台机器。但这不是进行故障转移的好方法，因为某些应用程序不会存储所有 IP 地址（尽管我认为大多数浏览器都存储），而且 DNS 缓存也会妨碍。