[Dnsmasq-discuss] Avoid conflicts between dnsmasq and systemd-resolved.

[Neal P. Murphy]

On Mon, 14 Sep 2020 06:52:49 +0800
Hongyi Zhao <hongyi.zhao at gmail.com> wrote:

> On Mon, Sep 14, 2020 at 4:26 AM Geert Stappers <stappers at stappers.nl> wrote:
> >
> > On Sun, Sep 13, 2020 at 03:36:42PM +0800, Hongyi Zhao wrote:  
> > > So I want to know how to solve the confliction problem between dnsmasq
> > > and systemd-resolved.  
> >
> > The trick is deciding which DNS is "upstream"  
> 
> Still, I'm no so clear on the solution. How to solve it? Any more
> hints/instructions?
> 
> Regards,
> HY

You should be able to disable that systemd stub resolver service so that it is not started. Or configure your resolvers so that the systemd stub is not referenced.

A longer answer is that each DNS resolver should have *one* upstream resolver (if there is one). To say it differently, DNS resolution is a *chain* of resolvers, not a *tree*.

Internally, the PC should first check if it can resolve the query. If it can't, it should ask its sole upstream resolver to try, if it has one. That upstream resolver should try, and if it can't, should ask *its* upstream resolver, if it has one. In time, the query will reach a resolver that has the answer cached, reach the authoritative resolver, or will reach a resolver at the end of the chain that will respond in the negative.

An organization might have a number of internal zones such that it might look like an upside-down tree (branches only toward the bottom), but each host should have a single chain of resolvers from itself to the authoritative resolver or to the root resolver.

Configuring one's internal resolvers as a chain will almost always prevent tufts of hair from laying on the floor.