Enable systemd-resolved and use as default resolver#288
Enable systemd-resolved and use as default resolver#288darkmuggle wants to merge 1 commit intocoreos:testing-develfrom darkmuggle:feature/systemd-resolved
Conversation
|
This is a WIP idea, that I wanted to put out there for discussion. This allows the system to use scoped resolvers. I'm not sure if this is a great idea -- or ifs been discussed -- but I gave it a shot while digging into the way that FCOS's networking works. |
| [main] | ||
|
|
||
| # Send the connection DNS configuration to systemd-resolved. | ||
| systemd-resolvd=true |
There was a problem hiding this comment.
Typo: systemd-resolved=true
(according to https://developer.gnome.org/NetworkManager/stable/NetworkManager.conf.html)
| systemd-resolvd=true | ||
|
|
||
| # Use systemd-resolved for name resolution. | ||
| dns=systemd-resolved |
There was a problem hiding this comment.
According to your commit message, it sounds like you'd want the auto-detect behavior of leaving dns= unspecified.
|
@darkmuggle not against this, but I fear we may be overly optimistic. I think the bug you are implicitly referencing is coreos/fedora-coreos-tracker#393. That one is about initramfs networking, where we (currently) don't run NM. So I guess that:
|
|
Yeah, I think the first step is to switch to NM in the initrd and see where we land. That specific issue may melt away entirely. |
That would be ideal. I threw this out for consideration and debate. I anticipate leaving this as a draft, until after NM in the initrd. |
|
As a data-point, Container Linux has been using systemd-resolved for a long time. I don't remember huge issues/regression or user friction with it, but there have been some CVEs in the past. However, it was used in its natural ecosystem (networkd+timesyncd+resolved), not on the side of NM. |
|
Discussed this with a member of the NM team. They pointed out that systemd-resolved is the best way to do DNS configuration and it is recommended to use it with NM. It also may become the default in the rest of Fedora (context). |
|
Hi everyone, as suggested by @dustymabe on IRC, I would add my use-case to this draft. systemd-resolved partially support DoT since v239 and fully support it since v243. |
When booting with DHCP6 and DHCP4, the most recent DHCP response will overwrite /etc/resolv.conf. By using systemd-resolved, we get ability to have scoped DNS resolvers. To keep the NetworkManager configurations in the same place, the overlay.d directory has been renamed. In the event a user does not want to use systemd-resolved, they can easily disable it by: - replacing /etc/resolv.conf with their own - populate a new /etc/NetworkManager/conf.d/99-user with: [main] dns=default systemd-resolved=false
|
Closing this a stale. The idea may be desirable for our users, but as @lucab pointed out the motivation on this is moot. If the group wants this to be continued, I can re-open after its been tested again. |
|
FWIW: https://fedoraproject.org/wiki/Changes/systemd-resolved So any subtle compatibility bug between systemd-resolved and NM will likely be shaken out if this goes forward. |
|
@jlebon do you think it's worth implementing for |
|
I would still push for this one on my own as I'm still blocked with the DTLS implementation for now and as it's a worthy security measure. |
|
See ongoing discussion in #575 |
6 participants
When booting with DHCP6 and DHCP4, the most recent DHCP response will
overwrite /etc/resolv.conf. By using systemd-resolvd, we get ability to
have scoped DNS resolvers.
To keep the NetworkManager configurations in the same place, the
overlay.d directory has been renamed.
In the event a user does not want to use systemd-resolved, they can
easily disable it by:
[main]
dns=default
systemd-resolved=false