• The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Issue DNS resolution wery slow

Erwan

Regular Pleskian
Hi all,

We just setup a new server (debian+obsedian).
When we perform a connection test to an external database, it takes more than 3 seconds to execute.
After various tests, it seems that the problem comes from the DNS resolution: when we used the ip of the database server, the connection is made normally in 0.03 seconds.
A simple ping on the domain is also very slow compared to a direct ping on the ip.
This phenomenon is spawning on different domains and IPs.

Do you have any idea how to solve this?

Thank you.

Erwan
 
Does the target have an IPv6 and IPv4 address? Are these both mentioned in your DNS records? It is possible that for example first an IPv6 connection is attempted and, as that fails, the requestor falls back to IPv4. The latency is caused by the timeout between the first attempt and the second. Similar symptoms can be observed when connecting to www or ftp service on systems that have one or the other IP type listed in their DNS, but do not actually allow access for either one.
 
Peter,

No only IPv4 on the server and on the destination server.
I've reread ips.

It's very slow too and big difference if i use www.google.com or www.google.com IP 172.217.19.228:

# ping 172.217.19.228 PING 172.217.19.228 (172.217.19.228) 56(84) bytes of data. 64 bytes from 172.217.19.228: icmp_seq=1 ttl=113 time=4.07 ms 64 bytes from 172.217.19.228: icmp_seq=2 ttl=113 time=4.09 ms 64 bytes from 172.217.19.228: icmp_seq=3 ttl=113 time=4.19 ms 64 bytes from 172.217.19.228: icmp_seq=4 ttl=113 time=4.22 ms --- 172.217.19.228 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3005ms
==> 3 seconds

# ping www.google.com PING www.google.com (172.217.19.228) 56(84) bytes of data. 64 bytes from par21s11-in-f4.1e100.net (172.217.19.228): icmp_seq=1 ttl=113 time=4.05 ms 64 bytes from par21s11-in-f4.1e100.net (172.217.19.228): icmp_seq=2 ttl=113 time=3.80 ms 64 bytes from par21s11-in-f4.1e100.net (172.217.19.228): icmp_seq=3 ttl=113 time=4.05 ms 64 bytes from 172.217.19.228: icmp_seq=4 ttl=113 time=3.96 ms --- www.google.com ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 9218ms
==> 9 seconds

It is possible that for example first an IPv6 connection is attempted and, as that fails, the requestor falls back to IPv4. The latency is caused by the timeout between the first attempt and the second.
Do you know any possibilities to test this with detailed error messages?
 
Try `host` or `nslookup`. Do they hang too? Any error messages about nonresponding DNS servers?
What's in /etc/resolv.conf?
 
Ok, after reboot the server and reread ips, i've an IPv6 that appear in the plesk panel.
Confirmation with ifconfig.

I've put instructions in /etc/sysctl.conf to disable IPv6:
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.all.autoconf = 0
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.default.autoconf = 0
# sysctl -p

And delete IPv6 in the plesk panel.
It's ok now.

Thank you for your help.
 
Back
Top