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.