Resolved curl: (6) Could not resolve host Unable to fetch URL only sometimes

[Lrnt]

Server operating system version

Debian 12.5

Plesk version and microupdate number

18.0.58 #2

Hi,

I changed my server recently and moved some websites several days ago.

I encounter error report from Plesk for some of my scheduled tasks.

curl: (6) Could not resolve host: www.mydomain.fr
Unable to fetch URL: https://www.mydomain.fr/[url_of_my_crontab]

In particular, one executed each minute : PHP Script takes pending mail in database and sends them (Want to know why? I have a back office history of emails sent to customers).

Please note that I didn't have these cURL errors on my old, less powerful server (Debian 9)...
Problem is not the PHP Script nor the fact that it is executed each minute, it has been working for years without problems.

And I can open my cron URL multiple times in my browser, no error.

According to other cURL Error (6) threads found here, I modified /etc/resolv.conf which now only contains:

nameserver 127.0.0.1
nameserver 8.8.8.8

And I launched:

systemctl restart sw-engine && systemctl restart sw-cp-server

Note that URL https://www.mydomain.fr/[url_of_my_crontab] is always reachable and when I open it manually no problem.
The scheduled task often launches without error but sometimes I get this error above.

Is there anything else I can do? Or something I can check?

Thanks.

 

[Lrnt]

/etc/resolv.conf seems to be automatically rewritten

 

[Lrnt]

I followed this: https://support.plesk.com/hc/en-us/...oes-not-hold-changes-on-the-server-with-Plesk (Solution 1)

So I added in /etc/systemd/resolved.conf (Google DNS):

DNS=8.8.8.8 8.8.4.4 2001:4860:4860::8888 2001:4860:4860::8844

Then executed:

restart systemd-resolved

I will keep you informed if errors disappear.

Any other advices will really be appreciated.

 

[AYamshanov]

Hi,

Please note that I didn't have these cURL errors on my old, less powerful server (Debian 9)...

Usually, it should not be related to powerful of a server (maybe except the case when the server really under a DDoS attack). If you changed DNS configuration for the domain (especially on the registrar side), taking it effect could take some time. Some DNS could cache negative answer for the request. And opposite, some servers, could cache IP-address and reply when no information publicly available yet.

• If you have control under DNS servers, make sense to check what information they have (and maybe clear cache)
• If you don't have control under DNS servers, make sense to check what other DNS services answer for the domain. It could be some temporary issue, in this case makes sense to wait.

Usually, if you plan to move domain from one IP-address to another, makes sense to decrease TTL for DNS-records, it decreases time that need to wait while new records will be propagated to the Internet.

• https://support.plesk.com/hc/en-us/...propagation-of-DNS-records-for-a-Plesk-domain
• Step #9 in the "Preparing servers" section, https://support.plesk.com/hc/en-us/...igration-and-Transfer-Guide#preparing servers
• https://support.plesk.com/hc/en-us/...or-SOA-records-on-all-domains-on-Plesk-server

 

[Lrnt]

@AYamshanov Thank you for your advices!

By "powerful" server, I mean "more recent" server.

Your answer makes me think that it is indeed a problem with DNS propagation.
However, when I migrate data or play with DNS, I always lower the TTL.

What do you think of the changes I made? Should I cancel them and just wait?

 

[Lrnt]

Error still here, 10 days after changing server and living website...

Do you think this is normal?

Everything I checked IP, DNS are good, I can't believe I can have a "Could not resolve host" after so many days.

What can I check precisely?
Thanks

 

[AYamshanov]

Could you share a domainname? Usually, it helps to perform some checks quickly to figure out what went wrong (if you want, through DM; then will provide results of checks here, but without exposing the domain name).

 

[Lrnt]

@AYamshanov DM sent with domain exposed.

 

[AYamshanov]

Usually, it helps to perform some checks quickly to figure out what went wrong (if you want, through DM; then will provide results of checks here, but without exposing the domain name).

Let me provide some details of checking here.
We found misconfiguration between settings on the Registrar side and the DNS zone configuration in Plesk for the specific domain name.
- Registrar's settings contain information about two nameservers (3rd and 4th rows on the screenshot); one of them have not answered at all. Another has a different name than is used as NS-record in zone configuration on Plesk.
- In Plesk, DNS zone contains two NS records, these nameservers respond quickly and correctly (1st and 2nd rows on the screenshot), but these nameservers were unknown the whole internet because of settings on Registrar side.
- It works partly because one of nameservers on the registrar's side points to same server which is configured in Plesk DNS zone as NS nameserver (lucky, otherwise it wouldn't work at all).



The fix is to update settings on one of sides (Registrar or Plesk), records should point to real nameservers that work, answer, authoritative for the DNS zone. Prolongation after update could take up to 24h.

What we see after the fix? It looks much better:



P.S. the checks were performed with MX Lookup Tool - Check your DNS MX Records online - MxToolbox tool.

 

[Lrnt]

Thanks to @AYamshanov for his precious help! This guy just rocks!

 

[Lrnt]

Thanks to the help of @AYamshanov for DNS servers and after disabling IPV6 according to this article and removing the entries I added before in /etc/systemd/resolved.conf (DNS=8.8.8.8 8.8.4.4 2001:4860:4860::8888 2001:4860:4860::8844), I haven't received any curl(6) errors since.

 

[AYamshanov]

Woohoo!
Glad to hear that!