I have a dnsmasq server running on my router, which handles both dhcp and dns (caching, forwarding). I configured my local domain: domain=example.com.

I can resolve local dhcp hostnames:

dig +short dhcp1.example.com

Now I have a public dns entry on public.example.com which doesn't get resolved by dnsmasq because it was not served by dhcp and is not in /etc/hosts

dig +short public.example.com

Now my question: Is it possible to tell dnsmasq to ask an upstream dns server for any host that was not served by dhcp?

As a workaround I could add public.example.com to the /etc/hosts file. But then I would have to do it manually for every public dns entry on that domain.

I read through the manpage and noticed the following portion under --domain:

If the domain is given as "#" then the domain is read from the first "search" directive in /etc/resolv.conf (or equivalent).

So I tried to add server=/example.com/# to the config, but it didn't have the desired effect.

Thank you for your answers :-)

1 Answer 1


DNS servers don't allow for partitioning entries in the same domain zone between multiple servers. If the server is authoritative for a zone, it can't pass the request on. You can add other servers to handle a zone (for example, if they are master and slave servers, or AD-replicated), but it's assumed that all servers have the same answers; if they don't, you will sometimes get an answer and sometimes not!

There are two possible methods that I can see for you to fix this issue:

  1. Make the internal/external split explicit. Have your internal domain (which is handled by dnsmasq) be called something like internal.example.com; external addresses continue to be resolved by the public DNS server. This has the advantage that you don't have to worry about name conflict.

  2. As you indicated, add the public DNS entries as static records into dnsmasq. In addition to the initial work, you'll have to change the records if your public addresses change because they won't track.

Of the two methods, I would probably choose the first one because it makes administration easier, but either method should work.

  • I think this isn't right. I got here looking for an option 3: recurse all lookups not from dnsmasq's own DHCP to the authoritative server and let it handle everything else.
    – Joshua
    Apr 3 at 15:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .