Pinging test.dev after Laravel Valet install returns "Unknown Host"

Question

Update: Don't use ".dev". When this was originally posted in 2016, it was fine. Now it's not. Start by changing your TLD to somethinge else like ".localhost" or whatever. (This change would not have fixed my issue, but it might fix yours if you're still using ".dev").

Problem: I've installed Laravel Valet and it all seems to be working except when I ping test.dev (which just contains an index.htm file and is located in ~/Sites), after hanging for a long time I get the response ping: cannot resolve test.dev: Unknown host

Here's what I've already done:

• I've gone through the Laravel Valet docs and everything installed fine.
• Apache is not running
• /etc/hosts contains no mention of test.dev
• I'm on valet v1.1.12
• I've restarted my computer
• I've installed php 7.0.7 via homebrew fresh and --with-fpm
• My $PATH contains $PATH:$HOME/.composer/vendor/bin
• sudo lsof -n -i:80 | grep LISTEN returns the caddy proc
• brew services list returns dnsmasq and is started
• I've updated brew, run brew doctor and all is good there
• I can start and stop valet successfully.
• valet paths returns successfully: [ "/Users/nateritter/.valet/Sites", "/Users/nateritter/Sites" ]
• Using valet link inside the test directory has no effect on this issue

Now, in addition to all this, I decided to try all the valet arguments out. valet share seemed to bork with an error at one point, which is interesting but I'm not sure it has anything to do with the original issue.

ERROR: Tunnel 'command_line' specifies invalid address 'test.dev:80': unexpected '[' in address test.dev:80

After this I get 21 lines of Failed to connect to 127.0.0.1 port 4040: Connection refused and then an exception:

[Httpful\Exception\ConnectionErrorException]                                                                              
Unable to connect to "http://127.0.0.1:4040/api/tunnels": 7 Failed to connect to 127.0.0.1 port 4040: Connection refused                                                                                                                              

fetch-share-url

Plea

Open console on OSX and search for dnsmasq. There may be errors like failed to create listening socket for {IP}: Permission denied, failed to start up. – Asseverate

Answer 1

The problem ended up being something to do with dnsmasq. Using the very thorough this answer to another related SO post, I ended up doing the following to solve my issue:

brew unlink dnsmasq

brew install dnsmasq

brew prune

brew services restart dnsmasq

valet install

Then, just to test before I did a ping, I did dig test.dev and the response included:

;; ANSWER SECTION:
test.dev.       3599    IN  A   127.0.53.53

I'm not sure why the IP is 127.0.53.53 and not 127.0.0.1 but when I did a ping test.dev it did return ...

PING test.dev (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.036 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.072 ms

Browsing to test.dev worked as well.

One thing to note that I haven't looked into yet is that index.htm is not recognized by valet/caddy as a potential index file. Not part of the issue, but something interesting to note.

Plea

Internal domains resolving to 127.0.53.53 means you have a name collision and ICANN is trying to tell you that you urgently need to fix your DNS configuration. You can use dig -t TXT test.dev +short for information but it'll likely say needs attention and you should see icann.org/namecollision – Rycca

Thanks Ben. Would using Google's DNS on my router or OS X network prefs create this issue? I would guess it's not the cause but perhaps where the namespace is leaking out to, but I'm not sure where to look to find out how it's leaking out to the public space in the first place. Any hints on that? – Plea

Come to find out it's leaking because it should. iyware.com/dont-use-dev-for-development and iana.org/domains/root/db/dev.html indicate that ".dev" is a delegated TLD (which Google owns). The response of 127.0.53.53 makes a bit more sense since I use Google for DNS instead of my ISP. The warning is not to use .dev TLDs for dev environments. Instead, use a suggested TLD like .localhost (which is what I've changed valet to use by way of valet domain localhost. Voila. – Plea

This worked but worth also mentioning that in my case i also had to brew link dnsmasq and this gave an error brew prune – Golding

Answer 2

I had the same problem, some brew services were stopped, running this command fixed it:

sudo brew services start --all

Impose

I have been pulling my hair out (not really, I am bald) for a week trying everything! Thank you! – Linkous

Answer 3

I had everything set up correctly, but had the same issue - could not get the app.dev running.

After running

brew services list

I noticed that all services except dnsmasq were running as "root", but dnsmasq was running on my user.

Stopped dnsmasq with

brew services stop dnsmasq

and started it with:

sudo brew services start dnsmasq

This worked for me, after a few hours of frustration.

Crassulaceous

Answer 4

Nothing mentioned above helped me on macos sierra, but one little remark did:

since I use Google for DNS instead of my ISP. The warning is not to use .dev TLDs for dev environments. Instead, use a suggested TLD like .localhost (which is what I've changed valet to use by way of valet domain localhost. Voila. – Nate Ritter

Avoiding '.dev' and using '.devel' did the trick for me, probably needed if you are on google's 8.8.8.8 dns

Cowles

Answer 5

*.dev does not work anymore since it is a real TLD. So use something else like *.test or *.local.

ping dev.test
PING dev.test (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.051 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.149 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.137 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.133 ms
64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.138 ms
64 bytes from 127.0.0.1: icmp_seq=5 ttl=64 time=0.166 ms
64 bytes from 127.0.0.1: icmp_seq=6 ttl=64 time=0.142 ms

Also don't forget to add http:// or https:// to your domain like http://blog.test for the first time when you open in the browser. Otherwise it will go to your default search engine.

Muskrat

That's correct, but back in '16 when the OP was posted, it did. Good point though. – Plea

Thank you @Krishnadas. Now, in 2018, your answer takes priority. None of the other answers helped me, and I was needlessly worried, until I saw your response. – Orange

Answer 6

If you're just getting started with Laravel and following the Laracast tutorials, make sure to also read the latest documentation.

In Laravel 5.6 and Valet 2.0.12 the *.dev domains were replaced by *.test, as you can see in here: https://laravel.com/docs/5.6/valet#installation

Rimma

just coming from a (old) laracast video where jway was using *.dev, you saved my day, thanks – Carrot

Answer 7

For me somehow a syntax error sneaked into the dnsmasq.conf which would prevent it from starting up correctly.

To check this I did dnsmasq --test which gave the following output dnsmasq: bad option at line 1 of /usr/local/etc/dnsmasq.conf

I fixed the typo on line 1 and did restarted all services with brew services restart --all

After that, I can ping again to .dev domains and it works in my browser

ping test.dev
PING test.dev (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.062 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.035 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.056 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.053 ms
--- test.dev ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.035/0.051/0.062/0.010 ms

Hope this will help some one!

Voluntarism

In my case, dnsmasq --test returned dnsmasq: failed to create listening socket for 127.0.0.1: Permission denied which is a big red flag to work on! – Yuzik