Hide Forgot
User-Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:48.0) Gecko/20100101 Firefox/48.0 Build Identifier: I mainly work off the following network configuration: - Wi-Fi connection to home network - VPN connection over the Wi-Fi to the Red Hat VPN This works fine - I haven't seen any DNS problems with this regular setup, with both public internet and Red Hat internal DNS lookups working fine. However, my ISP's DNS servers have been flaky lately, so I added Google's DNS servers to the Wi-Fi connection as additional ones to check. When I do this, name resolution for "redhat.com" domains breaks entirely, regardless of whether the servers are public or not. Removing the Google DNS servers from the Wi-Fi connection and disconnecting and reconnecting to the network isn't enough to restore correct behaviour, I have to restart the machine (this part sounds a lot like https://bugzilla.redhat.com/show_bug.cgi?id=1338731 or https://bugzilla.redhat.com/show_bug.cgi?id=1373485 though) Reproducible: Always Steps to Reproduce: 1. Connect to Wi-Fi and VPN as usual 2. Notice ISP DNS being flaky, so add Google DNS servers to the "Other DNS Servers" setting in the Wi-Fi connection's IPv4 tab 3. Disconnect & reconnect the Wi-Fi and then reconnect to the VPN Actual Results: * Name resolution for redhat.com domains no longer works * "dig bugzilla.redhat.com +trace" reports that it can't even find ns[1-4].redhat.com Expected Results: redhat.com name resolution still works for both public and private domains, even after the Google DNS settings are added to the Wi-Fi connection - I've filed this against dnsmasq, as this system was upgraded from Fedora 23 (in turn upgraded from 22), and neither unbound nor dnssec-trigger are installed, while dnsmasq is listening locally on port 53: tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 9407/dnsmasq So this system isn't using the default setup described in https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver and the problem I'm having sounds a lot like the discussion in https://bugzilla.redhat.com/show_bug.cgi?id=1338731 which resulted in https://bugzilla.redhat.com/show_bug.cgi?id=1373485 being filed against dnsmasq - I don't know enough about what's happening to know if the problem I'm seeing and https://bugzilla.redhat.com/show_bug.cgi?id=1373485 might have a common cause - I also found https://bugzilla.redhat.com/show_bug.cgi?id=1327555 but that seems specific to the new default config in F24, rather than systems using dnsmasq as the local resolver - there's a separate instance of dnsmasq running for docker's benefit (see http://stackoverflow.com/questions/35693117/how-can-i-give-docker-containers-access-to-a-dnsmasq-local-dns-resolver-on-the-h ) but that should be properly isolated from the default instance handling normal lookups
Component versions: $ rpm -qa dnsmasq NetworkManager dnsmasq-2.76-1.fc24.x86_64 NetworkManager-1.2.4-2.fc24.x86_64
Since initially filing this, I've been able to confirm that everything starts working properly if I restart the laptop after changing the Wi-Fi DNS resolution settings such that the system comes up with the fallback to Google DNS already configured. That suggests that the problem is specifically with dnsmasq's ability to react to DNS config changes in the running network configuration, rather than with its ability to handle this particular configuration in general.
Encountered this again today while testing out a switch from vpnc to OpenVPN as the VPN connector - after dropping the vpnc connection and starting the OpenVPN one, name resolution for internal URLs didn't work. While "sudo systemctl restart dnsmasq" didn't help, doing "sudo systemctl restart NetworkManager" *did* - the Wi-Fi reconnected automatically, and then internal DNS worked as expected after bringing up the OpenVPN connection again. Also, a clarification on how I can be confident "unbound" isn't at fault here: it's not installed, and netstat reports: $ sudo netstat -tunlp | grep 'tcp.*:53' tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 24771/dnsmasq tcp 0 0 172.17.0.1:53 0.0.0.0:* LISTEN 13793/dnsmasq tcp6 0 0 fe80::42:66ff:fe8f:c:53 :::* LISTEN 13793/dnsmasq
Attempting to access an internal resource without connecting to the VPN first provided a useful opportunity to investigate this problem further, and I've changed the title of the issue accordingly. Precise sequence of events: 1. Attempted to access internal resource 2. DNS lookup failed (as expected, since I wasn't on the VPN) 3. Connected to VPN 4. DNS lookup still failed, presumably due to caching of the result in (2) 5. Disconnected from WiFi entirely 6. Reconnected to both WiFi and VPN 7. DNS lookup still failed, presumably due to caching of the result in (2) 8. Restarted NetworkManager as described in previous comment 9. Reconnected to both WiFi and VPN 10. DNS lookup for internal resource now works
which vpn technology/plugin are you using? NetworkManager-libreswan? vpnc? openvpn?
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
The original problems were with vpnc, but I later saw them with openvpn as well. The step-by-step case in https://bugzilla.redhat.com/show_bug.cgi?id=1374693#c4 was after the switch to openvpn.
This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '24'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 24 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.