我们正在对Docusign进行API调用，该调用有时会因“ getaddrinfo：名称或服务未知”错误而失败。进一步调查，我们发现当我们连接时，名称解析有时会失败，但是只能从我们的West数据中心位置进行。似乎美国西部的GLB DNS可能需要很长时间才能解决，导致DNS客户端超时，而查找时间超过10秒钟就会导致DNS客户端超时。
$ dig @1.1.1.1 www.docusign.net
; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> @1.1.1.1 www.docusign.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49468
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;www.docusign.net. IN A
;; ANSWER SECTION:
www.docusign.net. 22 IN CNAME www-geo.docusign.net.akadns.net.
www-geo.docusign.net.akadns.net. 22 IN CNAME www-west.docusign.net.akadns.net.
www-west.docusign.net.akadns.net. 22 IN A 162.248.184.27
;; Query time: 1 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Thu Oct 04 13:16:43 EDT 2018
;; MSG SIZE rcvd: 126
以上是一个很好的结果，花费了1毫秒（缓存）
$ dig @1.1.1.1 www.docusign.net
; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> @1.1.1.1 www.docusign.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21193
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;www.docusign.net. IN A
;; ANSWER SECTION:
www.docusign.net. 6 IN CNAME www-geo.docusign.net.akadns.net.
www-geo.docusign.net.akadns.net. 6 IN CNAME www-west.docusign.net.akadns.net.
www-west.docusign.net.akadns.net. 6 IN A 162.248.184.27
;; Query time: 2725 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Thu Oct 04 13:21:29 EDT 2018
;; MSG SIZE rcvd: 126
这更糟，因为它花了将近3秒钟。在测试过程中，我们看到这超过了12秒，这会使许多DNS客户端和请求应用程序超时。
由于TTL设置为30s，这意味着每30秒就有机会发生超时，我们的应用会生成错误，然后DNS成功导致服务恢复。不幸的是，这在我们的应用程序中对我们的客户显示为错误。
我们可以使用黑客来解决此问题，但是很好奇是否有人看到它，以及您如何解决它。另外，对docusign / akamai的人们来说，调查为什么www-west.docusign.net.akadns.net记录的性能如此差可能是一件好事。