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

[Hongyi Zhao]

On Mon, Sep 14, 2020 at 9:02 AM Neal P. Murphy
<neal.p.murphy at alum.wpi.edu> wrote:
>
> 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.

I really like to use the systemd-resolvd relevant command for check
the DNS status, say, the following:

$ systemd-resolve --status
$ resolvectl status

If I disabled the systemd-resolvd service, then the above commands
should be unavailable.

> Or configure your resolvers so that the systemd stub is not referenced.

Do you mean operations similar to the following:

$ sudo rm /etc/resolv.conf
$ echo nameserver 127.0.0.1 | sudo tee /etc/resolv.conf

But I also set the DNS sever as 127.0.0.1 with the following netplan
config file:

$ cat /etc/netplan/99-networkd-local-dns.yaml
network:
 version: 2
 renderer: networkd
 ethernets:
   enp:
     match:
       name: enp*
     dhcp4: true
     dhcp4-overrides:
       use-dns: false
     nameservers:
      addresses:
       - 127.0.0.1
   docker:
     match:
       name: docker*
     dhcp4: true
     dhcp4-overrides:
       use-dns: false
     nameservers:
      addresses:
       - 127.0.0.1


So, I still can't figure out the differences between the DNS set by
netplan and /etc/resolv.conf. Any more hints on this question?


>
> 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*.

But, as we all know, dnsmasq has the *all-servers* option.

>
> 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.
>
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss



-- 
Hongyi Zhao <hongyi.zhao at gmail.com>