Never Touch /Etc/Hosts Again for All Your Development Work
When I develop locally on my MacBook, I use Vagrant a lot. In there I run an Ubuntu based VM with my preferred configuration with PHP-FPM and Nginx, all managed by Puppet.
Included within that box is dnsmasq which handles DNS queries from within the box and it’s configured to resolve to the VM’s IP own IP address for all
*.prod queries - and regularly lookup everything else.
While this worked out like a charm from within the box, I still had to enter each and every new project in my
/etc/hosts file to resolve to my Vagrant box. Of course, this works - but it’s annoying, especially if the Nginx configuration is built like “create a new directory and it’s available under that name as a vHost right away”…
The OS X resolver system can use multiple resolvers. In the default setup it uses just one single DNS server to query and resolve the name to an IP address. But one can override the DNS resolver for particular domains. See Alain Ivey’s detailed blog post on this issue.
Basically this is the minimum needed to be executed on your Mac:
sudo mkdir -v /etc/resolver sudo bash -c 'echo "nameserver 192.168.42.42" > /etc/resolver/dev'
This adds a specific resolver entry for all
*.dev names, and tells the system to query those domain names at the IP
192.168.42.42 (in my case the IP address of the Vagrant box).
Repeat the second command if you have multiple domains that you want to query locally only (and make sure you don’t use a generally and used top-level domain like *.net or *.com unless you like troubles).
In case you’ve not queried a certain domain yet, this resolver entry seems to work immediately - if you queried already and added the resolver entry later on, a reboot might be needed.
Why this way?
I know many others that have dnsmasq installed right on their OS X. When I got my new gear, I decided to keep my main OS free of such tools and run all development stuff from within Vagrant box. Of course, this setup means that I can’t query any *.dev domain as long as the virtual box is not up and running - but actual development is not possible in that situation anyway…