我正在尝试了解 crl.verisign.net 的 A 记录是如何工作的。请参阅下面的跟踪，进行多次挖掘并不总是返回相同的 IP。这很好，因为我认为他们使用的是某种循环负载平衡。但是，在没有 +short 标志的情况下进行挖掘不会提供所有可用的 A 记录。
$ dig @127.0.0.1 crl.verisign.net +short
199.7.52.190
$ dig @127.0.0.1 crl.verisign.net +short
199.7.52.190
$ dig @127.0.0.1 crl.verisign.net +short
199.7.59.190
$ dig @127.0.0.1 crl.verisign.net +short
199.7.59.190
$ dig @127.0.0.1 crl.verisign.net +short
199.7.51.190
$ dig crl.verisign.net
; <<>> DiG 9.9.2-P1 <<>> crl.verisign.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27537
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 11, ADDITIONAL: 12
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;crl.verisign.net. IN A
;; ANSWER SECTION:
crl.verisign.net. 1 IN A 199.7.59.190
;; AUTHORITY SECTION:
verisign.net. 29151 IN NS k2.nstld.net.
verisign.net. 29151 IN NS m2.nstld.net.
verisign.net. 29151 IN NS h2.nstld.net.
verisign.net. 29151 IN NS c2.nstld.net.
verisign.net. 29151 IN NS g2.nstld.com.
verisign.net. 29151 IN NS l2.nstld.com.
verisign.net. 29151 IN NS a2.nstld.com.
verisign.net. 29151 IN NS f2.nstld.com.
verisign.net. 29151 IN NS d2.nstld.net.
verisign.net. 29151 IN NS j2.nstld.net.
verisign.net. 29151 IN NS e2.nstld.net.
;; ADDITIONAL SECTION:
a2.nstld.com. 110706 IN A 192.5.6.31
a2.nstld.com. 23323 IN AAAA 2001:503:a83e::2:31
d2.nstld.net. 18060 IN A 192.31.80.31
e2.nstld.net. 4014 IN A 192.12.94.31
f2.nstld.com. 110706 IN A 192.35.51.31
g2.nstld.com. 57072 IN A 192.42.93.31
h2.nstld.net. 143445 IN A 192.54.112.31
j2.nstld.net. 117704 IN A 192.48.79.31
k2.nstld.net. 90449 IN A 192.52.178.31
l2.nstld.com. 113725 IN A 192.41.162.31
m2.nstld.net. 22505 IN A 192.55.83.31
;; Query time: 7 msec
;; SERVER: 172.30.3.30#53(172.30.3.30)
;; WHEN: Tue Mar 26 12:14:19 2013
;; MSG SIZE rcvd: 451
我可以举一个例子，当我挖掘 google.com 时，我得到了多个 IP。
dig google.com
; <<>> DiG 9.9.2-P1 <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28707
;; flags: qr rd ra; QUERY: 1, ANSWER: 11, AUTHORITY: 4, ADDITIONAL: 5
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 152 IN A 74.125.226.70
google.com. 152 IN A 74.125.226.71
google.com. 152 IN A 74.125.226.72
google.com. 152 IN A 74.125.226.73
google.com. 152 IN A 74.125.226.78
google.com. 152 IN A 74.125.226.64
google.com. 152 IN A 74.125.226.65
google.com. 152 IN A 74.125.226.66
google.com. 152 IN A 74.125.226.67
google.com. 152 IN A 74.125.226.68
google.com. 152 IN A 74.125.226.69
;; AUTHORITY SECTION:
google.com. 253951 IN NS ns1.google.com.
google.com. 253951 IN NS ns3.google.com.
google.com. 253951 IN NS ns2.google.com.
google.com. 253951 IN NS ns4.google.com.
;; ADDITIONAL SECTION:
ns1.google.com. 199215 IN A 216.239.32.10
ns2.google.com. 112828 IN A 216.239.34.10
ns3.google.com. 199396 IN A 216.239.36.10
ns4.google.com. 199396 IN A 216.239.38.10
;; Query time: 6 msec
;; SERVER: 172.30.3.30#53(172.30.3.30)
;; WHEN: Tue Mar 26 12:14:10 2013
;; MSG SIZE rcvd: 351
问题是我们试图将此 IP 列入防火墙的白名单，但我们无法正确执行此操作，因为我们不知道哪个 IP 是正确的。
这个域名如何运作？
谢谢
答案1
负载平衡系统的名称服务器verisign.net.仅为 提供一个 IP 地址crl.verisign.net.，其TTL生存时间为1(1 秒)，从而导致您的递归解析器在请求后续解析时始终向权威服务器执行后续请求。
因此，您无法知道 的所有 IP 地址crl.verisign.net.，因为与 Google 的情况不同，每次只提供一个 IP 地址。最好的猜测是whois其中一个地址，看看它属于哪个网络，并且，如果所有其他地址都来自同一网络，并且网络不是太大（主观概念），那么也许可以将整个网络列入白名单（特别是如果防火墙规则仅针对某个相当独特的服务或端口组合）。
% whois 199.7.59.190
…
NetRange: 199.7.48.0 - 199.7.63.255
CIDR: 199.7.48.0/20
OriginAS:
NetName: VGRSGTLD-15
…
然而，一般来说，这种白名单（即您手动确定必须列入白名单的 IP 地址）注定是一种非常脆弱的做法，因为另一方不知道您有这样的白名单，并且可能随时更改其配置，导致需要更新防火墙上的规则。
最好的办法是向 的某人发送电子邮件verisign.net.，询问他们是否可以在防火墙中将其服务列入白名单，以及哪些 IP 地址或网络可以保证完成这项工作。