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=10000 > 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 <somedomain.com> ANY If that is working as intended, then test Dnsmasq: dig @127.0.0.1 <somedomain.com> ANY If there's still no problem, then test systemd-resolved: dig @127.0.0.53 <somedomain.com> ANY Hopefully, this should help you find the problem. Regards, Dominick _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
