Re: [Dnsmasq-discuss] Avoid conflicts between dnsmasq and systemd-resolved.
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
Re: [Dnsmasq-discuss] Avoid conflicts between dnsmasq and systemd-resolved.
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.
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
Re: [Dnsmasq-discuss] Incorrect response for DNAME'd records in dnsmasq 2.80+
On Mon, Sep 14, 2020 at 11:23:44AM -0700, James Brown wrote: > That is fantastic, Dominick! > > I'm testing now, but in preliminary testing, this patch appears to fix the > DNAME issue for me. OK. Acknowledge. Thursday night (CEST, UTC+2) I'll retransmit the patch + "Tested-by" ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Incorrect response for DNAME'd records in dnsmasq 2.80+
That is fantastic, Dominick! I'm testing now, but in preliminary testing, this patch appears to fix the DNAME issue for me. On Sun, Sep 13, 2020 at 10:03 PM Dominick C. Pastore < dominickpast...@dcpx.org> wrote: > This caught my eye because it's similar to a bug I noticed in 2.80. See > (and ignore the first half of the message about CNAMEs; that was an > unrelated issue): > http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2019q4/013483.html > > It sounds like that was essentially the same issue, but without DNAMEs. It > turned out it had already been fixed but the fix hadn't been released yet > at the time: > > http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=162e5e0062ce923c494cc64282f293f0ed64fc10 > > That fix was eventually in 2.81, but it looks like it misses the cases > where the NXDOMAIN reply contains a CNAME or DNAME. > > I've attached a patch that hopefully fixes this, but word of warning: I've > only been able to verify that it fixes the CNAME case, not the DNAME case. > I don't think it breaks the intended functionality from b6f926f, but I will > admit, I don't feel familiar enough with the inner workings of Dnsmasq to > verify that myself. > > Regards, > Dominick > > On Fri, Sep 11, 2020, at 7:53 PM, James Brown wrote: > > Just wanted to bump this thread since this is still kind of a > show-stopper for anyone that uses DNAMEs heavily. Any thoughts on how to > fix? > > > > On Wed, Jul 29, 2020 at 12:16 PM James Brown > wrote: > >> Indeed, that's the commit that did it. > >> > >> I'm not sure why that change has any effect for DNAMEs, though (which > are not being generated internally to dnsmasq)... > >> > >> On Wed, Jul 29, 2020 at 12:07 PM Geert Stappers > wrote: > >>> On Wed, Jul 29, 2020 at 11:23:17AM -0700, James Brown wrote: > >>> > I'm upgrading some test nodes in my employer's cluster from 2.78 to > 2.82 > >>> > and handling of DNAMEs in the new version seems different (and > wrong). > >>> > > >>> > The setup: > >>> > > >>> > local.mycompany.net is a DNAME to local-.mycompany.net, with > >>> > authoritative resolvers in each datacenter serving a different DNAME > record > >>> > prod.mycompany.net is an unrelated domain > >>> > > >>> > /etc/resolv.conf contains the line > >>> > > >>> > search local.mycompany.net prod.mycompany.net > >>> > > >>> > Imagine searching for the bare-word "foo", which is defined in > >>> > prod.mycompany.net but nowhere else. > >>> > > >>> > Under dnsmasq 2.78, querying for the bare name "foo" using the system > >>> > resolver will correctly first attempt to query for " > foo.local.mycompany.net", > >>> > get back a DNAME to foo.local-dcname.mycompany.net, then get an > empty > >>> > response with the NXDOMAIN code; that will fail, and glibc will then > query " > >>> > foo.prod.mycompany.net", which is the correct record. > >>> > > >>> > Under dnsmasq 2.82, querying for the bare name "foo" using the system > >>> > resolver will correctly first attempt to query for " > foo.local.mycompany.net", > >>> > get back a DNAME to foo.local-dcname.mycompany.net, gets back an > empty > >>> > response with the NOERROR code. This causes the system resolver to > stop > >>> > trying new search domains. This behavior seems to be dependent on > caching; > >>> > the first request correctly returns NXDOMAIN but subsequent requests > return > >>> > NOERROR. There's actually something more confusing to it than this; > if the > >>> > first request is for A, then subsequent requests return NOERROR > but > >>> > subsequent A requests return NXDOMAIN. Some kind of weird cache > poisoning > >>> > between record types? > >>> > > >>> > I bisected this in git and this behavioral change was introduced in > >>> > commit b6f926fbefcd2471699599e44f32b8d25b87b471. > >>> > >>> $ git log b6f926fbe...b6f926fbe^1 > >>> commit b6f926fbefcd2471699599e44f32b8d25b87b471 > >>> Author: Simon Kelley > >>> Date: Tue Aug 21 17:46:52 2018 +0100 > >>> > >>> Don't return NXDOMAIN to empty non-terminals. > >>> > >>> When a record is defined locally, eg an A record for > one.two.example then > >>> we already know that if we forward, eg an query for > one.two.example, > >>> and get back NXDOMAIN, then we need to alter that to NODATA. This > is handled > >>> by check_for_local_domain(). But, if we forward two.example, > because > >>> one.two.example exists, then the answer to two.example should also > be > >>> a NODATA. > >>> > >>> For most local records this is easy, just to substring matching. > >>> for A, and CNAME records that are in the cache, it's more > difficult. > >>> The cache has no efficient way to find such records. The fix is to > >>> insert empty (none of F_IPV4, F_IPV6 F_CNAME set) records for each > >>> non-terminal. > >>> > >>> The same considerations apply in auth mode, and the same basic > mechanism > >>> is used there too. > >>> > >>> > >>> Regards > >>> Geert Stappers > >>> -- > >>> Silence is
Re: [Dnsmasq-discuss] Avoid conflicts between dnsmasq and systemd-resolved.
> > 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.
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
[Dnsmasq-discuss] [PATCH] Disable *.info and *.bind zones with runtime configuration option
Hi, I noticed disabling responses to *.info and *.bind chaos txt queries can only be done by recompiling with the NO_ID flag. I'm using a binary distribution of dnsmasq and cannot easily recompile. In any case, it seems useful to make this configurable at runtime. 0001-Add-no-id-flag-that-works-like-NO_ID-compile-flag-di.patch Description: Binary data ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
