Description of problem: Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Sorry for the empty initial comment, I somehow hit "send" by accident too early. Anyway, NM currently writes both the VPN's and the (w)lan's DNS servers to /etc/resolv.conf, when it is connected to both, and the (w)lan is used as transport for the VPN. It will put the VPN DNS servers first, and the (w)lan DNS servers second, currently. This is something I'd like you to change, I think only the VPN DNS servers should be listed. The rationale for this is the way DNS resolvers work: they one-by-one go through the list of DNS servers and contact each one until they find one that responds. Then, they stay with that one for future lookups. In glibc, this state machine is kept within each process, as the DNS resolver is implemented directly in the library. In such an NM setup as described this will thus usually result in the first DNS VPN server being used most of the time, and only if that VPN DNS server fails once, the state machine will proceed to the next one. Finally, after all VPN DNS servers failed to respond, the one of the wlan is tried. Now, this means that DNS names only resolvable via the VPN will usually work fine, and only after all VPN DNS servers failed once the logic will proceed to the w(lan) DNS server, were then suddenly the VPN names are not resolvable anymore. Now, as this stays local to the process, and dropped replies are not very frequent this usually has no impact. However, we are currently working on a local caching DNS resolver that is run as a tiny daemon (systemd-resolved). It does the state logic described above in a daemon that is shared between all processes of the host. it might thus happen much more likely that the we start talking to the w(lan) DNS server and no VPN names are resolvable anymore, system-wide for a long time. Hence, I'd like to ask you to only write the DNS servers that should be authoritative with the highest priority into /etc/resolv.conf. Do not mix DNS servers of different authoritativeness priorities into the same resolv.conf, since then a single lost packet might result in a different set of names to be resolvable, and that's not desirable. The current logic of NM is particularly a problem for resolved, but I'd argue it's already broken for the glibc resolver too, just not as visibly.
Hi Lennart. I think what you're proposing should be OK in the current situation. However, I would like to share a few things we ran into while working on dnssec-trigger. NM currently supports setting where VPN is used only for resources on that network. In this case we (me, Pavel Simerda, Petr Spacek, ...) think that also DNS servers from VPN should be used only for resolving names from that network. I admit this can be hard to do and may be even impossible (if the VPN server doesn't provide any domains). Another thing is DNSSEC. Once you decide to use DNSSEC on the client, you should do the validation whenever possible. In case the (w)lan-provided DNS resolvers are capable of providing all the necessary data for DNSSEC validation, but the VPN-provided DNS servers are not capable of providing such data, you should prefer the "DNSSEC enabled" ones for the global name resolution. In this situation using only VPN-provided DNS servers would break the name resolution (since the DNSSEC validation would fail). We have an idea how to solve this, but didn't implement it yet. I'm not sure how far you are with the DNSSEC support in resolved, but you may want to keep these situations in mind when doing some design decisions.
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 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.