| Summary: | DNS negative lookup cache not being invalidated when activating new network connections | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Nick Coghlan <ncoghlan> |
| Component: | dnsmasq | Assignee: | Petr Menšík <pemensik> |
| Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 24 | CC: | drjohnson1, itamar, laine, pj.pandit, pwouters, thozza, veillard |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-08-08 17:13:03 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Nick Coghlan
2016-09-09 12:45:59 UTC
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. |