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

[Hongyi Zhao]

On Fri, Sep 18, 2020 at 2:59 PM Geert Stappers  wrote:
>
> On Fri, Sep 18, 2020 at 08:08:07AM +0800, Hongyi Zhao wrote:
> > On Thu, Sep 17, 2020 at 07:25:43AM +0800, Hongyi Zhao wrote:
> > >
> > > But I still can't figure out what's the wrong configuration or
> > > **bug** (may or may not exist, I'm not sure.) in dnsmasq itself
> > > triggered this problem.
> >
> > I can confirm this problem is caused by the response to type=ANY
> > request of dnsmasq. And when I substitute the corresponding job done
> > by dnsmasq with dnsproxy, the problem will be solved.
>
> I fail to see the dnsmasq problem.

I mean, if I use the let dnsmasq listening on 127.0.0.1:6054 as
following, the problem will appear:

$ /usr/local/sbin/dnsmasq --port=6054
--servers-file=/home/werner/Public/anti-gfw/dns/dnsmasq/conf/servers-file/cn
-C /home/werner/Public/anti-gfw/dns/dnsmasq/conf/cn-dns.conf

While if I use dnsproxy to do the same job as following, the problem
will disappear:

$ dnsproxy -u 114.114.114.114 -u 114.114.115.115 -u
114.114.114.119 -u 114.114.115.119 -u 114.114.114.110 -u
 114.114.115.110 -u 223.5.5.5 -u 223.6.6.6 -u 180.76.76.76 -u
 112.124.47.27 -u 114.215.126.16 --fastest-addr --all-servers -l
 127.0.0.1 -p 6054

So, I draw that conclusion.

Regards,
HY

>
>
> > See following for more information:
>
> I did
>
>
> >
> > werner@X10DAi-01:~$ pgrep -ax dnsproxy
> > 50211 ./dnsproxy -l 127.0.0.1 -p 6053 --all-servers --fastest-addr -u
>
> port 6053
>
>
> > tls://8.8.4.4 -u tls://8.8.8.8 -u tls://1.0.0.1 -u tls://1.1.1.1 -u
> > tls://9.9.9.9 -u tls://9.9.9.10 -u tls://149.112.112.10
> > 50212 ./dnsproxy -u 114.114.114.114 -u 114.114.115.115 -u
> > 114.114.114.119 -u 114.114.115.119 -u 114.114.114.110 -u
> > 114.114.115.110 -u 223.5.5.5 -u 223.6.6.6 -u 180.76.76.76 -u
> > 112.124.47.27 -u 114.215.126.16 --fastest-addr --all-servers -l
> > 127.0.0.1 -p 6054
> > werner@X10DAi-01:~$ pgrep -ax dnsmasq
> > 50243 /usr/local/sbin/dnsmasq --port=53 -c10240 --localise-queries
>
> port 53
>
>
> > --server=127.0.0.1#6053
>
> port 6053
>
>
> > --conf-dir=/home/werner/Public/anti-gfw/dns/dnsmasq/conf/conf-dir,*.conf
> > -C /home/werner/Public/anti-gfw/dns/dnsmasq/conf/dnsmasq.conf
> > werner@X10DAi-01:~$ dig www.baidu.com ANY @127.0.0.1
>
> Probably port 53
>
>
> > ; <<>> DiG 9.16.1-Ubuntu <<>> www.baidu.com ANY @127.0.0.1
> > ;; global options: +cmd
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51448
> > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> >
> > ;; OPT PSEUDOSECTION:
> > ; EDNS: version: 0, flags:; udp: 4096
> > ;; QUESTION SECTION:
> > ;www.baidu.com.INANY
> >
> > ;; ANSWER SECTION:
> > www.baidu.com.1133INCNAMEwww.a.shifen.com.
> >
> > ;; Query time: 36 msec
> > ;; SERVER: 127.0.0.1#53(127.0.0.1)
>
> Yes indeed port 53
>
>
> > ;; WHEN: Fri Sep 18 08:03:37 CST 2020
> > ;; MSG SIZE  rcvd: 69
> >
> > Regards,
> > HY
>
>
> Regards
> Geert Stappers
> --
> Silence is hard to parse
>
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss



-- 
Hongyi Zhao 

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

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

[Geert Stappers]

On Fri, Sep 18, 2020 at 08:08:07AM +0800, Hongyi Zhao wrote:
> On Thu, Sep 17, 2020 at 07:25:43AM +0800, Hongyi Zhao wrote:
> >
> > But I still can't figure out what's the wrong configuration or
> > **bug** (may or may not exist, I'm not sure.) in dnsmasq itself
> > triggered this problem.
> 
> I can confirm this problem is caused by the response to type=ANY
> request of dnsmasq. And when I substitute the corresponding job done
> by dnsmasq with dnsproxy, the problem will be solved.

I fail to see the dnsmasq problem.


> See following for more information:

I did


> 
> werner@X10DAi-01:~$ pgrep -ax dnsproxy
> 50211 ./dnsproxy -l 127.0.0.1 -p 6053 --all-servers --fastest-addr -u

port 6053


> tls://8.8.4.4 -u tls://8.8.8.8 -u tls://1.0.0.1 -u tls://1.1.1.1 -u
> tls://9.9.9.9 -u tls://9.9.9.10 -u tls://149.112.112.10
> 50212 ./dnsproxy -u 114.114.114.114 -u 114.114.115.115 -u
> 114.114.114.119 -u 114.114.115.119 -u 114.114.114.110 -u
> 114.114.115.110 -u 223.5.5.5 -u 223.6.6.6 -u 180.76.76.76 -u
> 112.124.47.27 -u 114.215.126.16 --fastest-addr --all-servers -l
> 127.0.0.1 -p 6054
> werner@X10DAi-01:~$ pgrep -ax dnsmasq
> 50243 /usr/local/sbin/dnsmasq --port=53 -c10240 --localise-queries

port 53


> --server=127.0.0.1#6053

port 6053


> --conf-dir=/home/werner/Public/anti-gfw/dns/dnsmasq/conf/conf-dir,*.conf
> -C /home/werner/Public/anti-gfw/dns/dnsmasq/conf/dnsmasq.conf
> werner@X10DAi-01:~$ dig www.baidu.com ANY @127.0.0.1

Probably port 53

 
> ; <<>> DiG 9.16.1-Ubuntu <<>> www.baidu.com ANY @127.0.0.1
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51448
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;www.baidu.com.INANY
> 
> ;; ANSWER SECTION:
> www.baidu.com.1133INCNAMEwww.a.shifen.com.
> 
> ;; Query time: 36 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)

Yes indeed port 53


> ;; WHEN: Fri Sep 18 08:03:37 CST 2020
> ;; MSG SIZE  rcvd: 69
> 
> Regards,
> HY


Regards
Geert Stappers
-- 
Silence is hard to parse

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

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

[Hongyi Zhao]

On Thu, Sep 17, 2020 at 2:04 PM Geert Stappers  wrote:
>
> On Thu, Sep 17, 2020 at 07:25:43AM +0800, Hongyi Zhao wrote:
> >
> > But I still can't figure out what's the wrong configuration or
> > **bug** (may or may not exist, I'm not sure.) in dnsmasq itself
> > triggered this problem.

I can confirm this problem is caused by the response to type=ANY
request of dnsmasq. And when I substitute the corresponding job done
by dnsmasq with dnsproxy, the problem will be solved. See following
for more information:

werner@X10DAi-01:~$ pgrep -ax dnsproxy
50211 ./dnsproxy -l 127.0.0.1 -p 6053 --all-servers --fastest-addr -u
tls://8.8.4.4 -u tls://8.8.8.8 -u tls://1.0.0.1 -u tls://1.1.1.1 -u
tls://9.9.9.9 -u tls://9.9.9.10 -u tls://149.112.112.10
50212 ./dnsproxy -u 114.114.114.114 -u 114.114.115.115 -u
114.114.114.119 -u 114.114.115.119 -u 114.114.114.110 -u
114.114.115.110 -u 223.5.5.5 -u 223.6.6.6 -u 180.76.76.76 -u
112.124.47.27 -u 114.215.126.16 --fastest-addr --all-servers -l
127.0.0.1 -p 6054
werner@X10DAi-01:~$ pgrep -ax dnsmasq
50243 /usr/local/sbin/dnsmasq --port=53 -c10240 --localise-queries
--server=127.0.0.1#6053
--conf-dir=/home/werner/Public/anti-gfw/dns/dnsmasq/conf/conf-dir,*.conf
-C /home/werner/Public/anti-gfw/dns/dnsmasq/conf/dnsmasq.conf
werner@X10DAi-01:~$ dig www.baidu.com ANY @127.0.0.1

; <<>> DiG 9.16.1-Ubuntu <<>> www.baidu.com ANY @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51448
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.baidu.com.INANY

;; ANSWER SECTION:
www.baidu.com.1133INCNAMEwww.a.shifen.com.

;; Query time: 36 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Sep 18 08:03:37 CST 2020
;; MSG SIZE  rcvd: 69

Regards,
HY


>
>
> Acknowledge
>
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss



-- 
Hongyi Zhao 

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] Avoid conflicts between dnsmasq and systemd-resolved. DNS list

[Geert Stappers]

On Wed, Sep 16, 2020 at 04:16:40PM +0800, Hongyi Zhao wrote:
> On Wed, Sep 16, 2020 at 3:06 PM Dominick C. Pastore wrote:
> > On Wed, Sep 16, 2020, at 1:36 AM, Geert Stappers wrote:
> > > > > I was a little surprised this one worked since the previous one
> > > > > didn't, but I suspect systemd-resolved is falling back to the
> > > > > FallbackDNS servers (which are hardcoded in if not set explicitly).
> > >
> > > > What's the FallbackDNS servers and how can I find/list them?
> > >
> > > Good question.  The "hardcoded" suggest it is in source code.
> >
> > Yes, that is indeed the case. I'm not aware of what those
> > defaults are, but they can be overridden or unset. See
> > the description of the "FallbackDNS" option here:
> >  http://manpages.ubuntu.com/manpages/bionic/man5/resolved.conf.5.html
> 
> I found some public DNS servers in the source code here:
> 
> https://github.com/systemd/systemd/blob/e66d2b4332ca94aeb62e95ec76f1f17ee9b7/meson_options.txt#L252

At https://github.com/systemd/systemd/blob/master/meson_options.txt#L252

  option('dns-servers', type : 'string',
   description : 'space-separated list of default DNS servers',
   value : '1.1.1.1 8.8.8.8 1.0.0.1 8.8.4.4 2606:4700:4700:: 
2001:4860:4860:: 2606:4700:4700::1001 2001:4860:4860::8844')
 

> But I'm not sure whether they are the default/FallbackDNS for systemd-resolvd.
> 
> >
> > (Anyway, I'm not meaning to pull the discussion too far from Dnsmasq.)

I did enjoy the by-catch


Groeten
Geert Stappers
-- 
Silence is hard to parse

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

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

[Geert Stappers]

On Thu, Sep 17, 2020 at 07:25:43AM +0800, Hongyi Zhao wrote:
> 
> But I still can't figure out what's the wrong configuration or
> **bug** (may or may not exist, I'm not sure.) in dnsmasq itself
> triggered this problem.


Acknowledge

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

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

[Hongyi Zhao]

On Thu, Sep 17, 2020 at 7:02 AM Hongyi Zhao  wrote:

>
> Further testing again:
>
> Even I don't use the dnsasmq resolver in systemd, the problem still
> will appear. See following for more info:
>
> $ resolvectl status | grep 'DNS Server'
>   Current DNS Server: 114.114.114.114
>  DNS Servers: 114.114.114.114
>  DNS Servers: 114.114.114.114
>   Current DNS Server: 114.114.114.114
>  DNS Servers: 114.114.114.114
>  DNS Servers: 114.114.114.114
>
>
> werner@X10DAi-01:~$ pgrep -ax dnsmasq
> 26163 /usr/local/sbin/dnsmasq --port=6054
> --servers-file=/home/werner/Public/anti-gfw/dns/dnsmasq/conf/servers-file/cn
> -C /home/werner/Public/anti-gfw/dns/dnsmasq/conf/cn-dns.conf
> 26174 /usr/local/sbin/dnsmasq --port=53 -c10240
> --server=127.0.0.1#6053
> --conf-dir=/home/werner/Public/anti-gfw/dns/dnsmasq/conf/conf-dir,*.conf
> --hostsdir=/home/werner/Public/anti-gfw/dns/dnsmasq/conf/hostsdir -C
> /home/werner/Public/anti-gfw/dns/dnsmasq/conf/dnsmasq.conf
> werner@X10DAi-01:~$ dig www.baidu.com ANY @127.0.0.1
> ^C
> werner@X10DAi-01:~$ pgrep -ax dnsmasq
> 26163 /usr/local/sbin/dnsmasq --port=6054
> --servers-file=/home/werner/Public/anti-gfw/dns/dnsmasq/conf/servers-file/cn
> -C /home/werner/Public/anti-gfw/dns/dnsmasq/conf/cn-dns.conf
> 26174 /usr/local/sbin/dnsmasq --port=53 -c10240
> --server=127.0.0.1#6053
> --conf-dir=/home/werner/Public/anti-gfw/dns/dnsmasq/conf/conf-dir,*.conf
> --hostsdir=/home/werner/Public/anti-gfw/dns/dnsmasq/conf/hostsdir -C
> /home/werner/Public/anti-gfw/dns/dnsmasq/conf/dnsmasq.conf
> 40020 /usr/local/sbin/dnsmasq --port=53 -c10240
> --server=127.0.0.1#6053
> --conf-dir=/home/werner/Public/anti-gfw/dns/dnsmasq/conf/conf-dir,*.conf
> --hostsdir=/home/werner/Public/anti-gfw/dns/dnsmasq/conf/hostsdir -C
> /home/werner/Public/anti-gfw/dns/dnsmasq/conf/dnsmasq.conf
> 40021 /usr/local/sbin/dnsmasq --port=6054
> --servers-file=/home/werner/Public/anti-gfw/dns/dnsmasq/conf/servers-file/cn
> -C /home/werner/Public/anti-gfw/dns/dnsmasq/conf/cn-dns.conf
>
>
> So, I think there should some bugs in dnsmasq corresponding to this problem.

Finally, I pinpointed the problem. See my following testings for more info.

Put it simply, if I start dnsmasq like the following, then the problem
will disappear:

$ pgrep -ax dnsmasq
50789 /usr/local/sbin/dnsmasq --port=53 -c10240
--server=127.0.0.1#6053 -C
/home/werner/Public/anti-gfw/dns/dnsmasq/conf/dnsmasq.conf

werner@X10DAi-01:~$ dig www.baidu.com ANY @127.0.0.1

; <<>> DiG 9.16.1-Ubuntu <<>> www.baidu.com ANY @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14805
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.baidu.com.INANY

;; ANSWER SECTION:
www.baidu.com.866INCNAMEwww.a.shifen.com.

;; Query time: 52 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Sep 17 07:20:05 CST 2020
;; MSG SIZE  rcvd: 69

werner@X10DAi-01:~$ pgrep -ax dnsmasq
50789 /usr/local/sbin/dnsmasq --port=53 -c10240
--server=127.0.0.1#6053 -C
/home/werner/Public/anti-gfw/dns/dnsmasq/conf/dnsmasq.conf

So the problem is caused by the following dnsmasq instance:

$ /usr/local/sbin/dnsmasq --port=6054
--servers-file=/home/werner/Public/anti-gfw/dns/dnsmasq/conf/servers-file/cn
-C /home/werner/Public/anti-gfw/dns/dnsmasq/conf/cn-dns.conf

But I still can't figure out what's the wrong configuration or
**bug** (may or may not exist, I'm not sure.) in dnsmasq itself
triggered this problem.

Regards,
-- 
Hongyi Zhao 

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

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

[Hongyi Zhao]

On Thu, Sep 17, 2020 at 6:28 AM Hongyi Zhao  wrote:
>
> On Wed, Sep 16, 2020 at 9:31 PM Hongyi Zhao  wrote:
> >
> > On Tue, Sep 15, 2020 at 9:47 PM Hongyi Zhao  wrote:
> > >
> > > On Tue, Sep 15, 2020 at 11:09 AM Dominick C. Pastore
> > >  wrote:
> > > >
> > > > On Mon, Sep 14, 2020, at 8:03 PM, Hongyi Zhao wrote:
> > > > > I run dnsmasq as following:
> > > > >
> > > > > $ /usr/local/sbin/dnsmasq --port=53 -c10240 --server=127.0.0.1#6053
> > > > > --conf-dir=/home/werner/Public/anti-gfw/dns/dnsmasq/conf/conf-dir,*.conf
> > > > > -C /home/werner/Public/anti-gfw/dns/dnsmasq/conf/dnsmasq.conf
> > > > >
> > > > > The 127.0.0.1#6053 is a DNS proxy based on dnsproxy which has with
> > > > > DoH, DoT, DoQ and DNSCrypt support.
> > > > > The conf files here:
> > > > > /home/werner/Public/anti-gfw/dns/dnsmasq/conf/conf-dir,*.conf, are for
> > > > > China domains which using China's mainland DNS servers.
> > > > >
> > > > > And the main dnsmasq.conf file has the following options enabled:
> > > > >
> > > > > $ egrep -v '^([[:blank:]]*#|$)'
> > > > > /home/werner/Public/anti-gfw/dns/dnsmasq/conf/dnsmasq.conf
> > > > > dns-forward-max=1
> > > > > no-negcache
> > > > > min-cache-ttl=3600
> > > > > all-servers
> > > > > domain-needed
> > > > > bogus-priv
> > > > > filterwin2k
> > > > > no-resolv
> > > > > no-poll
> > > > > interface=lo
> > > > > bind-interfaces
> > > >
> > > > I see. This is making more sense now.
> > > >
> > > > > > Why what? Why won't other programs on the host use Dnsmasq? That's 
> > > > > > the way systems with systemd-resolved work by default. Generally, 
> > > > > > programs on the host will query /etc/resolv.conf to determine which 
> > > > > > DNS servers to use (though the manpage for 
> > > > > > systemd-resolved.service(8) suggests that some programs do not use 
> > > > > > /etc/resolv.conf and connect to systemd-resolved though other 
> > > > > > means. To be honest, that part is a little unclear to me). By 
> > > > > > default, it's a symlink to a file that direct clients to 
> > > > > > systemd-resolved (127.0.0.53).
> > > > > >
> > > > > > The trouble is, systemd-resolved also uses resolv.conf to determine 
> > > > > > its own behavior. The moment you delete the symlink and replace it 
> > > > > > with your own file pointing to Dnsmasq (127.0.0.1), two things will 
> > > > > > happen:
> > > > >
> > > > > This is exactly my situation, see following for more detail info:
> > > > >
> > > > > werner@X10DAi-01:~$ cat /etc/resolv.conf
> > > > > nameserver 127.0.0.1
> > > > > werner@X10DAi-01:~$ realpath -e /etc/resolv.conf
> > > > > /etc/resolv.conf
> > > > >
> > > > > > 1.) systemd-resolved will itself add Dnsmasq to its list of 
> > > > > > nameservers. This probably won't break systemd-resolved entirely, 
> > > > > > but it will potentially cause lots of retries and slowdowns.
> > > > >
> > > > > Seems so complicated and still can't figure out a perfect solution for
> > > > > the coexistence of dnsmasq and systemd-resolved.
> > > >
> > > > Running both on the same system is compicated, and systemd-resolved 
> > > > adds little value when you already have Dnsmasq running. That is is why 
> > > > it's usually not recommended, though I'm reasonably confident it can be 
> > > > done if you really want to.
> > > >
> > > > > > 2.) Unless you've manually configured a nameserver in 
> > > > > > /etc/dnsmasq.conf, Dnsmasq will not have anywhere to send queries. 
> > > > > > This *will* break some things. It's smart enough to know that it 
> > > > > > shouldn't use itself as the upstream server, but neither 
> > > > > > /etc/resolv.conf nor /etc/dnsmasq.conf gives it other options, so 
> > > > > > it fails.
> > > > >
> > > > > As you can see, I've set upstream nameservers for my dnsmasq, so this
> > > > > shouldn't be the culprit for my case.
> > > >
> > > > Agreed.
> > > >
> > > > > >
> > > > > > If you want other programs on the same host to go through Dnsmasq, 
> > > > > > you should use the first option I suggested.
> > > > >
> > > > > Do you mean the following thing you have told:
> > > > >
> > > > > If you want Dnsmasq to query the upstream servers,
> > > > > systemd-resolved to query Dnsmasq,
> > > > > and everything else on the host to query systemd-resolved:
> > > >
> > > > Yes, that is what I meant. That said, based on everything you just 
> > > > sent, it sounds like that's how you currently have things configured:
> > > >
> > > > 1.) Your Dnsmasq is configured to ignore /etc/resolv.conf and has 
> > > > manually configured servers for upstream. Dnsmasq should be working 
> > > > fine, as long as there isn't anything in 
> > > > /home/werner/Public/anti-gfw/dns/dnsmasq/conf/conf-dir causing 
> > > > problems. (But make sure you are escaping the asterisk for that option 
> > > > if you are running dnsmasq in a shell.)
> > > >
> > > > 2.) systemd-resolved should be working well. It gets its upstream 
> > > > servers from your network config. Since you have Netplan configured for 

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

[Hongyi Zhao]

On Wed, Sep 16, 2020 at 9:31 PM Hongyi Zhao  wrote:
>
> On Tue, Sep 15, 2020 at 9:47 PM Hongyi Zhao  wrote:
> >
> > On Tue, Sep 15, 2020 at 11:09 AM Dominick C. Pastore
> >  wrote:
> > >
> > > On Mon, Sep 14, 2020, at 8:03 PM, Hongyi Zhao wrote:
> > > > I run dnsmasq as following:
> > > >
> > > > $ /usr/local/sbin/dnsmasq --port=53 -c10240 --server=127.0.0.1#6053
> > > > --conf-dir=/home/werner/Public/anti-gfw/dns/dnsmasq/conf/conf-dir,*.conf
> > > > -C /home/werner/Public/anti-gfw/dns/dnsmasq/conf/dnsmasq.conf
> > > >
> > > > The 127.0.0.1#6053 is a DNS proxy based on dnsproxy which has with
> > > > DoH, DoT, DoQ and DNSCrypt support.
> > > > The conf files here:
> > > > /home/werner/Public/anti-gfw/dns/dnsmasq/conf/conf-dir,*.conf, are for
> > > > China domains which using China's mainland DNS servers.
> > > >
> > > > And the main dnsmasq.conf file has the following options enabled:
> > > >
> > > > $ egrep -v '^([[:blank:]]*#|$)'
> > > > /home/werner/Public/anti-gfw/dns/dnsmasq/conf/dnsmasq.conf
> > > > dns-forward-max=1
> > > > no-negcache
> > > > min-cache-ttl=3600
> > > > all-servers
> > > > domain-needed
> > > > bogus-priv
> > > > filterwin2k
> > > > no-resolv
> > > > no-poll
> > > > interface=lo
> > > > bind-interfaces
> > >
> > > I see. This is making more sense now.
> > >
> > > > > Why what? Why won't other programs on the host use Dnsmasq? That's 
> > > > > the way systems with systemd-resolved work by default. Generally, 
> > > > > programs on the host will query /etc/resolv.conf to determine which 
> > > > > DNS servers to use (though the manpage for 
> > > > > systemd-resolved.service(8) suggests that some programs do not use 
> > > > > /etc/resolv.conf and connect to systemd-resolved though other means. 
> > > > > To be honest, that part is a little unclear to me). By default, it's 
> > > > > a symlink to a file that direct clients to systemd-resolved 
> > > > > (127.0.0.53).
> > > > >
> > > > > The trouble is, systemd-resolved also uses resolv.conf to determine 
> > > > > its own behavior. The moment you delete the symlink and replace it 
> > > > > with your own file pointing to Dnsmasq (127.0.0.1), two things will 
> > > > > happen:
> > > >
> > > > This is exactly my situation, see following for more detail info:
> > > >
> > > > werner@X10DAi-01:~$ cat /etc/resolv.conf
> > > > nameserver 127.0.0.1
> > > > werner@X10DAi-01:~$ realpath -e /etc/resolv.conf
> > > > /etc/resolv.conf
> > > >
> > > > > 1.) systemd-resolved will itself add Dnsmasq to its list of 
> > > > > nameservers. This probably won't break systemd-resolved entirely, but 
> > > > > it will potentially cause lots of retries and slowdowns.
> > > >
> > > > Seems so complicated and still can't figure out a perfect solution for
> > > > the coexistence of dnsmasq and systemd-resolved.
> > >
> > > Running both on the same system is compicated, and systemd-resolved adds 
> > > little value when you already have Dnsmasq running. That is is why it's 
> > > usually not recommended, though I'm reasonably confident it can be done 
> > > if you really want to.
> > >
> > > > > 2.) Unless you've manually configured a nameserver in 
> > > > > /etc/dnsmasq.conf, Dnsmasq will not have anywhere to send queries. 
> > > > > This *will* break some things. It's smart enough to know that it 
> > > > > shouldn't use itself as the upstream server, but neither 
> > > > > /etc/resolv.conf nor /etc/dnsmasq.conf gives it other options, so it 
> > > > > fails.
> > > >
> > > > As you can see, I've set upstream nameservers for my dnsmasq, so this
> > > > shouldn't be the culprit for my case.
> > >
> > > Agreed.
> > >
> > > > >
> > > > > If you want other programs on the same host to go through Dnsmasq, 
> > > > > you should use the first option I suggested.
> > > >
> > > > Do you mean the following thing you have told:
> > > >
> > > > If you want Dnsmasq to query the upstream servers,
> > > > systemd-resolved to query Dnsmasq,
> > > > and everything else on the host to query systemd-resolved:
> > >
> > > Yes, that is what I meant. That said, based on everything you just sent, 
> > > it sounds like that's how you currently have things configured:
> > >
> > > 1.) Your Dnsmasq is configured to ignore /etc/resolv.conf and has 
> > > manually configured servers for upstream. Dnsmasq should be working fine, 
> > > as long as there isn't anything in 
> > > /home/werner/Public/anti-gfw/dns/dnsmasq/conf/conf-dir causing problems. 
> > > (But make sure you are escaping the asterisk for that option if you are 
> > > running dnsmasq in a shell.)
> > >
> > > 2.) systemd-resolved should be working well. It gets its upstream servers 
> > > from your network config. Since you have Netplan configured for 
> > > 127.0.0.1, it should be using Dnsmasq as its upstream server. You also 
> > > have a regular file for /etc/resolv.conf, so systemd-resolved will use 
> > > the nameserver there as upstream too, but it's the same one, so there is 
> > > no change.
> > >
> > > 

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

[Hongyi Zhao]

On Tue, Sep 15, 2020 at 9:47 PM Hongyi Zhao  wrote:
>
> On Tue, Sep 15, 2020 at 11:09 AM Dominick C. Pastore
>  wrote:
> >
> > On Mon, Sep 14, 2020, at 8:03 PM, Hongyi Zhao wrote:
> > > I run dnsmasq as following:
> > >
> > > $ /usr/local/sbin/dnsmasq --port=53 -c10240 --server=127.0.0.1#6053
> > > --conf-dir=/home/werner/Public/anti-gfw/dns/dnsmasq/conf/conf-dir,*.conf
> > > -C /home/werner/Public/anti-gfw/dns/dnsmasq/conf/dnsmasq.conf
> > >
> > > The 127.0.0.1#6053 is a DNS proxy based on dnsproxy which has with
> > > DoH, DoT, DoQ and DNSCrypt support.
> > > The conf files here:
> > > /home/werner/Public/anti-gfw/dns/dnsmasq/conf/conf-dir,*.conf, are for
> > > China domains which using China's mainland DNS servers.
> > >
> > > And the main dnsmasq.conf file has the following options enabled:
> > >
> > > $ egrep -v '^([[:blank:]]*#|$)'
> > > /home/werner/Public/anti-gfw/dns/dnsmasq/conf/dnsmasq.conf
> > > dns-forward-max=1
> > > no-negcache
> > > min-cache-ttl=3600
> > > all-servers
> > > domain-needed
> > > bogus-priv
> > > filterwin2k
> > > no-resolv
> > > no-poll
> > > interface=lo
> > > bind-interfaces
> >
> > I see. This is making more sense now.
> >
> > > > Why what? Why won't other programs on the host use Dnsmasq? That's the 
> > > > way systems with systemd-resolved work by default. Generally, programs 
> > > > on the host will query /etc/resolv.conf to determine which DNS servers 
> > > > to use (though the manpage for systemd-resolved.service(8) suggests 
> > > > that some programs do not use /etc/resolv.conf and connect to 
> > > > systemd-resolved though other means. To be honest, that part is a 
> > > > little unclear to me). By default, it's a symlink to a file that direct 
> > > > clients to systemd-resolved (127.0.0.53).
> > > >
> > > > The trouble is, systemd-resolved also uses resolv.conf to determine its 
> > > > own behavior. The moment you delete the symlink and replace it with 
> > > > your own file pointing to Dnsmasq (127.0.0.1), two things will happen:
> > >
> > > This is exactly my situation, see following for more detail info:
> > >
> > > werner@X10DAi-01:~$ cat /etc/resolv.conf
> > > nameserver 127.0.0.1
> > > werner@X10DAi-01:~$ realpath -e /etc/resolv.conf
> > > /etc/resolv.conf
> > >
> > > > 1.) systemd-resolved will itself add Dnsmasq to its list of 
> > > > nameservers. This probably won't break systemd-resolved entirely, but 
> > > > it will potentially cause lots of retries and slowdowns.
> > >
> > > Seems so complicated and still can't figure out a perfect solution for
> > > the coexistence of dnsmasq and systemd-resolved.
> >
> > Running both on the same system is compicated, and systemd-resolved adds 
> > little value when you already have Dnsmasq running. That is is why it's 
> > usually not recommended, though I'm reasonably confident it can be done if 
> > you really want to.
> >
> > > > 2.) Unless you've manually configured a nameserver in 
> > > > /etc/dnsmasq.conf, Dnsmasq will not have anywhere to send queries. This 
> > > > *will* break some things. It's smart enough to know that it shouldn't 
> > > > use itself as the upstream server, but neither /etc/resolv.conf nor 
> > > > /etc/dnsmasq.conf gives it other options, so it fails.
> > >
> > > As you can see, I've set upstream nameservers for my dnsmasq, so this
> > > shouldn't be the culprit for my case.
> >
> > Agreed.
> >
> > > >
> > > > If you want other programs on the same host to go through Dnsmasq, you 
> > > > should use the first option I suggested.
> > >
> > > Do you mean the following thing you have told:
> > >
> > > If you want Dnsmasq to query the upstream servers,
> > > systemd-resolved to query Dnsmasq,
> > > and everything else on the host to query systemd-resolved:
> >
> > Yes, that is what I meant. That said, based on everything you just sent, it 
> > sounds like that's how you currently have things configured:
> >
> > 1.) Your Dnsmasq is configured to ignore /etc/resolv.conf and has manually 
> > configured servers for upstream. Dnsmasq should be working fine, as long as 
> > there isn't anything in 
> > /home/werner/Public/anti-gfw/dns/dnsmasq/conf/conf-dir causing problems. 
> > (But make sure you are escaping the asterisk for that option if you are 
> > running dnsmasq in a shell.)
> >
> > 2.) systemd-resolved should be working well. It gets its upstream servers 
> > from your network config. Since you have Netplan configured for 127.0.0.1, 
> > it should be using Dnsmasq as its upstream server. You also have a regular 
> > file for /etc/resolv.conf, so systemd-resolved will use the nameserver 
> > there as upstream too, but it's the same one, so there is no change.
> >
> > 3.) Other programs on your system will either use systemd-networkd or 
> > Dnsmasq for DNS, depending on whether they obey /etc/resolv.conf or not. 
> > Either way, since systemd-resolved is forwarding all queries to Dnsmasq, 
> > every request should eventually end up going through Dnsmasq. (By the way, 

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

[Hongyi Zhao]

On Wed, Sep 16, 2020 at 2:03 PM Geert Stappers  wrote:
>
> On Wed, Sep 16, 2020 at 01:19:27PM +0800, Hongyi Zhao wrote:
> > On Wed, Sep 16, 2020 at 11:18 AM Dominick C. Pastore wrote:
>   ...
> > >
> > > This does indeed seem strange. Unfortunately, I'm not sure either. The
> > > best I can suggest is to check the syslog for any clues, if you
> > > haven't yet.
> >
> > If I’ve time later this afternoon, I will check it and feedback.
>
> Please do

I tried with the following steps but still can't find out any valuable
information for the syslog:

$ dig @127.0.0.1 www.baidu.com ANY
$ grep www.baidu.com  /var/log/syslog
$ tail -100 /var/log/syslog
Sep 16 16:29:28 ubuntu-01 kernel: [ 7365.343806] pcieport
:00:1c.0: AER:   device [8086:a115] error
status/mask=1000/2000
Sep 16 16:29:28 ubuntu-01 kernel: [ 7365.343811] pcieport
:00:1c.0: AER:[12] Timeout
Sep 16 16:29:29 ubuntu-01 kernel: [ 7365.962314] pcieport
:00:1c.0: AER: Multiple Corrected error received: :00:1c.0
Sep 16 16:29:29 ubuntu-01 kernel: [ 7365.962330] pcieport
:00:1c.0: AER: PCIe Bus Error: severity=Corrected, type=Data Link
Layer, (Transmitter ID)
Sep 16 16:29:29 ubuntu-01 kernel: [ 7365.962339] pcieport
:00:1c.0: AER:   device [8086:a115] error
status/mask=1000/2000
Sep 16 16:29:29 ubuntu-01 kernel: [ 7365.962346] pcieport
:00:1c.0: AER:[12] Timeout
Sep 16 16:29:29 ubuntu-01 kernel: [ 7365.977551] pcieport
:00:1c.0: AER: Corrected error received: :00:1c.0
Sep 16 16:29:29 ubuntu-01 kernel: [ 7365.977567] pcieport
:00:1c.0: AER: PCIe Bus Error: severity=Corrected, type=Data Link
Layer, (Transmitter ID)
Sep 16 16:29:29 ubuntu-01 kernel: [ 7365.977575] pcieport
:00:1c.0: AER:   device [8086:a115] error
status/mask=1000/2000
Sep 16 16:29:29 ubuntu-01 kernel: [ 7365.977580] pcieport
:00:1c.0: AER:[12] Timeout
Sep 16 16:29:29 ubuntu-01 kernel: [ 7366.177188] pcieport
:00:1c.0: AER: Corrected error received: :00:1c.0
Sep 16 16:29:29 ubuntu-01 kernel: [ 7366.177203] pcieport
:00:1c.0: AER: PCIe Bus Error: severity=Corrected, type=Data Link
Layer, (Transmitter ID)
Sep 16 16:29:29 ubuntu-01 kernel: [ 7366.177211] pcieport
:00:1c.0: AER:   device [8086:a115] error
status/mask=1000/2000
Sep 16 16:29:29 ubuntu-01 kernel: [ 7366.177216] pcieport
:00:1c.0: AER:[12] Timeout
Sep 16 16:29:30 ubuntu-01 kernel: [ 7366.828912] pcieport
:00:1c.0: AER: Corrected error received: :00:1c.0
Sep 16 16:29:30 ubuntu-01 kernel: [ 7366.828933] pcieport
:00:1c.0: AER: PCIe Bus Error: severity=Corrected, type=Data Link
Layer, (Transmitter ID)
Sep 16 16:29:30 ubuntu-01 kernel: [ 7366.828941] pcieport
:00:1c.0: AER:   device [8086:a115] error
status/mask=1000/2000
Sep 16 16:29:30 ubuntu-01 kernel: [ 7366.828946] pcieport
:00:1c.0: AER:[12] Timeout
Sep 16 16:29:31 ubuntu-01 kernel: [ 7367.678465] pcieport
:00:1c.0: AER: Corrected error received: :00:1c.0
Sep 16 16:29:31 ubuntu-01 kernel: [ 7367.678480] pcieport
:00:1c.0: AER: PCIe Bus Error: severity=Corrected, type=Data Link
Layer, (Transmitter ID)
Sep 16 16:29:31 ubuntu-01 kernel: [ 7367.678487] pcieport
:00:1c.0: AER:   device [8086:a115] error
status/mask=1000/2000
Sep 16 16:29:31 ubuntu-01 kernel: [ 7367.678492] pcieport
:00:1c.0: AER:[12] Timeout
Sep 16 16:29:31 ubuntu-01 kernel: [ 7367.699104] pcieport
:00:1c.0: AER: Corrected error received: :00:1c.0
Sep 16 16:29:31 ubuntu-01 kernel: [ 7367.699114] pcieport
:00:1c.0: AER: PCIe Bus Error: severity=Corrected, type=Data Link
Layer, (Transmitter ID)
Sep 16 16:29:31 ubuntu-01 kernel: [ 7367.699121] pcieport
:00:1c.0: AER:   device [8086:a115] error
status/mask=1000/2000
Sep 16 16:29:31 ubuntu-01 kernel: [ 7367.699127] pcieport
:00:1c.0: AER:[12] Timeout
Sep 16 16:29:31 ubuntu-01 kernel: [ 7367.710196] pcieport
:00:1c.0: AER: Corrected error received: :00:1c.0
Sep 16 16:29:31 ubuntu-01 kernel: [ 7367.710211] pcieport
:00:1c.0: AER: PCIe Bus Error: severity=Corrected, type=Data Link
Layer, (Transmitter ID)
Sep 16 16:29:31 ubuntu-01 kernel: [ 7367.710219] pcieport
:00:1c.0: AER:   device [8086:a115] error
status/mask=1000/2000
Sep 16 16:29:31 ubuntu-01 kernel: [ 7367.710224] pcieport
:00:1c.0: AER:[12] Timeout
Sep 16 16:29:31 ubuntu-01 kernel: [ 7367.866300] pcieport
:00:1c.0: AER: Corrected error received: :00:1c.0
Sep 16 16:29:31 ubuntu-01 kernel: [ 7367.866315] pcieport
:00:1c.0: AER: PCIe Bus Error: severity=Corrected, type=Data Link
Layer, (Transmitter ID)
Sep 16 16:29:31 ubuntu-01 kernel: [ 7367.866322] pcieport
:00:1c.0: AER:   device [8086:a115] error
status/mask=1000/2000
Sep 16 16:29:31 ubuntu-01 kernel: [ 7367.866326] pcieport
:00:1c.0: AER:[12] Timeout
Sep 16 16:29:31 ubuntu-01 kernel: [ 7368.243076] pcieport
:00:1c.0: AER: Corrected error received: :00:1c.0
Sep 16 16:29:31 ubuntu-01 kern

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

[Hongyi Zhao]

On Wed, Sep 16, 2020 at 3:06 PM Dominick C. Pastore
 wrote:
>
> On Wed, Sep 16, 2020, at 1:36 AM, Geert Stappers wrote:
> > > > I was a little surprised this one worked since the previous one
> > > > didn't, but I suspect systemd-resolved is falling back to the
> > > > FallbackDNS servers (which are hardcoded in if not set explicitly).
> >
> > > What's the FallbackDNS servers and how can I find/list them?
> >
> > Good question.  The "hardcoded" suggest it is in source code.
>
> Yes, that is indeed the case. I'm not aware of what those defaults are, but 
> they can be overridden or unset. See the description of the "FallbackDNS" 
> option here: 
> http://manpages.ubuntu.com/manpages/bionic/man5/resolved.conf.5.html

I found some public DNS servers in the source code here:

https://github.com/systemd/systemd/blob/e66d2b4332ca94aeb62e95ec76f1f17ee9b7/meson_options.txt#L252

But I'm not sure whether they are the default/FallbackDNS for systemd-resolvd.

Regards,
HY

>
> (Anyway, I'm not meaning to pull the discussion too far from Dnsmasq.)
>
> > Regards
> > Geert Stappers
> > --
> > Silence is hard to parse
> >
> > ___
> > Dnsmasq-discuss mailing list
> > Dnsmasq-discuss@lists.thekelleys.org.uk
> > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> >
>
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss



-- 
Hongyi Zhao 

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

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

[Hongyi Zhao]

On Wed, Sep 16, 2020 at 2:03 PM Geert Stappers  wrote:
>
> On Wed, Sep 16, 2020 at 01:19:27PM +0800, Hongyi Zhao wrote:
> > On Wed, Sep 16, 2020 at 11:18 AM Dominick C. Pastore wrote:
>   ...
> > >
> > > This does indeed seem strange. Unfortunately, I'm not sure either. The
> > > best I can suggest is to check the syslog for any clues, if you
> > > haven't yet.
> >
> > If I’ve time later this afternoon, I will check it and feedback.
>
> Please do
>
>
>...
> > > I was a little surprised this one worked since the previous one
> > > didn't, but I suspect systemd-resolved is falling back to the
> > > FallbackDNS servers (which are hardcoded in if not set explicitly).
>
> > What's the FallbackDNS servers and how can I find/list them?
>
> Good question.  The "hardcoded" suggest it is in source code.

If so, in the compiled binary, we can't detect/pinpoint/pick out it at
all. The only way is to check the source code for confirmation.

>
>
> Regards
> Geert Stappers
> --
> Silence is hard to parse
>
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss



-- 
Hongyi Zhao 

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

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

[Dominick C. Pastore]

On Wed, Sep 16, 2020, at 1:36 AM, Geert Stappers wrote:
> > > I was a little surprised this one worked since the previous one
> > > didn't, but I suspect systemd-resolved is falling back to the
> > > FallbackDNS servers (which are hardcoded in if not set explicitly).
>  
> > What's the FallbackDNS servers and how can I find/list them?
> 
> Good question.  The "hardcoded" suggest it is in source code.

Yes, that is indeed the case. I'm not aware of what those defaults are, but 
they can be overridden or unset. See the description of the "FallbackDNS" 
option here: 
http://manpages.ubuntu.com/manpages/bionic/man5/resolved.conf.5.html

(Anyway, I'm not meaning to pull the discussion too far from Dnsmasq.)

> Regards
> Geert Stappers
> -- 
> Silence is hard to parse
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

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

[Geert Stappers]

On Wed, Sep 16, 2020 at 01:19:27PM +0800, Hongyi Zhao wrote:
> On Wed, Sep 16, 2020 at 11:18 AM Dominick C. Pastore wrote:
  ...
> >
> > This does indeed seem strange. Unfortunately, I'm not sure either. The
> > best I can suggest is to check the syslog for any clues, if you
> > haven't yet.
> 
> If I’ve time later this afternoon, I will check it and feedback.
 
Please do


   ...
> > I was a little surprised this one worked since the previous one
> > didn't, but I suspect systemd-resolved is falling back to the
> > FallbackDNS servers (which are hardcoded in if not set explicitly).
 
> What's the FallbackDNS servers and how can I find/list them?

Good question.  The "hardcoded" suggest it is in source code.


Regards
Geert Stappers
-- 
Silence is hard to parse

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

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

[Hongyi Zhao]

On Wed, Sep 16, 2020 at 11:18 AM Dominick C. Pastore
 wrote:
>
> On Tue, Sep 15, 2020, at 9:47 AM, Hongyi Zhao wrote:
> > On Tue, Sep 15, 2020 at 11:09 AM Dominick C. Pastore
> >  wrote:
> > >
> > > On Mon, Sep 14, 2020, at 8:03 PM, Hongyi Zhao wrote:
> > > > I run dnsmasq as following:
> > > >
> > > > $ /usr/local/sbin/dnsmasq --port=53 -c10240 --server=127.0.0.1#6053
> > > > --conf-dir=/home/werner/Public/anti-gfw/dns/dnsmasq/conf/conf-dir,*.conf
> > > > -C /home/werner/Public/anti-gfw/dns/dnsmasq/conf/dnsmasq.conf
> > > >
> > > > The 127.0.0.1#6053 is a DNS proxy based on dnsproxy which has with
> > > > DoH, DoT, DoQ and DNSCrypt support.
> > > > The conf files here:
> > > > /home/werner/Public/anti-gfw/dns/dnsmasq/conf/conf-dir,*.conf, are for
> > > > China domains which using China's mainland DNS servers.
> > > >
> > > > And the main dnsmasq.conf file has the following options enabled:
> > > >
> > > > $ egrep -v '^([[:blank:]]*#|$)'
> > > > /home/werner/Public/anti-gfw/dns/dnsmasq/conf/dnsmasq.conf
> > > > dns-forward-max=1
> > > > no-negcache
> > > > min-cache-ttl=3600
> > > > all-servers
> > > > domain-needed
> > > > bogus-priv
> > > > filterwin2k
> > > > no-resolv
> > > > no-poll
> > > > interface=lo
> > > > bind-interfaces
> > >
> > > I see. This is making more sense now.
> > >
> > > > > Why what? Why won't other programs on the host use Dnsmasq? That's 
> > > > > the way systems with systemd-resolved work by default. Generally, 
> > > > > programs on the host will query /etc/resolv.conf to determine which 
> > > > > DNS servers to use (though the manpage for 
> > > > > systemd-resolved.service(8) suggests that some programs do not use 
> > > > > /etc/resolv.conf and connect to systemd-resolved though other means. 
> > > > > To be honest, that part is a little unclear to me). By default, it's 
> > > > > a symlink to a file that direct clients to systemd-resolved 
> > > > > (127.0.0.53).
> > > > >
> > > > > The trouble is, systemd-resolved also uses resolv.conf to determine 
> > > > > its own behavior. The moment you delete the symlink and replace it 
> > > > > with your own file pointing to Dnsmasq (127.0.0.1), two things will 
> > > > > happen:
> > > >
> > > > This is exactly my situation, see following for more detail info:
> > > >
> > > > werner@X10DAi-01:~$ cat /etc/resolv.conf
> > > > nameserver 127.0.0.1
> > > > werner@X10DAi-01:~$ realpath -e /etc/resolv.conf
> > > > /etc/resolv.conf
> > > >
> > > > > 1.) systemd-resolved will itself add Dnsmasq to its list of 
> > > > > nameservers. This probably won't break systemd-resolved entirely, but 
> > > > > it will potentially cause lots of retries and slowdowns.
> > > >
> > > > Seems so complicated and still can't figure out a perfect solution for
> > > > the coexistence of dnsmasq and systemd-resolved.
> > >
> > > Running both on the same system is compicated, and systemd-resolved adds 
> > > little value when you already have Dnsmasq running. That is is why it's 
> > > usually not recommended, though I'm reasonably confident it can be done 
> > > if you really want to.
> > >
> > > > > 2.) Unless you've manually configured a nameserver in 
> > > > > /etc/dnsmasq.conf, Dnsmasq will not have anywhere to send queries. 
> > > > > This *will* break some things. It's smart enough to know that it 
> > > > > shouldn't use itself as the upstream server, but neither 
> > > > > /etc/resolv.conf nor /etc/dnsmasq.conf gives it other options, so it 
> > > > > fails.
> > > >
> > > > As you can see, I've set upstream nameservers for my dnsmasq, so this
> > > > shouldn't be the culprit for my case.
> > >
> > > Agreed.
> > >
> > > > >
> > > > > If you want other programs on the same host to go through Dnsmasq, 
> > > > > you should use the first option I suggested.
> > > >
> > > > Do you mean the following thing you have told:
> > > >
> > > > If you want Dnsmasq to query the upstream servers,
> > > > systemd-resolved to query Dnsmasq,
> > > > and everything else on the host to query systemd-resolved:
> > >
> > > Yes, that is what I meant. That said, based on everything you just sent, 
> > > it sounds like that's how you currently have things configured:
> > >
> > > 1.) Your Dnsmasq is configured to ignore /etc/resolv.conf and has 
> > > manually configured servers for upstream. Dnsmasq should be working fine, 
> > > as long as there isn't anything in 
> > > /home/werner/Public/anti-gfw/dns/dnsmasq/conf/conf-dir causing problems. 
> > > (But make sure you are escaping the asterisk for that option if you are 
> > > running dnsmasq in a shell.)
> > >
> > > 2.) systemd-resolved should be working well. It gets its upstream servers 
> > > from your network config. Since you have Netplan configured for 
> > > 127.0.0.1, it should be using Dnsmasq as its upstream server. You also 
> > > have a regular file for /etc/resolv.conf, so systemd-resolved will use 
> > > the nameserver there as upstream too, but it's the same one, so there is 
> > > no change.
> > >

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

[Dominick C. Pastore]

On Tue, Sep 15, 2020, at 9:47 AM, Hongyi Zhao wrote:
> On Tue, Sep 15, 2020 at 11:09 AM Dominick C. Pastore
>  wrote:
> >
> > On Mon, Sep 14, 2020, at 8:03 PM, Hongyi Zhao wrote:
> > > I run dnsmasq as following:
> > >
> > > $ /usr/local/sbin/dnsmasq --port=53 -c10240 --server=127.0.0.1#6053
> > > --conf-dir=/home/werner/Public/anti-gfw/dns/dnsmasq/conf/conf-dir,*.conf
> > > -C /home/werner/Public/anti-gfw/dns/dnsmasq/conf/dnsmasq.conf
> > >
> > > The 127.0.0.1#6053 is a DNS proxy based on dnsproxy which has with
> > > DoH, DoT, DoQ and DNSCrypt support.
> > > The conf files here:
> > > /home/werner/Public/anti-gfw/dns/dnsmasq/conf/conf-dir,*.conf, are for
> > > China domains which using China's mainland DNS servers.
> > >
> > > And the main dnsmasq.conf file has the following options enabled:
> > >
> > > $ egrep -v '^([[:blank:]]*#|$)'
> > > /home/werner/Public/anti-gfw/dns/dnsmasq/conf/dnsmasq.conf
> > > dns-forward-max=1
> > > no-negcache
> > > min-cache-ttl=3600
> > > all-servers
> > > domain-needed
> > > bogus-priv
> > > filterwin2k
> > > no-resolv
> > > no-poll
> > > interface=lo
> > > bind-interfaces
> >
> > I see. This is making more sense now.
> >
> > > > Why what? Why won't other programs on the host use Dnsmasq? That's the 
> > > > way systems with systemd-resolved work by default. Generally, programs 
> > > > on the host will query /etc/resolv.conf to determine which DNS servers 
> > > > to use (though the manpage for systemd-resolved.service(8) suggests 
> > > > that some programs do not use /etc/resolv.conf and connect to 
> > > > systemd-resolved though other means. To be honest, that part is a 
> > > > little unclear to me). By default, it's a symlink to a file that direct 
> > > > clients to systemd-resolved (127.0.0.53).
> > > >
> > > > The trouble is, systemd-resolved also uses resolv.conf to determine its 
> > > > own behavior. The moment you delete the symlink and replace it with 
> > > > your own file pointing to Dnsmasq (127.0.0.1), two things will happen:
> > >
> > > This is exactly my situation, see following for more detail info:
> > >
> > > werner@X10DAi-01:~$ cat /etc/resolv.conf
> > > nameserver 127.0.0.1
> > > werner@X10DAi-01:~$ realpath -e /etc/resolv.conf
> > > /etc/resolv.conf
> > >
> > > > 1.) systemd-resolved will itself add Dnsmasq to its list of 
> > > > nameservers. This probably won't break systemd-resolved entirely, but 
> > > > it will potentially cause lots of retries and slowdowns.
> > >
> > > Seems so complicated and still can't figure out a perfect solution for
> > > the coexistence of dnsmasq and systemd-resolved.
> >
> > Running both on the same system is compicated, and systemd-resolved adds 
> > little value when you already have Dnsmasq running. That is is why it's 
> > usually not recommended, though I'm reasonably confident it can be done if 
> > you really want to.
> >
> > > > 2.) Unless you've manually configured a nameserver in 
> > > > /etc/dnsmasq.conf, Dnsmasq will not have anywhere to send queries. This 
> > > > *will* break some things. It's smart enough to know that it shouldn't 
> > > > use itself as the upstream server, but neither /etc/resolv.conf nor 
> > > > /etc/dnsmasq.conf gives it other options, so it fails.
> > >
> > > As you can see, I've set upstream nameservers for my dnsmasq, so this
> > > shouldn't be the culprit for my case.
> >
> > Agreed.
> >
> > > >
> > > > If you want other programs on the same host to go through Dnsmasq, you 
> > > > should use the first option I suggested.
> > >
> > > Do you mean the following thing you have told:
> > >
> > > If you want Dnsmasq to query the upstream servers,
> > > systemd-resolved to query Dnsmasq,
> > > and everything else on the host to query systemd-resolved:
> >
> > Yes, that is what I meant. That said, based on everything you just sent, it 
> > sounds like that's how you currently have things configured:
> >
> > 1.) Your Dnsmasq is configured to ignore /etc/resolv.conf and has manually 
> > configured servers for upstream. Dnsmasq should be working fine, as long as 
> > there isn't anything in 
> > /home/werner/Public/anti-gfw/dns/dnsmasq/conf/conf-dir causing problems. 
> > (But make sure you are escaping the asterisk for that option if you are 
> > running dnsmasq in a shell.)
> >
> > 2.) systemd-resolved should be working well. It gets its upstream servers 
> > from your network config. Since you have Netplan configured for 127.0.0.1, 
> > it should be using Dnsmasq as its upstream server. You also have a regular 
> > file for /etc/resolv.conf, so systemd-resolved will use the nameserver 
> > there as upstream too, but it's the same one, so there is no change.
> >
> > 3.) Other programs on your system will either use systemd-networkd or 
> > Dnsmasq for DNS, depending on whether they obey /etc/resolv.conf or not. 
> > Either way, since systemd-resolved is forwarding all queries to Dnsmasq, 
> > every request should eventually end up going through Dnsmasq. (By the way, 

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

[Hongyi Zhao]

On Tue, Sep 15, 2020 at 11:09 AM Dominick C. Pastore
 wrote:
>
> On Mon, Sep 14, 2020, at 8:03 PM, Hongyi Zhao wrote:
> > I run dnsmasq as following:
> >
> > $ /usr/local/sbin/dnsmasq --port=53 -c10240 --server=127.0.0.1#6053
> > --conf-dir=/home/werner/Public/anti-gfw/dns/dnsmasq/conf/conf-dir,*.conf
> > -C /home/werner/Public/anti-gfw/dns/dnsmasq/conf/dnsmasq.conf
> >
> > The 127.0.0.1#6053 is a DNS proxy based on dnsproxy which has with
> > DoH, DoT, DoQ and DNSCrypt support.
> > The conf files here:
> > /home/werner/Public/anti-gfw/dns/dnsmasq/conf/conf-dir,*.conf, are for
> > China domains which using China's mainland DNS servers.
> >
> > And the main dnsmasq.conf file has the following options enabled:
> >
> > $ egrep -v '^([[:blank:]]*#|$)'
> > /home/werner/Public/anti-gfw/dns/dnsmasq/conf/dnsmasq.conf
> > dns-forward-max=1
> > no-negcache
> > min-cache-ttl=3600
> > all-servers
> > domain-needed
> > bogus-priv
> > filterwin2k
> > no-resolv
> > no-poll
> > interface=lo
> > bind-interfaces
>
> I see. This is making more sense now.
>
> > > Why what? Why won't other programs on the host use Dnsmasq? That's the 
> > > way systems with systemd-resolved work by default. Generally, programs on 
> > > the host will query /etc/resolv.conf to determine which DNS servers to 
> > > use (though the manpage for systemd-resolved.service(8) suggests that 
> > > some programs do not use /etc/resolv.conf and connect to systemd-resolved 
> > > though other means. To be honest, that part is a little unclear to me). 
> > > By default, it's a symlink to a file that direct clients to 
> > > systemd-resolved (127.0.0.53).
> > >
> > > The trouble is, systemd-resolved also uses resolv.conf to determine its 
> > > own behavior. The moment you delete the symlink and replace it with your 
> > > own file pointing to Dnsmasq (127.0.0.1), two things will happen:
> >
> > This is exactly my situation, see following for more detail info:
> >
> > werner@X10DAi-01:~$ cat /etc/resolv.conf
> > nameserver 127.0.0.1
> > werner@X10DAi-01:~$ realpath -e /etc/resolv.conf
> > /etc/resolv.conf
> >
> > > 1.) systemd-resolved will itself add Dnsmasq to its list of nameservers. 
> > > This probably won't break systemd-resolved entirely, but it will 
> > > potentially cause lots of retries and slowdowns.
> >
> > Seems so complicated and still can't figure out a perfect solution for
> > the coexistence of dnsmasq and systemd-resolved.
>
> Running both on the same system is compicated, and systemd-resolved adds 
> little value when you already have Dnsmasq running. That is is why it's 
> usually not recommended, though I'm reasonably confident it can be done if 
> you really want to.
>
> > > 2.) Unless you've manually configured a nameserver in /etc/dnsmasq.conf, 
> > > Dnsmasq will not have anywhere to send queries. This *will* break some 
> > > things. It's smart enough to know that it shouldn't use itself as the 
> > > upstream server, but neither /etc/resolv.conf nor /etc/dnsmasq.conf gives 
> > > it other options, so it fails.
> >
> > As you can see, I've set upstream nameservers for my dnsmasq, so this
> > shouldn't be the culprit for my case.
>
> Agreed.
>
> > >
> > > If you want other programs on the same host to go through Dnsmasq, you 
> > > should use the first option I suggested.
> >
> > Do you mean the following thing you have told:
> >
> > If you want Dnsmasq to query the upstream servers,
> > systemd-resolved to query Dnsmasq,
> > and everything else on the host to query systemd-resolved:
>
> Yes, that is what I meant. That said, based on everything you just sent, it 
> sounds like that's how you currently have things configured:
>
> 1.) Your Dnsmasq is configured to ignore /etc/resolv.conf and has manually 
> configured servers for upstream. Dnsmasq should be working fine, as long as 
> there isn't anything in 
> /home/werner/Public/anti-gfw/dns/dnsmasq/conf/conf-dir causing problems. (But 
> make sure you are escaping the asterisk for that option if you are running 
> dnsmasq in a shell.)
>
> 2.) systemd-resolved should be working well. It gets its upstream servers 
> from your network config. Since you have Netplan configured for 127.0.0.1, it 
> should be using Dnsmasq as its upstream server. You also have a regular file 
> for /etc/resolv.conf, so systemd-resolved will use the nameserver there as 
> upstream too, but it's the same one, so there is no change.
>
> 3.) Other programs on your system will either use systemd-networkd or Dnsmasq 
> for DNS, depending on whether they obey /etc/resolv.conf or not. Either way, 
> since systemd-resolved is forwarding all queries to Dnsmasq, every request 
> should eventually end up going through Dnsmasq. (By the way, you should 
> safely be able to restore /etc/resolv.conf to its original symlink to 
> /run/systemd/resolve/stub-resolv.conf since you don't have Dnsmasq reading 
> from it.)
>
> So, at this point, I'm not quite sure what the problem is. You mentioned 
> using dig ear

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

[Hongyi Zhao]

On Tue, Sep 15, 2020 at 11:09 AM Dominick C. Pastore
 wrote:
>
> On Mon, Sep 14, 2020, at 8:03 PM, Hongyi Zhao wrote:
> > I run dnsmasq as following:
> >
> > $ /usr/local/sbin/dnsmasq --port=53 -c10240 --server=127.0.0.1#6053
> > --conf-dir=/home/werner/Public/anti-gfw/dns/dnsmasq/conf/conf-dir,*.conf
> > -C /home/werner/Public/anti-gfw/dns/dnsmasq/conf/dnsmasq.conf
> >
> > The 127.0.0.1#6053 is a DNS proxy based on dnsproxy which has with
> > DoH, DoT, DoQ and DNSCrypt support.
> > The conf files here:
> > /home/werner/Public/anti-gfw/dns/dnsmasq/conf/conf-dir,*.conf, are for
> > China domains which using China's mainland DNS servers.
> >
> > And the main dnsmasq.conf file has the following options enabled:
> >
> > $ egrep -v '^([[:blank:]]*#|$)'
> > /home/werner/Public/anti-gfw/dns/dnsmasq/conf/dnsmasq.conf
> > dns-forward-max=1
> > no-negcache
> > min-cache-ttl=3600
> > all-servers
> > domain-needed
> > bogus-priv
> > filterwin2k
> > no-resolv
> > no-poll
> > interface=lo
> > bind-interfaces
>
> I see. This is making more sense now.
>
> > > Why what? Why won't other programs on the host use Dnsmasq? That's the 
> > > way systems with systemd-resolved work by default. Generally, programs on 
> > > the host will query /etc/resolv.conf to determine which DNS servers to 
> > > use (though the manpage for systemd-resolved.service(8) suggests that 
> > > some programs do not use /etc/resolv.conf and connect to systemd-resolved 
> > > though other means. To be honest, that part is a little unclear to me). 
> > > By default, it's a symlink to a file that direct clients to 
> > > systemd-resolved (127.0.0.53).
> > >
> > > The trouble is, systemd-resolved also uses resolv.conf to determine its 
> > > own behavior. The moment you delete the symlink and replace it with your 
> > > own file pointing to Dnsmasq (127.0.0.1), two things will happen:
> >
> > This is exactly my situation, see following for more detail info:
> >
> > werner@X10DAi-01:~$ cat /etc/resolv.conf
> > nameserver 127.0.0.1
> > werner@X10DAi-01:~$ realpath -e /etc/resolv.conf
> > /etc/resolv.conf
> >
> > > 1.) systemd-resolved will itself add Dnsmasq to its list of nameservers. 
> > > This probably won't break systemd-resolved entirely, but it will 
> > > potentially cause lots of retries and slowdowns.
> >
> > Seems so complicated and still can't figure out a perfect solution for
> > the coexistence of dnsmasq and systemd-resolved.
>
> Running both on the same system is compicated, and systemd-resolved adds 
> little value when you already have Dnsmasq running. That is is why it's 
> usually not recommended, though I'm reasonably confident it can be done if 
> you really want to.
>
> > > 2.) Unless you've manually configured a nameserver in /etc/dnsmasq.conf, 
> > > Dnsmasq will not have anywhere to send queries. This *will* break some 
> > > things. It's smart enough to know that it shouldn't use itself as the 
> > > upstream server, but neither /etc/resolv.conf nor /etc/dnsmasq.conf gives 
> > > it other options, so it fails.
> >
> > As you can see, I've set upstream nameservers for my dnsmasq, so this
> > shouldn't be the culprit for my case.
>
> Agreed.
>
> > >
> > > If you want other programs on the same host to go through Dnsmasq, you 
> > > should use the first option I suggested.
> >
> > Do you mean the following thing you have told:
> >
> > If you want Dnsmasq to query the upstream servers,
> > systemd-resolved to query Dnsmasq,
> > and everything else on the host to query systemd-resolved:
>
> Yes, that is what I meant. That said, based on everything you just sent, it 
> sounds like that's how you currently have things configured:
>
> 1.) Your Dnsmasq is configured to ignore /etc/resolv.conf and has manually 
> configured servers for upstream. Dnsmasq should be working fine, as long as 
> there isn't anything in 
> /home/werner/Public/anti-gfw/dns/dnsmasq/conf/conf-dir causing problems. (But 
> make sure you are escaping the asterisk for that option if you are running 
> dnsmasq in a shell.)

I run the dnsmasq command shown here from a bash shell script instead
of directly issued from terminal. So the escaping character, i.e., \,
should be unnecessary.

I think you mean if I run the command directly under a terminal, I
should issue it as following:

$ /usr/local/sbin/dnsmasq --port=53 -c10240 --server=127.0.0.1#6053
 --conf-dir=/home/werner/Public/anti-gfw/dns/dnsmasq/conf/conf-dir,\*.conf
 -C /home/werner/Public/anti-gfw/dns/dnsmasq/conf/dnsmasq.conf


As for the other questions below, I will test them carefully before I
can give the feedback.

Thanks again for your careful and in-depth analysis.

Best regards,
HY

>
> 2.) systemd-resolved should be working well. It gets its upstream servers 
> from your network config. Since you have Netplan configured for 127.0.0.1, it 
> should be using Dnsmasq as its upstream server. You also have a regular file 
> for /etc/resolv.conf, so systemd-resolved will use the nameserver there a

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

[Dominick C. Pastore]

On Mon, Sep 14, 2020, at 8:03 PM, Hongyi Zhao wrote:
> I run dnsmasq as following:
> 
> $ /usr/local/sbin/dnsmasq --port=53 -c10240 --server=127.0.0.1#6053
> --conf-dir=/home/werner/Public/anti-gfw/dns/dnsmasq/conf/conf-dir,*.conf
> -C /home/werner/Public/anti-gfw/dns/dnsmasq/conf/dnsmasq.conf
> 
> The 127.0.0.1#6053 is a DNS proxy based on dnsproxy which has with
> DoH, DoT, DoQ and DNSCrypt support.
> The conf files here:
> /home/werner/Public/anti-gfw/dns/dnsmasq/conf/conf-dir,*.conf, are for
> China domains which using China's mainland DNS servers.
> 
> And the main dnsmasq.conf file has the following options enabled:
> 
> $ egrep -v '^([[:blank:]]*#|$)'
> /home/werner/Public/anti-gfw/dns/dnsmasq/conf/dnsmasq.conf
> dns-forward-max=1
> no-negcache
> min-cache-ttl=3600
> all-servers
> domain-needed
> bogus-priv
> filterwin2k
> no-resolv
> no-poll
> interface=lo
> bind-interfaces

I see. This is making more sense now.

> > Why what? Why won't other programs on the host use Dnsmasq? That's the way 
> > systems with systemd-resolved work by default. Generally, programs on the 
> > host will query /etc/resolv.conf to determine which DNS servers to use 
> > (though the manpage for systemd-resolved.service(8) suggests that some 
> > programs do not use /etc/resolv.conf and connect to systemd-resolved though 
> > other means. To be honest, that part is a little unclear to me). By 
> > default, it's a symlink to a file that direct clients to systemd-resolved 
> > (127.0.0.53).
> >
> > The trouble is, systemd-resolved also uses resolv.conf to determine its own 
> > behavior. The moment you delete the symlink and replace it with your own 
> > file pointing to Dnsmasq (127.0.0.1), two things will happen:
> 
> This is exactly my situation, see following for more detail info:
> 
> werner@X10DAi-01:~$ cat /etc/resolv.conf
> nameserver 127.0.0.1
> werner@X10DAi-01:~$ realpath -e /etc/resolv.conf
> /etc/resolv.conf
> 
> > 1.) systemd-resolved will itself add Dnsmasq to its list of nameservers. 
> > This probably won't break systemd-resolved entirely, but it will 
> > potentially cause lots of retries and slowdowns.
> 
> Seems so complicated and still can't figure out a perfect solution for
> the coexistence of dnsmasq and systemd-resolved.

Running both on the same system is compicated, and systemd-resolved adds little 
value when you already have Dnsmasq running. That is is why it's usually not 
recommended, though I'm reasonably confident it can be done if you really want 
to.

> > 2.) Unless you've manually configured a nameserver in /etc/dnsmasq.conf, 
> > Dnsmasq will not have anywhere to send queries. This *will* break some 
> > things. It's smart enough to know that it shouldn't use itself as the 
> > upstream server, but neither /etc/resolv.conf nor /etc/dnsmasq.conf gives 
> > it other options, so it fails.
> 
> As you can see, I've set upstream nameservers for my dnsmasq, so this
> shouldn't be the culprit for my case.

Agreed.

> >
> > If you want other programs on the same host to go through Dnsmasq, you 
> > should use the first option I suggested.
> 
> Do you mean the following thing you have told:
> 
> If you want Dnsmasq to query the upstream servers,
> systemd-resolved to query Dnsmasq,
> and everything else on the host to query systemd-resolved:

Yes, that is what I meant. That said, based on everything you just sent, it 
sounds like that's how you currently have things configured:

1.) Your Dnsmasq is configured to ignore /etc/resolv.conf and has manually 
configured servers for upstream. Dnsmasq should be working fine, as long as 
there isn't anything in /home/werner/Public/anti-gfw/dns/dnsmasq/conf/conf-dir 
causing problems. (But make sure you are escaping the asterisk for that option 
if you are running dnsmasq in a shell.)

2.) systemd-resolved should be working well. It gets its upstream servers from 
your network config. Since you have Netplan configured for 127.0.0.1, it should 
be using Dnsmasq as its upstream server. You also have a regular file for 
/etc/resolv.conf, so systemd-resolved will use the nameserver there as upstream 
too, but it's the same one, so there is no change.

3.) Other programs on your system will either use systemd-networkd or Dnsmasq 
for DNS, depending on whether they obey /etc/resolv.conf or not. Either way, 
since systemd-resolved is forwarding all queries to Dnsmasq, every request 
should eventually end up going through Dnsmasq. (By the way, you should safely 
be able to restore /etc/resolv.conf to its original symlink to 
/run/systemd/resolve/stub-resolv.conf since you don't have Dnsmasq reading from 
it.)

So, at this point, I'm not quite sure what the problem is. You mentioned using 
dig earlier, so I'm not sure if you already tried this, but you can try 
connecting to each server directly to pinpoint which step in the chain is 
causing issues:

To test your DNS proxy:
dig @127.0.0.1 -p 6053  ANY

If that is working as intended, then test Dnsmasq:

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

[Hongyi Zhao]

On Mon, Sep 14, 2020 at 10:45 PM Dominick C. Pastore
 wrote:
>
> > > Personally, I am not a fan of Netplan for reasons like this. It's 
> > > supposed to abstract away the details of NetworkManager or 
> > > systemd-networkd, but it doesn't do a great job of it. You end up having 
> > > to refer to the NetworkManager or systemd-networkd documentation anyway, 
> > > and having Netplan on top muddies the water.
> > >
> > > Anyway: Those address lines in the Netplan yaml are used to tell 
> > > systemd-resolved which upstream DNS server to use, so it is using your 
> > > Dnsmasq server. Then, /etc/resolv.conf specifies what DNS server other 
> > > programs on the system will use (not all programs use that mechanism, but 
> > > many do), and by default, it points to 127.0.0.53 so everything else will 
> > > go through systemd-resolved. This includes Dnsmasq unless you configure 
> > > it to do otherwise!
> > >
> > > The net result is most likely that Dnsmasq and systemd-resolved are each 
> > > trying to use the other as their upstream server, so neither can resolve 
> > > anything.
> > >
> > > If you really want to keep using both systemd-resolved and Dnsmasq, you 
> > > need to pick one to be "upstream" from the other, as Geert and Neal said.
> > >
> > > If you want Dnsmasq to query the upstream servers, systemd-resolved to 
> > > query Dnsmasq, and everything else on the host to query systemd-resolved:
> > > Then you need to edit the Dnsmasq configuration to quit using 
> > > /etc/resolv.conf. This probably means you want to manually specify DNS 
> > > servers in /etc/dnsmasq.conf with the "server=W.X.Y.Z" and "no-resolv" 
> > > options. That does assume you know what DNS server you want to use.
> >
> > Very strange, for my case, I've already set the following options in
> > my dnsmasq.conf:
> >
> > no-resolv
> > no-poll
> >
> > and keep /etc/resolv.conf as the symlink to
> > /run/systemd/resolve/stub-resolv.conf
>
> Did you specify a server for Dnsmasq some other way? E.g. the 
> "server=W.X.Y.Z" option? Or, better yet, can you share your Dnsmasq config?

I run dnsmasq as following:

$ /usr/local/sbin/dnsmasq --port=53 -c10240 --server=127.0.0.1#6053
--conf-dir=/home/werner/Public/anti-gfw/dns/dnsmasq/conf/conf-dir,*.conf
-C /home/werner/Public/anti-gfw/dns/dnsmasq/conf/dnsmasq.conf

The 127.0.0.1#6053 is a DNS proxy based on dnsproxy which has with
DoH, DoT, DoQ and DNSCrypt support.
The conf files here:
/home/werner/Public/anti-gfw/dns/dnsmasq/conf/conf-dir,*.conf, are for
China domains which using China's mainland DNS servers.

And the main dnsmasq.conf file has the following options enabled:

$ egrep -v '^([[:blank:]]*#|$)'
/home/werner/Public/anti-gfw/dns/dnsmasq/conf/dnsmasq.conf
dns-forward-max=1
no-negcache
min-cache-ttl=3600
all-servers
domain-needed
bogus-priv
filterwin2k
no-resolv
no-poll
interface=lo
bind-interfaces


>
> > >
> > > Alternatively, if you want systemd-resolved to query the upstream servers 
> > > and Dnsmasq to query systemd-resolved:
> > > Then you need to remove the "use-dns: false" and "nameservers" directives 
> > > from Netplan so systemd-resolved stops trying to query Dnsmasq and uses 
> > > the proper upstream servers instead. Dnsmasq will continue to use 
> > > systemd-resolved, since /etc/resolv.conf will point it there. Note that 
> > > programs on the same host will still use systemd-resolved and not Dnsmasq 
> > > at all.
> >
> > Why?
>
> Why what? Why won't other programs on the host use Dnsmasq? That's the way 
> systems with systemd-resolved work by default. Generally, programs on the 
> host will query /etc/resolv.conf to determine which DNS servers to use 
> (though the manpage for systemd-resolved.service(8) suggests that some 
> programs do not use /etc/resolv.conf and connect to systemd-resolved though 
> other means. To be honest, that part is a little unclear to me). By default, 
> it's a symlink to a file that direct clients to systemd-resolved (127.0.0.53).
>
> The trouble is, systemd-resolved also uses resolv.conf to determine its own 
> behavior. The moment you delete the symlink and replace it with your own file 
> pointing to Dnsmasq (127.0.0.1), two things will happen:

This is exactly my situation, see following for more detail info:

werner@X10DAi-01:~$ cat /etc/resolv.conf
nameserver 127.0.0.1
werner@X10DAi-01:~$ realpath -e /etc/resolv.conf
/etc/resolv.conf

> 1.) systemd-resolved will itself add Dnsmasq to its list of nameservers. This 
> probably won't break systemd-resolved entirely, but it will potentially cause 
> lots of retries and slowdowns.

Seems so complicated and still can't figure out a perfect solution for
the coexistence of dnsmasq and systemd-resolved.

> 2.) Unless you've manually configured a nameserver in /etc/dnsmasq.conf, 
> Dnsmasq will not have anywhere to send queries. This *will* break some 
> things. It's smart enough to know that it shouldn't use itself as the 
> upstream server, but neither /etc/resolv.conf nor /etc

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

[Dominick C. Pastore]

> > Personally, I am not a fan of Netplan for reasons like this. It's supposed 
> > to abstract away the details of NetworkManager or systemd-networkd, but it 
> > doesn't do a great job of it. You end up having to refer to the 
> > NetworkManager or systemd-networkd documentation anyway, and having Netplan 
> > on top muddies the water.
> >
> > Anyway: Those address lines in the Netplan yaml are used to tell 
> > systemd-resolved which upstream DNS server to use, so it is using your 
> > Dnsmasq server. Then, /etc/resolv.conf specifies what DNS server other 
> > programs on the system will use (not all programs use that mechanism, but 
> > many do), and by default, it points to 127.0.0.53 so everything else will 
> > go through systemd-resolved. This includes Dnsmasq unless you configure it 
> > to do otherwise!
> >
> > The net result is most likely that Dnsmasq and systemd-resolved are each 
> > trying to use the other as their upstream server, so neither can resolve 
> > anything.
> >
> > If you really want to keep using both systemd-resolved and Dnsmasq, you 
> > need to pick one to be "upstream" from the other, as Geert and Neal said.
> >
> > If you want Dnsmasq to query the upstream servers, systemd-resolved to 
> > query Dnsmasq, and everything else on the host to query systemd-resolved:
> > Then you need to edit the Dnsmasq configuration to quit using 
> > /etc/resolv.conf. This probably means you want to manually specify DNS 
> > servers in /etc/dnsmasq.conf with the "server=W.X.Y.Z" and "no-resolv" 
> > options. That does assume you know what DNS server you want to use.
> 
> Very strange, for my case, I've already set the following options in
> my dnsmasq.conf:
> 
> no-resolv
> no-poll
> 
> and keep /etc/resolv.conf as the symlink to
> /run/systemd/resolve/stub-resolv.conf

Did you specify a server for Dnsmasq some other way? E.g. the "server=W.X.Y.Z" 
option? Or, better yet, can you share your Dnsmasq config?

> >
> > Alternatively, if you want systemd-resolved to query the upstream servers 
> > and Dnsmasq to query systemd-resolved:
> > Then you need to remove the "use-dns: false" and "nameservers" directives 
> > from Netplan so systemd-resolved stops trying to query Dnsmasq and uses the 
> > proper upstream servers instead. Dnsmasq will continue to use 
> > systemd-resolved, since /etc/resolv.conf will point it there. Note that 
> > programs on the same host will still use systemd-resolved and not Dnsmasq 
> > at all.
> 
> Why?

Why what? Why won't other programs on the host use Dnsmasq? That's the way 
systems with systemd-resolved work by default. Generally, programs on the host 
will query /etc/resolv.conf to determine which DNS servers to use (though the 
manpage for systemd-resolved.service(8) suggests that some programs do not use 
/etc/resolv.conf and connect to systemd-resolved though other means. To be 
honest, that part is a little unclear to me). By default, it's a symlink to a 
file that direct clients to systemd-resolved (127.0.0.53).

The trouble is, systemd-resolved also uses resolv.conf to determine its own 
behavior. The moment you delete the symlink and replace it with your own file 
pointing to Dnsmasq (127.0.0.1), two things will happen:
1.) systemd-resolved will itself add Dnsmasq to its list of nameservers. This 
probably won't break systemd-resolved entirely, but it will potentially cause 
lots of retries and slowdowns.
2.) Unless you've manually configured a nameserver in /etc/dnsmasq.conf, 
Dnsmasq will not have anywhere to send queries. This *will* break some things. 
It's smart enough to know that it shouldn't use itself as the upstream server, 
but neither /etc/resolv.conf nor /etc/dnsmasq.conf gives it other options, so 
it fails.

If you want other programs on the same host to go through Dnsmasq, you should 
use the first option I suggested.

> > Only other hosts on the same network will be able to use Dnsmasq.
> 
> Seems this is not my purpose.
> 
> >
> > Regards,
> > Dominick
> >
> > ___
> > Dnsmasq-discuss mailing list
> > Dnsmasq-discuss@lists.thekelleys.org.uk
> > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 
> 
> 
> -- 
> Hongyi Zhao 
>

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

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

[Hongyi Zhao]

On Mon, Sep 14, 2020 at 12:31 PM Dominick C. Pastore
 wrote:
>
> On Sun, Sep 13, 2020, at 10:44 PM, Hongyi Zhao wrote:
> > On Mon, Sep 14, 2020 at 9:02 AM Neal P. Murphy
> >  wrote:
> > >
> > > On Mon, 14 Sep 2020 06:52:49 +0800
> > > Hongyi Zhao  wrote:
> > >
> > > > On Mon, Sep 14, 2020 at 4:26 AM Geert Stappers  
> > > > 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?
>
> Personally, I am not a fan of Netplan for reasons like this. It's supposed to 
> abstract away the details of NetworkManager or systemd-networkd, but it 
> doesn't do a great job of it. You end up having to refer to the 
> NetworkManager or systemd-networkd documentation anyway, and having Netplan 
> on top muddies the water.
>
> Anyway: Those address lines in the Netplan yaml are used to tell 
> systemd-resolved which upstream DNS server to use, so it is using your 
> Dnsmasq server. Then, /etc/resolv.conf specifies what DNS server other 
> programs on the system will use (not all programs use that mechanism, but 
> many do), and by default, it points to 127.0.0.53 so everything else will go 
> through systemd-resolved. This includes Dnsmasq unless you configure it to do 
> otherwise!
>
> The net result is most likely that Dnsmasq and systemd-resolved are each 
> trying to use the other as their upstream server, so neither can resolve 
> anything.
>
> If you really want to keep using both systemd-resolved and Dnsmasq, you need 
> to pick one to be "upstream" from the other, as Geert and Neal said.
>
> If you want Dnsmasq to query the upstream servers, systemd-resolved to query 
> Dnsmasq, and everything else on the host to query systemd-resolved:
> Then you need to edit the Dnsmasq configuration to quit using 
> /etc/resolv.conf. This probably means you want to manually specify DNS 
> servers in /etc/dnsmasq.conf with the "server=W.X.Y.Z" and "no-resolv" 
> options. That does assume you know what DNS server you want to use.

Very strange, for my case, I've already set the following options in
my dnsmasq.conf:

no-resolv
no-poll

and keep /etc/resolv.conf as the symlink to
/run/systemd/resolve/stub-resolv.conf

>
> Alternatively, if you want systemd-resolved to query the upstream servers and 
> Dnsmasq to query systemd-resolved:
> Then you need to remove the "use-dns: false" and "nameservers" directives 
> from Netplan so systemd-resolved stops trying to query Dnsmasq and uses the 
> proper upstream servers instead. Dnsmasq will continue to use 
> systemd-resolved, since /etc/resolv.conf will point it there. Note that 
> programs on the same host will still use systemd-resolved and not Dnsmasq at 
> all.

Why?

> Only other hosts on the same network will be able to use Dnsmasq.

Seems this is not my purpose.

>
> Regards,
> Dominick
>
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss



-- 
Hongyi Zhao 

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

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

[Dominick C. Pastore]

On Sun, Sep 13, 2020, at 10:44 PM, Hongyi Zhao wrote:
> On Mon, Sep 14, 2020 at 9:02 AM Neal P. Murphy
>  wrote:
> >
> > On Mon, 14 Sep 2020 06:52:49 +0800
> > Hongyi Zhao  wrote:
> >
> > > On Mon, Sep 14, 2020 at 4:26 AM Geert Stappers  
> > > 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?

Personally, I am not a fan of Netplan for reasons like this. It's supposed to 
abstract away the details of NetworkManager or systemd-networkd, but it doesn't 
do a great job of it. You end up having to refer to the NetworkManager or 
systemd-networkd documentation anyway, and having Netplan on top muddies the 
water.

Anyway: Those address lines in the Netplan yaml are used to tell 
systemd-resolved which upstream DNS server to use, so it is using your Dnsmasq 
server. Then, /etc/resolv.conf specifies what DNS server other programs on the 
system will use (not all programs use that mechanism, but many do), and by 
default, it points to 127.0.0.53 so everything else will go through 
systemd-resolved. This includes Dnsmasq unless you configure it to do otherwise!

The net result is most likely that Dnsmasq and systemd-resolved are each trying 
to use the other as their upstream server, so neither can resolve anything.

If you really want to keep using both systemd-resolved and Dnsmasq, you need to 
pick one to be "upstream" from the other, as Geert and Neal said.

If you want Dnsmasq to query the upstream servers, systemd-resolved to query 
Dnsmasq, and everything else on the host to query systemd-resolved:
Then you need to edit the Dnsmasq configuration to quit using /etc/resolv.conf. 
This probably means you want to manually specify DNS servers in 
/etc/dnsmasq.conf with the "server=W.X.Y.Z" and "no-resolv" options. That does 
assume you know what DNS server you want to use.

Alternatively, if you want systemd-resolved to query the upstream servers and 
Dnsmasq to query systemd-resolved:
Then you need to remove the "use-dns: false" and "nameservers" directives from 
Netplan so systemd-resolved stops trying to query Dnsmasq and uses the proper 
upstream servers instead. Dnsmasq will continue to use systemd-resolved, since 
/etc/resolv.conf will point it there. Note that programs on the same host will 
still use systemd-resolved and not Dnsmasq at all. Only other hosts on the same 
network will be able to use Dnsmasq.

Regards,
Dominick

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

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

[Hongyi Zhao]

On Mon, Sep 14, 2020 at 9:02 AM Neal P. Murphy
 wrote:
>
> On Mon, 14 Sep 2020 06:52:49 +0800
> Hongyi Zhao  wrote:
>
> > On Mon, Sep 14, 2020 at 4:26 AM Geert Stappers  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@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss



-- 
Hongyi Zhao 

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

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

[Neal P. Murphy]

On Mon, 14 Sep 2020 06:52:49 +0800
Hongyi Zhao  wrote:

> On Mon, Sep 14, 2020 at 4:26 AM Geert Stappers  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.

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

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

[Hongyi Zhao]

On Mon, Sep 14, 2020 at 4:26 AM Geert Stappers  wrote:
>
> On Sun, Sep 13, 2020 at 03:36:42PM +0800, Hongyi Zhao wrote:
> > Hi,
> >
> > On Ubuntu 20.04, I let dnsmasq listen on 127.0.0.1:53, at the same
> > time, I also noted that systemd-resolved has a default stub dns
> > resolver which is listening on 127.0.0.53:53.
> >
> > And for my case, the /etc/resolv.conf is a symlink as following:
> >
> > $ realpath -e /etc/resolv.conf
> > /run/systemd/resolve/stub-resolv.conf
> >
> > The content of this file is shown as follows:
> >
> > $ cat /etc/resolv.conf
> > # This file is managed by man:systemd-resolved(8). Do not edit.
> > #
> > # This is a dynamic resolv.conf file for connecting local clients to the
> > # internal DNS stub resolver of systemd-resolved. This file lists all
> > # configured search domains.
> > #
> > # Run "resolvectl status" to see details about the uplink DNS servers
> > # currently in use.
> > #
> > # Third party programs must not access this file directly, but only through 
> > the
> > # symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different 
> > way,
> > # replace this symlink by a static file or a different symlink.
> > #
> > # See man:systemd-resolved.service(8) for details about the supported modes 
> > of
> > # operation for /etc/resolv.conf.
> >
> > nameserver 127.0.0.53
> > options edns0
> >
> >
> > I use the netplan to set 127.0.0.1 as the dns for all interfaces. But
> > it seems there are some conflicts on my above configuration. Say, when
> > I do the following testing:
> >
> > $ dig www.baidu.com
> >
> > I always noticed that there will have multiple dnsmasq instances be
> > triggered automatically and the resolution will fail.
> >
> > 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

>
>
>
> Groeten
> Geert Stappers
> --
> Silence is hard to parse
>
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss



-- 
Hongyi Zhao 

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

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

[Geert Stappers]

On Sun, Sep 13, 2020 at 03:36:42PM +0800, Hongyi Zhao wrote:
> Hi,
> 
> On Ubuntu 20.04, I let dnsmasq listen on 127.0.0.1:53, at the same
> time, I also noted that systemd-resolved has a default stub dns
> resolver which is listening on 127.0.0.53:53.
> 
> And for my case, the /etc/resolv.conf is a symlink as following:
> 
> $ realpath -e /etc/resolv.conf
> /run/systemd/resolve/stub-resolv.conf
> 
> The content of this file is shown as follows:
> 
> $ cat /etc/resolv.conf
> # This file is managed by man:systemd-resolved(8). Do not edit.
> #
> # This is a dynamic resolv.conf file for connecting local clients to the
> # internal DNS stub resolver of systemd-resolved. This file lists all
> # configured search domains.
> #
> # Run "resolvectl status" to see details about the uplink DNS servers
> # currently in use.
> #
> # Third party programs must not access this file directly, but only through 
> the
> # symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different 
> way,
> # replace this symlink by a static file or a different symlink.
> #
> # See man:systemd-resolved.service(8) for details about the supported modes of
> # operation for /etc/resolv.conf.
> 
> nameserver 127.0.0.53
> options edns0
> 
> 
> I use the netplan to set 127.0.0.1 as the dns for all interfaces. But
> it seems there are some conflicts on my above configuration. Say, when
> I do the following testing:
> 
> $ dig www.baidu.com
> 
> I always noticed that there will have multiple dnsmasq instances be
> triggered automatically and the resolution will fail.
> 
> So I want to know how to solve the confliction problem between dnsmasq
> and systemd-resolved.

The trick is deciding which DNS is "upstream"



Groeten
Geert Stappers
-- 
Silence is hard to parse

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

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

[Hongyi Zhao]

Hi,

On Ubuntu 20.04, I let dnsmasq listen on 127.0.0.1:53, at the same
time, I also noted that systemd-resolved has a default stub dns
resolver which is listening on 127.0.0.53:53.

And for my case, the /etc/resolv.conf is a symlink as following:

$ realpath -e /etc/resolv.conf
/run/systemd/resolve/stub-resolv.conf

The content of this file is shown as follows:

$ cat /etc/resolv.conf
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.53
options edns0


I use the netplan to set 127.0.0.1 as the dns for all interfaces. But
it seems there are some conflicts on my above configuration. Say, when
I do the following testing:

$ dig www.baidu.com

I always noticed that there will have multiple dnsmasq instances be
triggered automatically and the resolution will fail.

So I want to know how to solve the confliction problem between dnsmasq
and systemd-resolved.

Regards,
-- 
Hongyi Zhao 

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss