Description of problem: Followed directions for testing on f23 https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver#How_To_Test did this: $ sudo dnf install dnssec-trigger and this: If you use NetworkManager, configure it to use unbound. Add the following line into /etc/NetworkManager/NetworkManager.conf dns=unbound not this: Enable and start dnssec-trigger $ sudo systemctl enable dnssec-triggerd.service did this: $ # disable and stop any existing DNS service, e.g., dnsmasq sudo killall dnsmasq (I didn't see any other way to stop it) did this: $ sudo systemctl start dnssec-triggerd.service Stopped/started enet interface via NetworkManager to make sure dhcp got run. results: host slashdot.org: works fine host nbecker7.hns.com: doesn't work This is on the private dns which is supposed to be supplied from dhcp. possibly relevant: Dec 2 07:17:30 nbecker2 NetworkManager[841]: <info> Policy set 'enp0s25' (enp0s25) as default for IPv4 routing and DNS. Dec 2 07:17:30 nbecker2 NetworkManager[841]: <warn> could not commit DNS changes: Could not replace /etc/resolv.conf: Operation not permitted Dec 2 07:17:30 nbecker2 NetworkManager[841]: <info> (enp0s25): Activation: successful, device activated. perhaps it's necessary to also restart NetworkManager so that it re-reads the change to NetworkManager.conf? How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Tried again - this time NetworkManager had re-started and so re-read the change to NetworkManager.conf Almost works: [nbecker@nbecker2 log]$ host slashdot.org slashdot.org has address 216.34.181.45 slashdot.org mail is handled by 10 mx.sourceforge.net. [nbecker@nbecker2 log]$ host nbecker7.hns.com Host nbecker7.hns.com not found: 3(NXDOMAIN) [nbecker@nbecker2 log]$ host nbecker7 Host nbecker7 not found: 3(NXDOMAIN) [nbecker@nbecker2 log]$ host nbecker7.hughes.com nbecker7.hughes.com has address 10.32.112.121 [nbecker@nbecker2 log]$ domainname (none) So looks like problem is domainname isn't set
dnssec-trigger does not touch the domainname. I would say that things work as expected, based on comment #1. Do you have any specific issue you see after restarting NetworkManager and it worked before?
Sorry, I mispoke. The issue is not domainname, it's the domain search list. Previously this was supplied by dhcp, and set in resolv.conf. Now it isn't. For example, previously, resolv.conf says: # Generated by NetworkManager search hughes.com. hns.com. md.hnsnet. md.hns.com. ca.hnsnet. backups.hnsnet. nameserver 10.33.41.30 So yes, this is an issue that must be resolved. Perhaps the problem is due to Dec 2 07:17:30 nbecker2 NetworkManager[841]: <warn> could not commit DNS changes: Could not replace /etc/resolv.conf: Operation not permitted
(In reply to Neal Becker from comment #3) > Sorry, I mispoke. The issue is not domainname, it's the domain search list. > Previously this was supplied by dhcp, and set in resolv.conf. Now it isn't. This is intentional. Domain search list supplied by DHCP can not be trusted and therefore it is ignored. If you need some search domains to be set in resolv.conf, you have to set the 'search' option in /etc/dnssec-trigger/dnssec-trigger.conf. The reasoning is that any DHCP server can send you any search domains list (and this can be even intercepted by an attacker, because DHCP is not secure) and it would make your traffic to go elsewhere for domain names that are not FQDN. > For example, previously, resolv.conf says: > # Generated by NetworkManager > search hughes.com. hns.com. md.hnsnet. md.hns.com. ca.hnsnet. backups.hnsnet. > nameserver 10.33.41.30 > > > So yes, this is an issue that must be resolved. Perhaps the problem is due > to > Dec 2 07:17:30 nbecker2 NetworkManager[841]: <warn> could not commit DNS > changes: Could not replace /etc/resolv.conf: Operation not permitted No. This is expected, if you don't use 'dns=unbound' or 'dns=none' in /etc/NetworkManager/NetworkManager.conf. Dnssec-trigger sets the immutable attribute on the /etc/resolv.conf so that it is the only service that can modify it. If the search domains list is the only thing that was not working for you, I'll update the documentation on Fedora Wiki and close this as NOTABUG.
So on my laptop, which moves to different locations, how are different search lists going to be set, depending on location?
search lists should have never been changed based on DHCP. That's a security bug. In fact, I've experienced the opposite lately, where my laptop which has a search list of nohats.ca libreswan.org _did_ get mangled by useless search domains from coffeeshops. Again, I think this is a feature that belongs in the "user said this is a "trusted connection" and so then it will pick up the DHCP search list. This is related to NM in general and not to the DNS feature.
Are you suggesting that user should be able to specify search list in NM under IPV4 tab? If so, I tried that and it doesn't work. I have the line dns=unbound in NetworkManager.conf I restarted NM and dnssec-triggerd resolv.conf is immutable So how is this supposed to work exactly?
(In reply to Neal Becker from comment #7) > Are you suggesting that user should be able to specify search list in NM > under IPV4 tab? Not really, since AFAIK there is no way to tell from NM API, if the search domain was set by user or if it came from DHCP. But I may be wrong and in that case we could add this. > If so, I tried that and it doesn't work. > I have the line > dns=unbound > in NetworkManager.conf > > I restarted NM and dnssec-triggerd > > resolv.conf is immutable > > So how is this supposed to work exactly? As I said before, you can set the search domains in dnssec-trigger.conf statically for all networks or else you won't have any search domain set on any network.
I'm testing this, but no luck. I added search: "hughes.com" to /etc/dnssec-trigger/dns-trigger.conf, but seems to have no effect. Restarted dns-trigger. But: # Generated by dnssec-trigger-script nameserver 127.0.0.1 And host nbecker7 Host nbecker7 not found: 3(NXDOMAIN)
(In reply to Neal Becker from comment #9) > I'm testing this, but no luck. > > I added > search: "hughes.com" > > to /etc/dnssec-trigger/dns-trigger.conf, but seems to have no effect. > Restarted dns-trigger. But: > > # Generated by dnssec-trigger-script > nameserver 127.0.0.1 > > > And > host nbecker7 > Host nbecker7 not found: 3(NXDOMAIN) Yes, this is a regression added by the change making the daemon to use the dnssec-trigger-script for writing out the resolv.conf. This would need to be changed.
(In reply to Tomas Hozza from comment #10) > (In reply to Neal Becker from comment #9) > > I'm testing this, but no luck. > > > > I added > > search: "hughes.com" > > > > to /etc/dnssec-trigger/dns-trigger.conf, but seems to have no effect. > > Restarted dns-trigger. But: > > > > # Generated by dnssec-trigger-script > > nameserver 127.0.0.1 > > > > > > And > > host nbecker7 > > Host nbecker7 not found: 3(NXDOMAIN) > > Yes, this is a regression added by the change making the daemon to use the > dnssec-trigger-script for writing out the resolv.conf. Sounds likely. I wasn't aware of the 'search:' option to be honest.
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. 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 '23'. 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 23 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 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 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.
I still see this problem on F24, wasn't this fixed?
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle. Changing version to '26'.
This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle. Changing version to '28'.
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. 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 '28'. 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 28 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.
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to 31.
The problem still persists in Fedora 31.
The solution to the problem is to configure the UNDOCUMENTED `/etc/dnssec.conf` file with the value `set_search_domains=yes`. From that point on the config values in `/etc/dnssec-trigger/dnssec-trigger.conf` are not ignored anymore. This twofold configuration is not only confusing, but undocumented, it has to be reverse engineeered currently from the script `/usr/libexec/dnssec-trigger-script`
This message is a reminder that Fedora 31 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-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 '31'. 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 31 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 31 changed to end-of-life (EOL) status on 2020-11-24. Fedora 31 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.