#2381 F33 System-Wide Change: systemd-resolved
Closed: Accepted 23 days ago by ignatenkobrain. Opened a month ago by bcotton.

Enable systemd-resolved by default. glibc will perform name resolution using nss-resolve rather than nss-dns.


I think this is a great change ;) Nevertheless, as a person directly involved in the implementation, I'll abstain from voting.

Some issues were raised on the mailing list, in particular the handling of local DNSSEC requests when the DNSSEC support is off in resolved, and the request for non-rfc-conformant routing of single-label names. In both cases turning off resolved as the server specified in /etc/resolv.conf or fully disabling resolved is an easy work-around. Both of those issues impact specialized users, and using a work-around is IMHO OK. Additionally, we are looking into those issues upstream, but I don't think any upstream change should be treated as a prerequisite.

After a week+ I count the vote as (0, 1, -0). Waiting for additional votes.

Counting (+2, 1, -0) after ~9 days, waiting for more votes.

What will a new /etc/resolv.conf file look like under this proposal? That is, how would I change my nameservers manually if I wanted to?

/etc/resolv.conf will be a symlink to /run/systemd/resolve/stub-resolv.conf by default. If you want to control it manually, just delete it and create a new /etc/resolv.conf that's not a symlink. Then systemd-resolved will switch to consuming the file rather than providing it, and use what you specify there.

I am currently -1 on this proposal as described right now. I think it's needlessly invasive.

I'd rather see a proposal where systemd-resolved is listening on localhost:53 and the default /etc/resolv.conf simply points there. As designed right now, it will be incredibly difficult to disable it if you need to.

Metadata Update from @sgallagh:
- Issue tagged with: meeting

a month ago

As designed right now, it will be incredibly difficult to disable it if you need to.

I think the process described in https://pagure.io/fesco/issue/2381#comment-650068 cannot be described as "incredibly difficult".

systemd-resolved is listening on localhost:53 and the default /etc/resolv.conf simply points there

Using unicast dns as transport limits us to things that DNS supports, in particular address scopes are lost. So this would be stop-gap solution that would be confusing and would limit capabilities. And since the requests would still be processed through resolved anyway, in case resolved handles some case wrong, in this scheme users would still see the problem, and would need to touch /etc/resolv.conf to resolve the issue anyway. I don't think this is a good idea.

We discussed this during today's meeting, and reached consensus on this proposal:

Post feedback on the devel list and restart discussion (+7, 0, -0)

From the meeting log:

15:40:54 <sgallagh> The major concern is the modifications to nsswitch.conf which are not trivially reversible.

There's no need to reverse changes to nsswitch.conf. We will use [!UNAVAIL=return] so that nss-resolve will simply be skipped if systemd-resolved is not running.

Sorry, I was not on the last meeting so I did not have chance to join conversation. It seems that only reason to "get more discussion on devel" was the response of Red Hat Security Team, however I don't see any post there from @sgallagh or aforementioned team.

@sgallagh can you make sure that somebody sends their concerns there? Thanks!

I'd like to have this change implemented ASAP so that there is enough time for everyone to test it, fix any issues which may arise and in the worst case to revert it.

I'm hesitant here because it's not clear to me how users handle situations where this setup does not work. Taking a long standing file and removing the ability to edit it without some complication is going to cause headaches for users. I don't see information on how users will deal with those situations.

+0

Taking a long standing file and removing the ability to edit it without some complication is going to cause headaches for users.

That assumes /etc/resolv.conf is currently unmanaged, but that is not correct. Currently, it is managed by NetworkManager, and manual modifications will not work as expected. We are just moving management from NetworkManager to systemd-resolved. Currently, if you want to manually edit the file, you need to completely disable NetworkManager (at least, I don't think there's a way to make changes persist otherwise?). Under this proposal, managing the file manually is as simple as deleting the symlink and recreating /etc/resolv.conf as a normal file.

  • AGREED: APPROVED (+6, ±3, -0) (ignatenkobrain, 15:21:23)

@zbyszek make sure to coordinate nsswitch changes with necessary people :)

Metadata Update from @ignatenkobrain:
- Issue close_status updated to: Accepted
- Issue status updated to: Closed (was: Open)

23 days ago

AGREED: APPROVED (+6, ±3, -0) (ignatenkobrain, 15:21:23)

Thanks.

@zbyszek make sure to coordinate nsswitch changes with necessary people :)

I think it only needs to be coordinated with authselect maintainers; everything else should be fine.

I think it only needs to be coordinated with authselect maintainers; everything else should be fine.

sgallagh requested to be CC'ed too.

Login to comment on this ticket.

Metadata