Description of problem: While configuring network using dhcp, NetworkManager creates resolv.conf file, which contains wrong "search" line. The log contains -- begin quote -- Dec 13 21:54:23 avangard.maison NetworkManager[791]: <debug> [1481640863.5639] dhcp4 (wlo1): DHCP reason 'REBOOT' -> state 'bound' Dec 13 21:54:23 avangard.maison NetworkManager[791]: <info> [1481640863.5640] dhcp4 (wlo1): address 10.0.0.16 Dec 13 21:54:23 avangard.maison NetworkManager[791]: <info> [1481640863.5640] dhcp4 (wlo1): plen 24 (255.255.255.0) Dec 13 21:54:23 avangard.maison NetworkManager[791]: <info> [1481640863.5641] dhcp (wlo1): static route 192.168.1.0/24 via 10.0.0.4 metric 600 mss 0 src dhcp Dec 13 21:54:23 avangard.maison NetworkManager[791]: <info> [1481640863.5641] dhcp (wlo1): static route 172.20.0.0/16 via 10.0.0.1 metric 600 mss 0 src dhcp Dec 13 21:54:23 avangard.maison NetworkManager[791]: <info> [1481640863.5641] dhcp4 (wlo1): gateway 10.0.0.254 Dec 13 21:54:23 avangard.maison NetworkManager[791]: <info> [1481640863.5641] dhcp4 (wlo1): server identifier 10.0.0.1 Dec 13 21:54:23 avangard.maison NetworkManager[791]: <info> [1481640863.5641] dhcp4 (wlo1): lease time 86000 Dec 13 21:54:23 avangard.maison NetworkManager[791]: <info> [1481640863.5641] dhcp4 (wlo1): nameserver '10.0.0.1' Dec 13 21:54:23 avangard.maison NetworkManager[791]: <info> [1481640863.5641] dhcp4 (wlo1): domain name 'maison' Dec 13 21:54:23 avangard.maison NetworkManager[791]: <info> [1481640863.5641] dhcp (wlo1): domain search 'maison.' Dec 13 21:54:23 avangard.maison NetworkManager[791]: <info> [1481640863.5641] dhcp (wlo1): domain search 'binp.gcf.' Dec 13 21:54:23 avangard.maison NetworkManager[791]: <info> [1481640863.5641] dhcp4 (wlo1): state changed unknown -> bound -- end quote -- It correctly lists "domain search 'maison.'" and "domain search 'binp.gcf.'" options. However, the resulting resolv.conf file looks like # Generated by NetworkManager search binp.gcf avangard.maison nameserver 10.0.0.1 instead of expected ... search maison binp.gcf ... Version-Release number of selected component (if applicable): NetworkManager-1.4.2-2.fc25.x86_64 How reproducible: Always Steps to Reproduce: 1. Have dhcp server with option domain-search "maison", "binp.gcf"; in config. 2. Set up network with NM using dhcp Actual results: shown above. Expected results: shown above. Additional info: dhclient, if run it manually, forms correct resolv.conf.
(In reply to z117 from comment #0) > Description of problem: > While configuring network using dhcp, NetworkManager creates resolv.conf > file, which contains wrong "search" line. Hi, I'm unable to reproduce the issue. Can you please set level=TRACE in the [logging] section of /etc/NetworkManager/NetworkManager.conf, do a 'systemctl restart NetworkManager' and attach the journal log of NM from the restart ('journalctl -u NetworkManager -b')? Thanks!
Created attachment 1231759 [details] requested NetworkManager log at TRACE level
I've played a little with my dhcp server and discovered that NetworkManager gets domains just right except the "maison" domain. The latter is always ignored, and the hostname "avangard.maison" is always added at the end of "search" line in resolv.conf.
The root cause is that .maison is a TLD [1] and so NM refuses to put it in resolv.conf due to this check: https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/dns/nm-dns-manager.c#n308 I think that your own internal DHCP server shouldn't distribute a top level domain in the search list, as this is going to create resolution conflicts. [1] https://git.gnome.org/browse/libsoup/commit/?id=56850c441625cb7d57c6746dc6780aeba93930ac
So as far as I understood, libsoup implemented recently a list of "good" TLDs and now marks everything else invalid? Why? I do want to have my local TLD (as I used to for many years). Imagine my localnet have no internet connection at all. Should than the bug be readressed to libsoup? Anyhow, I see no reason why the hostname appears in the resolv.conf.
(In reply to z117 from comment #5) > So as far as I understood, libsoup implemented recently a list of "good" > TLDs and now marks everything else invalid? Correct, NM already did this check before but 'maison' was not in the known TLDs list provided by libsoup and thus it was accepted. > Why? The check is to prevent a DNS hijack from a malicious DNS server. See bugs [1], [2], [3] for a detailed explanation. [1] https://bugzilla.gnome.org/show_bug.cgi?id=729137 [2] https://bugzilla.redhat.com/show_bug.cgi?id=812394 [3] https://bugzilla.redhat.com/show_bug.cgi?id=851521 > I do want to have my local TLD (as I used to for many > years). Imagine my localnet have no internet connection at > all. Should than the bug be readressed to libsoup? No, libsoup only provides the list of known TLDs here. NM uses that list to check whether the search domain can be added to resolv.conf. I think your use case is valid (especially because today the list of TLDs is very long and the risk of conflicts is high [4]), but we should try to find a way to support it without reintroducing the security vulnerability described above. [4] https://data.iana.org/TLD/tlds-alpha-by-domain.txt > Anyhow, I see no reason why the hostname appears in the resolv.conf. It's still to prevent .maison to be used as a search domain.
> All right, could I we should try to find a way to support it without reintroducing the security vulnerability described above. Could I be of any help? Is there any workaround?
Probably we can add a new global configuration option ('dns-search-tld=yes|no', no is default) that allows user to override this check and use a public suffix in the search list. But any other idea is welcome...
Another variant would be to have an additional list of allowed TLDs.
I've re-read all the comments and now I think I got the understanding. My local "maison" domain is blocked because it _IS_ included in the list of known TLDs. The reason is to prevent "domain hijack" which technically really takes place in my case - I'm using "maison" TLD owned by someone in the Internet. Then the most logical solution would be, in my opinion, to implement a configuration option (say, 'allow-local-tld=yes|no', no is default) not as a global one, but for each known connection separately, and then it could be activated only for connection(s) known to be safe (like my localnet).
I oppose introduction of a configuration knob for what can reasonably be considered a misconfiguration and has very marginal consequences (obviously, a FQDN can be used as a workaround). It's not all that difficult to get and configure a proper domain name. If you're not willing to, a safe bet would be to use a ".lan" TLD, which, despite neither a standard nor a good idea, seems to be the common practice with consumer hardware. Just configure your DHCP server to announce "maison.lan" in place of "maison" and you're done.
Well, I personally would not object to close the bug report as "NOTABUG". Sure I had immediately changed "maison" to "local". However adding the host FQDN to search domains to patch the security hole seems like a dirty hack to me. I mean, perhaps this is not a standard behaviour. (And the hole is not that big...) And if marking this report as NOTABUG, one should immediately submit the similar bug report for the plain dhclient.
I have a similar issue with my internal domain: my home pc, laptop, router (which is a dhcp server also) and a couple of virtual machines have been set up to belong to domain .dexpl. These hosts get their resolv.conf populated with 'search dexpl' — all of them except for a F26 installation. As far as I know, .dexpl is not a gTLD.
Also getting this on Debian testing - after updating NM to 1.8 my "haven" domain none of the machines with 1.8 get "haven" in the search domain. I'm personally on the side of "revert the change" as I suspect there are more of us that have our own domains and while the change makes sense, it stays too far into "paranoid security" territory (does any other OS do this? Not to my knowledge). It might be possible to carry a list of TLDs (or common ones) and use that? At the very least, an option is preferable for me (and many others) to any of * Patching NM, and distributing the patch to each machine, each time an update comes through * Running something other than NM * Changing my domain, which would be many (possibly 100+) individual configuration changes
This is really unexpected behavior - have been using a fake TLD for my internal network forever. It never gets seen beyond my network. As mentioned above lots and lots of people likely have a setup like this. dhcp / NM and dns search worked fine till a F26 update today on one machine.
Created attachment 1298161 [details] [PATCH] dns: perform the public-suffix check only for the hostname-derived domain
the tld I use in my lab (ldev) is not on the list, but still ignored.
I use ".home" as tld (and have been for year) which is not not on the list as well. Worked in F25 and is now ignored by NM.
Hmm... ".local" doesn't seem to work either.
Hi, I have prepared the a scratch build with the patch from comment 16: https://koji.fedoraproject.org/koji/taskinfo?taskID=20571858 Please download the RPMs there, then do: rpm -Fvh *.rpm systemctl restart NetworkManager and check if the issue is still present. Thanks!
*** Bug 1470966 has been marked as a duplicate of this bug. ***
Solves my problem. Thanks for the fix!
(In reply to Beniamino Galvani from comment #16) > Created attachment 1298161 [details] > [PATCH] dns: perform the public-suffix check only for the hostname-derived > domain lgtm
Confirmed working on a VM with fresh F26 install (wired), and on a laptop with F25->F26 upgrade (wireless).
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.