Created attachment 1103782 [details] Lightly-sanitized results of "journalctl -b -u NetworkManager -u dnssec-triggerd -u unbound" Description of problem: I followed the directions at https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver#How_To_Test on a Fedora 22 laptop. My network domain is DNSSEC-protected and split DNS, with a private and public view, both of which are signed. DHCP(v6) offer DNS resolvers that are running bind-9.10.2-5.P4.fc22.x86_64. These resolvers present a private view when accessed via internal IP addresses and a public view when accessed via external IP addresses. The addresses presented by DHCP(v6) are internal addresses, so if these addresses are used, the laptop should get the private view. After booting my laptop today, I found that DNS lookups were using my domain's public view instead of the private view. After disabling WiFi & re-enabling it, DNS lookups used my private view as expected. I'm not sure which component to file this against, as I suspect it may be a race condition in the interactions between components (based on the logs), but the Change page says to file against dnssec-trigger, so that's what I went with. Version-Release number of selected component (if applicable): dnssec-trigger-0.13-0.1.20150714svn.fc22.x86_64 NetworkManager-1.0.6-8.fc22.x86_64 unbound-1.5.6-1.fc22.x86_64 How reproducible: I'm not sure -- I've just tried the one boot so far. If this matters, I can provide more detailed information as I boot the laptop over time. Steps to Reproduce: 1. Boot the PC from a cold start in range of an already-configured WiFi network providing the private view of a DNSSEC-protected split DNS zone (both views signed) 2. Observe that lookups use the public zone after connection 3. Disable and re-enable the network connection 4. Observe that lookups use the private zone after connection Actual results: The public view is used (apparently) due to timeouts while the system is starting. The private view is used after disconnecting and reconnecting from the network. Expected results: The private view is used, every time. Additional info: I'm attaching the lightly-sanitized results of "journalctl -b -u NetworkManager -u dnssec-triggerd -u unbound" You can see the log results from startup, after disabling the WiFi, and after re-enabling the WiFi.
can you show the output of sudo unbound-control list_forwards normally, that should contain a forwarder for "." (the root) to one of your DHCP supplied DNS servers, which would be internal, and so things should work? Another check you can do is running: sudo dnssec-trigger-control status which will show the results of the last probe and could have a hint about what happened.
Sorry it took me a while to get back to you, as soon as you gave me those commands to try, it stopped happening until today. Looking at my logs, I've booted 9 times since enabling dnssec-triggerd and only 3/9 of those boots came up with the external view (so far). Anyway, the output you were looking for: $ sudo unbound-control list_forwards $ sudo dnssec-trigger-control status at (no probe performed) no cache: no DNS servers have been supplied via DHCP state: auth secure Hope this helps!
So it seems NetworkManager is telling dnssec-trigger hooks that it did not get any DNS servers from DHCP. When this happens next, can you check with nmcli if it lists DNS servers? This is either an issue in NM lying to dnssec-trigger, or dnssec-trigger misreading NM.
Created attachment 1111683 [details] Requested information for various boots See attachment for the journalctl and requested command output for various connections to my network. I tried to get enough samples with consistent structure so that you can diff between good & bad, etc. My naming isn't perfectly consistent, but hopefully the timestamps should make things fairly clear.
This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle. Changing version to '25'.
This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. 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 '25'. 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 25 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 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 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.