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.

+1

+1

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.

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 :)

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.

Note that this feature broke FreeIPA in F33 and no coordination with FreeIPA team was done at all.

Sorry, it's certainly not something we expected to happen....

@catanzaro FreeIPA provides own DNS server and DNSSEC support. When the host is an IPA server, it is authoritative for the DNS zones hosted on it. If this setup is disjoint to upstream DNS (self-hosted DNS for internal DNS zones, for example), systemd-resolved makes it dark completely, even on the host itself. What's worse, when multi-server configuration is deployed where multiple IPA servers replicate to each other, replicas have to know about the master's DNS server or be able to reach it. We either rely on upstream DNS server knowing about zones or configure IPA master to be a forwarder, for disjoint configurations -- which is the case in OpenQA in Fedora.

These cases were simply ignored as it seems systemd-resolved was only considering a client-side setup.

These cases were simply ignored as it seems systemd-resolved was only considering a client-side setup.

Right, certainly systemd-resolved is not designed to be run on DNS servers. You might want to consider disabling it when configuring an IPA server.

A closed FESCo tiket is not a good place for discussion. In case of specific issues, please use bugzilla. For a more general discussion, the devel mailing list.

See also FreeIPA server doesn't get along well with systemd-resolved (need to manually disable it).