Chaining dnsmasq instances together

---

Laravel’s valet allows you to set up PHP-based sites so that they have their own domain name ending in.test so that you can easily deploy multiple projects in your local development environment. To do this, it uses dnsmasq listening on 127.0.0.1 (lo). Other development tools like libvirt use dnsmasq in a similar way, but coordinating all the instances of dnsmasq is tricky and can result in infinite loop lookups.

Assuming you have libvirt set up to deploy hosts on a virtual bridge (usually virbr0), libvirt will deploy dnsmasq on to listen on the ip address that is the default route for that network. dnsmasq responds to DHCP requests, so it knows the IPs of all the hosts on that network and acts as the resolver for all the hosts there.

In my case, virbr0 is where the 10.5.5.0/24 subnet lives and the default route for hosts on that subnet is 10.5.5.1. Since I can communicate with 10.5.5.1 and I know that the virtual machine I just spun up is on 10.5.5.185, I’ll ask that dnsmasq to perform a reverse lookup to get the top-level-domain for the network:

From here, we can see that it is assigning .network as the TLD for the subnet.

Now, recall that I have valet configured with a separately managed dnsmasq listening on lo. I want to want to point it to the dnsmasq that manages virbr0 and pass reverse lookups for the 10.5.5.0/24 subnet and any name resolution for the .network tld to that instance of dnsmasq.

Adding the following two lines to the dnsmasq configuration does this:

After reloading the dnsmasq configuration, I can ssh to the virtual hosts by name and use their names in my browser.