Why Does Ping to pop3.sina.net Pause for 15 Seconds? A DNS Troubleshooting Walkthrough

Yesterday a colleague reported an abnormal connection to our POP service for a telecom user. When I pinged the service from an Alibaba Cloud ECS instance, the connection reached the telecom VIP address, but the first frame to the second was unusually slow—about 15 seconds—while the overall ping latency averaged only 15 ms.

Suspecting the ping tool itself, I captured traffic with tcpdump:

$ tcpdump -s 0 -i eth1 host 49.7.36.125 -w 11-17-ping1.pcap

The capture showed that each ICMP request and response was fast, but after the second packet there was a 15‑second gap before the third packet arrived.

To investigate further I ran strace on the ping command:

$ strace -e trace=network -o 11-17-1.log -Tt ping pop3.sina.net -c 2

The strace output (see image) confirmed that the ICMP packets were exchanged quickly, but a large amount of time was spent in DNS resolution. The local Alibaba Cloud DNS servers (10.202.72.118 and 10.202.72.116) were queried to resolve pop3.sina.net to 49.7.36.125.

When I pinged the IP address directly, the command finished instantly:

$ strace -e trace=network -o 11-17-2.log -Tt ping 49.7.36.125 -c 2

Similarly, pinging www.baidu.com was fast, indicating that the problem lay with DNS rather than the ping implementation.

I captured DNS traffic with tcpdump for both the ping and a dig query:

$ tcpdump -s 0 -i eth0 port 53 -w 11-17-dns2.pcap   # ping pop3.sina.net
$ tcpdump -s 0 -i eth0 port 53 -w 11-17-dns3.pcap   # dig -t a pop3.sina.net

The dig capture was simple and fast, while the ping capture showed many DNS‑related delays.

After switching the local DNS to Google’s 8.8.8.8, both ping and dig responded instantly, confirming that the slowdown was caused by the Alibaba Cloud local DNS (or our corporate DNS server) rather than the network itself.

Thus, the culprit appears to be slow DNS resolution, not the ping tool or the underlying network.