Hide Forgot
Description of problem: I am using the option below to split the DNS setup. $ cat /etc/NetworkManager/conf.d/dns-dnsmasq.conf [main] dns=dnsmasq However, when a VPN is established, the DNS doesn't work. Restarting NetworkManager works around the problem: # killall -SIGHUP NetworkManager Version-Release number of selected component (if applicable): NetworkManager-1.2.4-2.fc24.x86_64 How reproducible: Always Steps to Reproduce: 1. Configure dns=dnsmasq 2. Reboot 3. Establish a VPN (in my case vpnc) Actual results: DNS fails to resolve names. Expected results: DNS to work based on domains.
Created attachment 1200815 [details] log after establishing VPN followed by a SIHGUP
This happens after a fresh boot, so it doesn't seem to be related to suspend/hibernate.
(In reply to Flavio Leitner from comment #2) > This happens after a fresh boot, so it doesn't seem to be related to > suspend/hibernate. Hi, does it happen also the first time you connect to the VPN or only starting from the second (re)connection? If it happens only when reconnecting, I think this is the same as bug 1373485, for which we should soon have a fix in dnsmasq. It this is a different issue, can you please do: echo log-queries > /etc/NetworkManager/dnsmasq.d/log-queries killall -HUP NetworkManager then reproduce the issue and attach the dnsmasq output in the journal when you try to resolve a name? Thanks! In the meanwhile, if you want to avoid the manual SIGHUP at every VPN connection you can use the ugly workaround at: https://bugzilla.redhat.com/show_bug.cgi?id=1338731#c23
(In reply to Beniamino Galvani from comment #3) It happens at the first time. The command to log queries helped. Now I understood what is happening here. My LAN has only one DNS server, so I have configured my internal DNS followed by google DNS (as a fallback) in the IPv4 properties: DNS Servers: 192.168.0.1,8.8.8.8 When the VPN is established, the order changes and the queries are sent to 8.8.8.8 which obviously doesn't know about my LAN addresses. Sep 16 09:40:07 plex dnsmasq[2110]: query[A] osp.home from 127.0.0.1 Sep 16 09:40:07 plex dnsmasq[2110]: forwarded osp.home to 8.8.8.8 When I restart, the order is fixed and everything works. I removed the google's DNS from the config and everything seems to be working just fine. Having said that, I will close this NotABug but I've been using this config for years and only now it became a problem.
Hi Flavio, by default dnsmasq assumes that all upstream servers are equivalent and thus implements its own logic to decide which server to contact if there are multiple ones available. It first sends the query to all knows servers in parallel and then sticks with the first that reponds, retrying all servers after a given amount of time/queries or when the selected one doesn't answer. To obtain a behavior similar to the libc resolver, the 'strict-order' option can be added in a file in /etc/NetworkManager/dnsmasq.d/. With this, dnsmasq will try each supplied server in order. There is also a 'all-servers' option to send all queries to all servers in parallel. We greatly improved dnsmasq support in NM recently, but I don't remember of any change that could have caused the regression you found. Is it possible that the local nameserver is sometimes slower than Google's one and so dnsmasq selects it for the next 20 seconds?