wildcard DNS record on OS X in localhost development with dnsmasq

dnsmasq_setup_osx.md

wildcard DNS in localhost development

• install dnsmasq

$ brew install dnsmasq
   ...
$ cp /usr/local/opt/dnsmasq/dnsmasq.conf.example /usr/local/etc/dnsmasq.conf

• edit /usr/local/etc/dnsmasq.conf

address=/local/127.0.0.1

• start dnsmasq

$ sudo brew services start dnsmasq

• any time we change dnsmasq.conf we have to re-start dnsmasq:

$ sudo launchctl stop homebrew.mxcl.dnsmasq
$ sudo launchctl start homebrew.mxcl.dnsmasq

• For OS X to resolve requests from *.local to localhost we need to add a resolver:

$ sudo mkdir /etc/resolver
$ sudo touch /etc/resolver/local

• edit /etc/resolver/local

nameserver 127.0.0.1

• re-start the computer to enable the resolver

=== REFERENCES

• Using Dnsmasq for local development on OS X - Passing Curiosity
• Using Dnsmasq Configure Wildcard DNS Record on Mac | Ri Xu Online
• unix - In my /etc/hosts/ file on Linux/OSX, how do I do a wildcard subdomain? - Server Fault
• hostname - Wildcard in /etc/hosts file - Unix & Linux Stack Exchange
• Mac OS Lion - Wildcard subdomain virtual host - Stack Overflow
• How to put wildcard entry into /etc/hosts? - Stack Overflow

$ cp /usr/local/opt/dnsmasq/dnsmasq.conf.example /usr/local/etc/dnsmasq.conf

is not needed anymore

@hauleth the point of even using avahi/bonjour in the first place is so your team mates on the same network can also access this. localhost implies that you wish to not work in a team.

@airtonix yes, what I meant is that you should use .localhost which is reserved for unspecified use for now instead of .local TLD which is reserved for specific use, so you should use:

address=/localhost/127.0.0.1

and

sudo touch /etc/resolver/localhost

Instead for locally hosted wildcard domains to avoid problems like one pointed by @dewey4iv.

This is an old thread but since it has a recent reply, here a my 2 cents:

For *.localhost you do not need dnsmasq!

Should you want a shorter url, use *.test, since that is a reserved tld: https://tools.ietf.org/id/draft-chapin-rfc2606bis-00.html#rfc.section.2

@TheM1984 last time I have checked it didn't worked on my macOS Mojave, maybe in Catalina they changed it. For sure you do not need additional resolver on systemd enabled Linux, but Let's localhost be localhost RFC wasn't accepted and it is still not standardised solution.

@hauleth I recently downgraded to Mojave 10.14.6 (18G103) so I can tell you that it works.

The .localhost is already accepted in the old https://tools.ietf.org/html/rfc2606.
That said the .test is off course a lot shorter.

It was reserved there as:

The ".localhost" TLD has traditionally been statically defined in host DNS implementations as having an A record pointing to the loop back IP address and is reserved for such use. Any other use would conflict with widely deployed code which assumes this use.

But it do not requires it to be defined as such. I am on Mojave 10.14.6 (18G1012) and this is not available:

$ ping foo.localhost
ping: cannot resolve foo.localhost: Unknown host

If I setup the dnsmasq though it will work.

$ cat /etc/resolver/localhost
nameserver 127.0.0.1
$ ping -c1 foo.localhost
PING foo.localhost (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.021 ms
--- foo.localhost ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.021/0.021/0.021/0.000 ms

As @TheM1984 stated, *.localhost does work, but only in browsers like Chrome and Firefox. This is because the browser itself makes the domain resolution to 127.0.0.1.
Outside of browsers it might not work without a DNS server.

By the way, *.test TLD is the best choice for local apps and services, as this TLD is specifically reserved for such cases, as stated here.

@slavikme by what metric it would be the "best"? Because .localhost is also reserved for exactly that purpose (it is literally in the same article you have posted).

@hauleth
Using *.localhost or *.test is nearly the same, with few small differences:

1. test is a bit shorter - so it's somewhat a plus.
2. When using localhost as TLD, and accessing it from other machine on the same network, it causes some conflicts with other local machines.