Curl can't resolve host: img.youtube.com

Q: Date/Time this occurred (Provide your time zone also)
A: Discovered this on 22 Nov 2022, 15:00, Sao Paulo, BR time.

Q: DevKinsta Version
A: 2.8.0

Q: OS Version
A: MacOS Monterey, 12.6 (Running on M1 machine)

Q: Docker Desktop Version
A: v4.13.1

Q: Were any error codes or messages observed? If so, what were they?
A: curl: (6) Could not resolve host: img.youtube.com

Q: Detailed Description of the Problem
A: We have a script that calls the url https://img.youtube.com to retrieve the thumbnail of specific youtube videos for the user. But we can’t make the request to that URL using PHP, or even curl in the bash.

I can replicate this on bash and PHP. Here is a snippet how to replicate it using curl in bash:

docker exec -it devkinsta_fpm bash
curl -L https://img.youtube.com/vi/1YyO12WGju0/0.jpg
curl: (6) Could not resolve host: img.youtube.com

But if I call the domain that redirects to www I get the same error:

curl -L https://youtube.com
curl: (6) Could not resolve host: www.youtube.com

If I try another domain, like:

curl -L https://metaslider.com
<it outputs the source code correctly>

and

curl -L https://www.metaslider.com
<it outputs the source code correctly>

It seems to be related to DNS. The content of /etc/resolv.conf is the following:

nameserver 127.0.0.11
options ndots:0

If I change to:

nameserver 8.8.8.8
options ndots:0

Those requests to youtube start working, but of course the local sites’ domains stop working.

I’m able to make requests to img.youtube.com from another custom docker container, but not from inside the devkinsta_fpm.

Hi @andergmartins, thank you very much for the clear report and testing done here. Something similar came up in this thread without a solution that applies to what you are experiencing; that started an internal discussion about the DNS resolver we are using for DevKinsta. I’ll make sure the devs take a look at your findings/see if there’s a quick fix.

Hi @Kevin cool, thank you for the quick feedback. Yeah, that issue looks similar, sorry, I missed that one and created another thread here.

I will be glad to help. Please, could you, or the devs, give me a little more information about the DNS resolver used on DevKinsta? Which one, or where can I find it inside the container so I can try helping debugging or fixing that?

Is it related to the devkinsta_nginx container?

Oh, I found it when listing the devkinsta_fpm container’s processes.

It is shaman, and is running as the service dns_server.

I just tried doing the following:

dns_server list

And it displayed only the local domains I have on DevKinsta:

["php-74-dev.local","php-81-dev.local","php-80-dev.local"]

So I tried updating the register for the specific domain I need, running the command:

dns_server update -d img.youtube.com

It returned:

{"domain":"img.youtube.com.","records":[{"ttl":60,"class":"IN","type":"A","address":""}]}

And that worked! The local DNS server is able to find that domain.

Now it recognizes the domain and I can know run:

curl -L https://img.youtube.com/vi/1YyO12WGju0/0.jpg

And it returns the correct answer when doing the request throw PHP as well.

This is probably a temporary solution, but works for me for now.

I will comment on that other ticket, since I suppose that might help on that too.

Thanks

1 Like

Hello @andergmartins , Agus here :wave:
Thank you for your reply and the details of the workaround you provided which worked well for you - so that the default DNS resolver ( shaman ) we use finally recognizes that hostname/sub-domain.

I was able to replicate this issue on my Windows machine (Win 10 pro) and was able to resolve it with your solution above :clap:

though on my Linux laptop the local DNS resolver could resolve/recognize that same hostname/sub-domain just fine (without adding that dns_server update -d img.youtube.com line ).

I will mark your reply above as a solution now! Thank you for your reply on the other ticket as well!

PS: @Kevin is not available at the moment, but last week I talked with him as well about this internally with our Devs team, and will surely let them know about this solution as well! :+1:

1 Like

Sure, no problem. Thanks

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.