cURL error 6: Could not resolve: site.test (Domain name not found)

[necrojan]

I have a laravel app and a lumen api app both installed on my local machine. The laravel app uses the lumen app to get the data, so on my .env file the laravel app has its APP_DOMAIN=http://site.test/ and it's being used as a base_uri for the Guzzle Client class.

Everything was working smoothly not until today I got the error that says.

cURL error 6: Could not resolve: site.test (Domain name not found) (see http://curl.haxx.se/libcurl/c/libcurl-errors.html)

When I try to test the lumen url on the browser it works completely fine, as well as on postman. http://site.test/url-here it returns the json stuff that I need.

So I was wondering why isn't being recognized by the laravel app.

Also I saw very similar issue But I don't think adding the url on the /etc/hosts file is the right way

Any idea how to fix this? I am not quite sure if this is the right place to post this issue. So I apologize
if I'm on the wrong side.

Thanks

[drbyte]

First: reboot.

CURL error 6 means there's a dns lookup problem. (as you can see in the response you got).

Valet provides DNS services to *.test via dnsmasq.

You said "it was working smoothly until today". Does that mean you WERE doing successful CURL calls before today? If so, what changed on your workstation?
Possible causes of dnsmasq issues:

• a reboot is necessary
• tampering with Network / IP configs in OSX
• installation of other software that's interfering
• changing config files related to dnsmasq or osx

[necrojan]

Thanks for your comment @drbyte

Yes it was working completely a day before, the only thing I remember doing was some yarn upgrade. And I didn't bother to look on it after the upgrade since it was pretty late so I shut down the Mac and went to bed.

I've done the reboot couple of times and I haven't installed any software lately.
So I guess it's the second the fourth dot that I need to test. Which I'm not pretty sure how to do tbh.

Aside from I need to do a lot of google research for that,
Can you suggest any terminal commands or reference that I can check up into.

Thanks

[drbyte]

1. It's interesting that it's only curl that's giving trouble, and only with Guzzle. I'm not convinced this is a Valet issue.
   You could maybe enable Guzzle's debug mode, to get more information back:
   http://docs.guzzlephp.org/en/latest/request-options.html#debug

You could also install an alternate Client to override the default of using CURL: http://docs.guzzlephp.org/en/latest/faq.html#does-guzzle-require-curl

2. I wouldn't have expected a simple yarn update to do anything that's interfering, unless it's gone and installed some package that set some new ENV vars that CURL uses, or something that provides DNS services and now is clashing with dnsmasq or osx core. And if it does then that raises other concerns, beyond the scope of Valet.
   But, one way to rule it out is to delete everything yarn installed, and then remove the node_modules dir, and reboot. And if it's from "global" tools that yarn installed, clean those up too. Maybe not "ideal", but useful as a troubleshooting step nonetheless.

3. Given that you said other services are able to reach site.test it means dnsmasq "is" running, so the following troubleshooting for dnsmasq is probably pointless, but I'll leave it here for reference anyway.

DNSMASQ troubleshooting

Top 3 troubleshooting steps I've taken with dnsmasq issues:

• use dig to find out what's happening with lookups
• enable dnsmasq logging to get it to report any startup problems
• inspect OSX config

dig

dig site.test
This should come back with something like the following. Note the "A" record pointing to 127.0.0.1, and the SERVER: 127.0.0.1 in the following, and what's different in yours.

; <<>> DiG 9.10.6 <<>> site.test
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58405
;; flags: qr aa rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;site.test.			IN	A

;; ANSWER SECTION:
site.test.		0	IN	A	127.0.0.1

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Mar 01 10:26:39 EST 2019
;; MSG SIZE  rcvd: 54

logging

Enabling logging in dnsmasq:
One place to do this is in ~/.config/valet/dnsmasq.conf
It should already have 2 lines in it for your configured TLD.
Add the following lines, adjusting for your actual username:

# Logging
log-facility=/Users/MY_USERNAME/Downloads/dnsmasq.log
log-queries

Then sudo brew services stop dnsmasq && sudo brew services start dnsmasq && brew services list
What's the output? Does it show dnsmasq running as root?
Then look in your ~/Downloads/dnsmasq.log file for any messages, particularly things pointing out problems.
(Once you've resolved your dnsmasq issues, remove those logging entries, since it'll just waste disk space.)

OSX networking

• System Preferences -> Network -> Advanced -> DNS
  For dnsmasq to be the first lookup source, the first DNS listing should be 127.0.0.1

[necrojan]

Thanks @drbyte for the those clear instructions. I did follow all the things you listed.

Adding 127.0.0.1 to System Preferences -> Network -> Advanced -> DNS solves the issue.
It was blank at first (actually grayed out) So I just add it as first lookup source.

Thanks!!

[drbyte]

Note: you might need to add back a "real" DNS resource.

You can do that either in the System Prefs DNS pane, or add the following to your dnsmasq.conf file (you don't need all of them, pick one or two to uncomment):

# fallback DNS servers for regular resolution
#Cloudflare
server=1.1.1.1
server=1.0.0.1
#openDNS
server=208.67.220.222
server=208.67.220.220
#google dns
#server=8.8.8.8
#server=4.4.4.4
#familyshield:
#server=208.67.222.123
#server=208.67.220.123

[necrojan]

Yes I did add one of those. Thanks @drbyte!

[vesper8]

looks like this issue only started after upgrading to php 7.3.2

after adding the additional fallback dns servers to my dns network prefs I was getting no internet, had to reboot before it all worked

[matt-allan]

Hello, I just wanted to add some additional info as I ran into this as well.

I was seeing very slow requests between my Laravel applications with Curl via Guzzle. For some reason file_get_contents worked correctly but curl did not. In my case the Guzzle requests were actually finishing eventually, they just took ~25 seconds.

After turning on verbose logging (CURLOPT_VERBOSE) I saw the following:

* Could not resolve: slow-valet.test (Domain name not found)
* Expire in 300000 ms for 1 (transfer 0x7ff5f4008c00)
* Closing connection 0

I verified the error occurred with both PHP 7.1 and 7.3; changing the version of PHP didn't make a difference for me.

Adding 127.0.0.1 to the DNS servers as explained above fixed my issue.

[Triztan]

Had the same issue. Fixed it simply adding 127.0.0.1 as DNS entry in my network configuration and after loading my development environment(with guzzle), removed it and it just started working fine as it was before

[ahmadabdallah]

I did the same ( dding 127.0.0.1 as DNS entry in my network configuration) but i ended up having no internet connection and and if i removed it the issue is back again

[Triztan]

@ahmadabdallah you could add manually the domain to your hosts file
it's not a fix but it will just work fine

[alexpott]

I have had this problem several time after doing an update with brew. And I've forgotten the solution that works for me several times :)

As this was one of the first things I hit with google I'm going to post why this occurs for me here.

I got the solution from here https://stackoverflow.com/questions/54688451/curl-laravel-valet-dnsmasq-not-working

Quick way to check if this is your problem is to do:
curl --version and php --ri curl

The versions should match. If they don't it's probably because brew has installed curl-openssl. This can be removed by doing:
brew uninstall curl-openssl --ignore-dependencies

Maybe there's a way to configure the installed curl-openssl properly - I've not investigated this yet.

[drbyte]

@alexpott While I'm sure viewing the version/config info could be revealing and might lead towards something that could explain why things might not be working for someone, I'm not so sure it's "critical" that the versions match.

I have the following, and I get no Curl errors in my applications.

> php --ri curl
cURL Information => 7.65.1
Host => x86_64-apple-darwin18.6.0
SSL Version => OpenSSL/1.0.2r
ZLib Version => 1.2.11
libSSH Version => libssh2/1.8.2

> curl --version
curl 7.54.0 (x86_64-apple-darwin18.0) libcurl/7.54.0 LibreSSL/2.6.5 zlib/1.2.11 nghttp2/1.24.1

My curl-openssl is installed by Homebrew:

 > brew info curl
curl: stable 7.65.1 (bottled), HEAD [keg-only]
Not installed

> brew info curl-openssl
curl-openssl: stable 7.65.1 (bottled), HEAD [keg-only]
/usr/local/Cellar/curl-openssl/7.65.1 (451 files, 3.4MB)
  Poured from bottle on 2019-06-10 at 21:30:55

[elburro1887]

Just wanted to chime in and say that

brew uninstall curl-openssl --ignore-dependencies

worked for me.

Adding 127.0.0.1 to the DNS server list screwed up my internet (some hosts wouldn't resolve properly), so I removed it again.

[kingsloi]

Thank you! I've been using .localhost for my local valet development, and haven't experienced a single issue until this passed month where I've been using Guzzle in one local app to query another local app/api (both .localhost). I could manually type/visit in both apps and both would load within milliseconds, but took 2-4 minutes with Guzzle, and occasionally would cURL error 6: could not resolve site.localhost`.

I also use a PiHole, so I put it down to something to do with the local resolution, until I found this and added 127.0.0.1 to my DNS.

My DNS entries are in the following order:

127.0.0.1
192.168.1.106 (piHole)
8.8.8.8

Guzzle/cURL are now both instantaneous!

[emtiazzahid]

At first there was 192.168.1.1 in my system preference network DNS
added 127.0.0.1 and it solved my problem. thanks @drbyte

But i could not access other networks after that.
after that i added 192.168.1.1 below 127.0.0.1 .

Now my guzzle http and browser network both working .

[Goahnary]

So I have tried everything in this issue thread.
The only thing that has worked for me is putting 127.0.0.1 in my DNS entries AT THE TOP

I figured out this mattered after running dig dev-site.test and I got

SERVER: 8.8.8.8#53(8.8.8.8)

Then I moved the localhost(127.0.0.1) address to the top of my DNS entries and that resolved everything for me.

dig dev-site.test now results in:

SERVER: 127.0.0.1#53(127.0.0.1)

Make sure you have this at the top!!! The order matters! At least it did for me...

[drbyte]

Yes, putting 127.0.0.1 at the top of the list makes dnsmasq do the resolving locally first, and then goes external as a fallback. The "lag" is nanoseconds, especially with logging disabled (by default), so doesn't impact normal surfing, but allows for the local resolution to occur first.

[approached]

My solution:

sudo vi /etc/hosts

...
add to the buttom:

127.0.0.1 example.test

[keganlester]

Just wanted to chime in and say that

brew uninstall curl-openssl --ignore-dependencies

worked for me.

Adding 127.0.0.1 to the DNS server list screwed up my internet (some hosts wouldn't resolve properly), so I removed it again.

You have to keep your same DNS servers as before, just adding 127.0.0.1 removed other defaults. You need to manually add them back but keep 127.0.0.1 at the top.

[drbyte]

You have to keep your same DNS servers as before, just adding 127.0.0.1 removed other defaults. You need to manually add them back but keep 127.0.0.1 at the top.

Yes and no. An even better way is to tell Dnsmasq what you preferred DNS servers are. This is easily done by creating a new config file. Example: to use Cloudflare's 1.1.1.1 create:

~/.config/valet/dnsmasq.d/dns-cloudflare1111.conf contains:

# fallback servers to use if we can't resolve using our own rules
# these are Cloudflare's public dns
server=1.1.1.1
server=1.0.0.1

Add/remove *.conf files in the ~/.config/valet/dnsmasq.d/ directory to control your Dnsmasq configuration.

**This works since Valet 2.6.0

[keganlester]

You have to keep your same DNS servers as before, just adding 127.0.0.1 removed other defaults. You need to manually add them back but keep 127.0.0.1 at the top.

Yes and no. An even better way is to tell Dnsmasq what you preferred DNS servers are. This is easily done by creating a new config file. Example: to use Cloudflare's 1.1.1.1 create:

~/.config/valet/dnsmasq.d/dns-cloudflare1111.conf contains:

# fallback servers to use if we can't resolve using our own rules
# these are Cloudflare's public dns
server=1.1.1.1
server=1.0.0.1

Add/remove *.conf files in the ~/.config/valet/dnsmasq.d/ directory to control your Dnsmasq configuration.

**This works since Valet 2.6.0

Was just trying to make it simple for people changing their DNS then their internet not working. This is great to know though!

[crumb1e]

I have had this problem several time after doing an update with brew. And I've forgotten the solution that works for me several times :)

As this was one of the first things I hit with google I'm going to post why this occurs for me here.

I got the solution from here https://stackoverflow.com/questions/54688451/curl-laravel-valet-dnsmasq-not-working

Quick way to check if this is your problem is to do:
curl --version and php --ri curl

The versions should match. If they don't it's probably because brew has installed curl-openssl. This can be removed by doing:
brew uninstall curl-openssl --ignore-dependencies

Maybe there's a way to configure the installed curl-openssl properly - I've not investigated this yet.

This worked for me! Thank you v much

[r-martins]

In addition to DrByte's reply above, make sure 127.0.0.1 is the first entry in your dns list.

[shiroamada]

1. It's interesting that it's only curl that's giving trouble, and only with Guzzle. I'm not convinced this is a Valet issue.
   You could maybe enable Guzzle's debug mode, to get more information back:
   http://docs.guzzlephp.org/en/latest/request-options.html#debug

You could also install an alternate Client to override the default of using CURL: http://docs.guzzlephp.org/en/latest/faq.html#does-guzzle-require-curl

1. I wouldn't have expected a simple yarn update to do anything that's interfering, unless it's gone and installed some package that set some new ENV vars that CURL uses, or something that provides DNS services and now is clashing with dnsmasq or osx core. And if it does then that raises other concerns, beyond the scope of Valet.
   But, one way to rule it out is to delete everything yarn installed, and then remove the node_modules dir, and reboot. And if it's from "global" tools that yarn installed, clean those up too. Maybe not "ideal", but useful as a troubleshooting step nonetheless.
2. Given that you said other services are able to reach site.test it means dnsmasq "is" running, so the following troubleshooting for dnsmasq is probably pointless, but I'll leave it here for reference anyway.

DNSMASQ troubleshooting

Top 3 troubleshooting steps I've taken with dnsmasq issues:

• use dig to find out what's happening with lookups
• enable dnsmasq logging to get it to report any startup problems
• inspect OSX config

dig

dig site.test
This should come back with something like the following. Note the "A" record pointing to 127.0.0.1, and the SERVER: 127.0.0.1 in the following, and what's different in yours.

; <<>> DiG 9.10.6 <<>> site.test
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58405
;; flags: qr aa rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;site.test.			IN	A

;; ANSWER SECTION:
site.test.		0	IN	A	127.0.0.1

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Mar 01 10:26:39 EST 2019
;; MSG SIZE  rcvd: 54

logging

Enabling logging in dnsmasq:
One place to do this is in ~/.config/valet/dnsmasq.conf
It should already have 2 lines in it for your configured TLD.
Add the following lines, adjusting for your actual username:

# Logging
log-facility=/Users/MY_USERNAME/Downloads/dnsmasq.log
log-queries

Then sudo brew services stop dnsmasq && sudo brew services start dnsmasq && brew services list
What's the output? Does it show dnsmasq running as root?
Then look in your ~/Downloads/dnsmasq.log file for any messages, particularly things pointing out problems.
(Once you've resolved your dnsmasq issues, remove those logging entries, since it'll just waste disk space.)

OSX networking

• System Preferences -> Network -> Advanced -> DNS
  For dnsmasq to be the first lookup source, the first DNS listing should be 127.0.0.1

I think these should be added to valet documentation. It really help a lot. Thanks guys!

[jfgancia]

• 127.0.0.1

Excelent!

[digitaltim-de]

Thanks @drbyte for the those clear instructions. I did follow all the things you listed.

Adding 127.0.0.1 to System Preferences -> Network -> Advanced -> DNS solves the issue.
It was blank at first (actually grayed out) So I just add it as first lookup source.

Thanks!!

Helps me too