我想了解crl.verisign.net的Alogging是如何工作的。 看下面的跟踪，做多个挖并不总是返回相同的IP。 这很好，因为我认为他们正在使用循环负载平衡。 但是，如果不用+ short标记进行挖掘，则不会提供所有可用的Alogging。
$ 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是正确的。
这个域名是如何工作的？
谢谢
verisign.net.的域名服务器verisign.net. 负载平衡系统只为crl.verisign.net.提供一个IP地址crl.verisign.net. ，具有1 （1秒）的TTL （生存时间），从而导致您的recursionparsing器在请求后续parsing时始终执行对权威服务器的后续请求。
您因此无法知道crl.verisign.net.所有IP地址crl.verisign.net. ，因为与谷歌的情况不同，在任何时候都只提供一个。 最好的猜测是whois的地址之一，看看它属于哪个networking，如果所有其他地址来自同一个networking，并且networking不是太大（一个主观的概念），那么可能是白名单整个networking（尤其是防火墙规则只适用于某种特定的服务或端口组合）。
% 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地址的白名单，注定是一个非常脆弱的行为，因为对方不知道这样的白名单，可能在任何时候，更改其configuration，导致需要更新防火墙上的规则。
你最好的select是在verisign.net.发邮件给某人verisign.net. ，并询问他们是否可以在防火墙中将他们的服务列入白名单，并确保哪些IP地址或networking能够保证完成这项工作。