2:23 p.m.
https://fedoraproject.org/wiki/Changes/systemd-resolved
== Summary ==
Enable systemd-resolved by default. glibc will perform name resolution
using nss-resolve rather than nss-dns.
== Owner ==
* Name: [[User:catanzaro| Michael Catanzaro]]
* Email: <mcatanzaro(a)redhat.com>
== Detailed Description ==
We will enable systemd-resolved by default.
# We will change the
[https://src.fedoraproject.org/rpms/fedora-release/blob/f4cc5b6ce095bb4233...
fedora-release presets] to enable systemd-resolved instead of disable
it.
# systemd-libs currently has
[https://src.fedoraproject.org/rpms/systemd/blob/bb79fb73875f8e71841a1ee8e...
a %post scriplet] to enable nss-myhostname and nss-systemd by either
(a) modifying authselect's user-nsswitch.conf template, if authselect
is in use, or (b) directly modifying /etc/nsswitch.conf otherwise. We
will work with the systemd maintainers to enable nss-resolve here as
well.
# We will work with the authselect maintainers to update authselect's
minimal and nis profiles to enforce nss-resolve. These profiles modify
the hosts line of /etc/resolv.conf. (By default, Fedora uses
authselect's sssd profile, which does not modify the hosts line and
therefore does not have this problem.)
# We will remove our downstream patch to systemd that prevents systemd
from symlinking /etc/resolv.conf to
/run/systemd/resolve/stub-resolv.conf on new installs. For system
upgrades, a systemd-libs %post scriptlet will be used to reassign the
symlink during upgrade. Upon detecting this symlink, NetworkManager
will automatically enable its systemd-resolved support and configure
split DNS as appropriate.
systemd-resolved has been enabled by default in Ubuntu since Ubuntu
16.10, but please note we are doing this differently than Ubuntu has.
Ubuntu does not use nss-resolve. Instead, Ubuntu uses the traditional
nss-dns provided by glibc upstream, so glibc on Ubuntu continues to
read /etc/resolv.conf, as is traditional. This extra step is not
useful and not recommended by upstream. We want to follow upstream
recommendations in using nss-resolve instead.
If you do not wish to use systemd-resolved, then manual intervention
will be required to disable it:
* Modify /etc/authselect/user-nsswitch.conf and remove `resolve
[!UNAVAIL=return]` from the hosts line. Run `authselect
apply-changes`. (If you have disabled authselect, then edit
/etc/nsswitch.conf directly.)
* Disable and stop systemd-resolved.service.
* Restart the NetworkManager service. NetworkManager will then create
a traditional /etc/resolv.conf. (If you are not using NetworkManager,
you may create your own /etc/resolv.conf.)
== Benefit to Fedora ==
=== Standardization ===
Fedora will continue its history of enabling new systemd-provided
services whenever it makes sense to do so. Standardizing on upstream
systemd services is beneficial to the broader Linux ecosystem in
addition to Fedora, since standardizing reduces behavior differences
between different Linux distributions. Sadly, Fedora is no longer
leading in this area. Ubuntu has enabled systemd-resolved by default
since Ubuntu 16.10, so by the time Fedora 33 is released, we will be
three years behind Ubuntu here.
=== resolvectl ===
`resolvectl` has several useful functions (e.g. `resolvectl status` or
`resolvectl query`) that will be enabled out-of-the-box.
=== Caching ===
systemd-resolved caches DNS queries for a short while. This can
[https://gitlab.gnome.org/GNOME/glib/-/merge_requests/682#note_441846
dramatically] improve performance for applications that do not already
manually cache their own DNS results. (Generally, only web browsers
bother with manually caching DNS results.)
=== Split DNS ===
When systemd-resolved is enabled, users who use multiple VPNs at the
same time will notice that DNS requests are now sent to the correct
DNS server by default. Previously, this scenario would result in
embarrassing "DNS leaks" and, depending on the order that the VPN
connections were established, possible failure to resolve private
resources. These scenarios will now work properly. For example,
consider the scenario of Distrustful Denise, who (quite reasonably)
does not trust her ISP. Denise uses a public VPN service,
public-vpn.example.com, to hide her internet activity from her ISP,
but she also needs to use her employer's corporate VPN,
corporation.example.com, in order to access internal company resources
while working from home. Using the Network panel in System Settings,
Denise has configured her employer's VPN to "use this connection only
for resources on its network." Distrustful Denise expects that her
employer's VPN will receive all traffic for corporation.example.com,
and no other traffic. And while this mostly works in Fedora 32, she
discovers that it does not work properly for DNS:
* If Denise connects to public-vpn.example.com first and
corporation.example.com second, she is unable to access internal
company resources. All DNS requests are sent to
public-vpn.example.com's DNS server, so she is unable to resolve names
for internal company websites.
* If Denise connects to corporation.example.com first and
public-vpn.example.com second, then she is able to access internal
company resources. However, it only works because ''all'' her DNS
requests are sent to corporation.example.com's DNS server. Sadly for
Distrustful Denise, her employer discovers that she has been making
some embarrassing DNS requests that she had expected to go through
public-vpn.example.com instead.
Whichever VPN Denise connects to first receives all DNS requests
because glibc's nss-dns module is not smart enough to split the
requests. /etc/resolv.conf is just a list of DNS servers to try in
order, and NetworkManager has no plausible way to decide which to list
first, because both ways are broken, so it just prefers whichever was
connected first. And if one server fails to respond, then the next
server in the list will be tried, likely resulting in a DNS leak. In
contrast, when systemd-resolved is enabled, it will send each DNS
request only to the correct DNS server. The DNS server that will be
used for each tun interface can be inspected using the resolvectl
tool.
Migrating away from /etc/resolv.conf will also avoid an annoying
footgun with this legacy file: only the first three listed nameservers
are respected. All further nameservers are silently ignored.
NetworkManager adds a warning comment when writing more than three
nameservers to this file, but it cannot do any better than that.
=== DNS over TLS ===
systemd-resolved supports DNS over TLS (different from DNS over
HTTPS). Although this feature will not initially be enabled by
default, using systemd-resolved will enable us to turn on DNS over TLS
in a future Fedora release, providing improved security if the user's
DNS server supports DNS over TLS.
== Scope ==
* Proposal owners: We will update Fedora presets to enable
systemd-resolved by default.
* Other developers: This change requires coordination with the systemd
and authselect maintainers.
* Release engineering: [https://pagure.io/releng/issue/9367 #9367]
* Policies and guidelines: none required
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
systemd-resolved will be enabled automatically when upgrading to
Fedora 33. After upgrade, /etc/resolv.conf will be managed by systemd
and symlinked to /run/systemd/resolve/stub-resolv.conf. '''glibc will
no longer look at /etc/resolv.conf when performing name resolution.'''
Instead, glibc will communicate directly with systemd-resolved via
nss-resolve. systemd adds a large warning comment to the top of
/etc/resolv.conf to warn system administrators that changes to this
file will be ignored; however, scripts that edit this file manually
will break. Because this file is usually managed by NetworkManager,
impact to Fedora users will be limited to users who have manually
disabled NetworkManager; such users are expected to be experienced
system administrators who should be comfortable adapting to the change
(or disabling systemd-resolved).
Any applications that bypass glibc and read /etc/resolv.conf directly
will still work because /etc/resolv.conf will point to
systemd-resolved's stub resolver running on 127.0.0.53. Nevertheless,
/etc/resolv.conf is provided only for compatibility purposes, and
applications should prefer to use either glibc or the systemd-resolved
D-Bus API instead; see systemd-resolved(8) for details.
In short, '''applications that read /etc/resolv.conf will continue to
work as before.''' Applications that write to it will no longer work
as expected, but this only previously worked if NetworkManager is
disabled, a non-default configuration. It remains possible to disable
systemd-resolved if desired. Otherwise, any custom system
administration scripts that manage /etc/resolv.conf will need to be
updated.
=== DNSSEC ===
systemd-resolved's DNSSEC support is known to cause compatibility
problems with certain network access points. Per recommendation from
the systemd developers, we will change the default value of this
setting in Fedora from the upstream default `DNSSEC=allow-downgrade`
to `DNSSEC=no` by building systemd with the build option
`-Ddefault-dnssec=no`. The upstream default attempts to use DNSSEC if
it is working, but automatically disable it otherwise, allowing
man-in-the-middle attackers to disable DNSSEC. Sadly, even the
allow-downgrade setting suffers known compatibility problems. Because
Fedora is not prepared to handle an influx of DNSSEC-related bug
reports, we will disable this feature altogether. We anticipate that
enabling DNSSEC by default will not be possible in the foreseeable
future, or perhaps ever. Instead, enabling DNS over TLS (when
supported by the DNS server) seems likely in the near future.
=== Multicast DNS ===
systemd-resolved's multicast DNS support conflicts with Avahi. Per
recommendation from the systemd developers, we will change the default
value of this setting in Fedora from the upstream default
`MulticastDNS=yes` to `MulticastDNS=resolve`. Multicast DNS resolving
will be enabled, but responding will be disabled. This will require
adding a new systemd build option to control the default value of the
MulticastDNS setting, similar to the existing `default-dnssec` and
`default-dns-over-tls` build options.
== How To Test ==
Load any website in a web browser. If you succeed, then name
resolution probably works.
Try using `resolvectl status` and, for example, `resolvectl query
fedoraproject.org`, to see how they work and sanity-check their
output.
Users who use multiple VPNs at the same time are encouraged to test
DNS in a multiple VPN scenario, to ensure that DNS requests are sent
to the expected DNS server.
== User Experience ==
See the Benefit to Fedora section, above, for direct benefits to users
who use multiple VPNs at the same time.
Users will be able to use the resolvectl tool and the functionality it provides.
/etc/resolv.conf will now be managed by systemd rather than by
NetworkManager. As before, this file must not be modified directly
when it is managed.
== Dependencies ==
In Fedora, /etc/nsswitch.conf is managed by authselect. By default,
authselect uses the sssd profile to generate configuration compatible
with sssd. In this mode of operation, it does not modify the hosts
line in /etc/nsswitch.conf. This is also true if using the winbind
profile instead of the sssd profile. However, authselect's minimal and
nis profiles do modify the hosts line. These authselect profiles must
be updated to enable nss-resolved. If you are using authselect in one
of these modes, it will not be possible to cleanly disable
systemd-resolved because the hosts line in /etc/nsswitch.conf will be
clobbered whenever 'authselect apply-changes' is run. If you wish to
disable systemd-resolved and you are using authselect in one of these
modes, then you should stop using authselect. This is not expected to
cause many problems because virtually all Fedora users will be using
the default sssd profile.
We do not need to directly make any changes to the /etc/nsswitch.conf
shipped by glibc. Changes will be applied in the systemd-libs %post
scriptlet.
== Contingency Plan ==
The contingency plan, in the unlikely event of unexpected problems, is
simply to revert any changes and not enable systemd-resolved.
* Contingency deadline: beta freeze
* Blocks release? No
* Blocks product? No
== Documentation ==
* systemd-resolved is documented in several manpages: resolvectl(1),
resolved.conf(5), nss-resolve(8), systemd-resolved(8).
* [https://wiki.archlinux.org/index.php/Systemd-resolved Arch Wiki
documentation]
* [https://wiki.gnome.org/Projects/NetworkManager/DNS NetworkManager
DNS documentation]
== Release Notes ==
systemd-resolved is now enabled by default. systemd-resolved provides
a system-level DNS cache that can substantially improve performance
for applications that do not cache their own DNS results, allows
correct handling of split DNS scenarios such as when multiple VPNs are
in use, and will allow Fedora to enable DNS over TLS in the future.
/etc/resolv.conf will now be managed by systemd-resolved rather than
by NetworkManager. /etc/resolv.conf will no longer be read when
performing name resolution using glibc; however, it is still provided
for compatibility with applications that manually read this file to
perform name resolution. Writing to /etc/resolv.conf will no longer
work as expected.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
2:33 p.m.
On 4/14/20 2:23 PM, Ben Cotton wrote:
=== DNS over TLS ===
systemd-resolved supports DNS over TLS (different from DNS over
HTTPS). Although this feature will not initially be enabled by
default, using systemd-resolved will enable us to turn on DNS over TLS
in a future Fedora release, providing improved security if the user's
DNS server supports DNS over TLS.
Why wait?
This is something I've been interested in and was interested in implementing in
Fedora.
2:40 p.m.
On Tue, Apr 14, 2020 at 2:33 pm, Michael Cronenworth <mike(a)cchtml.com>
wrote:
Why wait?
This is something I've been interested in and was interested in
implementing in Fedora.
Caution mainly, so that we only make one major change at a time instead
of two. The goal is to do this without generating too many new bug
reports for the systemd developers all at the same time. My thinking
was that if this change goes smoothly in F33, then it should be
possible to enable DNS over TLS by default in F34.
That said, there are not currently any known compatibility problems
with the DNS over TLS support as far as I know, so I would *expect* it
to go smoothly regardless.
Of course, once systemd-resolved is enabled, then enabling or disabling
DNS over TLS will be a one-line config file change in
/etc/systemd/resolved.conf. :)
2:57 p.m.
On Tue, Apr 14, 2020 at 02:40:08PM -0500, Michael Catanzaro wrote:
On Tue, Apr 14, 2020 at 2:33 pm, Michael Cronenworth
<mike(a)cchtml.com>
wrote:
> Why wait?
>
> This is something I've been interested in and was interested in
> implementing in Fedora.
Caution mainly, so that we only make one major change at a time instead of
two. The goal is to do this without generating too many new bug reports for
the systemd developers all at the same time. My thinking was that if this
change goes smoothly in F33, then it should be possible to enable DNS over
TLS by default in F34.
Can you expand on what that means?
Does it mean:
a) systemd-resolved will use DNS over TLS if it detects that
the nameservers it is querying can do so (ie, it would do a query to
port 853 of the nameservers dhcp or static config gave it)
b) systemd-resolved will use DNS over TLS and always use some 'well
known' public dns servers for queries, ignoring locally configured
servers.
I'm very much in favor of a, but not in favor of b. :)
That said, there are not currently any known compatibility problems
with the
DNS over TLS support as far as I know, so I would *expect* it to go smoothly
regardless.
Of course, once systemd-resolved is enabled, then enabling or disabling DNS
over TLS will be a one-line config file change in
/etc/systemd/resolved.conf. :)
Is that going to be to set it to 'opportunistic' or 'true' ?
kevin
4:14 p.m.
On Tue, Apr 14, 2020 at 12:57 pm, Kevin Fenzi <kevin(a)scrye.com> wrote:
Can you expand on what that means?
Does it mean:
a) systemd-resolved will use DNS over TLS if it detects that
the nameservers it is querying can do so (ie, it would do a query to
port 853 of the nameservers dhcp or static config gave it)
b) systemd-resolved will use DNS over TLS and always use some 'well
known' public dns servers for queries, ignoring locally configured
servers.
I'm very much in favor of a, but not in favor of b. :)
It would do (a). (But as part of a future change, not part of this
change.)
I think (b) would be too controversial for Fedora.
> That said, there are not currently any known compatibility
problems
> with the
> DNS over TLS support as far as I know, so I would *expect* it to go
> smoothly
> regardless.
>
> Of course, once systemd-resolved is enabled, then enabling or
> disabling DNS
> over TLS will be a one-line config file change in
> /etc/systemd/resolved.conf. :)
Is that going to be to set it to 'opportunistic' or 'true' ?
It would be "opportunistic". (But again, that would be a future change,
not this change.)
8:34 a.m.
On Di, 14.04.20 12:57, Kevin Fenzi (kevin(a)scrye.com) wrote:
Can you expand on what that means?
Does it mean:
a) systemd-resolved will use DNS over TLS if it detects that
the nameservers it is querying can do so (ie, it would do a query to
port 853 of the nameservers dhcp or static config gave it)
b) systemd-resolved will use DNS over TLS and always use some 'well
known' public dns servers for queries, ignoring locally configured
servers.
Nah. We will only talk to configured DNS servers. If no DNS servers
are configured at all we'll try to use a default set of DNS servers
however, which can be specified when building systemd. it's a fallback
to make things more robust, i.e. making sure DNS works if possible.
Lennart
--
Lennart Poettering, Berlin
9:45 a.m.
On Wednesday, April 15, 2020 6:34:56 AM MST Lennart Poettering wrote:
On Di, 14.04.20 12:57, Kevin Fenzi (kevin(a)scrye.com) wrote:
> Can you expand on what that means?
>
>
>
> Does it mean:
>
>
>
> a) systemd-resolved will use DNS over TLS if it detects that
> the nameservers it is querying can do so (ie, it would do a query to
> port 853 of the nameservers dhcp or static config gave it)
>
>
>
> b) systemd-resolved will use DNS over TLS and always use some 'well
> known' public dns servers for queries, ignoring locally configured
> servers.
Nah. We will only talk to configured DNS servers. If no DNS servers
are configured at all we'll try to use a default set of DNS servers
however, which can be specified when building systemd. it's a fallback
to make things more robust, i.e. making sure DNS works if possible.
Lennart
--
Lennart Poettering, Berlin
If there are no servers configured... Shouldn't it use no servers?
--
John M. Harris, Jr.
Splentity
1:07 p.m.
On Thu, Apr 16, 2020 at 07:27:29PM +0200, Lennart Poettering wrote:
> If there are no servers configured... Shouldn't it use no
servers?
Well, our assumption is that working DNS is better than DNS that
doesn't work.
I hope no one is using lack of configured DNS as a security measure! But I
can see a case for wanting lack of configuration to be a failure rather than
working but non-obviously not in the way you expected.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
1:33 p.m.
On Do, 16.04.20 14:07, Matthew Miller (mattdm(a)fedoraproject.org) wrote:
On Thu, Apr 16, 2020 at 07:27:29PM +0200, Lennart Poettering wrote:
> > If there are no servers configured... Shouldn't it use no servers?
> Well, our assumption is that working DNS is better than DNS that
> doesn't work.
I hope no one is using lack of configured DNS as a security measure! But I
can see a case for wanting lack of configuration to be a failure rather than
working but non-obviously not in the way you expected.
Use FallbackDNS= to override the built-in defaults, and set it to the
empty string if you want lookups to fail.
Lennart
--
Lennart Poettering, Berlin
1:43 p.m.
* Matthew Miller:
On Thu, Apr 16, 2020 at 07:27:29PM +0200, Lennart Poettering wrote:
> > If there are no servers configured... Shouldn't it use no servers?
> Well, our assumption is that working DNS is better than DNS that
> doesn't work.
I hope no one is using lack of configured DNS as a security measure! But I
can see a case for wanting lack of configuration to be a failure rather than
working but non-obviously not in the way you expected.
At the lowest level, lack of configuration (i.e., no name servers in
/etc/resolv.conf or no such file at all) currently means that 127.0.0.1
is used as the DNS resolver. This has been the case for such a long
time that I think it would not be a good idea to configure different
servers instead.
Thanks,
Florian
7:53 p.m.
Once upon a time, Lennart Poettering <mzerqung(a)0pointer.de> said:
On Do, 16.04.20 07:45, John M. Harris Jr (johnmh(a)splentity.com)
wrote:
> If there are no servers configured... Shouldn't it use no servers?
Well, our assumption is that working DNS is better than DNS that
doesn't work.
Talking to servers the admin didn't configure could be an information
leak and IMHO should not be on by default. You have no idea why there
are no servers, so trying to second-guess it is a bad idea.
--
Chris Adams <linux(a)cmadams.net>
9:54 a.m.
DNS over TLS is offered already by package called stubby. But DNS over
TLS does not bring you more privacy usually. It only allows moving
(some) queries away from your ISP to somewhere else, but always someone
can read them.
On 4/14/20 9:33 PM, Michael Cronenworth wrote:
On 4/14/20 2:23 PM, Ben Cotton wrote:
> === DNS over TLS ===
>
> systemd-resolved supports DNS over TLS (different from DNS over
> HTTPS). Although this feature will not initially be enabled by
> default, using systemd-resolved will enable us to turn on DNS over TLS
> in a future Fedora release, providing improved security if the user's
> DNS server supports DNS over TLS.
Why wait?
This is something I've been interested in and was interested in
implementing in Fedora.
--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemensik(a)redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
10:46 a.m.
On Thu, Oct 1, 2020 at 11:45 AM Vitaly Zaitsev via devel
<devel(a)lists.fedoraproject.org> wrote:
On 01.10.2020 16:54, Petr Menšík wrote:
> But DNS over TLS does not bring you more privacy usually.
It does. DoT and DoH encrypt all DNS traffic. Your ISP can no longer spy
on you and sell the collected data to third parties.
They also completely break most VPNs and corporate network setups, so...
--
真実はいつも一つ！/ Always, there's only one truth!
11:48 a.m.
On Thu, Oct 1, 2020 at 3:48 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
On Thu, Oct 1, 2020 at 11:45 AM Vitaly Zaitsev via devel
<devel(a)lists.fedoraproject.org> wrote:
>
> On 01.10.2020 16:54, Petr Menšík wrote:
> > But DNS over TLS does not bring you more privacy usually.
>
> It does. DoT and DoH encrypt all DNS traffic. Your ISP can no longer spy
> on you and sell the collected data to third parties.
>
They also completely break most VPNs and corporate network setups, so...
Well, as much else, whether it breaks a VPN or
corporate network, or even a countries attempt
to use DNS for blocking purposes depends on
the details of implementation, and what tools are
available at the various levels to influence the
resolver behaviours to implement whatever the
entities are trying to accomplish.
It should come to no real surprise to those on
this list that newer tech can certainly require
existing practices to be forced to adopt, nor
that those that want things to stay the same
need to get used to disappointment.
5:59 p.m.
Am 01.10.20 um 19:45 schrieb Vitaly Zaitsev via devel:
On 01.10.2020 17:46, Neal Gompa wrote:
> They also completely break most VPNs and corporate network setups, so...
It will not, because Fedora will use opportunistic mode by default.
DoT won't break anything, it's blockable by an admin in the firewall,
unlike DoH, which uses port 443.
Marius
5:57 p.m.
Am 01.10.20 um 17:44 schrieb Vitaly Zaitsev via devel:
On 01.10.2020 16:54, Petr Menšík wrote:
> But DNS over TLS does not bring you more privacy usually.
It does. DoT and DoH encrypt all DNS traffic. Your ISP can no longer spy
on you and sell the collected data to third parties.
... if you changed the dns servers manually to other != isp caches. ;)
Marius
4:22 a.m.
On 10/1/20 5:44 PM, Vitaly Zaitsev via devel wrote:
On 01.10.2020 16:54, Petr Menšík wrote:
> But DNS over TLS does not bring you more privacy usually.
It does. DoT and DoH encrypt all DNS traffic. Your ISP can no longer spy
on you and sell the collected data to third parties.
No, it doesn't. Unless you operate the remote resolver as well, it moves
ability to see your name lookups from your ISP to DoT or DoH provider.
They can see it instead. It makes you able to choose different receiver,
but it does not 'protect' it from other parties in general.
Now your DoH provider can sell the collected data to third parties.
Living in the EU, I expect GDPR protects me better than DoH in the US.
My ISP needs legal consent to sell such information.
Cheers,
Petr
--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemensik(a)redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
2:45 p.m.
On Tue, 2020-04-14 at 15:23 -0400, Ben Cotton wrote:
> === Caching ===
> systemd-resolved caches DNS queries for a short while.
This can
> [https://gitlab.gnome.org/GNOME/glib/-/merge_requests/682#note_441846
> dramatically] improve performance for applications that do not already
> manually cache their own DNS results. (Generally, only web browsers
> bother with manually caching DNS results.)
> === Split DNS ===
Doesn't NetworkManager already broadly address both of these on all
installations where it's used (which is all Fedora installs by
default)?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
4:18 p.m.
On Tue, Apr 14, 2020 at 12:45 pm, Adam Williamson
<adamwill(a)fedoraproject.org> wrote:
Doesn't NetworkManager already broadly address both of these on
all
installations where it's used (which is all Fedora installs by
default)?
I don't think so, no.
As far as I know, NetworkManager does not have a DNS cache. The only
way to implement one systemwide would be to write a glibc NSS plugin.
Otherwise, how would glibc be able to talk to NetworkManager to use the
cached results?
Then the description of multi-VPN scenario is written based on the
status quo with NetworkManager already installed and enabled.
NetworkManager has three DNS backends: default (nss-dns, what we use
currently), dnsmasq, and systemd-resolved. The default backend just
does the wrong thing and cannot be fixed. When either dnsmasq or
systemd-resolved is in use, NetworkManager will go ahead and do the
right thing by telling dnsmasq/systemd-resolved which network
interfaces should be used to resolve which hostnames. I consulted with
the NetworkManager developers and they recommended systemd-resolved
over dnsmasq, although I understand that dnsmasq is good too.
Michael
4:24 p.m.
On Tue, 2020-04-14 at 16:18 -0500, Michael Catanzaro wrote:
On Tue, Apr 14, 2020 at 12:45 pm, Adam Williamson
<adamwill(a)fedoraproject.org> wrote:
> Doesn't NetworkManager already broadly address both of these on all
> installations where it's used (which is all Fedora installs by
> default)?
I don't think so, no.
As far as I know, NetworkManager does not have a DNS cache. The only
way to implement one systemwide would be to write a glibc NSS plugin.
Otherwise, how would glibc be able to talk to NetworkManager to use the
cached results?
Then the description of multi-VPN scenario is written based on the
status quo with NetworkManager already installed and enabled.
NetworkManager has three DNS backends: default (nss-dns, what we use
currently), dnsmasq, and systemd-resolved. The default backend just
does the wrong thing and cannot be fixed. When either dnsmasq or
systemd-resolved is in use, NetworkManager will go ahead and do the
right thing by telling dnsmasq/systemd-resolved which network
interfaces should be used to resolve which hostnames. I consulted with
the NetworkManager developers and they recommended systemd-resolved
over dnsmasq, although I understand that dnsmasq is good too.
I thought we'd made the dnsmasq config default at some point (that
implements both caching and split DNS). I guess I was remembering
wrong.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
5:52 p.m.
On Tue, 14 Apr 2020 16:18:02 -0500
Michael Catanzaro <mcatanzaro(a)gnome.org> wrote:
NetworkManager has three DNS backends: default (nss-dns, what we use
currently), dnsmasq, and systemd-resolved. The default backend just
does the wrong thing and cannot be fixed. When either dnsmasq or
systemd-resolved is in use, NetworkManager will go ahead and do the
right thing by telling dnsmasq/systemd-resolved which network
interfaces should be used to resolve which hostnames. I consulted
with the NetworkManager developers and they recommended
systemd-resolved over dnsmasq, although I understand that dnsmasq is
good too.
Will the ability to turn off NetworkManager involvement in DNS in the
configuration file (None) still remain? I use a local caching DNS
server, and had to do that in order to allow it to run without
interference / override by NetworkManager.
6:30 p.m.
On Tue, 14 Apr 2020 15:52:55 -0700
stan via devel <devel(a)lists.fedoraproject.org> wrote:
On Tue, 14 Apr 2020 16:18:02 -0500
Michael Catanzaro <mcatanzaro(a)gnome.org> wrote:
> NetworkManager has three DNS backends: default (nss-dns, what we
> use currently), dnsmasq, and systemd-resolved. The default backend
> just does the wrong thing and cannot be fixed. When either dnsmasq
> or systemd-resolved is in use, NetworkManager will go ahead and do
> the right thing by telling dnsmasq/systemd-resolved which network
> interfaces should be used to resolve which hostnames. I consulted
> with the NetworkManager developers and they recommended
> systemd-resolved over dnsmasq, although I understand that dnsmasq is
> good too.
Will the ability to turn off NetworkManager involvement in DNS in the
configuration file (None) still remain? I use a local caching DNS
server, and had to do that in order to allow it to run without
interference / override by NetworkManager.
Just a further note. I tried both dnsmasq and systemd-resolved, but
neither seemed to work. I still saw my browser saying
Looking up blah-blah.com ...
and timing for seconds even if I just visited the page a few minutes
before. Once I set up my own caching DNS server, that went away except
when I visit a new site.
6:39 p.m.
On Tue, Apr 14, 2020 at 3:52 pm, stan via devel
<devel(a)lists.fedoraproject.org> wrote:
Will the ability to turn off NetworkManager involvement in DNS in
the
configuration file (None) still remain? I use a local caching DNS
server, and had to do that in order to allow it to run without
interference / override by NetworkManager.
Of course. You just have to set dns=None in your
/etc/NetworkManager.conf, as before. Also: 'systemctl disable
systemd-resolved.service'.
6:43 p.m.
On Tue, 14 Apr 2020 18:39:05 -0500
Michael Catanzaro <mcatanzaro(a)gnome.org> wrote:
On Tue, Apr 14, 2020 at 3:52 pm, stan via devel
<devel(a)lists.fedoraproject.org> wrote:
> Will the ability to turn off NetworkManager involvement in DNS in
> the configuration file (None) still remain? I use a local caching
> DNS server, and had to do that in order to allow it to run without
> interference / override by NetworkManager.
Of course. You just have to set dns=None in your
/etc/NetworkManager.conf, as before. Also: 'systemctl disable
systemd-resolved.service'.
Excellent! Thanks.
8:46 a.m.
On Di, 14.04.20 15:52, Fedora Development ML (devel(a)lists.fedoraproject.org) wrote:
On Tue, 14 Apr 2020 16:18:02 -0500
Michael Catanzaro <mcatanzaro(a)gnome.org> wrote:
> NetworkManager has three DNS backends: default (nss-dns, what we use
> currently), dnsmasq, and systemd-resolved. The default backend just
> does the wrong thing and cannot be fixed. When either dnsmasq or
> systemd-resolved is in use, NetworkManager will go ahead and do the
> right thing by telling dnsmasq/systemd-resolved which network
> interfaces should be used to resolve which hostnames. I consulted
> with the NetworkManager developers and they recommended
> systemd-resolved over dnsmasq, although I understand that dnsmasq is
> good too.
Will the ability to turn off NetworkManager involvement in DNS in the
configuration file (None) still remain? I use a local caching DNS
server, and had to do that in order to allow it to run without
interference / override by NetworkManager.
resolved has three modes:
1. If /etc/resolv.conf is a regular file, resolved will *consume* it
for DNS configuration, and never change it or modify it or replace
it. If this mode is selected arbitrary other programs that do DNS
will talk directly to the provided DNS servers, and resolved is out
of the loop.
2. Alternatvely, /etc/resolv.conf can be made a symlink to
/run/systemd/resolve/stub-resolv.conf. That file is updated by
resolved whenever DNS configuration changes. In it you'll find as
DNS server the local host configured, where resolved is
listening. In this mode other programs that do DNS will talk to
resolved, and resolved propagates it to other DNS servers.
3. Alternatively /etc/resolv.conf can be made a symlink to
/run/systemd/resolve/resolv.conf. That file is also updated by
resolved whenever DNS configuration changes. In it you find a
merged set of configured upstream DNS servers. In this mode
programs that do DNS will talk directly to the upstream DNS
servers, but resolved will still tell them which ones, based on all
the information it has.
In mode #1 resolved neither manages /etc/resolv.conf nor inserts
itself into DNS resolution in any way. In mode #2 it manages *and*
inserts itself into DNS resolution. In mode #3 it manages DNS
resolution but will not insert itself to.
NetworkManager natively supports informing resolved about DNS
configuration changes, hence whenever NM discovers a new DNS server it
tells resolved, which resolved then uses itself and writes it to
/run/systemd/resolve/stub-resolv.conf and
/run/systemd/resolve/resolv.conf.
Long story short: we want to default to mode #2. But if you can chose
mode #1 or #3 if you like, depending on whether you want to kick
resolved out of managing resolv.conf or out of doing any DNS lookups
for you at all.
Lennart
--
Lennart Poettering, Berlin
8:50 a.m.
* Lennart Poettering:
1. If /etc/resolv.conf is a regular file, resolved will *consume* it
for DNS configuration, and never change it or modify it or replace
it. If this mode is selected arbitrary other programs that do DNS
will talk directly to the provided DNS servers, and resolved is out
of the loop.
In mode #1 resolved neither manages /etc/resolv.conf nor inserts
itself into DNS resolution in any way.
What will nss_resolve do in this case? Nothing?
Does this mean we need both resolve and dns in nsswitch.conf?
Thanks,
Florian
9:30 a.m.
On Mi, 15.04.20 15:50, Florian Weimer (fweimer(a)redhat.com) wrote:
* Lennart Poettering:
> 1. If /etc/resolv.conf is a regular file, resolved will *consume* it
> for DNS configuration, and never change it or modify it or replace
> it. If this mode is selected arbitrary other programs that do DNS
> will talk directly to the provided DNS servers, and resolved is out
> of the loop.
> In mode #1 resolved neither manages /etc/resolv.conf nor inserts
> itself into DNS resolution in any way.
What will nss_resolve do in this case? Nothing?
The nss_resolve module is just a wrapper around resolved's bus
API. And the bus API uses resolved's own DNS resolution code. And
resolved is smart enough to automatically become a *consumer* of
/etc/nsswitch.conf (instead of a *manager* of it) if it is a regular
file instead of a symlink to resolved's own files in /run.
Does this mean we need both resolve and dns in nsswitch.conf?
Yeah, that's the idea. resolve takes control if resolved runs, and
otherwise we fall back to classic nss-dns.
Lennart
--
Lennart Poettering, Berlin
9:34 a.m.
On Mi, 15.04.20 16:30, Lennart Poettering (mzerqung(a)0pointer.de) wrote:
On Mi, 15.04.20 15:50, Florian Weimer (fweimer(a)redhat.com) wrote:
> * Lennart Poettering:
>
> > 1. If /etc/resolv.conf is a regular file, resolved will *consume* it
> > for DNS configuration, and never change it or modify it or replace
> > it. If this mode is selected arbitrary other programs that do DNS
> > will talk directly to the provided DNS servers, and resolved is out
> > of the loop.
>
> > In mode #1 resolved neither manages /etc/resolv.conf nor inserts
> > itself into DNS resolution in any way.
>
> What will nss_resolve do in this case? Nothing?
The nss_resolve module is just a wrapper around resolved's bus
API. And the bus API uses resolved's own DNS resolution code. And
resolved is smart enough to automatically become a *consumer* of
/etc/nsswitch.conf (instead of a *manager* of it) if it is a regular
file instead of a symlink to resolved's own files in /run.
Meh. I mean /etc/resolv.conf here, of course, not /etc/nsswitch.conf.
Lennart
--
Lennart Poettering, Berlin
5:53 a.m.
* Lennart Poettering:
On Mi, 15.04.20 16:30, Lennart Poettering (mzerqung(a)0pointer.de)
wrote:
> On Mi, 15.04.20 15:50, Florian Weimer (fweimer(a)redhat.com) wrote:
>
> > * Lennart Poettering:
> >
> > > 1. If /etc/resolv.conf is a regular file, resolved will *consume* it
> > > for DNS configuration, and never change it or modify it or replace
> > > it. If this mode is selected arbitrary other programs that do DNS
> > > will talk directly to the provided DNS servers, and resolved is out
> > > of the loop.
> >
> > > In mode #1 resolved neither manages /etc/resolv.conf nor inserts
> > > itself into DNS resolution in any way.
> >
> > What will nss_resolve do in this case? Nothing?
>
> The nss_resolve module is just a wrapper around resolved's bus
> API. And the bus API uses resolved's own DNS resolution code. And
> resolved is smart enough to automatically become a *consumer* of
> /etc/nsswitch.conf (instead of a *manager* of it) if it is a regular
> file instead of a symlink to resolved's own files in /run.
Meh. I mean /etc/resolv.conf here, of course, not /etc/nsswitch.conf.
So if /etc/resolv.conf comes from somewhere else, then nss_resolve will
still forward queries to the daemon, which contacts the upstream server
on nss_resolve's behave (possibly with some caching), and eventually
return the data to the application?
Or does nss_resolve fail with UNAVAIL and expects nss_dns to fetch the
data?
I'd prefer the first approach, but it really means that resolved is out
of the loop only for queries submitted over the DNS transport (so
res_query and the like, or direct use of UDP & TCP). Hence my
confusion. 8-)
Thanks,
Florian
7:47 a.m.
On Thu, Apr 16, 2020 at 12:53:48PM +0200, Florian Weimer wrote:
* Lennart Poettering:
> On Mi, 15.04.20 16:30, Lennart Poettering (mzerqung(a)0pointer.de) wrote:
>
>> On Mi, 15.04.20 15:50, Florian Weimer (fweimer(a)redhat.com) wrote:
>>
>> > * Lennart Poettering:
>> >
>> > > 1. If /etc/resolv.conf is a regular file, resolved will *consume* it
>> > > for DNS configuration, and never change it or modify it or replace
>> > > it. If this mode is selected arbitrary other programs that do DNS
>> > > will talk directly to the provided DNS servers, and resolved is
out
>> > > of the loop.
>> >
>> > > In mode #1 resolved neither manages /etc/resolv.conf nor inserts
>> > > itself into DNS resolution in any way.
>> >
>> > What will nss_resolve do in this case? Nothing?
>>
>> The nss_resolve module is just a wrapper around resolved's bus
>> API. And the bus API uses resolved's own DNS resolution code. And
>> resolved is smart enough to automatically become a *consumer* of
>> /etc/nsswitch.conf (instead of a *manager* of it) if it is a regular
>> file instead of a symlink to resolved's own files in /run.
>
> Meh. I mean /etc/resolv.conf here, of course, not /etc/nsswitch.conf.
So if /etc/resolv.conf comes from somewhere else, then nss_resolve will
still forward queries to the daemon, which contacts the upstream server
on nss_resolve's behave (possibly with some caching), and eventually
return the data to the application?
nss-resolve is enabled/disabled through nsswitch.conf. It always talks to
systemd-resolved using local IPC. It doesn't care about /etc/resolv.conf
in any way.
What Lennart wrote above applies to systemd-resolved and to things
which look at /etc/resolv.conf for some reason. If nss-resolve is enabled,
then only things which do not use nss at all would fall into this category.
Or does nss_resolve fail with UNAVAIL and expects nss_dns to fetch
the
data?
nss_resolve fails with UNAVAIL when systemd-resolved is not running.
So yeah, we use want to use nss_dns as a fallback for that case. I'm not
sure if that is what you are asking about.
I'd prefer the first approach, but it really means that resolved
is out
of the loop only for queries submitted over the DNS transport (so
res_query and the like, or direct use of UDP & TCP). Hence my
confusion. 8-)
Zbyszek
8:26 a.m.
* Zbigniew Jędrzejewski-Szmek:
On Thu, Apr 16, 2020 at 12:53:48PM +0200, Florian Weimer wrote:
> * Lennart Poettering:
>
> > On Mi, 15.04.20 16:30, Lennart Poettering (mzerqung(a)0pointer.de) wrote:
> >
> >> On Mi, 15.04.20 15:50, Florian Weimer (fweimer(a)redhat.com) wrote:
> >>
> >> > * Lennart Poettering:
> >> >
> >> > > 1. If /etc/resolv.conf is a regular file, resolved will *consume*
it
> >> > > for DNS configuration, and never change it or modify it or
replace
> >> > > it. If this mode is selected arbitrary other programs that do
DNS
> >> > > will talk directly to the provided DNS servers, and resolved is
out
> >> > > of the loop.
> >> >
> >> > > In mode #1 resolved neither manages /etc/resolv.conf nor inserts
> >> > > itself into DNS resolution in any way.
> >> >
> >> > What will nss_resolve do in this case? Nothing?
> >>
> >> The nss_resolve module is just a wrapper around resolved's bus
> >> API. And the bus API uses resolved's own DNS resolution code. And
> >> resolved is smart enough to automatically become a *consumer* of
> >> /etc/nsswitch.conf (instead of a *manager* of it) if it is a regular
> >> file instead of a symlink to resolved's own files in /run.
> >
> > Meh. I mean /etc/resolv.conf here, of course, not /etc/nsswitch.conf.
>
> So if /etc/resolv.conf comes from somewhere else, then nss_resolve will
> still forward queries to the daemon, which contacts the upstream server
> on nss_resolve's behave (possibly with some caching), and eventually
> return the data to the application?
nss-resolve is enabled/disabled through nsswitch.conf. It always talks to
systemd-resolved using local IPC. It doesn't care about /etc/resolv.conf
in any way.
What Lennart wrote above applies to systemd-resolved and to things
which look at /etc/resolv.conf for some reason. If nss-resolve is enabled,
then only things which do not use nss at all would fall into this category.
> Or does nss_resolve fail with UNAVAIL and expects nss_dns to fetch the
> data?
nss_resolve fails with UNAVAIL when systemd-resolved is not running.
So yeah, we use want to use nss_dns as a fallback for that case. I'm not
sure if that is what you are asking about.
Let me rephrase:
If /etc/resolv.conf is a regular file, will systemd-resolved deactivate
itself? Or use the name server configuration found there instead?
Thanks,
Florian
8:42 a.m.
On Thu, Apr 16, 2020, at 9:26 AM, Florian Weimer wrote:
* Zbigniew Jędrzejewski-Szmek:
> On Thu, Apr 16, 2020 at 12:53:48PM +0200, Florian Weimer wrote:
>> * Lennart Poettering:
>>
>> > On Mi, 15.04.20 16:30, Lennart Poettering (mzerqung(a)0pointer.de) wrote:
>> >
>> >> On Mi, 15.04.20 15:50, Florian Weimer (fweimer(a)redhat.com) wrote:
>> >>
>> >> > * Lennart Poettering:
>> >> >
>> >> > > 1. If /etc/resolv.conf is a regular file, resolved will
*consume* it
>> >> > > for DNS configuration, and never change it or modify it or
replace
>> >> > > it. If this mode is selected arbitrary other programs that
do DNS
>> >> > > will talk directly to the provided DNS servers, and
resolved is out
>> >> > > of the loop.
>> >> >
>> >> > > In mode #1 resolved neither manages /etc/resolv.conf nor
inserts
>> >> > > itself into DNS resolution in any way.
>> >> >
>> >> > What will nss_resolve do in this case? Nothing?
>> >>
>> >> The nss_resolve module is just a wrapper around resolved's bus
>> >> API. And the bus API uses resolved's own DNS resolution code. And
>> >> resolved is smart enough to automatically become a *consumer* of
>> >> /etc/nsswitch.conf (instead of a *manager* of it) if it is a regular
>> >> file instead of a symlink to resolved's own files in /run.
>> >
>> > Meh. I mean /etc/resolv.conf here, of course, not /etc/nsswitch.conf.
>>
>> So if /etc/resolv.conf comes from somewhere else, then nss_resolve will
>> still forward queries to the daemon, which contacts the upstream server
>> on nss_resolve's behave (possibly with some caching), and eventually
>> return the data to the application?
>
> nss-resolve is enabled/disabled through nsswitch.conf. It always talks to
> systemd-resolved using local IPC. It doesn't care about /etc/resolv.conf
> in any way.
>
> What Lennart wrote above applies to systemd-resolved and to things
> which look at /etc/resolv.conf for some reason. If nss-resolve is enabled,
> then only things which do not use nss at all would fall into this category.
>
>> Or does nss_resolve fail with UNAVAIL and expects nss_dns to fetch the
>> data?
>
> nss_resolve fails with UNAVAIL when systemd-resolved is not running.
> So yeah, we use want to use nss_dns as a fallback for that case. I'm not
> sure if that is what you are asking about.
Let me rephrase:
If /etc/resolv.conf is a regular file, will systemd-resolved deactivate
itself? Or use the name server configuration found there instead?
Based on earlier replies in the thread, resolved will use the nameservers from the file.
There's no mention of it disabling itself.
V/r,
James Cassell
8:45 a.m.
On Do, 16.04.20 15:26, Florian Weimer (fweimer(a)redhat.com) wrote:
If /etc/resolv.conf is a regular file, will systemd-resolved
deactivate
itself? Or use the name server configuration found there instead?
It will use it.
It's smart on this: if it finds a symlink there that points to one of
the files resolved manages it will assume it will not read the files,
and assume it's the *provider*, not the *consumer* of them. But if it
finds a regular file there it understands that and becomes a
*consumer* of that file, like any other tool, and knows it doesn't
provide the file anymore.
Lennart
--
Lennart Poettering, Berlin
8:50 a.m.
On Do, 16.04.20 12:53, Florian Weimer (fweimer(a)redhat.com) wrote:
> Meh. I mean /etc/resolv.conf here, of course, not
/etc/nsswitch.conf.
So if /etc/resolv.conf comes from somewhere else, then nss_resolve will
still forward queries to the daemon, which contacts the upstream server
on nss_resolve's behave (possibly with some caching), and eventually
return the data to the application?
correct.
Or does nss_resolve fail with UNAVAIL and expects nss_dns to fetch
the
data?
no.
Lennart
--
Lennart Poettering, Berlin
9:18 a.m.
* Lennart Poettering:
On Do, 16.04.20 12:53, Florian Weimer (fweimer(a)redhat.com) wrote:
> > Meh. I mean /etc/resolv.conf here, of course, not /etc/nsswitch.conf.
>
> So if /etc/resolv.conf comes from somewhere else, then nss_resolve will
> still forward queries to the daemon, which contacts the upstream server
> on nss_resolve's behave (possibly with some caching), and eventually
> return the data to the application?
correct.
> Or does nss_resolve fail with UNAVAIL and expects nss_dns to fetch the
> data?
no.
Okay, this behavior is nice and what I expect.
Thanks,
Florian
4:35 p.m.
migrating a couple of local servers to, atm, F32, i noted this planned/accepted
'systemd-wide change' for switching to systemd-resolved as default in >= F33,
here, and
https://fedoraproject.org/wiki/Changes/systemd-resolved
again, i understand it's default @ >= F33.
iiuc, tho, it should already be usable with F32?
attempting to enable 'mode #2' on a F32 install, my override configs are being
ignored.
reading more closely, i've managed to miss any comment re: config splitting into
"/etc/systemd/resolved.conf.d", either currently or planned.
looking at current install @ F32, there's only
"/etc/systemd/resolved.conf".
both docs referenced
https://www.freedesktop.org/software/systemd/man/resolved.conf.html
https://wiki.archlinux.org/index.php/Systemd-resolved
make mention of
/etc/systemd/resolved.conf.d/*.conf
config support.
in my F32 install, i've enabled
systemctl status systemd-resolved.service -l
● systemd-resolved.service - Network Name Resolution
Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; enabled; vendor
preset: disabled)
Active: active (running) since Sun 2020-07-26 13:58:26 PDT; 18min ago
created the necessary symlink,
ls -al /etc/resolv.conf
lrwxrwxrwx 1 root root 37 Jul 26 13:43 /etc/resolv.conf ->
/run/systemd/resolve/stub-resolv.conf
and, in the 'supported' /etc/systemd/resolved.conf.d dir,
config'd my local resolver
cat /etc/systemd/resolved.conf.d/dns_servers.conf
[Resolve]
DNS=10.0.1.53
Domains=.
and DISabled fallbacks
cat /etc/systemd/resolved.conf.d/fallback_dns.conf
[Resolve]
FallbackDNS=
but, after restart
systemctl restart systemd-resolved
i still see
resolvectl status
Global
LLMNR setting: yes
MulticastDNS setting: yes
DNSOverTLS setting: no
DNSSEC setting: allow-downgrade
DNSSEC supported: yes
Fallback DNS Servers: 1.1.1.1
8.8.8.8
1.0.0.1
8.8.4.4
2606:4700:4700::1111
2001:4860:4860::8888
2606:4700:4700::1001
2001:4860:4860::8844
...
which are still/only the defaults,
grep -i fallback /etc/systemd/resolved.conf
#FallbackDNS=1.1.1.1 8.8.8.8 1.0.0.1 8.8.4.4 2606:4700:4700::1111 2001:4860:4860::8888
2606:4700:4700::1001 2001:4860:4860::8844
assuming that conf.d/* configs _are_ to be supported for F33, and already work with F32,
what's the correct method/mechanism for overrides of the defaults?
2:57 p.m.
On Tue, Apr 14, 2020, at 3:23 PM, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/systemd-resolved
== Summary ==
Enable systemd-resolved by default. glibc will perform name resolution
using nss-resolve rather than nss-dns.
== Owner ==
* Name: [[User:catanzaro| Michael Catanzaro]]
* Email: <mcatanzaro(a)redhat.com>
== Detailed Description ==
We will enable systemd-resolved by default.
Does this require systemd to be running? How does this affect DNS resolution on a Fedora
33 container?
V/r
James Cassell
3:48 p.m.
On Tue, Apr 14, 2020 at 03:57:50PM -0400, James Cassell wrote:
On Tue, Apr 14, 2020, at 3:23 PM, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/systemd-resolved
>
> == Summary ==
>
> Enable systemd-resolved by default. glibc will perform name resolution
> using nss-resolve rather than nss-dns.
>
> == Owner ==
> * Name: [[User:catanzaro| Michael Catanzaro]]
> * Email: <mcatanzaro(a)redhat.com>
>
> == Detailed Description ==
>
> We will enable systemd-resolved by default.
>
Does this require systemd to be running? How does this affect DNS resolution on a Fedora
33 container?
That's a good point. With systemd-resolved not running, resolution
might not work properly.
There's two parts to this:
- whether a fallback is included in the nss stack
- whether dns servers are appropriately configured
For the first part: there should be no issue.
Upstream recommends nss-resolve(8) the following:
hosts: ... resolve [!UNAVAIL=return] dns ...
Assuming
that the same is done in Fedora, the nss stack will
automatically fall back to nss-dns when resolved is not running.
I guess the lesson here is the nsswitch.conf change should be
clarified in the proposal.
For the second part: the answer is complicated.
When /etc/resolv.conf is a symlink to /run/systemd/resolve/stub-resolv.conf,
nss-dns does not work when systemd-resolved stops. In the case of a
container without systemd running, this will be a broken symlink, and
nss-dns will not work either.
But we seem to already have this problem to some extent.
NetworkManager allows /etc/resolv.conf to be a symlink to
/run/NetworkManager/resolv.conf too, to support name servers
configured at run time with a read-only root, and with systemd
not running, NM won't either, and this will be a dangling symlink.
I'm not sure what the best path option here is. The path of least
resistance would be to simply leave /etc/resolv.conf out of this change.
nss-resolve doesn't care, and the effect is only on things which
don't use the nss stack, or read /etc/resolv.conf for other purposes.
Zbyszek
4:26 p.m.
On Tue, Apr 14, 2020 at 8:48 pm, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl> wrote:
I guess the lesson here is the nsswitch.conf change should be
clarified in the proposal.
OK, I've just added it at the end of this part here:
"systemd-libs currently has
[https://src.fedoraproject.org/rpms/systemd/blob/bb79fb73875f8e71841a1ee8e...
a %post scriplet] to enable nss-myhostname and nss-systemd by either
(a) modifying authselect's user-nsswitch.conf template, if authselect
is in use, or (b) directly modifying /etc/nsswitch.conf otherwise. We
will work with the systemd maintainers to enable nss-resolve here as
well by adding `resolve [!UNAVAIL=return]` to the hosts line."
Then the instructions in the change proposal for disabling
systemd-resolved say:
"Modify /etc/authselect/user-nsswitch.conf and remove resolve
[!UNAVAIL=return] from the hosts line. Run authselect apply-changes.
(If you have disabled authselect, then edit /etc/nsswitch.conf
directly.)"
I guess I should delete that from the proposal, since it's not needed?
I'm not sure what the best path option here is. The path of
least
resistance would be to simply leave /etc/resolv.conf out of this
change.
nss-resolve doesn't care, and the effect is only on things which
don't use the nss stack, or read /etc/resolv.conf for other purposes.
NetworkManager only enables its systemd-resolved backend if
/etc/resolv.conf is symlinked appropriately. So that needs to happen.
I didn't consider cases where systemd is not running because Fedora
hasn't supported booting without systemd in about a decade. But I guess
the problem here is for containers where systemd is not running inside
the container, but is running on the host system? I hadn't considered
this scenario. What do Ubuntu containers do? I guess those are not all
broken. :)
2:36 a.m.
* Michael Catanzaro:
On Tue, Apr 14, 2020 at 8:48 pm, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl> wrote:
> I guess the lesson here is the nsswitch.conf change should be
> clarified in the proposal.
OK, I've just added it at the end of this part here:
"systemd-libs currently has
[https://src.fedoraproject.org/rpms/systemd/blob/bb79fb73875f8e71841a1ee8e...
a %post scriplet] to enable nss-myhostname and nss-systemd by either
(a) modifying authselect's user-nsswitch.conf template, if authselect
is in use, or (b) directly modifying /etc/nsswitch.conf otherwise. We
will work with the systemd maintainers to enable nss-resolve here as
well by adding `resolve [!UNAVAIL=return]` to the hosts line."
At which position? After files?
Does systemd-resolved cache /etc/hosts?
And we really need to move /etc/nsswitch.conf out of glibc. We spend
some time on maintaining that file, when in fact it doesn't matter
because too many scriptlets and programs patch it.
Thanks,
Florian
9:12 a.m.
On Mi, 15.04.20 09:36, Florian Weimer (fweimer(a)redhat.com) wrote:
* Michael Catanzaro:
> On Tue, Apr 14, 2020 at 8:48 pm, Zbigniew Jędrzejewski-Szmek
> <zbyszek(a)in.waw.pl> wrote:
>> I guess the lesson here is the nsswitch.conf change should be
>> clarified in the proposal.
>
> OK, I've just added it at the end of this part here:
>
> "systemd-libs currently has
>
[https://src.fedoraproject.org/rpms/systemd/blob/bb79fb73875f8e71841a1ee8e...
> a %post scriplet] to enable nss-myhostname and nss-systemd by either
> (a) modifying authselect's user-nsswitch.conf template, if authselect
> is in use, or (b) directly modifying /etc/nsswitch.conf otherwise. We
> will work with the systemd maintainers to enable nss-resolve here as
> well by adding `resolve [!UNAVAIL=return]` to the hosts line."
At which position? After files?
The suggested line in nsswitch.conf is:
hosts: files mymachines resolve [!UNAVAIL=return] dns myhostname
See https://www.freedesktop.org/software/systemd/man/nss-resolve.html
So currently we leave "files" the way it is, taking precendence.
That said, resolved has a bus API for resolving hosts too, which gives
a bit richer an API to do things, instead of using
gethostbyname(). resolved parses and caches /etc/hosts for that
natively, so that we can server the same set of names when going via
the bus API or via NSS.
Does systemd-resolved cache /etc/hosts?
Yes.
Lennart
--
Lennart Poettering, Berlin
9:27 a.m.
* Lennart Poettering:
On Mi, 15.04.20 09:36, Florian Weimer (fweimer(a)redhat.com) wrote:
> * Michael Catanzaro:
>
> > On Tue, Apr 14, 2020 at 8:48 pm, Zbigniew Jędrzejewski-Szmek
> > <zbyszek(a)in.waw.pl> wrote:
> >> I guess the lesson here is the nsswitch.conf change should be
> >> clarified in the proposal.
> >
> > OK, I've just added it at the end of this part here:
> >
> > "systemd-libs currently has
> >
[https://src.fedoraproject.org/rpms/systemd/blob/bb79fb73875f8e71841a1ee8e...
> > a %post scriplet] to enable nss-myhostname and nss-systemd by either
> > (a) modifying authselect's user-nsswitch.conf template, if authselect
> > is in use, or (b) directly modifying /etc/nsswitch.conf otherwise. We
> > will work with the systemd maintainers to enable nss-resolve here as
> > well by adding `resolve [!UNAVAIL=return]` to the hosts line."
>
> At which position? After files?
The suggested line in nsswitch.conf is:
hosts: files mymachines resolve [!UNAVAIL=return] dns myhostname
See https://www.freedesktop.org/software/systemd/man/nss-resolve.html
So currently we leave "files" the way it is, taking precendence.
That said, resolved has a bus API for resolving hosts too, which gives
a bit richer an API to do things, instead of using
gethostbyname(). resolved parses and caches /etc/hosts for that
natively, so that we can server the same set of names when going via
the bus API or via NSS.
> Does systemd-resolved cache /etc/hosts?
Yes.
Then I don't understand why we are listing files first, before resolve.
If we can handle /etc/hosts through nss_resolve, with caching, we make
progress towards replacing nscd. /etc/hosts is one of the things not
handled by ssssd, so one of the remaining gaps would be covered.
Thanks,
Florian
9:34 a.m.
On Mi, 15.04.20 16:27, Florian Weimer (fweimer(a)redhat.com) wrote:
> That said, resolved has a bus API for resolving hosts too, which
gives
> a bit richer an API to do things, instead of using
> gethostbyname(). resolved parses and caches /etc/hosts for that
> natively, so that we can server the same set of names when going via
> the bus API or via NSS.
>
>> Does systemd-resolved cache /etc/hosts?
>
> Yes.
Then I don't understand why we are listing files first, before
resolve.
It should be fine to swap this around I guess. This hasn't come up
before. The /etc/hosts support in resolved was added primarily for
full compat when queries come in via dbus. It wasn't supposed to be a
better implementation of nss-files (though it effectively is, since we
parse on when the file changes and cache in memory), but I guess we
can decide it's not just compat feature now, but also and performance
improvement feature.
Lennart
--
Lennart Poettering, Berlin
10:02 a.m.
On Wed, Apr 15, 2020 at 4:12 pm, Lennart Poettering
<mzerqung(a)0pointer.de> wrote:
The suggested line in nsswitch.conf is:
hosts: files mymachines resolve [!UNAVAIL=return] dns myhostname
My plan is to use:
hosts: files resolve [!UNAVAIL=return] mdns4_minimal [NOTFOUND=return]
dns myhostname
Apparently there is some problem with mymachines, so we don't use it
currently, and adding it would require a separate change proposal. Then
we need to keep avahi as well.
I guess we can swap files and resolve if Florian thinks that's best.
Let's update the upstream manpage's recommendation if we do so, though.
11:33 a.m.
On Wed, Apr 15, 2020 at 10:02:17AM -0500, Michael Catanzaro wrote:
On Wed, Apr 15, 2020 at 4:12 pm, Lennart Poettering
<mzerqung(a)0pointer.de> wrote:
>The suggested line in nsswitch.conf is:
>
> hosts: files mymachines resolve [!UNAVAIL=return] dns myhostname
My plan is to use:
hosts: files resolve [!UNAVAIL=return] mdns4_minimal
[NOTFOUND=return] dns myhostname
Apparently there is some problem with mymachines, so we don't use it
currently, and adding it would require a separate change proposal.
Then we need to keep avahi as well.
I guess we can swap files and resolve if Florian thinks that's best.
Let's update the upstream manpage's recommendation if we do so,
though.
https://github.com/systemd/systemd/pull/15437
Zbyszek
12:05 p.m.
On Wed, Apr 15, 2020 at 4:33 pm, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl> wrote:
To change this for existing Fedora systems is going to require some
scriptlet hackery... somewhere (systemd package, maybe?).
1:28 p.m.
On Wed, Apr 15, 2020 at 12:05:40PM -0500, Michael Catanzaro wrote:
On Wed, Apr 15, 2020 at 4:33 pm, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl> wrote:
>https://github.com/systemd/systemd/pull/15437
To change this for existing Fedora systems is going to require some
scriptlet hackery... somewhere (systemd package, maybe?).
Yeah. We already have such hackery in systemd's %post macros, so while
this is not something enjoyable, we can add more... Alternatively, the
same rules might be moved to some other package, most likely the one
that ends up owning /etc/nsswitch.conf.
Zbyszek
10:02 a.m.
On Wed, Apr 15, 2020 at 9:36 am, Florian Weimer <fweimer(a)redhat.com>
wrote:
And we really need to move /etc/nsswitch.conf out of glibc. We
spend
some time on maintaining that file, when in fact it doesn't matter
because too many scriptlets and programs patch it.
Moving it to authselect might be sensible.
BTW: I have https://src.fedoraproject.org/rpms/glibc/pull-request/17
still outstanding to fix a mistake in glibc's version.
10:09 a.m.
On Mi, 15.04.20 10:02, Michael Catanzaro (mcatanzaro(a)gnome.org) wrote:
On Wed, Apr 15, 2020 at 9:36 am, Florian Weimer <fweimer(a)redhat.com> wrote:
> And we really need to move /etc/nsswitch.conf out of glibc. We spend
> some time on maintaining that file, when in fact it doesn't matter
> because too many scriptlets and programs patch it.
Moving it to authselect might be sensible.
Why not setup.rpm? /etc/hosts is owned by setup.rpm.
Lennart
--
Lennart Poettering, Berlin
10:43 a.m.
* Michael Catanzaro:
On Wed, Apr 15, 2020 at 9:36 am, Florian Weimer
<fweimer(a)redhat.com>
wrote:
> And we really need to move /etc/nsswitch.conf out of glibc. We spend
> some time on maintaining that file, when in fact it doesn't matter
> because too many scriptlets and programs patch it.
Moving it to authselect might be sensible.
I came up with setup:
<https://bugzilla.redhat.com/show_bug.cgi?id=1717384>
If authselect wants to take it, that's okay with me too. We can
reassign the bug.
BTW: I have https://src.fedoraproject.org/rpms/glibc/pull-request/17
still outstanding to fix a mistake in glibc's version.
I've merged it, sorry that it fell through the cracks.
Thanks,
Florian
8:01 a.m.
On 4/14/20 17:26, Michael Catanzaro wrote:
On Tue, Apr 14, 2020 at 8:48 pm, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl> wrote:
> I guess the lesson here is the nsswitch.conf change should be
> clarified in the proposal.
OK, I've just added it at the end of this part here:
"systemd-libs currently has
[https://src.fedoraproject.org/rpms/systemd/blob/bb79fb73875f8e71841a1ee8e...
a %post scriplet] to enable nss-myhostname and nss-systemd by either
(a) modifying authselect's user-nsswitch.conf template, if authselect
is in use, or (b) directly modifying /etc/nsswitch.conf otherwise. We
will work with the systemd maintainers to enable nss-resolve here as
well by adding `resolve [!UNAVAIL=return]` to the hosts line."
Then the instructions in the change proposal for disabling
systemd-resolved say:
"Modify /etc/authselect/user-nsswitch.conf and remove resolve
[!UNAVAIL=return] from the hosts line. Run authselect apply-changes.
(If you have disabled authselect, then edit /etc/nsswitch.conf
directly.)"
I guess I should delete that from the proposal, since it's not needed?
> I'm not sure what the best path option here is. The path of least
> resistance would be to simply leave /etc/resolv.conf out of this change.
> nss-resolve doesn't care, and the effect is only on things which
> don't use the nss stack, or read /etc/resolv.conf for other purposes.
NetworkManager only enables its systemd-resolved backend if
/etc/resolv.conf is symlinked appropriately. So that needs to happen.
I didn't consider cases where systemd is not running because Fedora
hasn't supported booting without systemd in about a decade. But I
guess the problem here is for containers where systemd is not running
inside the container, but is running on the host system? I hadn't
considered this scenario. What do Ubuntu containers do? I guess those
are not all broken. :)
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
We can change container engines (podman, Buildah, CRI-O) to handle this
but they need to have a location of a properly configured resolv.conf
file, somewhere on the system to be used without systemd.
9:27 a.m.
On Mi, 15.04.20 09:01, Daniel J Walsh (dwalsh(a)redhat.com) wrote:
> I didn't consider cases where systemd is not running because
Fedora
> hasn't supported booting without systemd in about a decade. But I
> guess the problem here is for containers where systemd is not running
> inside the container, but is running on the host system? I hadn't
> considered this scenario. What do Ubuntu containers do? I guess those
> are not all broken. :)
>
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
We can change container engines (podman, Buildah, CRI-O) to handle this
but they need to have a location of a properly configured resolv.conf
file, somewhere on the system to be used without systemd.
My suggestion for those container managers: if /etc/resolv.conf is a
regular file, always use that as copy source. If it is a symlinkt to
/run/systemd/resolve/stub-resolv.conf or
/run/systemd/resolve/resolv.conf then use
/run/systemd/resolve/resolv.conf as copy source.
Yes, I mean that, even if /run/systemd/resolve/stub-resolv.conf is the
symlink destination use the file without "stub-" in the name as copy
source. Because that file always contains the literal upstream DNS
servers, and does not redirect DNS traffic to 127.0.0.53 like the file
with "-stub" in the name does. Since containers are typically run
inside their own network namespace it's wise to use the upstream DNS
servers directly, instead of trying to the DNS forwarder called
resolved on localhost that is likely not going to be there in a netns
container.
The algorithm above in C-ish pseudo-code:
for (;;) {
fd = open("/etc/resolv.conf", O_RDONLY|O_CLOEXEC|O_NOFOLLOW);
if (fd >= 0)
break; /* success! it's a regular file */
if (errno != ELOOP)
break; /* failure! something unexpected */
/* It's a symlink */
r = readlink("/etc/resolv.conf", &dest);
if (r < 0) {
if (errno == EINVAL)
continue; /* Oh, it's not a symlink anymore?
somebody must just have replace
the file, let's try again */
/* failure! some unexpected error */
break;
}
/* Check where the symlink points. Check by absolute and by
relative paths, just in case. If this points to any of the
three files provided by systemd-resolved, use the one that
encodes upstream DNS info */
if (strcmp(dest, "/run/systemd/resolve/stub-resolv.conf") == 0 ||
strcmp(dest, "../run/systemd/resolve/stub-resolv.conf") == 0 ||
strcmp(dest, "/run/systemd/resolve/resolv.conf") == 0 ||
strcmp(dest, "../run/systemd/resolve/resolv.conf") == 0 ||
strcmp(dest, "/usr/lib/systemd/resolv.conf") == 0 ||
strcmp(dest, "../usr/lib/systemd/resolv.conf") == 0)) {
fd = open("/run/systemd/resolve/resolv.conf", O_RDONLY|O_CLOEXEC);
else
fd = open("/run/systemd/resolve/resolv.conf", O_RDONLY|O_CLOEXEC);
break;
}
You get the idea: use O_LOOP to check if it's a symlink and then use
readlink() to see if the file points to something managed by resolved.
Lennart
--
Lennart Poettering, Berlin
9:07 a.m.
On Di, 14.04.20 15:57, James Cassell (fedoraproject(a)cyberpear.com) wrote:
On Tue, Apr 14, 2020, at 3:23 PM, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/systemd-resolved
>
> == Summary ==
>
> Enable systemd-resolved by default. glibc will perform name resolution
> using nss-resolve rather than nss-dns.
>
> == Owner ==
> * Name: [[User:catanzaro| Michael Catanzaro]]
> * Email: <mcatanzaro(a)redhat.com>
>
> == Detailed Description ==
>
> We will enable systemd-resolved by default.
Does this require systemd to be running? How does this affect DNS resolution on a Fedora
33 container?
Depends.
If a container manager copies in /etc/resolv.conf from the host into
the container on container *start*, it might be wise to copy in
/run/systemd/resolve/resolv.conf instead of /etc/resolv.conf, if it
exists. That file in /run contains the currently up-to-date upstream
DNS info literally.
If a container builder copies in /etc/resolv.conf during build time,
it probably should insert something like 8.8.8.8 as DNS servers there,
also replacing whatever is there.
Note that the logic in systemd and resolved is very defensive: if
/etc/resolv.conf is not a symlink to
/run/systemd/resolve/{stub-,}resolv.conf then resolved will consume
/etc/resolv.conf instead of managing it (see other mail), hence a
container mgr/builder that wants to direct DNS traffic somewhere
should just override the file to whatever it wants, and things will
just work, regarldess if resolved runs in the container or not, and
resolved -- if used -- will honour whatever the container mgr/builder
put there.
Lennart
--
Lennart Poettering, Berlin
12:27 p.m.
On 4/15/20 10:07, Lennart Poettering wrote:
On Di, 14.04.20 15:57, James Cassell (fedoraproject(a)cyberpear.com)
wrote:
> On Tue, Apr 14, 2020, at 3:23 PM, Ben Cotton wrote:
>> https://fedoraproject.org/wiki/Changes/systemd-resolved
>>
>> == Summary ==
>>
>> Enable systemd-resolved by default. glibc will perform name resolution
>> using nss-resolve rather than nss-dns.
>>
>> == Owner ==
>> * Name: [[User:catanzaro| Michael Catanzaro]]
>> * Email: <mcatanzaro(a)redhat.com>
>>
>> == Detailed Description ==
>>
>> We will enable systemd-resolved by default.
> Does this require systemd to be running? How does this affect DNS resolution on a
Fedora 33 container?
Depends.
If a container manager copies in /etc/resolv.conf from the host into
the container on container *start*, it might be wise to copy in
/run/systemd/resolve/resolv.conf instead of /etc/resolv.conf, if it
exists. That file in /run contains the currently up-to-date upstream
DNS info literally.
Containers copy the /etc/resolv.conf. /etc/hosts on creation, that way
they can modify it internally,
It looks like podman will just follow the link. I setup this simple test
# ls -l /etc/resolv.conf
lrwxrwxrwx. 1 root root 16 Apr 15 13:25 /etc/resolv.conf -> /run/resolv.conf
# cat /etc/resolv.conf
# Generated by NetworkManager
search redhat.com
nameserver 10.5.30.160
nameserver 10.11.5.19
nameserver 192.168.1.1
# podman run fedora cat /etc/resolv.conf
search redhat.com
nameserver 10.5.30.160
nameserver 10.11.5.19
nameserver 192.168.1.1
So as long as the
/run/systemd/resolve/resolv.conf
file is properly formated, our container engines will just work.
If a container builder copies in /etc/resolv.conf during build time,
it probably should insert something like 8.8.8.8 as DNS servers there,
also replacing whatever is there.
Note that the logic in systemd and resolved is very defensive: if
/etc/resolv.conf is not a symlink to
/run/systemd/resolve/{stub-,}resolv.conf then resolved will consume
/etc/resolv.conf instead of managing it (see other mail), hence a
container mgr/builder that wants to direct DNS traffic somewhere
should just override the file to whatever it wants, and things will
just work, regarldess if resolved runs in the container or not, and
resolved -- if used -- will honour whatever the container mgr/builder
put there.
Lennart
--
Lennart Poettering, Berlin
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
4:06 p.m.
On Wed, Apr 15, 2020, at 1:27 PM, Daniel Walsh wrote:
On 4/15/20 10:07, Lennart Poettering wrote:
> On Di, 14.04.20 15:57, James Cassell (fedoraproject(a)cyberpear.com) wrote:
>
>> On Tue, Apr 14, 2020, at 3:23 PM, Ben Cotton wrote:
>>> https://fedoraproject.org/wiki/Changes/systemd-resolved
>>>
>>> == Summary ==
>>>
>>> Enable systemd-resolved by default. glibc will perform name resolution
>>> using nss-resolve rather than nss-dns.
>>>
>>> == Owner ==
>>> * Name: [[User:catanzaro| Michael Catanzaro]]
>>> * Email: <mcatanzaro(a)redhat.com>
>>>
>>> == Detailed Description ==
>>>
>>> We will enable systemd-resolved by default.
>> Does this require systemd to be running? How does this affect DNS resolution on
a Fedora 33 container?
> Depends.
>
> If a container manager copies in /etc/resolv.conf from the host into
> the container on container *start*, it might be wise to copy in
> /run/systemd/resolve/resolv.conf instead of /etc/resolv.conf, if it
> exists. That file in /run contains the currently up-to-date upstream
> DNS info literally.
Containers copy the /etc/resolv.conf. /etc/hosts on creation, that way
they can modify it internally,
It looks like podman will just follow the link. I setup this simple test
# ls -l /etc/resolv.conf
lrwxrwxrwx. 1 root root 16 Apr 15 13:25 /etc/resolv.conf -> /run/resolv.conf
# cat /etc/resolv.conf
# Generated by NetworkManager
search redhat.com
nameserver 10.5.30.160
nameserver 10.11.5.19
nameserver 192.168.1.1
# podman run fedora cat /etc/resolv.conf
search redhat.com
nameserver 10.5.30.160
nameserver 10.11.5.19
nameserver 192.168.1.1
So as long as the
/run/systemd/resolve/resolv.conf
file is properly formated, our container engines will just work.
I think there's some existing black magic to handle the case when resolv.conf
references 127.0.0.1... maybe it already also works for 127.0.0.53. Otherwise, maybe it
could be patched to handle 127.0.0.0/8 in the same way. Then no special casing for
resolved would be needed.
V/r,
James Cassell
> >
> > If a container builder copies in /etc/resolv.conf during build time,
> > it probably should insert something like 8.8.8.8 as DNS servers there,
> > also replacing whatever is there.
> >
> > Note that the logic in systemd and resolved is very defensive: if
> > /etc/resolv.conf is not a symlink to
> > /run/systemd/resolve/{stub-,}resolv.conf then resolved will consume
> > /etc/resolv.conf instead of managing it (see other mail), hence a
> > container mgr/builder that wants to direct DNS traffic somewhere
> > should just override the file to whatever it wants, and things will
> > just work, regarldess if resolved runs in the container or not, and
> > resolved -- if used -- will honour whatever the container mgr/builder
> > put there.
> >
> > Lennart
> >
9:50 a.m.
On 4/15/20 17:06, James Cassell wrote:
On Wed, Apr 15, 2020, at 1:27 PM, Daniel Walsh wrote:
> On 4/15/20 10:07, Lennart Poettering wrote:
>> On Di, 14.04.20 15:57, James Cassell (fedoraproject(a)cyberpear.com) wrote:
>>
>>> On Tue, Apr 14, 2020, at 3:23 PM, Ben Cotton wrote:
>>>> https://fedoraproject.org/wiki/Changes/systemd-resolved
>>>>
>>>> == Summary ==
>>>>
>>>> Enable systemd-resolved by default. glibc will perform name resolution
>>>> using nss-resolve rather than nss-dns.
>>>>
>>>> == Owner ==
>>>> * Name: [[User:catanzaro| Michael Catanzaro]]
>>>> * Email: <mcatanzaro(a)redhat.com>
>>>>
>>>> == Detailed Description ==
>>>>
>>>> We will enable systemd-resolved by default.
>>> Does this require systemd to be running? How does this affect DNS resolution
on a Fedora 33 container?
>> Depends.
>>
>> If a container manager copies in /etc/resolv.conf from the host into
>> the container on container *start*, it might be wise to copy in
>> /run/systemd/resolve/resolv.conf instead of /etc/resolv.conf, if it
>> exists. That file in /run contains the currently up-to-date upstream
>> DNS info literally.
> Containers copy the /etc/resolv.conf. /etc/hosts on creation, that way
> they can modify it internally,
>
> It looks like podman will just follow the link. I setup this simple test
>
> # ls -l /etc/resolv.conf
> lrwxrwxrwx. 1 root root 16 Apr 15 13:25 /etc/resolv.conf -> /run/resolv.conf
> # cat /etc/resolv.conf
> # Generated by NetworkManager
> search redhat.com
> nameserver 10.5.30.160
> nameserver 10.11.5.19
> nameserver 192.168.1.1
> # podman run fedora cat /etc/resolv.conf
> search redhat.com
> nameserver 10.5.30.160
> nameserver 10.11.5.19
> nameserver 192.168.1.1
>
> So as long as the
>
> /run/systemd/resolve/resolv.conf
>
> file is properly formated, our container engines will just work.
>
I think there's some existing black magic to handle the case when resolv.conf
references 127.0.0.1... maybe it already also works for 127.0.0.53. Otherwise, maybe it
could be patched to handle 127.0.0.0/8 in the same way. Then no special casing for
resolved would be needed.
V/r,
James Cassell
Yes I believe the container engines see 127.0.0.1 and switch it to
8.8.8.8
>> If a container builder copies in /etc/resolv.conf during
build time,
>> it probably should insert something like 8.8.8.8 as DNS servers there,
>> also replacing whatever is there.
>>
>> Note that the logic in systemd and resolved is very defensive: if
>> /etc/resolv.conf is not a symlink to
>> /run/systemd/resolve/{stub-,}resolv.conf then resolved will consume
>> /etc/resolv.conf instead of managing it (see other mail), hence a
>> container mgr/builder that wants to direct DNS traffic somewhere
>> should just override the file to whatever it wants, and things will
>> just work, regarldess if resolved runs in the container or not, and
>> resolved -- if used -- will honour whatever the container mgr/builder
>> put there.
>>
>> Lennart
>>
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
8:06 a.m.
On Mi, 15.04.20 13:27, Daniel J Walsh (dwalsh(a)redhat.com) wrote:
> If a container manager copies in /etc/resolv.conf from the host
into
> the container on container *start*, it might be wise to copy in
> /run/systemd/resolve/resolv.conf instead of /etc/resolv.conf, if it
> exists. That file in /run contains the currently up-to-date upstream
> DNS info literally.
Containers copy the /etc/resolv.conf. /etc/hosts on creation, that way
they can modify it internally,
It looks like podman will just follow the link. I setup this simple test
# ls -l /etc/resolv.conf
lrwxrwxrwx. 1 root root 16 Apr 15 13:25 /etc/resolv.conf -> /run/resolv.conf
# cat /etc/resolv.conf
# Generated by NetworkManager
search redhat.com
nameserver 10.5.30.160
nameserver 10.11.5.19
nameserver 192.168.1.1
# podman run fedora cat /etc/resolv.conf
search redhat.com
nameserver 10.5.30.160
nameserver 10.11.5.19
nameserver 192.168.1.1
So as long as the
/run/systemd/resolve/resolv.conf
file is properly formated, our container engines will just work.
Yes, /run/systemd/resolve/resolv.conf is properly formatted, the way
glibc expects it. It only contains IPv4 + IPv6 "nameserver" stanzas as
well as "search" stanzas.
The files systemd-resolved generates there look something like this:
```
nameserver 172.31.0.1
nameserver fd00::3a10:d5ff:fe78:6bbe
search fritz.box
```
(with some additional explanatory comments at the top, which I
stripped here)
Key is to access it under its proper path instead of via the symlink,
for the aforementioned reasons.
Lennart
--
Lennart Poettering, Berlin
12:10 a.m.
On Tuesday, April 14, 2020 9:23:27 PM CEST Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/systemd-resolved
== Summary ==
Enable systemd-resolved by default. ...
We had serious headaches because racy systemd-resolved got enabled for
some unknown reasons on copr builders before (and my host as well, for
example). I filled bug [1] and then I was told that nobody
tests/maintains systemd-resolved... why on earth I'd opt-in to use that.
Can we fix the bug, so the generated resolv.conf pointing to local server
does work _immediately_ inside mock, and isn't it port-triggered (or what
it is :-))?
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1710699
Pavel
7:57 a.m.
On Mi, 15.04.20 07:10, Pavel Raiskup (praiskup(a)redhat.com) wrote:
On Tuesday, April 14, 2020 9:23:27 PM CEST Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/systemd-resolved
>
> == Summary ==
>
> Enable systemd-resolved by default. ...
We had serious headaches because racy systemd-resolved got enabled for
some unknown reasons on copr builders before (and my host as well, for
example). I filled bug [1] and then I was told that nobody
tests/maintains systemd-resolved... why on earth I'd opt-in to use that.
Can we fix the bug, so the generated resolv.conf pointing to local server
does work _immediately_ inside mock, and isn't it port-triggered (or what
it is :-))?
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1710699
For the sake of the archives, let's follow-up the discussion on this
specific issue on the bug report, instead of the ML.
Lennart
--
Lennart Poettering, Berlin
12:42 a.m.
On 4/14/20 9:23 PM, Ben Cotton wrote:
=== Multicast DNS ===
systemd-resolved's multicast DNS support conflicts with Avahi. Per
recommendation from the systemd developers, we will change the default
value of this setting in Fedora from the upstream default
`MulticastDNS=yes` to `MulticastDNS=resolve`. Multicast DNS resolving
will be enabled, but responding will be disabled. This will require
adding a new systemd build option to control the default value of the
MulticastDNS setting, similar to the existing `default-dnssec` and
`default-dns-over-tls` build options.
Hi Michael,
would you mind telling me more about the change's impact on MDNS support
provided by Avahi and nss-mdns package, since you mention Avahi
conflicts with systemd-resolved?
CUPS relies on Avahi/nss-mdns for its MDNS functionality (resolving MDNS
addresses, browsing services, registering services...) because it is
essential for automatic printer discovery and driverless printing
functionality, which is supported by devices since 2010.
According https://github.com/apple/cups/issues/5452 systemd-resolved was
not the replacement for Avahi at the time, so is there a way how to make
Avahi work with the change, hopefully as default?
Non-working MDNS via Avahi would put us back in <2010.
Thank you in advance for response!
Zdenek
--
Zdenek Dohnal
Software Engineer
Red Hat Czech - Brno TPB-C
2:11 a.m.
On Wed, Apr 15, 2020 at 07:42:12AM +0200, Zdenek Dohnal wrote:
On 4/14/20 9:23 PM, Ben Cotton wrote:
> === Multicast DNS ===
>
> systemd-resolved's multicast DNS support conflicts with Avahi. Per
> recommendation from the systemd developers, we will change the default
> value of this setting in Fedora from the upstream default
> `MulticastDNS=yes` to `MulticastDNS=resolve`. Multicast DNS resolving
> will be enabled, but responding will be disabled. This will require
> adding a new systemd build option to control the default value of the
> MulticastDNS setting, similar to the existing `default-dnssec` and
> `default-dns-over-tls` build options.
>
>
Hi Michael,
would you mind telling me more about the change's impact on MDNS support
provided by Avahi and nss-mdns package, since you mention Avahi
conflicts with systemd-resolved?
It conflicts in the default settings of "yes". With that changed
to "resolve" as described, there should be no interference with Avahi.
resolved will function as a client, without announcing hostnames or
services.
Zbyszek
3:08 a.m.
* Ben Cotton:
Enable systemd-resolved by default. glibc will perform name
resolution
using nss-resolve rather than nss-dns.
Is this intended for Fedora Server and others as well, or just
Workstation? I assume it's for everywhere.
systemd-resolved has been enabled by default in Ubuntu since Ubuntu
16.10, but please note we are doing this differently than Ubuntu has.
Ubuntu does not use nss-resolve. Instead, Ubuntu uses the traditional
nss-dns provided by glibc upstream, so glibc on Ubuntu continues to
read /etc/resolv.conf, as is traditional. This extra step is not
useful and not recommended by upstream. We want to follow upstream
recommendations in using nss-resolve instead.
I cannot find documentation of the systemd stub resolver behavior: how
it handles search list processing, and how it decides which upstream
name servers to query.
Most Kubernetes/OKD clusters assume that both single-label and
multi-label query names are forwarded over DNS (contrary to ICANN
recommendations), and that DNS servers are processed in listed order for
all queries (no parallel queries, no randomized server selection). If
systemd-resolved behaves differently, it can make Fedora incompatible
with Kubernetes clusters. (This is one reason why glibc still not
follows the ICANN recommendations.)
With the Ubuntu approach, search list processing still resides within
glibc, so their Kubernetes experience would not necessarily match ours.
=== Split DNS ===
When systemd-resolved is enabled, users who use multiple VPNs at the
same time will notice that DNS requests are now sent to the correct
DNS server by default. Previously, this scenario would result in
embarrassing "DNS leaks" and, depending on the order that the VPN
connections were established, possible failure to resolve private
resources. These scenarios will now work properly. For example,
consider the scenario of Distrustful Denise, who (quite reasonably)
does not trust her ISP. Denise uses a public VPN service,
public-vpn.example.com, to hide her internet activity from her ISP,
but she also needs to use her employer's corporate VPN,
corporation.example.com, in order to access internal company resources
while working from home. Using the Network panel in System Settings,
Denise has configured her employer's VPN to "use this connection only
for resources on its network." Distrustful Denise expects that her
employer's VPN will receive all traffic for corporation.example.com,
and no other traffic. And while this mostly works in Fedora 32, she
discovers that it does not work properly for DNS:
Will Fedora treat such cross-VPN leaks as security bugs going and
forward and fix them? (I suspect it would require constant work, and
lots of it.)
Is this expected to work with the Red Hat VPN out of the box, or do we
have to disable all this and use a custom configuration? Has this been
discussed with Infosec? It looks like this will break their DNS
sinkholing for domains such as REDHAT[.]CO (not COM).
== Scope ==
* Other developers: This change requires coordination with the
systemd
and authselect maintainers.
It may also need to changes to Postfix (for DANE/TLSA handling in
particular, depending on the level of DNSSEC support, see below).
libvirt may need changes as well, for its internal DNS relay.
The manual page resolv.conf(5) needs to be updated.
Since libnss_resolve.so.2 is still linked against libpthread and we
might not be able to remove libpthread from glibc as a separate library
in time for Fedora 33, some applications may have to start linking
against libpthread explicitly even though they do not actually need it.
(This is due to a long-standing limitation of loading libpthread via
dlopen.)
=== DNSSEC ===
systemd-resolved's DNSSEC support is known to cause compatibility
problems with certain network access points. Per recommendation from
the systemd developers, we will change the default value of this
setting in Fedora from the upstream default `DNSSEC=allow-downgrade`
to `DNSSEC=no` by building systemd with the build option
`-Ddefault-dnssec=no`. The upstream default attempts to use DNSSEC if
it is working, but automatically disable it otherwise, allowing
man-in-the-middle attackers to disable DNSSEC. Sadly, even the
allow-downgrade setting suffers known compatibility problems. Because
Fedora is not prepared to handle an influx of DNSSEC-related bug
reports, we will disable this feature altogether. We anticipate that
enabling DNSSEC by default will not be possible in the foreseeable
future, or perhaps ever. Instead, enabling DNS over TLS (when
supported by the DNS server) seems likely in the near future.
Will the built-in DNS server still support DNSSEC without validation,
passing through the records if they are requested by the client over the
DNS interface? The section above is not clear.
Thanks,
Florian
3:29 a.m.
On 15/04/2020 09:08, Florian Weimer wrote:
I cannot find documentation of the systemd stub resolver behavior:
how
it handles search list processing, and how it decides which upstream
name servers to query.
As I understand the terminology the "stub resolver" in systemd-resolved
refers to the thing that listens on 127.0.0.53 and that won't do
anything clever with single label queries because it will expect
it is answering DNS queries - that is exactly the way that Ubuntu
uses it.
Most Kubernetes/OKD clusters assume that both single-label and
multi-label query names are forwarded over DNS (contrary to ICANN
recommendations), and that DNS servers are processed in listed order for
all queries (no parallel queries, no randomized server selection). If
systemd-resolved behaves differently, it can make Fedora incompatible
with Kubernetes clusters. (This is one reason why glibc still not
follows the ICANN recommendations.)
When accessed via nss-resolve single label queries will be subject
to search list processing but I don't believe multi label ones will.
Each interface can have DNS servers and search domains as well as
there being global ones. There can also be search domains with a
prefix of "~" which force queries for that domain to be sent to a
specific interface (this is how the VPN thing works).
I'm not sure what happens if there are multiple interfaces with
no specific routing but I think it may try them all?
It definitely doesn't use the servers on an interface in any
particular order, but I didn't think glibc did either? It has a
current server but will sometimes change it based on how well
they are responding or something.
Is this expected to work with the Red Hat VPN out of the box, or do
we
have to disable all this and use a custom configuration? Has this been
discussed with Infosec? It looks like this will break their DNS
sinkholing for domains such as REDHAT[.]CO (not COM).
I think so long as the VPN interface has ~redhat.co in it's search
list then queries for that domain will be forced to the servers for
that interface if that's what is required?
Will the built-in DNS server still support DNSSEC without
validation,
passing through the records if they are requested by the client over the
DNS interface? The section above is not clear.
I don't think so no. I happen to have a query to hand which fails
validation due to a bug in systemd-resolved and I get SERVFAIL when
querying 127.0.0.53 even with +cdflag on the dig command.
Tom
--
Tom Hughes (tom(a)compton.nu)
http://compton.nu/
3:37 a.m.
On 15/04/2020 09:29, Tom Hughes via devel wrote:
I'm not sure what happens if there are multiple interfaces with
no specific routing but I think it may try them all?
Found the documentation now - it does try them all. Full details
from systemd-resolved(8) are:
Lookup requests are routed to the available DNS servers, LLMNR and
MulticastDNS interfaces according to the following rules:
· Lookups for the special hostname "localhost" are never routed to
the network. (A few other, special domains are handled the same
way.)
· Single-label names are routed to all local interfaces capable of IP
multicasting, using the LLMNR protocol. Lookups for IPv4 addresses
are only sent via LLMNR on IPv4, and lookups for IPv6 addresses are
only sent via LLMNR on IPv6. Lookups for the locally configured
host name and the "_gateway" host name are never routed to LLMNR.
· Multi-label names with the domain suffix ".local" are routed to all
local interfaces capable of IP multicasting, using the MulticastDNS
protocol. As with LLMNR IPv4 address lookups are sent via IPv4 and
IPv6 address lookups are sent via IPv6.
· Other multi-label names are routed to all local interfaces that
have a DNS server configured, plus the globally configured DNS
server if there is one. Address lookups from the link-local address
range are never routed to DNS. Note that by default lookups for
domains with the ".local" suffix are not routed to DNS servers,
unless the domain is specified explicitly as routing or search
domain for the DNS server and interface. This means that on
networks where the ".local" domain is defined in a site-specific
DNS server, explicit search or routing domains need to be
configured to make lookups within this DNS domain work. Note that
today it's generally recommended to avoid defining ".local" in a
DNS server, as RFC6762[3] reserves this domain for exclusive
MulticastDNS use.
If lookups are routed to multiple interfaces, the first successful
response is returned (thus effectively merging the lookup zones on all
matching interfaces). If the lookup failed on all interfaces, the last
failing response is returned.
Routing of lookups may be influenced by configuring per-interface
domain names and other settings. See systemd.network(5) and
resolvectl(1) for details. The following query routing logic applies
for unicast DNS traffic:
· If a name to look up matches (that is: is equal to or has as
suffix) any of the configured search or route-only domains of any
link (or the globally configured DNS settings), the "best matching"
search/route-only domain is determined: the matching one with the
most labels. The query is then sent to all DNS servers of any links
or the globally configured DNS servers associated with this "best
matching" search/route-only domain. (Note that more than one link
might have this same "best matching" search/route-only domain
configured, in which case the query is sent to all of them in
parallel).
· If a query does not match any configured search/route-only domain
(neither per-link nor global), it is sent to all DNS servers that
are configured on links with the "DNS default route" option set, as
well as the globally configured DNS server.
· If there is no link configured as "DNS default route" and no global
DNS server configured, the compiled-in fallback DNS server is used.
· Otherwise the query is failed as no suitable DNS servers could be
determined.
The "DNS default route" option is a boolean setting configurable with
resolvectl or in .network files. If not set, it is implicitly
determined based on the configured DNS domains for a link: if there's
any route-only domain (not matching "~.") it defaults to false,
otherwise to true.
Effectively this means: in order to preferably route all DNS queries
not explicitly matched by search/route-only domain configuration to a
specific link, configure a "~." route-only domain on it. This will
ensure that other links will not be considered for the queries (unless
they too carry such a route-only domain). In order to route all such
DNS queries to a specific link only in case no other link is
preferable, then set the "DNS default route" option for the link to
true, and do not configure a "~." route-only domain on it. Finally, in
order to ensure that a specific link never receives any DNS traffic not
matching any of its configured search/route-only domains, set the "DNS
default route" option for it to false.
Tom
--
Tom Hughes (tom(a)compton.nu)
http://compton.nu/
3:53 a.m.
* Tom Hughes:
· Single-label names are routed to all local interfaces
capable of IP
multicasting, using the LLMNR protocol. Lookups for IPv4 addresses
are only sent via LLMNR on IPv4, and lookups for IPv6 addresses are
only sent via LLMNR on IPv6. Lookups for the locally configured
host name and the "_gateway" host name are never routed to LLMNR.
Routing of lookups may be influenced by configuring
per-interface
domain names and other settings. See systemd.network(5) and
resolvectl(1) for details. The following query routing logic applies
for unicast DNS traffic:
· If a name to look up matches (that is: is equal to or has as
suffix) any of the configured search or route-only domains of any
link (or the globally configured DNS settings), the "best matching"
search/route-only domain is determined: the matching one with the
most labels. The query is then sent to all DNS servers of any links
or the globally configured DNS servers associated with this "best
matching" search/route-only domain. (Note that more than one link
might have this same "best matching" search/route-only domain
configured, in which case the query is sent to all of them in
parallel).
· If a query does not match any configured search/route-only domain
(neither per-link nor global), it is sent to all DNS servers that
are configured on links with the "DNS default route" option set, as
well as the globally configured DNS server.
· If there is no link configured as "DNS default route" and no global
DNS server configured, the compiled-in fallback DNS server is used.
· Otherwise the query is failed as no suitable DNS servers could be
determined.
Thanks. Does this mean that no search list processing happens, for
neither single-label names (per for the first paragraph), nor for
multi-label names (per the routing description)? Or is this process
described in some other context?
Thanks,
Florian
3:59 a.m.
On 15/04/2020 09:53, Florian Weimer wrote:
Thanks. Does this mean that no search list processing happens, for
neither single-label names (per for the first paragraph), nor for
multi-label names (per the routing description)? Or is this process
described in some other context?
That text doesn't mention search list processing because I assume
it is describing what happens to each name after any domain from the
search list has been added but resolved.conf(5) says:
Domains=
A space-separated list of domains. These domains are used as search
suffixes when resolving single-label host names (domain names which
contain no dot), in order to qualify them into fully-qualified
domain names (FQDNs). Search domains are strictly processed in the
order they are specified, until the name with the suffix appended
is found. For compatibility reasons, if this setting is not
specified, the search domains listed in /etc/resolv.conf are used
instead, if that file exists and any domains are configured in it.
This setting defaults to the empty list.
Specified domain names may optionally be prefixed with "~". In this
case they do not define a search path, but preferably direct DNS
queries for the indicated domains to the DNS servers configured
with the system DNS= setting (see above), in case additional,
suitable per-link DNS servers are known. If no per-link DNS servers
are known using the "~" syntax has no effect. Use the construct
"~." (which is composed of "~" to indicate a routing
domain and
"." to indicate the DNS root domain that is the implied suffix of
all DNS domains) to use the system DNS server defined with DNS=
preferably for all domains.
That is about the global option but the same logic applies to per-interface
search lists I assume.
Tom
--
Tom Hughes (tom(a)compton.nu)
http://compton.nu/
10:26 a.m.
On Mi, 15.04.20 10:53, Florian Weimer (fweimer(a)redhat.com) wrote:
Thanks. Does this mean that no search list processing happens, for
neither single-label names (per for the first paragraph), nor for
multi-label names (per the routing description)? Or is this process
described in some other context?
We never suffix search domains to multi-label names. We do
traditional suffixing however for single-label names.
Lennart
--
Lennart Poettering, Berlin
3:48 a.m.
* Tom Hughes:
On 15/04/2020 09:08, Florian Weimer wrote:
> I cannot find documentation of the systemd stub resolver behavior: how
> it handles search list processing, and how it decides which upstream
> name servers to query.
As I understand the terminology the "stub resolver" in systemd-resolved
refers to the thing that listens on 127.0.0.53 and that won't do
anything clever with single label queries because it will expect
it is answering DNS queries - that is exactly the way that Ubuntu
uses it.
Well, the whole thing is a stub resolver externally, even if it doesn't
speak DNS with applications. It has to perform upstream server
selection and search list processing in some way. The search list
processing turns into the responsibility of the local client
(application) only on the DNS interface.
To be clear here, glibc does not perform generic search list processing
for all NSS modules, that behavior is specific to nss_dns. Any DNS
lookalike that aims to replace nss_dns has to implement some search list
processing from scratch.
> Most Kubernetes/OKD clusters assume that both single-label and
> multi-label query names are forwarded over DNS (contrary to ICANN
> recommendations), and that DNS servers are processed in listed order for
> all queries (no parallel queries, no randomized server selection). If
> systemd-resolved behaves differently, it can make Fedora incompatible
> with Kubernetes clusters. (This is one reason why glibc still not
> follows the ICANN recommendations.)
When accessed via nss-resolve single label queries will be subject
to search list processing but I don't believe multi label ones will.
That is reasonable (and matches ICANN recommendations), but it looks
like it will break many Kubernetes deployments unfortunatelly.
It definitely doesn't use the servers on an interface in any
particular order, but I didn't think glibc did either? It has a
current server but will sometimes change it based on how well
they are responding or something.
No, glibc does not do this by default. (There is a non-default “rotate”
option that provides some randomness in the server selection.)
Actually, Fedora's current NetworkManager/OpenVPN behavior depends on
this because it lists the original system name server in
/etc/resolv.conf after the ones received over OpenVPN. This means that
with randomized/parallel queries, you might try to resolve internal
domains over the public Internet, and get unwanted/unusable result.
The second Kubernetes issue I worry about [1] is that the CoreDNS name
server is installed first, and it does additional rule-based processing
for in-cluster names. External DNS servers are listed later. Parallel
queries and random server selection could bypass the CoreDNS service for
queries that need to be handled by it.
[1] I have no real Kubernetes experience, I'm relaying (perhaps
imperfectly) the results of discussions I had with people who actually
know something about it.
> Is this expected to work with the Red Hat VPN out of the box, or
do we
> have to disable all this and use a custom configuration? Has this been
> discussed with Infosec? It looks like this will break their DNS
> sinkholing for domains such as REDHAT[.]CO (not COM).
I think so long as the VPN interface has ~redhat.co in it's search
list then queries for that domain will be forced to the servers for
that interface if that's what is required?
Does OpenVPN log the list of these domains somewhere? Or do they have
to be configured manually?
> Will the built-in DNS server still support DNSSEC without
validation,
> passing through the records if they are requested by the client over the
> DNS interface? The section above is not clear.
I don't think so no. I happen to have a query to hand which fails
validation due to a bug in systemd-resolved and I get SERVFAIL when
querying 127.0.0.53 even with +cdflag on the dig command.
Ugh. That will have to be fixed, otherwise it will break DANE/TLSA and
other DNSSEC-mandatory functionality on upgrades: the system used to
have a DNSSEC-clean path to the outside world, and after the switch to
systemd-resolved, it won't.
Thanks,
Florian
4:11 a.m.
On 15/04/2020 09:48, Florian Weimer wrote:
>> Is this expected to work with the Red Hat VPN out of the box,
or do we
>> have to disable all this and use a custom configuration? Has this been
>> discussed with Infosec? It looks like this will break their DNS
>> sinkholing for domains such as REDHAT[.]CO (not COM).
>
> I think so long as the VPN interface has ~redhat.co in it's search
> list then queries for that domain will be forced to the servers for
> that interface if that's what is required?
Does OpenVPN log the list of these domains somewhere? Or do they have
to be configured manually?
I think a lot will depend on exactly how it is setup. My openvpn
setups on linux tend to use an up script to configure DNS things
so my VPN to home just has an up script that does:
resolvectl dns $1 172.16.15.1 172.16.15.2 172.16.15.5
resolvectl domain $1 ~compton.nu ~15.16.172.in-addr.arpa
~d.b.0.0.0.b.8.0.1.0.0.2.ip6.arpa
resolvectl flush-caches
To set the DNS servers on the interface and force routing of
certain domains to it.
I'm not sure OpenVPN itself has any way to do DNS setup automatically
on linux but the NetworkManager integration might, I don't use that
though.
Tom
--
Tom Hughes (tom(a)compton.nu)
http://compton.nu/
6:38 a.m.
* Tom Hughes:
I'm not sure OpenVPN itself has any way to do DNS setup
automatically
on linux but the NetworkManager integration might, I don't use that
though.
Yes, the NetworkManager integration seems to mirror what happens on
Windows, by looking at the foreign_option_* environment variables and
processing those which start with "dhcp-option ".
Not sure if that's compatible with the new split DNS model because VPN1
could simply start pushing longer names in the scope of VPN2, thus
hijacking internal traffic there (and this sort of hijacking is exactly
what a DNS sinkhole against typosquatting would need).
Thanks,
Florian
10:02 a.m.
On Wed, Apr 15, 2020 at 1:38 pm, Florian Weimer <fweimer(a)redhat.com>
wrote:
Not sure if that's compatible with the new split DNS model
because
VPN1
could simply start pushing longer names in the scope of VPN2, thus
hijacking internal traffic there (and this sort of hijacking is
exactly
what a DNS sinkhole against typosquatting would need).
You deserve bonus points for thinking like an attacker and exploring
the security model, but let's assume the configured VPNs are trusted.
Otherwise the user is screwed no matter what. ;)
9:18 a.m.
On Wed, 2020-04-15 at 10:02 -0500, Michael Catanzaro wrote:
On Wed, Apr 15, 2020 at 1:38 pm, Florian Weimer
<fweimer(a)redhat.com>
wrote:
> Not sure if that's compatible with the new split DNS model because
> VPN1
> could simply start pushing longer names in the scope of VPN2, thus
> hijacking internal traffic there (and this sort of hijacking is
> exactly
> what a DNS sinkhole against typosquatting would need).
You deserve bonus points for thinking like an attacker and exploring
the security model, but let's assume the configured VPNs are
trusted.
Otherwise the user is screwed no matter what. ;)
Trusted for what? I would expect corporate VPNs doing such tricks to
monitor the user's internet traffic. Which does not mean the user is
fully screwed with such VPN if he for example uses hardcoded
configuration of a caching nameserver.
--
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]
9:41 a.m.
On Thu, Apr 16, 2020 at 4:18 pm, Tomas Mraz <tmraz(a)redhat.com> wrote:
Trusted for what? I would expect corporate VPNs doing such tricks to
monitor the user's internet traffic. Which does not mean the user is
fully screwed with such VPN if he for example uses hardcoded
configuration of a caching nameserver.
In Florian's scenario, one of the VPNs is actively malicious. E.g.
public-vpn.example.com tries to hijack DNS for
subdomain.corporation.example.com. It might actually be a realistic
attack scenario, but it's not something we should attempt to mitigate.
Anyway this goes both ways. As explained many times already, without
systemd-resolved, the VPN you connect to first gets all the DNS queries
currently. Normally users connect to public VPN first, then corporate
VPN second. That's broken. Splitting the DNS is just the right thing to
do. If you want the corporate VPN to see everything, then do not check
"use this VPN only for resources on its network" and it will get
everything (but then it needs to have capacity to really handle
everything!).
Michael
10:39 a.m.
* Tomas Mraz:
On Wed, 2020-04-15 at 10:02 -0500, Michael Catanzaro wrote:
> On Wed, Apr 15, 2020 at 1:38 pm, Florian Weimer <fweimer(a)redhat.com>
> wrote:
> > Not sure if that's compatible with the new split DNS model because
> > VPN1
> > could simply start pushing longer names in the scope of VPN2, thus
> > hijacking internal traffic there (and this sort of hijacking is
> > exactly
> > what a DNS sinkhole against typosquatting would need).
>
> You deserve bonus points for thinking like an attacker and exploring
> the security model, but let's assume the configured VPNs are
> trusted.
> Otherwise the user is screwed no matter what. ;)
Trusted for what? I would expect corporate VPNs doing such tricks to
monitor the user's internet traffic. Which does not mean the user is
fully screwed with such VPN if he for example uses hardcoded
configuration of a caching nameserver.
Yes, what I described was given as a motivation for this change.
I find the response puzzling. I would definitely like to see greater
robustness to hostile networks, but it is a lot of work. Really a lot.
Lots of code to review, and quite a few shell scripts as well.
Thanks,
Florian
10:04 a.m.
On Wed, Apr 15, 2020 at 10:48 am, Florian Weimer <fweimer(a)redhat.com>
wrote:
The second Kubernetes issue I worry about [1] is that the CoreDNS
name
server is installed first, and it does additional rule-based
processing
for in-cluster names. External DNS servers are listed later.
Parallel
queries and random server selection could bypass the CoreDNS service
for
queries that need to be handled by it.
Hm, CoreDNS might need to construct its own nss module, or you might
need to use /etc/resolv.conf in "mode 1" or "mode 3" described by
Lennart. (Or disable systemd-resolved, but that shouldn't be
necessary.) We'll default to Lennart's "mode 2" so it sounds like that
might be a problem indeed.
Does OpenVPN log the list of these domains somewhere? Or do they
have
to be configured manually?
This managed by NetworkManager and systemd-resolved. You can inspect
with 'resolvectl status'. I don't think OpenVPN knows anything about it.
Ugh. That will have to be fixed, otherwise it will break DANE/TLSA
and
other DNSSEC-mandatory functionality on upgrades: the system used to
have a DNSSEC-clean path to the outside world, and after the switch to
systemd-resolved, it won't.
I think that, if you need DNSSEC, you will just need to enable it
manually. I think >99% of users won't need to do this, and it's a
one-line config file change for power users who do need it, just edit
/etc/systemd/resolved.conf and then restart systemd-resolved service.
Problem is that DNSSEC is just not safe to enable by default. :(
5:49 a.m.
* Michael Catanzaro:
On Wed, Apr 15, 2020 at 10:48 am, Florian Weimer
<fweimer(a)redhat.com>
wrote:
> The second Kubernetes issue I worry about [1] is that the CoreDNS name
> server is installed first, and it does additional rule-based
> processing
> for in-cluster names. External DNS servers are listed later.
> Parallel
> queries and random server selection could bypass the CoreDNS service
> for
> queries that need to be handled by it.
Hm, CoreDNS might need to construct its own nss module,
This is not possible. You cannot realistically inject binary code into
the container (see the fun with GPU userspace driver parts).
or you might need to use /etc/resolv.conf in "mode 1" or
"mode 3"
described by Lennart. (Or disable systemd-resolved, but that shouldn't
be necessary.) We'll default to Lennart's "mode 2" so it sounds like
that might be a problem indeed.
Yeah.
> Does OpenVPN log the list of these domains somewhere? Or do they
have
> to be configured manually?
This managed by NetworkManager and systemd-resolved. You can inspect
with 'resolvectl status'. I don't think OpenVPN knows anything about
it.
As explained elsewhere, NetworkManager-openvpn extracts the search list
from OpenVPN parameters, passes that to NetworkManager, which I expect
will pass ito to systemd-resolved in the future.
> Ugh. That will have to be fixed, otherwise it will break
DANE/TLSA
> and
> other DNSSEC-mandatory functionality on upgrades: the system used to
> have a DNSSEC-clean path to the outside world, and after the switch to
> systemd-resolved, it won't.
I think that, if you need DNSSEC, you will just need to enable it
manually. I think >99% of users won't need to do this, and it's a
one-line config file change for power users who do need it, just edit
/etc/systemd/resolved.conf and then restart systemd-resolved
service. Problem is that DNSSEC is just not safe to enable by
default. :(
See my message to Lennart about separate DO/CD query caching.
My point is that these users *have* enabled DNSSEC in their
infrastructure, and we break what they have during an update (assuming
that DNSSEC=off means that systemd-resolved turns DNSSEC-unware, rather
than just disabling validation).
Thanks,
Florian
8:36 a.m.
On Do, 16.04.20 12:49, Florian Weimer (fweimer(a)redhat.com) wrote:
As explained elsewhere, NetworkManager-openvpn extracts the search
list
from OpenVPN parameters, passes that to NetworkManager, which I expect
will pass ito to systemd-resolved in the future.
>> Ugh. That will have to be fixed, otherwise it will break DANE/TLSA
>> and
>> other DNSSEC-mandatory functionality on upgrades: the system used to
>> have a DNSSEC-clean path to the outside world, and after the switch to
>> systemd-resolved, it won't.
>
> I think that, if you need DNSSEC, you will just need to enable it
> manually. I think >99% of users won't need to do this, and it's a
> one-line config file change for power users who do need it, just edit
> /etc/systemd/resolved.conf and then restart systemd-resolved
> service. Problem is that DNSSEC is just not safe to enable by
> default. :(
See my message to Lennart about separate DO/CD query caching.
My point is that these users *have* enabled DNSSEC in their
infrastructure, and we break what they have during an update (assuming
that DNSSEC=off means that systemd-resolved turns DNSSEC-unware, rather
than just disabling validation).
Maybe a safer bet might be to leave resolved off during upgrades on
the server edition?
I don't think we can reliably determine whether people have deployed
things in a way that relies on /etc/resolv.conf only listing a fully
blown DNS server or who are fine with it being a more restricted stub
like systemd-resolved.
I'd claim it's reasonably safe to declare that on workstations having
a restrictive stub between local clients and a real DNS server is OK,
but maybe for servers we don't want to make such a claim, dunno, and
just enable this for newly deployed stuff but not on upgraded stuff.
Lennart
--
Lennart Poettering, Berlin
10:14 a.m.
* Lennart Poettering:
On Do, 16.04.20 12:49, Florian Weimer (fweimer(a)redhat.com) wrote:
> As explained elsewhere, NetworkManager-openvpn extracts the search list
> from OpenVPN parameters, passes that to NetworkManager, which I expect
> will pass ito to systemd-resolved in the future.
>
> >> Ugh. That will have to be fixed, otherwise it will break DANE/TLSA
> >> and
> >> other DNSSEC-mandatory functionality on upgrades: the system used to
> >> have a DNSSEC-clean path to the outside world, and after the switch to
> >> systemd-resolved, it won't.
> >
> > I think that, if you need DNSSEC, you will just need to enable it
> > manually. I think >99% of users won't need to do this, and it's a
> > one-line config file change for power users who do need it, just edit
> > /etc/systemd/resolved.conf and then restart systemd-resolved
> > service. Problem is that DNSSEC is just not safe to enable by
> > default. :(
>
> See my message to Lennart about separate DO/CD query caching.
>
> My point is that these users *have* enabled DNSSEC in their
> infrastructure, and we break what they have during an update (assuming
> that DNSSEC=off means that systemd-resolved turns DNSSEC-unware, rather
> than just disabling validation).
Maybe a safer bet might be to leave resolved off during upgrades on
the server edition?
A Fedora upgrade can also mean reprovision from start via
kickstart/ansible, so I assume that this isn't a proper mitigation,
sorry.
I don't think we can reliably determine whether people have
deployed
things in a way that relies on /etc/resolv.conf only listing a fully
blown DNS server or who are fine with it being a more restricted stub
like systemd-resolved.
Unfortunately, I see something similar to what Tom Hughes reported
earlier: dig +dnssec responses are not even correctly formatted. The CD
query flag is not handled, either. The AD bit is not set on validated
responses. I also see some really strange stability issues. It seems
that resolved is incorrectly blacklisting upstream servers with an
incompatible-server error after a validation failure.
This is with systemd-245.4-1.fc33.x86_64 in rawhide. Is this
approximately what will land in Fedora 33? Or is this old code, long
replaced upstream?
Thanks,
Florian
12:36 p.m.
On Do, 16.04.20 17:14, Florian Weimer (fweimer(a)redhat.com) wrote:
> I don't think we can reliably determine whether people have
deployed
> things in a way that relies on /etc/resolv.conf only listing a fully
> blown DNS server or who are fine with it being a more restricted stub
> like systemd-resolved.
Unfortunately, I see something similar to what Tom Hughes reported
earlier: dig +dnssec responses are not even correctly formatted. The CD
query flag is not handled, either. The AD bit is not set on validated
responses. I also see some really strange stability issues. It seems
that resolved is incorrectly blacklisting upstream servers with an
incompatible-server error after a validation failure.
Again, we do not support DNSSEC from client to the stub. If you set CD
we'll return NOTIMP as rcode, indicating that. We do not implement a
full DNS server, but just enough for local stub clients (such as the
one implemented in glibc or Java) to work. If you want the full DNSSEC
client stuff, talk directly to the upstream DNS server.
We set AD only if we managed to authenticate ourselves, which can
either be via DNSSEC if that's enabled to the upstream DNS server. We
also set it for hosts we read from /etc/hosts (i.e. a source owned by
root). If you saw incompatible server this looks like you left DNSSEC
on between resolved and upstream DNS server? Again, this is not what
we intend to do in Fedora.
Lennart
--
Lennart Poettering, Berlin
1:07 p.m.
* Lennart Poettering:
On Do, 16.04.20 17:14, Florian Weimer (fweimer(a)redhat.com) wrote:
> > I don't think we can reliably determine whether people have deployed
> > things in a way that relies on /etc/resolv.conf only listing a fully
> > blown DNS server or who are fine with it being a more restricted stub
> > like systemd-resolved.
>
> Unfortunately, I see something similar to what Tom Hughes reported
> earlier: dig +dnssec responses are not even correctly formatted. The CD
> query flag is not handled, either. The AD bit is not set on validated
> responses. I also see some really strange stability issues. It seems
> that resolved is incorrectly blacklisting upstream servers with an
> incompatible-server error after a validation failure.
Again, we do not support DNSSEC from client to the stub.
I don't think this change is ready for Fedora, then.
If you set CD we'll return NOTIMP as rcode, indicating that. We
do not
implement a full DNS server, but just enough for local stub clients
(such as the one implemented in glibc or Java) to work.
Sorry? RES_USE_DNSSEC is part of the glibc stub resolver. It does not
work anymore.
The libunbound validator is broken by this, too.
If you want the full DNSSEC client stuff, talk directly to the
upstream DNS server.
How? The address is no longer in /etc/resolv.conf. According to the
change proposal, this also endangers Denise, who relies on the request
routing in systemd-resolved.
Thanks,
Florian
1:54 p.m.
On Thu, Apr 16, 2020 at 8:07 pm, Florian Weimer <fweimer(a)redhat.com>
wrote:
I don't think this change is ready for Fedora, then.
Florian, isn't this a quite specialized use-case of the sort where you
can simply write your own /etc/resolv.conf and let resolved consume
that? Or just disable resolved?
How? The address is no longer in /etc/resolv.conf. According to the
change proposal, this also endangers Denise, who relies on the
request
routing in systemd-resolved.
Well, I guess you're right, you can't have all of the above. But how
many users really need to use Postfix or something else that needs
DNSSEC on a machine with multiple VPNs enabled...?
I think resolved is a sane default for Workstation users. And for
Server users, if you need more control, you can just create your own
/etc/resolv.conf and things will work as before, but you lose the split
DNS feature. That's OK, right?
7:53 p.m.
Once upon a time, Lennart Poettering <mzerqung(a)0pointer.de> said:
Again, we do not support DNSSEC from client to the stub. If you set
CD
we'll return NOTIMP as rcode, indicating that. We do not implement a
full DNS server, but just enough for local stub clients (such as the
one implemented in glibc or Java) to work. If you want the full DNSSEC
client stuff, talk directly to the upstream DNS server.
If you want to go in /etc/resolv.conf, you need to be a full resolver.
There's no telling what programs expect to be able to talk the full DNS
protocol to the "nameserver" lines from /etc/resolv.conf (for example,
the perl Net::DNS module gets its servers from there by default, so all
kinds of perl scripts could break). dnsmasq defaults to using resolvers
from /etc/resolv.conf too IIRC.
If you want to be a resolver, be an actual resolver, and in 2020, that
includes implementing EDNS0, DNSSEC, etc.
--
Chris Adams <linux(a)cmadams.net>
9:23 a.m.
On Do, 16.04.20 19:53, Chris Adams (linux(a)cmadams.net) wrote:
Once upon a time, Lennart Poettering <mzerqung(a)0pointer.de>
said:
> Again, we do not support DNSSEC from client to the stub. If you set CD
> we'll return NOTIMP as rcode, indicating that. We do not implement a
> full DNS server, but just enough for local stub clients (such as the
> one implemented in glibc or Java) to work. If you want the full DNSSEC
> client stuff, talk directly to the upstream DNS server.
If you want to go in /etc/resolv.conf, you need to be a full resolver.
There's no telling what programs expect to be able to talk the full DNS
protocol to the "nameserver" lines from /etc/resolv.conf (for example,
the perl Net::DNS module gets its servers from there by default, so all
kinds of perl scripts could break). dnsmasq defaults to using resolvers
from /etc/resolv.conf too IIRC.
If you want to be a resolver, be an actual resolver, and in 2020, that
includes implementing EDNS0, DNSSEC, etc.
resolved implements edns0 just fine.
And then there's DNSSEC support and DNSSEC support.
There's DNSSEC support as in "AD bit". Which is a silly thing if you
ask me. It is a bit you can set in the DNS response which tells the
client the data was "authenticated". It has no value however, because
anyone can claim that, it's not signed or nothing. This is the DNSSEC
support glibc implementss. It's silly, fake security.
And then there's DNSSEC support as in "full validation". In this case
the client checks all the signatures, and the AD bit isn't
relevant. This one actually is useful, but isn't what glibc
implement. Few clients implement that, and even fewer are deployed
that do this regularly. (My guess is that most clients that do this
are probably tools like "dig", that are used to debug this.)
The DNS servers in edge routers are awful at supporting
either. i.e. the DNS servers you usually get informed about in DHCP
leases are typically too crap at supporting either kind of DNSSEC (and
that for a reason actually, these devices generally define their own
private, local DNS names (e.g. "fritz.box"), which couldn't possibly
be validated with DNSSEC, because they are made up and local.)
systemd-resolved implements the full validation when talking to its
upstream servers. Because edge routers are so awful, we have trouble
making this work reliably enough in the general case. In specific
cases with a nice DNS server upstream everything is fine, but in the
general case it's not fun. systemd-reslolved does not care for the
"AD" bit stuff when talking to its upstream servers, because it's
useless.
When clients talk to systemd-resolved's DNS stub they will get errors
back if they themselves try to do the full validation, because we
don't cache that information suitably. We return clean errors in this
case, so that the client understands it cannot talk DNSSEC to us. We
intend to implement the "AD" stuff however correctly for this, but
this isn't tested much since pretty much noone except for a few DNS
devs actually set this, hence there might be issues, which might be
what Florian found. At least in our history of having been enabled in
Ubuntu this came up only sporadingly.
I think it#s worth tweaking the "AD" support in the stub, but I also
don't think it's really as important as people might think, because
there are so few clients that actually want it, and conceptually it's
kinda silly anyway (OK, admittedly, it's a bit less silly if a you
trust the "AD" bit if it's only sent between a local client to a local
system stub via the loopback device, but still...).
Lennart
--
Lennart Poettering, Berlin
10:32 a.m.
Once upon a time, Lennart Poettering <mzerqung(a)0pointer.de> said:
The DNS servers in edge routers are awful at supporting
either. i.e. the DNS servers you usually get informed about in DHCP
leases are typically too crap at supporting either kind of DNSSEC (and
that for a reason actually, these devices generally define their own
private, local DNS names (e.g. "fritz.box"), which couldn't possibly
be validated with DNSSEC, because they are made up and local.)
That might be true if you are just considering residential users with
cheap gateways as your only use case (but even then, most of those run
dnsmasq, which has gotten a lot better). However, there are lots of
other use cases.
We
intend to implement the "AD" stuff however correctly for this, but
this isn't tested much since pretty much noone except for a few DNS
devs actually set this, hence there might be issues, which might be
what Florian found.
Advertising yourself as a "nameserver" in /etc/resolv.conf means you get
to handle all the requests, including the ones you didn't think about or
want to just dismiss as only of interest "a few DNS devs". That's the
only standard way for software to find DNS servers to use for any
purpose. Returning errors to clients for things you don't care about is
basically useless, because they have no other way to get that
information when actual DNS servers aren't in /etc/resolv.conf.
If systemd-resolved is not going to implement a standards-compliant DNS
server (and not just "we return errors to things we don't care about",
but actual current DNS standards), then it does not belong in
/etc/resolv.conf. Listening on the system bus as an alternative, to
implment gethostbyname/getaddrinfo/etc., is fine, but don't pretend to
be an actual DNS server and go in /etc/resolv.conf.
--
Chris Adams <linux(a)cmadams.net>
10:43 a.m.
On Fri, Apr 17, 2020 at 8:34 AM Chris Adams <linux(a)cmadams.net> wrote:
Once upon a time, Lennart Poettering <mzerqung(a)0pointer.de>
said:
> The DNS servers in edge routers are awful at supporting
> either. i.e. the DNS servers you usually get informed about in DHCP
> leases are typically too crap at supporting either kind of DNSSEC (and
> that for a reason actually, these devices generally define their own
> private, local DNS names (e.g. "fritz.box"), which couldn't possibly
> be validated with DNSSEC, because they are made up and local.)
That might be true if you are just considering residential users with
cheap gateways as your only use case (but even then, most of those run
dnsmasq, which has gotten a lot better). However, there are lots of
other use cases.
> We
> intend to implement the "AD" stuff however correctly for this, but
> this isn't tested much since pretty much noone except for a few DNS
> devs actually set this, hence there might be issues, which might be
> what Florian found.
Advertising yourself as a "nameserver" in /etc/resolv.conf means you get
to handle all the requests, including the ones you didn't think about or
want to just dismiss as only of interest "a few DNS devs". That's the
only standard way for software to find DNS servers to use for any
purpose. Returning errors to clients for things you don't care about is
basically useless, because they have no other way to get that
information when actual DNS servers aren't in /etc/resolv.conf.
If systemd-resolved is not going to implement a standards-compliant DNS
server (and not just "we return errors to things we don't care about",
but actual current DNS standards), then it does not belong in
/etc/resolv.conf. Listening on the system bus as an alternative, to
implment gethostbyname/getaddrinfo/etc., is fine, but don't pretend to
be an actual DNS server and go in /etc/resolv.conf.
I tend to agree. Right now, a client-side resolving validator works on
Fedora. This change proposal breaks that. Could resolved be extended to
pass DNSSEC data through correctly so that client side validation will
continue to work?
10:46 a.m.
On Mi, 15.04.20 10:48, Florian Weimer (fweimer(a)redhat.com) wrote:
> As I understand the terminology the "stub resolver" in
systemd-resolved
> refers to the thing that listens on 127.0.0.53 and that won't do
> anything clever with single label queries because it will expect
> it is answering DNS queries - that is exactly the way that Ubuntu
> uses it.
Well, the whole thing is a stub resolver externally, even if it doesn't
speak DNS with applications. It has to perform upstream server
selection and search list processing in some way. The search list
processing turns into the responsibility of the local client
(application) only on the DNS interface.
Yes, resolved is a stub resolver only. And it is so regardless which
interface you use to talk to it.
The local listener on 127.0.0.53:53 is not a fully featured DNS server
either because of that. It does stuff real DNS servers don't do (such
as LLMNR, merging in /etc/hosts and stuff, such as the scope routing
and so on), and we will say NOTIMPL to a vareity of requests that you
can send to a real DNS server but that make no sense for a local
resolving stub.
Yes, this means if you have some special "dig" command line with all
kinds of special options there's a good chance systemd-resolved will
refuse your request, because that option is not implemented. It tries
to make this discoverable as much as that is possible, by returned the
most appropriate error (the error vocabulary isn't too verbose
howerver) and by logging about it to syslog.
Note that when you talk to resolved via the DNS protocol it will not
do search list processing for you, it leaves that to the client as
this was always handled, in order to not do it twice. If you talk to
resolved via the bus API (i.e. over nss-resolve or so) then it will to
the search list stuff server side. Beaviour in these two cases is
slightly different, as mentioned elsewhere, as resolved never leaks
unqualified names to upstream servers as they are.
Actually, Fedora's current NetworkManager/OpenVPN behavior
depends on
this because it lists the original system name server in
/etc/resolv.conf after the ones received over OpenVPN. This means that
with randomized/parallel queries, you might try to resolve internal
domains over the public Internet, and get unwanted/unusable result.
NM can tell resolved the full DNS info with per-interface info, so
that resolved can merge the view of the world on each (see other mail)
> I think so long as the VPN interface has ~redhat.co in it's
search
> list then queries for that domain will be forced to the servers for
> that interface if that's what is required?
Does OpenVPN log the list of these domains somewhere? Or do they have
to be configured manually?
Most other distributions (and even BSDs) provide a tool called
"resolvconf" that various subsystems that provide DNS server info call
when they learn some new DNS severs or DNS servers known go
away. OpenVPN is a subsystem with DNS info, hence on most distros it
will already be hooked up to "resolvconf" to provide the DNS data at
the right moment. The various existing implementations of "resolvconf"
usually take this info, sort it somehow and write it to
/etc/resolv.conf. systemd now implements its own version of the tool
which uses the information in a smarter way.
Long story short: if OpenVPN is configured like it already is on other
distros then we should have excellent behaviour as resolved will learn
about the DNS servers correctly with the right metadata we need to do
our per-interface magic.
>> Will the built-in DNS server still support DNSSEC without
validation,
>> passing through the records if they are requested by the client over the
>> DNS interface? The section above is not clear.
>
> I don't think so no. I happen to have a query to hand which fails
> validation due to a bug in systemd-resolved and I get SERVFAIL when
> querying 127.0.0.53 even with +cdflag on the dig command.
Ugh. That will have to be fixed, otherwise it will break DANE/TLSA and
other DNSSEC-mandatory functionality on upgrades: the system used to
have a DNSSEC-clean path to the outside world, and after the switch to
systemd-resolved, it won't.
Do we do DANE/TLSA by default anywhere in Fedora? I mean, we
realistically cannot because DNSSEC sucks in most DNS servers...
But yeah, clients that want to do full DNSSEC need to talk directly to
upstream DNS servers.
There's a feature request to switch to a special pass-through-proxy
mode in resolved as soon as some of the more special DNSSEC features
are turned on in an incoming DNS client packet on the stub. it's
something to think about, but having been on the other end of DNSSEC I
am a bit afraid it just makes things worse: i.e. writing a DNS client
that can deal with servers that expose completely different behaviour
depending on some flags in the headers is extremely hard. i.e. think
about this: if you send a regular DNS packet to resolved it would
process it natively, answer from its cache, do its LLMNR, mDNS,
/etc/hosts magic and whatever else it does. But as soon as you turn on
that DNSSEC bit resolved would just proxy through without any of this,
without caching, any processing, without the other information
sources. A client trying to make sense of such a server will be
utterly confused since without the bit set it will be exposed to
resolved's behaviour and quirks and its view of the world and with the
bit set it will be exposed to some upstream server's view of the world
and its quirks and behaviours, which are likely very very
different... Hence so far my take on it was: if you want real, fully
featured DNS with all weird, strange options then talk to upstream
directly, don't bother with resolved's internal stub, it's not built
for that.
Lennart
--
Lennart Poettering, Berlin
10:23 a.m.
On Mi, 15.04.20 09:29, Fedora Development ML (devel(a)lists.fedoraproject.org) wrote:
> Most Kubernetes/OKD clusters assume that both single-label and
> multi-label query names are forwarded over DNS (contrary to ICANN
> recommendations), and that DNS servers are processed in listed order for
> all queries (no parallel queries, no randomized server selection). If
> systemd-resolved behaves differently, it can make Fedora incompatible
> with Kubernetes clusters. (This is one reason why glibc still not
> follows the ICANN recommendations.)
When accessed via nss-resolve single label queries will be subject
to search list processing but I don't believe multi label ones will.
correct.
Each interface can have DNS servers and search domains as well as
there being global ones. There can also be search domains with a
prefix of "~" which force queries for that domain to be sent to a
specific interface (this is how the VPN thing works).
Small addition: the "~" thing will declare a domain as suitable for
routing only. i.e. classic search domains are used both for suffixing
and for routing, but those prefixed with "~" are used for routing only
and not for suffixing.
Classic DNS doesn't know the routing concept, it thus only uses search
domains for suffixing. We are hence using this information provided to
us for more than it was originally intended, but this should be an OK
thing to do.
I'm not sure what happens if there are multiple interfaces with
no specific routing but I think it may try them all?
Exactly. If our routing info doesn't help us our logic is to route
queries to all scopes in parallel.
Lennart
--
Lennart Poettering, Berlin
10:06 a.m.
On Mi, 15.04.20 10:08, Florian Weimer (fweimer(a)redhat.com) wrote:
> systemd-resolved has been enabled by default in Ubuntu since
Ubuntu
> 16.10, but please note we are doing this differently than Ubuntu has.
> Ubuntu does not use nss-resolve. Instead, Ubuntu uses the traditional
> nss-dns provided by glibc upstream, so glibc on Ubuntu continues to
> read /etc/resolv.conf, as is traditional. This extra step is not
> useful and not recommended by upstream. We want to follow upstream
> recommendations in using nss-resolve instead.
I cannot find documentation of the systemd stub resolver behavior: how
it handles search list processing, and how it decides which upstream
name servers to query.
systemd-resolved generally manages DNS servers and search lists per
interface, if possible. Basically, each interface that is up and has
DNS info associated with it gets a "scope" associated with it. If
there's global DNS configuration (i.e. read from /etc/resolv.conf if
that's a regular file), then that's considered an additional "scope".
Whenever looking up a hostname systemd-resolved will match the name
against all current scopes and issue queries on all matching ones in
parallel. Scopes are considered "matching" if the hostname being
looked up has a suffix of one of the search domains configured for the
scope. If no scopes match given the search domains, the query is sent
to all scopes in parallel.
This has some nice effects. Let's say you have one wifi interface and
one vpn interface. The latter has "redhat.com" as search domain, the
former has "fritz.box" as search domain configured. Now you try to
look up a name "quux.redhat.com". Because the vpn has "redhat.com" as
search domain the query will only be sent onto the vpn. If you look up
"wuff.fritz.box" otoh it will be sent only to the local wifi. if you
look up "systemd.io" otoh (i.e a domain for which no search domain is
configured on any local interface), the query is sent to both scopes
in parallel.
If a query is sent to multiple scopes in parallel then the the first
positive answer wins. If there are no positive answers than the last
negative one wins. This if you are connected to two different networks
with private DNS zones, the view is merged.
Search domains are also used to suffix unqualified names. Note that
resolved is a lot more strict than traditional DNS clients:
single-label names are considered unqualified, and multi-label names
are considered qualified. Unqualified names are never queried as they
are on public DNS, but require a search domain of some kind to be
configured with which they can be suffixed. Qualified names are never
subject to search domain suffixing however.
Search domains/query routing are a bit more complex than what i
describe above. See the man page for further details:
https://www.freedesktop.org/software/systemd/man/systemd-resolved.html#Pr...
resolved will start using the first DNS server configured for a scope,
and stick to it for subsequent lookups. When an error is seen from it,
it will switch to the next DNS server and then stick to that for
future lookups. i.e. it basically "caches" whether the first lookup
worked or not to speed up subsequent lookups. This means if the first
listed DNS server is borked and doesn't respond you'll pay for it
during the first lookup only, but all subsequent ones would use the
working one immediately. This is of course quite different from
nss-dns where on every single lookup things begin with the first DNS
server configured.
resolved's behaviour on this hence assumes that all DNS servers
configured on a scope are equivalent in the zones they provide. Or to
turn this around, if you have multiple DNS servers offering different
views of the world, then configure each set of them on a separate
interface, so that they become different scopes and thus can be
queried in parallel.
Most Kubernetes/OKD clusters assume that both single-label and
multi-label query names are forwarded over DNS (contrary to ICANN
recommendations), and that DNS servers are processed in listed order for
all queries (no parallel queries, no randomized server selection).
resolved never sends single-label names to public DNS, under the
assumption they have local meaning only, and should not leak onto the
internet. They will end up on the Internet only if a search domain is
defined that can be used to qualify them.
systemd-resolved starts with the first listed DNS server initially,
but as mentioned if it fails it will switch to the next DNS server and
then stay with it for subsequent lookups, unlike nss-dns which starts
from the beginning on every single query.
If passing single-label un-suffixed to the DNS servers is mandatory
for OKD/kubernetes, and if starting with the first DNS server on every
single lookup is too, then such images should probably override
/etc/resolv.conf with their own.
I am pretty sure that both these behaviours of kubernetes/OKD only
make sense in a very specific environment, and are not approproate for
general purpose systems.
systemd-resolved behaves differently, it can make Fedora
incompatible
with Kubernetes clusters. (This is one reason why glibc still not
follows the ICANN recommendations.)
With the Ubuntu approach, search list processing still resides within
glibc, so their Kubernetes experience would not necessarily match
ours.
Hmm, containers usually don#t boot up systemd inside, and thus usually
don't get resolved inside them anyway either. Hence my guess would be
that ubuntu just copies in upstream DNS info directly to
/etc/resolv.conf when starting the container, at which point what
resolved does doesn't matter at all anymore.
Will Fedora treat such cross-VPN leaks as security bugs going and
forward and fix them? (I suspect it would require constant work, and
lots of it.)
Is this expected to work with the Red Hat VPN out of the box, or do we
have to disable all this and use a custom configuration? Has this been
discussed with Infosec? It looks like this will break their DNS
sinkholing for domains such as REDHAT[.]CO (not COM).
If RH VPN configures "redhat.com" as search domain for their VPN then
this means all redhat.com traffic is automatically pulled over to the
VPN and will not be routed elsewhere anymore.
Will the built-in DNS server still support DNSSEC without
validation,
passing through the records if they are requested by the client over the
DNS interface? The section above is not clear.
depends on the record type. A number of DNSSEC RR types are magic, and
we'll refuse sending those to DNS servers that we don't think speak
DNSSEC.
Lennart
--
Lennart Poettering, Berlin
10:26 a.m.
On Wed, Apr 15, 2020 at 5:06 pm, Lennart Poettering
<mzerqung(a)0pointer.de> wrote:
If RH VPN configures "redhat.com" as search domain for
their VPN then
this means all redhat.com traffic is automatically pulled over to the
VPN and will not be routed elsewhere anymore.
In particular: current behavior is that redhat.com queries will leak to
public DNS if the user connects to the public VPN first, which is the
usual case, especially for anyone who configures public VPN to
autoconnect on startup. So the status quo is really not secure at all.
Yes, it will break the sinkholing for lookalike domains, but on balance
I would say that getting the right DNS queries to the right servers is
more important for security overall.
10:09 a.m.
On Wed, Apr 15, 2020 at 10:08 am, Florian Weimer <fweimer(a)redhat.com>
wrote:
* Ben Cotton:
> Enable systemd-resolved by default. glibc will perform name
> resolution
> using nss-resolve rather than nss-dns.
Is this intended for Fedora Server and others as well, or just
Workstation? I assume it's for everywhere.
Well I've proposed it for everywhere, because it seems desirable to
have everywhere. But if Server or another product doesn't want it, we
could do Workstation-only. It's already been approved by the
Workstation WG.
Most Kubernetes/OKD clusters assume that both single-label and
multi-label query names are forwarded over DNS (contrary to ICANN
recommendations), and that DNS servers are processed in listed order
for
all queries (no parallel queries, no randomized server selection). If
systemd-resolved behaves differently, it can make Fedora incompatible
with Kubernetes clusters. (This is one reason why glibc still not
follows the ICANN recommendations.)
With the Ubuntu approach, search list processing still resides within
glibc, so their Kubernetes experience would not necessarily match
ours.
Hm, it sounds like this is the main outstanding issue from this
discussion. It is beyond my expertise. I guess we'll need a bug report
where the relevant experts can figure out whether we need to change
Kubernetes or systemd here.
You're right that continuing to use nss-dns would avoid any such
problems while maintaining the other benefits of systemd-resolved. That
could be a fallback plan if needed.
Will Fedora treat such cross-VPN leaks as security bugs going and
forward and fix them? (I suspect it would require constant work, and
lots of it.)
Well they were always serious security bugs, just bugs that we were
unable to solve without a local resolver. I don't think it's going to
require constant work. It's a problem already solved by NetworkManager
as long as you use either dnsmasq and systemd-resolved for DNS.
Is this expected to work with the Red Hat VPN out of the box, or do
we
have to disable all this and use a custom configuration? Has this
been
discussed with Infosec? It looks like this will break their DNS
sinkholing for domains such as REDHAT[.]CO (not COM).
It works out of the box, yes, and should work with any other VPN plugin
as well, at least for VPNs that create separate tun interfaces for each
connection like OpenVPN does. I think some VPN plugins might not do
that (AnyConnect?).
I hadn't considered discussing a Fedora OS change with infosec. Anyway,
the current behavior is insecure, and the proposed behavior is correct.
;) A sinkholing hack used by one company is nice to avoid some
phishing, but it's still just a hack, not something we should design
our OS around. And certainly not worth compromising the privacy of
Fedora users. That said, any company's IT department can change
whatever defaults they want on managed systems, configure
systemd-resolved however they please, disable it entirely, whatever.
It may also need to changes to Postfix (for DANE/TLSA handling in
particular, depending on the level of DNSSEC support, see below).
Based on Tom's mail, it sounds like this will be a problem. I guess the
simple solution is to mention this in the release notes and suggest
that users enable DNSSEC if running Postfix. We can also warn the
Postfix developers to document this problem. I guess that should
suffice?
libvirt may need changes as well, for its internal DNS relay.
I'm not familiar with this; what would require changes in libvirt? Are
you concerned about nss-libvirt?
The manual page resolv.conf(5) needs to be updated.
Good catch, I would have forgotten that.
Since libnss_resolve.so.2 is still linked against libpthread and we
might not be able to remove libpthread from glibc as a separate
library
in time for Fedora 33, some applications may have to start linking
against libpthread explicitly even though they do not actually need
it.
(This is due to a long-standing limitation of loading libpthread via
dlopen.)
I don't understand this. Why would an application have to link to
pthread to dlopen a shared object that uses it?
Michael
10:17 a.m.
On Wed, Apr 15, 2020 at 10:09 am, Michael Catanzaro
<mcatanzaro(a)gnome.org> wrote:
Hm, it sounds like this is the main outstanding issue from this
discussion. It is beyond my expertise. I guess we'll need a bug
report where the relevant experts can figure out whether we need to
change Kubernetes or systemd here.
You're right that continuing to use nss-dns would avoid any such
problems while maintaining the other benefits of systemd-resolved.
That could be a fallback plan if needed.
As you see, I just lost an email race to Lennart. I like his suggestion
to manage /etc/resolv.conf manually on systems that need this behavior.
10:19 a.m.
On Mi, 15.04.20 10:09, Michael Catanzaro (mcatanzaro(a)gnome.org) wrote:
You're right that continuing to use nss-dns would avoid any such
problems
while maintaining the other benefits of systemd-resolved. That could be a
fallback plan if needed.
So, it is my understanding that containers as deployed with kubernetes
generally don't boot up with systemd as PID 1 inside them, no?
If that's the case things should just work: if a container manager
copies in their /etc/resolv.conf, and resolved is not running in the
container, then nss-dns with traditional configuration is in effect as
before.
If otoh containers are now started with systemd as PID 1 inside them,
then this would also mean resolved is started inside, and yes in that
case the single-label thing and the DNS-server-order thing might
conflict with kubernetes' expectations. In that case it should be
sufficient to "systemctl disable" systemd-resolved however, and
nss-dns will take front seat again.
Lennart
--
Lennart Poettering, Berlin
10:27 a.m.
* Lennart Poettering:
On Mi, 15.04.20 10:09, Michael Catanzaro (mcatanzaro(a)gnome.org)
wrote:
> You're right that continuing to use nss-dns would avoid any such problems
> while maintaining the other benefits of systemd-resolved. That could be a
> fallback plan if needed.
So, it is my understanding that containers as deployed with kubernetes
generally don't boot up with systemd as PID 1 inside them, no?
If that's the case things should just work: if a container manager
copies in their /etc/resolv.conf, and resolved is not running in the
container, then nss-dns with traditional configuration is in effect as
before.
As far as I know, the Kubernetes DNS hacks are used on the
infrastructure layer, not just within containers.
I guess we can prepare a Fedora compose with all this implemented, and
ask someone with the expertise to use it to deploy a Kubernetes cluster,
and see what happens?
Thanks,
Florian
4:14 a.m.
On 14.04.2020 21:23, Ben Cotton wrote:
Enable systemd-resolved by default. glibc will perform name
resolution
using nss-resolve rather than nss-dns.
I've tested systemd-resolved on my laptop for a month. It worked very,
very unstable. Sometimes it stopped responding and I needed to manually
restart its service.
I think we need to stay on current solution. It works stable for ages.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
4:30 a.m.
On 15/04/2020 10:14, Vitaly Zaitsev via devel wrote:
On 14.04.2020 21:23, Ben Cotton wrote:
> Enable systemd-resolved by default. glibc will perform name resolution
> using nss-resolve rather than nss-dns.
I've tested systemd-resolved on my laptop for a month. It worked very,
very unstable. Sometimes it stopped responding and I needed to manually
restart its service.
I too have been using it increasingly both on Fedora and on a
fleet of Ubuntu 18.04 machines and don't recognise that experience
at all.
I also (modulo one bug which is now fixed upstream) find it to be
much better at handling DNSSEC than either bind or unbound.
Tom
--
Tom Hughes (tom(a)compton.nu)
http://compton.nu/
6:41 a.m.
On Wed, Apr 15, 2020 at 5:31 AM Tom Hughes via devel
<devel(a)lists.fedoraproject.org> wrote:
On 15/04/2020 10:14, Vitaly Zaitsev via devel wrote:
> On 14.04.2020 21:23, Ben Cotton wrote:
>> Enable systemd-resolved by default. glibc will perform name resolution
>> using nss-resolve rather than nss-dns.
>
> I've tested systemd-resolved on my laptop for a month. It worked very,
> very unstable. Sometimes it stopped responding and I needed to manually
> restart its service.
I too have been using it increasingly both on Fedora and on a
fleet of Ubuntu 18.04 machines and don't recognise that experience
at all.
I have seen the stability issues that Vitaly described also, requiring
manual restart occasionally.
I also (modulo one bug which is now fixed upstream) find it to be
much better at handling DNSSEC than either bind or unbound.
I occasionally have to disable DNSSEC, because it doesn't always
work... though this might be due to improper DNS records for some
sites, and I haven't compared with anything else.
>
> Tom
>
> --
> Tom Hughes (tom(a)compton.nu)
> http://compton.nu/
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
9:01 a.m.
On Mi, 15.04.20 11:14, Fedora Development ML (devel(a)lists.fedoraproject.org) wrote:
On 14.04.2020 21:23, Ben Cotton wrote:
> Enable systemd-resolved by default. glibc will perform name resolution
> using nss-resolve rather than nss-dns.
I've tested systemd-resolved on my laptop for a month. It worked very,
very unstable. Sometimes it stopped responding and I needed to manually
restart its service.
I think we need to stay on current solution. It works stable for ages.
Note that resolved so far defaulted to DNSSEC mode by default (in
opportunistic mode). DNSSEC support in DNS servers provided by edge
routers (i.e. the DNS servers typically supplied in the DHCP leases
you get at home) is usually crap, and very hard to detect properly. So
far we have not been able to fine tune it in the myriad ways DNS
servers are creatively broken; and even for the many cases where we
detect things correctly it might still take a while after DNS config
became available for us to completed our learning.
DNSSEC with resolved should work fine if your local DNS server is well
behaving, but unfortunately that's generally not the case. THis means
DNSSEC support will be switched from opt-out to opt-in with resolved
becoming default to Fedora, to avoid this breakage.
Note that Ubuntu has been turning on resolved for quite some time by
default now (with DNSSEC off). They did a lot of testing for us
ultimately, so I#d expect few issues if we turn resolved on in Fedora
by default, as long as we also keep DNSSEC off.
Long story short: if you experienced issues with DNSSEC on with
resolved today, then be assured that with DNSSEC off things are much
much better, and that's how we'd ship it in Fedora if it becomes the
default.
Lennart
--
Lennart Poettering, Berlin
5:46 a.m.
* Lennart Poettering:
Long story short: if you experienced issues with DNSSEC on with
resolved today, then be assured that with DNSSEC off things are much
much better, and that's how we'd ship it in Fedora if it becomes the
default.
Would you please clarify what switching DNSSEC off means? Just no
validation, or no DNSSEC support at all?
I'm worried that the following scenario will break: A Fedora system on a
uses a DNSSEC-capable resolver (validating or not) and performs its own
DNSSEC validation, using data obtained by contacting the name servers in
/etc/resolv.conf. (/etc/resolv.conf is managed by NetworkManager or
cloud-init in this scenario.)
Since /etc/resolv.conf is already managed, I expect that after the
upgrade, systemd-resolved will be active, with the same upstream
recursive resolvers as before. The new /etc/resolv.conf contents will
point to the local systemd-resolved DNS service, though.
If systemd-resolved is not DNSSEC-aware with DNSSEC=off on the DNS
interface, this will break DNSSEC validation in the application. It
requires an explicit configuration change to fix.
In the past, caching resolvers have dealt with this situation by having
separate caches for DO (DNSSEC answer OK) or CD (Checking Disabled)
queries. This allows non-DNSSEC operations to continue even if the
DNSSEC side is broken, so it is safe to enable it by default. It would
also ensure that the configuration sketched above would not break (at
least not for this reason).
Thanks,
Florian
6:12 a.m.
On 16/04/2020 11:46, Florian Weimer wrote:
* Lennart Poettering:
> Long story short: if you experienced issues with DNSSEC on with
> resolved today, then be assured that with DNSSEC off things are much
> much better, and that's how we'd ship it in Fedora if it becomes the
> default.
Would you please clarify what switching DNSSEC off means? Just no
validation, or no DNSSEC support at all?
If I'm understanding what is expected correctly then it looks to me
like it is actually broken regardless of whether or not DNSSEC is
switched on...
Adding +dnssec to the dig flags results in some additional flags
being set in the OPT section of the response but it does not
cause RRSIG records to be returned and whether DNSSEC is on or
off makes no difference to that.
Tom
--
Tom Hughes (tom(a)compton.nu)
http://compton.nu/
8:42 a.m.
On Do, 16.04.20 12:46, Florian Weimer (fweimer(a)redhat.com) wrote:
* Lennart Poettering:
> Long story short: if you experienced issues with DNSSEC on with
> resolved today, then be assured that with DNSSEC off things are much
> much better, and that's how we'd ship it in Fedora if it becomes the
> default.
Would you please clarify what switching DNSSEC off means? Just no
validation, or no DNSSEC support at all?
It means we'd not attempt to validate DNS response we get with DNSSEC
and just trust them blindly, i.e. like this always worked.
It would still be compiled in, and be opt-in. And it works fine with a
well-behaving uptsream DNS servers, but given that so many public
networks I know have no well behaved upstream DNS servers it would be
opt-in.
I'm worried that the following scenario will break: A Fedora
system on a
uses a DNSSEC-capable resolver (validating or not) and performs its own
DNSSEC validation, using data obtained by contacting the name servers in
/etc/resolv.conf. (/etc/resolv.conf is managed by NetworkManager or
cloud-init in this scenario.)
So, yes, if you attempt to use a client-side validating resolver
against resolved's DNS stub you will not be happy. But you'll get a
clean error back, and you will find something about it in syslog. it's
not ideal, but it's usually OK. i.e. It's going to be like you talk to
a DNS server that simply cannot do DNSSEC, except better, because you
get helpful logging in syslog.
If you want a client-side validating resolver to work you need to
bypass resolved, for example using the DNS server data in
/run/systemd/resolve/resolv.conf. Or by using 8.8.8.8 or so directly...
Since /etc/resolv.conf is already managed, I expect that after the
upgrade, systemd-resolved will be active, with the same upstream
recursive resolvers as before. The new /etc/resolv.conf contents will
point to the local systemd-resolved DNS service, though.
Exactly.
Lennart
--
Lennart Poettering, Berlin
9:41 a.m.
On Tuesday, April 14, 2020 12:23:27 PM MST Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/systemd-resolved
== Summary ==
Enable systemd-resolved by default. glibc will perform name resolution
using nss-resolve rather than nss-dns.
== Owner ==
* Name: [[User:catanzaro| Michael Catanzaro]]
* Email: <mcatanzaro(a)redhat.com>
== Detailed Description ==
We will enable systemd-resolved by default.
# We will change the
[https://src.fedoraproject.org/rpms/fedora-release/blob/f4cc5b6ce095bb4233e5
e984a487e385def0ddca/f/90-default.preset fedora-release presets] to enable
systemd-resolved instead of disable it.
# systemd-libs currently has
[https://src.fedoraproject.org/rpms/systemd/blob/bb79fb73875f8e71841a1ee8ede
5d234b7878753/f/systemd.spec#_606 a %post scriplet] to enable
nss-myhostname and nss-systemd by either (a) modifying authselect's
user-nsswitch.conf template, if authselect is in use, or (b) directly
modifying /etc/nsswitch.conf otherwise. We will work with the systemd
maintainers to enable nss-resolve here as well.
# We will work with the authselect maintainers to update authselect's
minimal and nis profiles to enforce nss-resolve. These profiles modify
the hosts line of /etc/resolv.conf. (By default, Fedora uses
authselect's sssd profile, which does not modify the hosts line and
therefore does not have this problem.)
# We will remove our downstream patch to systemd that prevents systemd
from symlinking /etc/resolv.conf to
/run/systemd/resolve/stub-resolv.conf on new installs. For system
upgrades, a systemd-libs %post scriptlet will be used to reassign the
symlink during upgrade. Upon detecting this symlink, NetworkManager
will automatically enable its systemd-resolved support and configure
split DNS as appropriate.
systemd-resolved has been enabled by default in Ubuntu since Ubuntu
16.10, but please note we are doing this differently than Ubuntu has.
Ubuntu does not use nss-resolve. Instead, Ubuntu uses the traditional
nss-dns provided by glibc upstream, so glibc on Ubuntu continues to
read /etc/resolv.conf, as is traditional. This extra step is not
useful and not recommended by upstream. We want to follow upstream
recommendations in using nss-resolve instead.
If you do not wish to use systemd-resolved, then manual intervention
will be required to disable it:
* Modify /etc/authselect/user-nsswitch.conf and remove `resolve
[!UNAVAIL=return]` from the hosts line. Run `authselect
apply-changes`. (If you have disabled authselect, then edit
/etc/nsswitch.conf directly.)
* Disable and stop systemd-resolved.service.
* Restart the NetworkManager service. NetworkManager will then create
a traditional /etc/resolv.conf. (If you are not using NetworkManager,
you may create your own /etc/resolv.conf.)
== Benefit to Fedora ==
=== Standardization ===
Fedora will continue its history of enabling new systemd-provided
services whenever it makes sense to do so. Standardizing on upstream
systemd services is beneficial to the broader Linux ecosystem in
addition to Fedora, since standardizing reduces behavior differences
between different Linux distributions. Sadly, Fedora is no longer
leading in this area. Ubuntu has enabled systemd-resolved by default
since Ubuntu 16.10, so by the time Fedora 33 is released, we will be
three years behind Ubuntu here.
=== resolvectl ===
`resolvectl` has several useful functions (e.g. `resolvectl status` or
`resolvectl query`) that will be enabled out-of-the-box.
=== Caching ===
systemd-resolved caches DNS queries for a short while. This can
[https://gitlab.gnome.org/GNOME/glib/-/merge_requests/682#note_441846
dramatically] improve performance for applications that do not already
manually cache their own DNS results. (Generally, only web browsers
bother with manually caching DNS results.)
=== Split DNS ===
When systemd-resolved is enabled, users who use multiple VPNs at the
same time will notice that DNS requests are now sent to the correct
DNS server by default. Previously, this scenario would result in
embarrassing "DNS leaks" and, depending on the order that the VPN
connections were established, possible failure to resolve private
resources. These scenarios will now work properly. For example,
consider the scenario of Distrustful Denise, who (quite reasonably)
does not trust her ISP. Denise uses a public VPN service,
public-vpn.example.com, to hide her internet activity from her ISP,
but she also needs to use her employer's corporate VPN,
corporation.example.com, in order to access internal company resources
while working from home. Using the Network panel in System Settings,
Denise has configured her employer's VPN to "use this connection only
for resources on its network." Distrustful Denise expects that her
employer's VPN will receive all traffic for corporation.example.com,
and no other traffic. And while this mostly works in Fedora 32, she
discovers that it does not work properly for DNS:
* If Denise connects to public-vpn.example.com first and
corporation.example.com second, she is unable to access internal
company resources. All DNS requests are sent to
public-vpn.example.com's DNS server, so she is unable to resolve names
for internal company websites.
* If Denise connects to corporation.example.com first and
public-vpn.example.com second, then she is able to access internal
company resources. However, it only works because ''all'' her DNS
requests are sent to corporation.example.com's DNS server. Sadly for
Distrustful Denise, her employer discovers that she has been making
some embarrassing DNS requests that she had expected to go through
public-vpn.example.com instead.
Whichever VPN Denise connects to first receives all DNS requests
because glibc's nss-dns module is not smart enough to split the
requests. /etc/resolv.conf is just a list of DNS servers to try in
order, and NetworkManager has no plausible way to decide which to list
first, because both ways are broken, so it just prefers whichever was
connected first. And if one server fails to respond, then the next
server in the list will be tried, likely resulting in a DNS leak. In
contrast, when systemd-resolved is enabled, it will send each DNS
request only to the correct DNS server. The DNS server that will be
used for each tun interface can be inspected using the resolvectl
tool.
Migrating away from /etc/resolv.conf will also avoid an annoying
footgun with this legacy file: only the first three listed nameservers
are respected. All further nameservers are silently ignored.
NetworkManager adds a warning comment when writing more than three
nameservers to this file, but it cannot do any better than that.
=== DNS over TLS ===
systemd-resolved supports DNS over TLS (different from DNS over
HTTPS). Although this feature will not initially be enabled by
default, using systemd-resolved will enable us to turn on DNS over TLS
in a future Fedora release, providing improved security if the user's
DNS server supports DNS over TLS.
== Scope ==
* Proposal owners: We will update Fedora presets to enable
systemd-resolved by default.
* Other developers: This change requires coordination with the systemd
and authselect maintainers.
* Release engineering: [https://pagure.io/releng/issue/9367 #9367]
* Policies and guidelines: none required
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
systemd-resolved will be enabled automatically when upgrading to
Fedora 33. After upgrade, /etc/resolv.conf will be managed by systemd
and symlinked to /run/systemd/resolve/stub-resolv.conf. '''glibc will
no longer look at /etc/resolv.conf when performing name resolution.'''
Instead, glibc will communicate directly with systemd-resolved via
nss-resolve. systemd adds a large warning comment to the top of
/etc/resolv.conf to warn system administrators that changes to this
file will be ignored; however, scripts that edit this file manually
will break. Because this file is usually managed by NetworkManager,
impact to Fedora users will be limited to users who have manually
disabled NetworkManager; such users are expected to be experienced
system administrators who should be comfortable adapting to the change
(or disabling systemd-resolved).
Any applications that bypass glibc and read /etc/resolv.conf directly
will still work because /etc/resolv.conf will point to
systemd-resolved's stub resolver running on 127.0.0.53. Nevertheless,
/etc/resolv.conf is provided only for compatibility purposes, and
applications should prefer to use either glibc or the systemd-resolved
D-Bus API instead; see systemd-resolved(8) for details.
In short, '''applications that read /etc/resolv.conf will continue to
work as before.''' Applications that write to it will no longer work
as expected, but this only previously worked if NetworkManager is
disabled, a non-default configuration. It remains possible to disable
systemd-resolved if desired. Otherwise, any custom system
administration scripts that manage /etc/resolv.conf will need to be
updated.
=== DNSSEC ===
systemd-resolved's DNSSEC support is known to cause compatibility
problems with certain network access points. Per recommendation from
the systemd developers, we will change the default value of this
setting in Fedora from the upstream default `DNSSEC=allow-downgrade`
to `DNSSEC=no` by building systemd with the build option
`-Ddefault-dnssec=no`. The upstream default attempts to use DNSSEC if
it is working, but automatically disable it otherwise, allowing
man-in-the-middle attackers to disable DNSSEC. Sadly, even the
allow-downgrade setting suffers known compatibility problems. Because
Fedora is not prepared to handle an influx of DNSSEC-related bug
reports, we will disable this feature altogether. We anticipate that
enabling DNSSEC by default will not be possible in the foreseeable
future, or perhaps ever. Instead, enabling DNS over TLS (when
supported by the DNS server) seems likely in the near future.
=== Multicast DNS ===
systemd-resolved's multicast DNS support conflicts with Avahi. Per
recommendation from the systemd developers, we will change the default
value of this setting in Fedora from the upstream default
`MulticastDNS=yes` to `MulticastDNS=resolve`. Multicast DNS resolving
will be enabled, but responding will be disabled. This will require
adding a new systemd build option to control the default value of the
MulticastDNS setting, similar to the existing `default-dnssec` and
`default-dns-over-tls` build options.
== How To Test ==
Load any website in a web browser. If you succeed, then name
resolution probably works.
Try using `resolvectl status` and, for example, `resolvectl query
fedoraproject.org`, to see how they work and sanity-check their
output.
Users who use multiple VPNs at the same time are encouraged to test
DNS in a multiple VPN scenario, to ensure that DNS requests are sent
to the expected DNS server.
== User Experience ==
See the Benefit to Fedora section, above, for direct benefits to users
who use multiple VPNs at the same time.
Users will be able to use the resolvectl tool and the functionality it
provides.
/etc/resolv.conf will now be managed by systemd rather than by
NetworkManager. As before, this file must not be modified directly
when it is managed.
== Dependencies ==
In Fedora, /etc/nsswitch.conf is managed by authselect. By default,
authselect uses the sssd profile to generate configuration compatible
with sssd. In this mode of operation, it does not modify the hosts
line in /etc/nsswitch.conf. This is also true if using the winbind
profile instead of the sssd profile. However, authselect's minimal and
nis profiles do modify the hosts line. These authselect profiles must
be updated to enable nss-resolved. If you are using authselect in one
of these modes, it will not be possible to cleanly disable
systemd-resolved because the hosts line in /etc/nsswitch.conf will be
clobbered whenever 'authselect apply-changes' is run. If you wish to
disable systemd-resolved and you are using authselect in one of these
modes, then you should stop using authselect. This is not expected to
cause many problems because virtually all Fedora users will be using
the default sssd profile.
We do not need to directly make any changes to the /etc/nsswitch.conf
shipped by glibc. Changes will be applied in the systemd-libs %post
scriptlet.
== Contingency Plan ==
The contingency plan, in the unlikely event of unexpected problems, is
simply to revert any changes and not enable systemd-resolved.
* Contingency deadline: beta freeze
* Blocks release? No
* Blocks product? No
== Documentation ==
* systemd-resolved is documented in several manpages: resolvectl(1),
resolved.conf(5), nss-resolve(8), systemd-resolved(8).
* [https://wiki.archlinux.org/index.php/Systemd-resolved Arch Wiki
documentation]
* [https://wiki.gnome.org/Projects/NetworkManager/DNS NetworkManager
DNS documentation]
== Release Notes ==
systemd-resolved is now enabled by default. systemd-resolved provides
a system-level DNS cache that can substantially improve performance
for applications that do not cache their own DNS results, allows
correct handling of split DNS scenarios such as when multiple VPNs are
in use, and will allow Fedora to enable DNS over TLS in the future.
/etc/resolv.conf will now be managed by systemd-resolved rather than
by NetworkManager. /etc/resolv.conf will no longer be read when
performing name resolution using glibc; however, it is still provided
for compatibility with applications that manually read this file to
perform name resolution. Writing to /etc/resolv.conf will no longer
work as expected.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
Really, it may be best to go about this in the same way as Ubuntu, with nss-
dns instead of nss-resolve.. Editing /etc/resolv.conf is still commonly done
on Fedora, especially on servers. In fact, I never knew that NetworkManager
would clobber that until this thread. If this isn't mean to wreck everyone's
systems, backwards compatibility is key.
If not by using nss-dns, could systemd-resolved be modified such that it would
read /etc/resolv.conf?
--
John M. Harris, Jr.
Splentity
9:55 a.m.
On Thursday, April 16, 2020 7:41:07 AM MST John M. Harris Jr wrote:
Really, it may be best to go about this in the same way as Ubuntu,
with
nss- dns instead of nss-resolve.. Editing /etc/resolv.conf is still
commonly done on Fedora, especially on servers. In fact, I never knew that
NetworkManager would clobber that until this thread. If this isn't mean to
wreck everyone's systems, backwards compatibility is key.
If not by using nss-dns, could systemd-resolved be modified such that it
would read /etc/resolv.conf?
Correcting what I said above, perhaps it'd be best to use what Lennart
mentions as "mode 1" of systemd-resolved, such that /etc/resolv.conf is read,
while using nss-resolve.
--
John M. Harris, Jr.
Splentity
10:16 a.m.
On Thu, Apr 16, 2020 at 7:55 am, John M. Harris Jr
<johnmh(a)splentity.com> wrote:
Correcting what I said above, perhaps it'd be best to use what
Lennart
mentions as "mode 1" of systemd-resolved, such that /etc/resolv.conf
is read,
while using nss-resolve.
If you want to do that, you can. You just need to make /etc/resolv.conf
a regular file, not a symlink. The text of the change proposal is
wrong; I'll fix it.
10:43 a.m.
On Thu, Apr 16, 2020 at 07:41:07AM -0700, John M. Harris Jr wrote:
Really, it may be best to go about this in the same way as Ubuntu, with nss-
dns instead of nss-resolve.. Editing /etc/resolv.conf is still commonly done
on Fedora, especially on servers. In fact, I never knew that NetworkManager
would clobber that until this thread. If this isn't mean to wreck everyone's
systems, backwards compatibility is key.
Relying on nss_dns causes bugs like
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1624320
(systemd-resolved appends 127.0.0.53 to resolv.conf alongside existing
entries).
It still gets (angry) comments, years after it was filled.
--
Tomasz Torcz There exists no separation between gods and men:
tomek(a)pipebreaker.pl one blends softly casual into the other. — Frank Herbert
3:54 a.m.
On 4/16/20 5:43 PM, Tomasz Torcz wrote:
On Thu, Apr 16, 2020 at 07:41:07AM -0700, John M. Harris Jr wrote:
>
> Really, it may be best to go about this in the same way as Ubuntu, with nss-
> dns instead of nss-resolve.. Editing /etc/resolv.conf is still commonly done
> on Fedora, especially on servers. In fact, I never knew that NetworkManager
> would clobber that until this thread. If this isn't mean to wreck everyone's
> systems, backwards compatibility is key.
Relying on nss_dns causes bugs like
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1624320
(systemd-resolved appends 127.0.0.53 to resolv.conf alongside existing
entries).
It still gets (angry) comments, years after it was filled.
It is not nss_dns use, which makes angry comments from people. It should
not be pushed into nameservers list when its broken. It should be
possible to use resolved just for mdns and llmnr and leave dns for
proper servers. If it were opt-in and not opt-out, no annoyed comments
would be required.
--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemensik(a)redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
8:15 p.m.
On Tuesday, April 14, 2020 12:23:27 PM MST Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/systemd-resolved
== Summary ==
Enable systemd-resolved by default. glibc will perform name resolution
using nss-resolve rather than nss-dns.
== Owner ==
* Name: [[User:catanzaro| Michael Catanzaro]]
* Email: <mcatanzaro(a)redhat.com>
== Detailed Description ==
We will enable systemd-resolved by default.
# We will change the
[https://src.fedoraproject.org/rpms/fedora-release/blob/f4cc5b6ce095bb4233e5
e984a487e385def0ddca/f/90-default.preset
fedora-release presets] to enable
systemd-resolved instead of disable it.
# systemd-libs currently has
[https://src.fedoraproject.org/rpms/systemd/blob/bb79fb73875f8e71841a1ee8ede
5d234b7878753/f/systemd.spec#_606
a %post scriplet] to enable
nss-myhostname and nss-systemd by either (a) modifying
authselect's
user-nsswitch.conf template, if authselect is in use, or (b) directly
modifying /etc/nsswitch.conf otherwise. We will work with the systemd
maintainers to enable nss-resolve here as well.
# We will work with the authselect maintainers to update authselect's
minimal and nis profiles to enforce nss-resolve. These profiles modify
the hosts line of /etc/resolv.conf. (By default, Fedora uses
authselect's sssd profile, which does not modify the hosts line and
therefore does not have this problem.)
# We will remove our downstream patch to systemd that prevents systemd
from symlinking /etc/resolv.conf to
/run/systemd/resolve/stub-resolv.conf on new installs. For system
upgrades, a systemd-libs %post scriptlet will be used to reassign the
symlink during upgrade. Upon detecting this symlink, NetworkManager
will automatically enable its systemd-resolved support and configure
split DNS as appropriate.
systemd-resolved has been enabled by default in Ubuntu since Ubuntu
16.10, but please note we are doing this differently than Ubuntu has.
Ubuntu does not use nss-resolve. Instead, Ubuntu uses the traditional
nss-dns provided by glibc upstream, so glibc on Ubuntu continues to
read /etc/resolv.conf, as is traditional. This extra step is not
useful and not recommended by upstream. We want to follow upstream
recommendations in using nss-resolve instead.
If you do not wish to use systemd-resolved, then manual intervention
will be required to disable it:
* Modify /etc/authselect/user-nsswitch.conf and remove `resolve
[!UNAVAIL=return]` from the hosts line. Run `authselect
apply-changes`. (If you have disabled authselect, then edit
/etc/nsswitch.conf directly.)
* Disable and stop systemd-resolved.service.
* Restart the NetworkManager service. NetworkManager will then create
a traditional /etc/resolv.conf. (If you are not using NetworkManager,
you may create your own /etc/resolv.conf.)
== Benefit to Fedora ==
=== Standardization ===
Fedora will continue its history of enabling new systemd-provided
services whenever it makes sense to do so. Standardizing on upstream
systemd services is beneficial to the broader Linux ecosystem in
addition to Fedora, since standardizing reduces behavior differences
between different Linux distributions. Sadly, Fedora is no longer
leading in this area. Ubuntu has enabled systemd-resolved by default
since Ubuntu 16.10, so by the time Fedora 33 is released, we will be
three years behind Ubuntu here.
=== resolvectl ===
`resolvectl` has several useful functions (e.g. `resolvectl status` or
`resolvectl query`) that will be enabled out-of-the-box.
=== Caching ===
systemd-resolved caches DNS queries for a short while. This can
[https://gitlab.gnome.org/GNOME/glib/-/merge_requests/682#note_441846
dramatically] improve performance for applications that do not already
manually cache their own DNS results. (Generally, only web browsers
bother with manually caching DNS results.)
=== Split DNS ===
When systemd-resolved is enabled, users who use multiple VPNs at the
same time will notice that DNS requests are now sent to the correct
DNS server by default. Previously, this scenario would result in
embarrassing "DNS leaks" and, depending on the order that the VPN
connections were established, possible failure to resolve private
resources. These scenarios will now work properly. For example,
consider the scenario of Distrustful Denise, who (quite reasonably)
does not trust her ISP. Denise uses a public VPN service,
public-vpn.example.com, to hide her internet activity from her ISP,
but she also needs to use her employer's corporate VPN,
corporation.example.com, in order to access internal company resources
while working from home. Using the Network panel in System Settings,
Denise has configured her employer's VPN to "use this connection only
for resources on its network." Distrustful Denise expects that her
employer's VPN will receive all traffic for corporation.example.com,
and no other traffic. And while this mostly works in Fedora 32, she
discovers that it does not work properly for DNS:
* If Denise connects to public-vpn.example.com first and
corporation.example.com second, she is unable to access internal
company resources. All DNS requests are sent to
public-vpn.example.com's DNS server, so she is unable to resolve names
for internal company websites.
* If Denise connects to corporation.example.com first and
public-vpn.example.com second, then she is able to access internal
company resources. However, it only works because ''all'' her DNS
requests are sent to corporation.example.com's DNS server. Sadly for
Distrustful Denise, her employer discovers that she has been making
some embarrassing DNS requests that she had expected to go through
public-vpn.example.com instead.
Whichever VPN Denise connects to first receives all DNS requests
because glibc's nss-dns module is not smart enough to split the
requests. /etc/resolv.conf is just a list of DNS servers to try in
order, and NetworkManager has no plausible way to decide which to list
first, because both ways are broken, so it just prefers whichever was
connected first. And if one server fails to respond, then the next
server in the list will be tried, likely resulting in a DNS leak. In
contrast, when systemd-resolved is enabled, it will send each DNS
request only to the correct DNS server. The DNS server that will be
used for each tun interface can be inspected using the resolvectl
tool.
Migrating away from /etc/resolv.conf will also avoid an annoying
footgun with this legacy file: only the first three listed nameservers
are respected. All further nameservers are silently ignored.
NetworkManager adds a warning comment when writing more than three
nameservers to this file, but it cannot do any better than that.
=== DNS over TLS ===
systemd-resolved supports DNS over TLS (different from DNS over
HTTPS). Although this feature will not initially be enabled by
default, using systemd-resolved will enable us to turn on DNS over TLS
in a future Fedora release, providing improved security if the user's
DNS server supports DNS over TLS.
== Scope ==
* Proposal owners: We will update Fedora presets to enable
systemd-resolved by default.
* Other developers: This change requires coordination with the systemd
and authselect maintainers.
* Release engineering: [https://pagure.io/releng/issue/9367 #9367]
* Policies and guidelines: none required
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
systemd-resolved will be enabled automatically when upgrading to
Fedora 33. After upgrade, /etc/resolv.conf will be managed by systemd
and symlinked to /run/systemd/resolve/stub-resolv.conf. '''glibc will
no longer look at /etc/resolv.conf when performing name resolution.'''
Instead, glibc will communicate directly with systemd-resolved via
nss-resolve. systemd adds a large warning comment to the top of
/etc/resolv.conf to warn system administrators that changes to this
file will be ignored; however, scripts that edit this file manually
will break. Because this file is usually managed by NetworkManager,
impact to Fedora users will be limited to users who have manually
disabled NetworkManager; such users are expected to be experienced
system administrators who should be comfortable adapting to the change
(or disabling systemd-resolved).
Any applications that bypass glibc and read /etc/resolv.conf directly
will still work because /etc/resolv.conf will point to
systemd-resolved's stub resolver running on 127.0.0.53. Nevertheless,
/etc/resolv.conf is provided only for compatibility purposes, and
applications should prefer to use either glibc or the systemd-resolved
D-Bus API instead; see systemd-resolved(8) for details.
In short, '''applications that read /etc/resolv.conf will continue to
work as before.''' Applications that write to it will no longer work
as expected, but this only previously worked if NetworkManager is
disabled, a non-default configuration. It remains possible to disable
systemd-resolved if desired. Otherwise, any custom system
administration scripts that manage /etc/resolv.conf will need to be
updated.
=== DNSSEC ===
systemd-resolved's DNSSEC support is known to cause compatibility
problems with certain network access points. Per recommendation from
the systemd developers, we will change the default value of this
setting in Fedora from the upstream default `DNSSEC=allow-downgrade`
to `DNSSEC=no` by building systemd with the build option
`-Ddefault-dnssec=no`. The upstream default attempts to use DNSSEC if
it is working, but automatically disable it otherwise, allowing
man-in-the-middle attackers to disable DNSSEC. Sadly, even the
allow-downgrade setting suffers known compatibility problems. Because
Fedora is not prepared to handle an influx of DNSSEC-related bug
reports, we will disable this feature altogether. We anticipate that
enabling DNSSEC by default will not be possible in the foreseeable
future, or perhaps ever. Instead, enabling DNS over TLS (when
supported by the DNS server) seems likely in the near future.
=== Multicast DNS ===
systemd-resolved's multicast DNS support conflicts with Avahi. Per
recommendation from the systemd developers, we will change the default
value of this setting in Fedora from the upstream default
`MulticastDNS=yes` to `MulticastDNS=resolve`. Multicast DNS resolving
will be enabled, but responding will be disabled. This will require
adding a new systemd build option to control the default value of the
MulticastDNS setting, similar to the existing `default-dnssec` and
`default-dns-over-tls` build options.
== How To Test ==
Load any website in a web browser. If you succeed, then name
resolution probably works.
Try using `resolvectl status` and, for example, `resolvectl query
fedoraproject.org`, to see how they work and sanity-check their
output.
Users who use multiple VPNs at the same time are encouraged to test
DNS in a multiple VPN scenario, to ensure that DNS requests are sent
to the expected DNS server.
== User Experience ==
See the Benefit to Fedora section, above, for direct benefits to users
who use multiple VPNs at the same time.
Users will be able to use the resolvectl tool and the functionality it
provides.
/etc/resolv.conf will now be managed by systemd rather than by
NetworkManager. As before, this file must not be modified directly
when it is managed.
== Dependencies ==
In Fedora, /etc/nsswitch.conf is managed by authselect. By default,
authselect uses the sssd profile to generate configuration compatible
with sssd. In this mode of operation, it does not modify the hosts
line in /etc/nsswitch.conf. This is also true if using the winbind
profile instead of the sssd profile. However, authselect's minimal and
nis profiles do modify the hosts line. These authselect profiles must
be updated to enable nss-resolved. If you are using authselect in one
of these modes, it will not be possible to cleanly disable
systemd-resolved because the hosts line in /etc/nsswitch.conf will be
clobbered whenever 'authselect apply-changes' is run. If you wish to
disable systemd-resolved and you are using authselect in one of these
modes, then you should stop using authselect. This is not expected to
cause many problems because virtually all Fedora users will be using
the default sssd profile.
We do not need to directly make any changes to the /etc/nsswitch.conf
shipped by glibc. Changes will be applied in the systemd-libs %post
scriptlet.
== Contingency Plan ==
The contingency plan, in the unlikely event of unexpected problems, is
simply to revert any changes and not enable systemd-resolved.
* Contingency deadline: beta freeze
* Blocks release? No
* Blocks product? No
== Documentation ==
* systemd-resolved is documented in several manpages: resolvectl(1),
resolved.conf(5), nss-resolve(8), systemd-resolved(8).
* [https://wiki.archlinux.org/index.php/Systemd-resolved Arch Wiki
documentation]
* [https://wiki.gnome.org/Projects/NetworkManager/DNS NetworkManager
DNS documentation]
== Release Notes ==
systemd-resolved is now enabled by default. systemd-resolved provides
a system-level DNS cache that can substantially improve performance
for applications that do not cache their own DNS results, allows
correct handling of split DNS scenarios such as when multiple VPNs are
in use, and will allow Fedora to enable DNS over TLS in the future.
/etc/resolv.conf will now be managed by systemd-resolved rather than
by NetworkManager. /etc/resolv.conf will no longer be read when
performing name resolution using glibc; however, it is still provided
for compatibility with applications that manually read this file to
perform name resolution. Writing to /etc/resolv.conf will no longer
work as expected.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
Please do not disable reading from /etc/resolv.conf. If you do so, please
limit that to the Spins that it won't affect people on, such as Workstation,
if you believe people there don't set their own DNS servers.
The impact section of this is flat out wrong. Removing that file's contents
and replacing it with a symlink to some systemd think will break users'
systems, leaving them unable to make DNS queries. It's more than possible to
make use of the benefits of systemd-resolved without removing this critical
functionality. Ubuntu has already done so, and Lennart pointed out that you
can keep resolv.conf working without going about it the way Ubuntu did.
If this Change goes through as it's currently written, this will wreck users'
systems.
--
John M. Harris, Jr.
9:06 p.m.
On Sun, Jul 26, 2020 at 6:15 pm, John M. Harris Jr
<johnmh(a)splentity.com> wrote:
Please do not disable reading from /etc/resolv.conf. If you do so,
please
limit that to the Spins that it won't affect people on, such as
Workstation,
if you believe people there don't set their own DNS servers.
Except:
* /etc/resolv.conf is broken by design, as you would know if you read
the section on split DNS that you just quoted
* There's no value in reading from /etc/resolv.conf unless you have
written something custom to it
* /etc/resolv.conf is managed by NetworkManager in Fedora, so you
cannot safely write to it anyway in our default configuration
Fact is that unless you have done custom work to allow manual
modifications to /etc/resolv.conf, you're not going to notice this
change at all. And if you have, then surely you'll be able to figure
out the very, very simple steps to get back to the original behavior.
In fact, it should actually be *easier* than before to get traditional
behavior. Remove the symlink. Create your own /etc/resolv.conf. Hey
presto! systemd will read it....
1:30 a.m.
On Sunday, July 26, 2020 7:06:48 PM MST Michael Catanzaro wrote:
On Sun, Jul 26, 2020 at 6:15 pm, John M. Harris Jr
<johnmh(a)splentity.com> wrote:
> Please do not disable reading from /etc/resolv.conf. If you do so,
> please
> limit that to the Spins that it won't affect people on, such as
> Workstation,
> if you believe people there don't set their own DNS servers.
Except:
* /etc/resolv.conf is broken by design, as you would know if you read
the section on split DNS that you just quoted
/etc/resolv.conf is not broken. It's the standard way of defining DNS servers
for systems, and has worked for well over a decade.
* There's no value in reading from /etc/resolv.conf unless you
have
written something custom to it
The value is actually getting DNS lookup to work on users' systems. Unless
they've only used NetworkManager, and never touched /etc/resolv.conf, their
system *will not be able to resolve hostnames after this forced removal*.
There's a clean way to prevent that. Do not remove the file upon update.
* /etc/resolv.conf is managed by NetworkManager in Fedora, so you
cannot safely write to it anyway in our default configuration
/etc/resolv.conf is managed by NetworkManager, but it only gets updated if you
use NetworkManager to manage DNS.
Fact is that unless you have done custom work to allow manual
modifications to /etc/resolv.conf, you're not going to notice this
change at all.
This is literally removing the file upon upgrade. That wasn't there
originally, and it's a horrible addition. See your original response when I
brought up this concern..
And if you have, then surely you'll be able to figure
out the very, very simple steps to get back to the original behavior.
In fact, it should actually be *easier* than before to get traditional
behavior. Remove the symlink. Create your own /etc/resolv.conf. Hey
presto! systemd will read it....
Is that what will actually happen, or will systemd still continue to ignore
it? That's not made clear, because we've decided to go with something other
than what Lennart calls "mode 1".
--
John M. Harris, Jr.
1:47 a.m.
* Michael Catanzaro:
On Sun, Jul 26, 2020 at 6:15 pm, John M. Harris Jr
<johnmh(a)splentity.com> wrote:
> Please do not disable reading from /etc/resolv.conf. If you do so,
> please
> limit that to the Spins that it won't affect people on, such as
> Workstation,
> if you believe people there don't set their own DNS servers.
Except:
* /etc/resolv.conf is broken by design, as you would know if you read
the section on split DNS that you just quoted
It works for the things it's meant to do.
Split DNS does not exist as a concept. Some web browser concepts, such
as the canary domain for DoH are explicitly incompatible with it:
<https://support.mozilla.org/en-US/kb/canary-domain-use-application-dnsnet...
Incompatible in the sense that when connecting to a VPN, DNS traffic
will now be sent to a third party, when it would not before.
* There's no value in reading from /etc/resolv.conf unless you
have
written something custom to it
Any DNS client library has to read /etc/resolv.conf to determine the
system DNS configuration.
The format is about as stable than _res, and from languages which are
not C, much easier to access.
This isn't an obscure use case, this is something that really has to
work. Even C programs use alternative DNS clients for asynchronous name
resolution and similar things.
Fact is that unless you have done custom work to allow manual
modifications to /etc/resolv.conf, you're not going to notice this
change at all.
It depends on the quality of the DNS implementation whose address is
given in /etc/resolv.conf.
And if you have, then surely you'll be able to figure
out the very, very simple steps to get back to the original
behavior. In fact, it should actually be *easier* than before to get
traditional behavior. Remove the symlink. Create your own
/etc/resolv.conf. Hey presto! systemd will read it....
What if I want to manage name servers via DHCP (and Network Manager),
but still retain DNSSEC support for local applications?
Thanks,
Florian
8:06 a.m.
On Sun, 2020-07-26 at 21:06 -0500, Michael Catanzaro wrote:
On Sun, Jul 26, 2020 at 6:15 pm, John M. Harris Jr
<johnmh(a)splentity.com> wrote:
> Please do not disable reading from /etc/resolv.conf. If you do so,
> please
> limit that to the Spins that it won't affect people on, such as
> Workstation,
> if you believe people there don't set their own DNS servers.
Except:
* /etc/resolv.conf is broken by design, as you would know if you read
the section on split DNS that you just quoted
* There's no value in reading from /etc/resolv.conf unless you have
written something custom to it
* /etc/resolv.conf is managed by NetworkManager in Fedora, so you
cannot safely write to it anyway in our default configuration
Fact is that unless you have done custom work to allow manual
modifications to /etc/resolv.conf, you're not going to notice this
change at all. And if you have, then surely you'll be able to figure
out the very, very simple steps to get back to the original behavior.
In fact, it should actually be *easier* than before to get traditional
behavior. Remove the symlink. Create your own /etc/resolv.conf. Hey
presto! systemd will read it....
Sorry Michael,
but there are truckloads of programs that read resolv.conf directly, if
all this change is doing is moving the file elsewhere but providing the
same data in it, fine. If it is removing the pointers to DNS servers
this change is absolutely not something you can do covertly in an
update, it *will* be seen, but normal users will have a hard time
figuring out what broke in the first place, let alone figure out how to
resolve it (pun intended :).
Moreover if glibc is changed to use a different resolver then why
change resolv.conf away? Only non-glibc querying programs would use it,
and they intentionally do so anyway. Case in point one of the core
components of the identity system in Fedora (SSSD) MUST be able to
query directly DNS in scenarios were it is joined to an AD or IPA
domain. Because it queries for stuff like SRV and TXT records
concurrently (we use an async library) and needs to see those fields,
as well as receive multiple IP addresses in order to set up fallbacks.
Please do not break DNS this way, if you really want to force
everything through a single system resolver (I think that is a worthy
goal) then it needs to be a thing that speaks DNS on UDP port 53 on
127.0.0.X and that address needs to be in resolv.conf as the nameserver
address.
Any other "solution" will just break a bunch of stuff unnecessarily.
Simo.
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc
8:20 a.m.
On Mon, Jul 27, 2020 at 9:07 AM Simo Sorce <simo(a)redhat.com> wrote:
On Sun, 2020-07-26 at 21:06 -0500, Michael Catanzaro wrote:
> On Sun, Jul 26, 2020 at 6:15 pm, John M. Harris Jr
> <johnmh(a)splentity.com> wrote:
> > Please do not disable reading from /etc/resolv.conf. If you do so,
> > please
> > limit that to the Spins that it won't affect people on, such as
> > Workstation,
> > if you believe people there don't set their own DNS servers.
>
> Except:
>
> * /etc/resolv.conf is broken by design, as you would know if you read
> the section on split DNS that you just quoted
> * There's no value in reading from /etc/resolv.conf unless you have
> written something custom to it
> * /etc/resolv.conf is managed by NetworkManager in Fedora, so you
> cannot safely write to it anyway in our default configuration
>
> Fact is that unless you have done custom work to allow manual
> modifications to /etc/resolv.conf, you're not going to notice this
> change at all. And if you have, then surely you'll be able to figure
> out the very, very simple steps to get back to the original behavior.
> In fact, it should actually be *easier* than before to get traditional
> behavior. Remove the symlink. Create your own /etc/resolv.conf. Hey
> presto! systemd will read it....
Sorry Michael,
but there are truckloads of programs that read resolv.conf directly, if
all this change is doing is moving the file elsewhere but providing the
same data in it, fine. If it is removing the pointers to DNS servers
this change is absolutely not something you can do covertly in an
update, it *will* be seen, but normal users will have a hard time
figuring out what broke in the first place, let alone figure out how to
resolve it (pun intended :).
Moreover if glibc is changed to use a different resolver then why
change resolv.conf away? Only non-glibc querying programs would use it,
and they intentionally do so anyway. Case in point one of the core
components of the identity system in Fedora (SSSD) MUST be able to
query directly DNS in scenarios were it is joined to an AD or IPA
domain. Because it queries for stuff like SRV and TXT records
concurrently (we use an async library) and needs to see those fields,
as well as receive multiple IP addresses in order to set up fallbacks.
Please do not break DNS this way, if you really want to force
everything through a single system resolver (I think that is a worthy
goal) then it needs to be a thing that speaks DNS on UDP port 53 on
127.0.0.X and that address needs to be in resolv.conf as the nameserver
address.
Any other "solution" will just break a bunch of stuff unnecessarily.
That *is* what will happen. In this scenario, systemd-resolved creates
a file in /run that is populated with the required information for
applications to request name resolution from resolved through the
standard DNS protocol. The /etc/resolv.conf file becomes a symlink to
the file in /run so that the file in /etc is stable and regenerating
the file in /run won't cause issues for package management. This
system has been in use *already* for a while now in other
distributions (see Debian and resolvconf(8), which systemd-resolved
replaced in Ubuntu).
The only thing this mechanism breaks is applications trying to *write*
to the resolv.conf file, because systemd-resolved will just blow away
those changes right after. If you want to modify DNS settings, you
need to configure systemd-resolved itself, either through
NetworkManager (as we will recommend) or directly through
systemd-resolved's configuration interface (if not using NetworkManager).
--
真実はいつも一つ！/ Always, there's only one truth!
8:43 a.m.
On Mon, 2020-07-27 at 09:20 -0400, Neal Gompa wrote:
On Mon, Jul 27, 2020 at 9:07 AM Simo Sorce <simo(a)redhat.com>
wrote:
> On Sun, 2020-07-26 at 21:06 -0500, Michael Catanzaro wrote:
> > On Sun, Jul 26, 2020 at 6:15 pm, John M. Harris Jr
> > <johnmh(a)splentity.com> wrote:
> > > Please do not disable reading from /etc/resolv.conf. If you do so,
> > > please
> > > limit that to the Spins that it won't affect people on, such as
> > > Workstation,
> > > if you believe people there don't set their own DNS servers.
> >
> > Except:
> >
> > * /etc/resolv.conf is broken by design, as you would know if you read
> > the section on split DNS that you just quoted
> > * There's no value in reading from /etc/resolv.conf unless you have
> > written something custom to it
> > * /etc/resolv.conf is managed by NetworkManager in Fedora, so you
> > cannot safely write to it anyway in our default configuration
> >
> > Fact is that unless you have done custom work to allow manual
> > modifications to /etc/resolv.conf, you're not going to notice this
> > change at all. And if you have, then surely you'll be able to figure
> > out the very, very simple steps to get back to the original behavior.
> > In fact, it should actually be *easier* than before to get traditional
> > behavior. Remove the symlink. Create your own /etc/resolv.conf. Hey
> > presto! systemd will read it....
>
> Sorry Michael,
> but there are truckloads of programs that read resolv.conf directly, if
> all this change is doing is moving the file elsewhere but providing the
> same data in it, fine. If it is removing the pointers to DNS servers
> this change is absolutely not something you can do covertly in an
> update, it *will* be seen, but normal users will have a hard time
> figuring out what broke in the first place, let alone figure out how to
> resolve it (pun intended :).
>
> Moreover if glibc is changed to use a different resolver then why
> change resolv.conf away? Only non-glibc querying programs would use it,
> and they intentionally do so anyway. Case in point one of the core
> components of the identity system in Fedora (SSSD) MUST be able to
> query directly DNS in scenarios were it is joined to an AD or IPA
> domain. Because it queries for stuff like SRV and TXT records
> concurrently (we use an async library) and needs to see those fields,
> as well as receive multiple IP addresses in order to set up fallbacks.
>
> Please do not break DNS this way, if you really want to force
> everything through a single system resolver (I think that is a worthy
> goal) then it needs to be a thing that speaks DNS on UDP port 53 on
> 127.0.0.X and that address needs to be in resolv.conf as the nameserver
> address.
>
> Any other "solution" will just break a bunch of stuff unnecessarily.
>
That *is* what will happen. In this scenario, systemd-resolved creates
a file in /run that is populated with the required information for
applications to request name resolution from resolved through the
standard DNS protocol. The /etc/resolv.conf file becomes a symlink to
the file in /run so that the file in /etc is stable and regenerating
the file in /run won't cause issues for package management. This
system has been in use *already* for a while now in other
distributions (see Debian and resolvconf(8), which systemd-resolved
replaced in Ubuntu).
The only thing this mechanism breaks is applications trying to *write*
to the resolv.conf file, because systemd-resolved will just blow away
those changes right after. If you want to modify DNS settings, you
need to configure systemd-resolved itself, either through
NetworkManager (as we will recommend) or directly through
systemd-resolved's configuration interface (if not using NetworkManager).
Thanks, I guess I misunderstood because of alarmist tones.
This will work just fine, writing to resolv.conf is indeed something
advanced, and a user that can set that up will likely know how to fix
it as well.
Simo.
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc
8:57 a.m.
On Mon, Jul 27, 2020 at 09:43:23AM -0400, Simo Sorce wrote:
Thanks, I guess I misunderstood because of alarmist tones.
I think it's fair to say that there's a lesson to be learned here.
This will work just fine, writing to resolv.conf is indeed something
advanced, and a user that can set that up will likely know how to fix
it as well.
Additionally, Fedora's default configuration (for many, many, many years
now) has had /etc/resolv.conf dynamically generated by NetworkManager.
Local changes made directly to resolv.conf could (and would) get blown
away at any time.
So users needing a non-volatile resolv.conf already have to take extra
steps to achieve that. Under this proposal, different (but simpler!)
steps will be necessary to achieve the same result.
- Solomon
--
Solomon Peachy pizza at shaftnet dot org (email&xmpp)
@pizza:shaftnet dot org (matrix)
High Springs, FL speachy (freenode)
11:30 p.m.
On Monday, July 27, 2020 6:57:07 AM MST Solomon Peachy wrote:
Additionally, Fedora's default configuration (for many, many,
many years
now) has had /etc/resolv.conf dynamically generated by NetworkManager.
Local changes made directly to resolv.conf could (and would) get blown
away at any time.
Yes, but only IF NetworkManager is being used for DNS. If you don't set DNS
servers there, or use a static configuration (as I do both at home and at
work, and many others do, even though NetworkManager), this is just going to
break users' systems.
So users needing a non-volatile resolv.conf already have to take
extra
steps to achieve that. Under this proposal, different (but simpler!)
steps will be necessary to achieve the same result.
Yes, it's already there right now! And, upon upgrade, their file will be
removed without even checking to see if it's set by NetworkManager or the end
user, and replaced with a symlink. This will needlessly break users' systems
upon upgrade. Lennart described another mode of operation for systmed-
resolved, where it continues to use /etc/resolv.conf exactly as you'd expect.
--
John M. Harris, Jr.
11:28 p.m.
On Monday, July 27, 2020 6:43:23 AM MST Simo Sorce wrote:
On Mon, 2020-07-27 at 09:20 -0400, Neal Gompa wrote:
> On Mon, Jul 27, 2020 at 9:07 AM Simo Sorce <simo(a)redhat.com> wrote:
>
> > On Sun, 2020-07-26 at 21:06 -0500, Michael Catanzaro wrote:
> >
> > > On Sun, Jul 26, 2020 at 6:15 pm, John M. Harris Jr
> > > <johnmh(a)splentity.com> wrote:
> > >
> > > > Please do not disable reading from /etc/resolv.conf. If you do so,
> > > > please
> > > > limit that to the Spins that it won't affect people on, such as
> > > > Workstation,
> > > > if you believe people there don't set their own DNS servers.
> > >
> > >
> > > Except:
> > >
> > >
> > > * /etc/resolv.conf is broken by design, as you would know if you
> > > read
> > >
> > > the section on split DNS that you just quoted
> > >
> > > * There's no value in reading from /etc/resolv.conf unless you have
> > >
> > > written something custom to it
> > >
> > > * /etc/resolv.conf is managed by NetworkManager in Fedora, so you
> > >
> > > cannot safely write to it anyway in our default configuration
> > >
> > > Fact is that unless you have done custom work to allow manual
> > > modifications to /etc/resolv.conf, you're not going to notice this
> > > change at all. And if you have, then surely you'll be able to figure
> > > out the very, very simple steps to get back to the original behavior.
> > > In fact, it should actually be *easier* than before to get
> > > traditional
> > > behavior. Remove the symlink. Create your own /etc/resolv.conf. Hey
> > > presto! systemd will read it....
> >
> >
> > Sorry Michael,
> > but there are truckloads of programs that read resolv.conf directly, if
> > all this change is doing is moving the file elsewhere but providing the
> > same data in it, fine. If it is removing the pointers to DNS servers
> > this change is absolutely not something you can do covertly in an
> > update, it *will* be seen, but normal users will have a hard time
> > figuring out what broke in the first place, let alone figure out how to
> > resolve it (pun intended :).
> >
> > Moreover if glibc is changed to use a different resolver then why
> > change resolv.conf away? Only non-glibc querying programs would use it,
> > and they intentionally do so anyway. Case in point one of the core
> > components of the identity system in Fedora (SSSD) MUST be able to
> > query directly DNS in scenarios were it is joined to an AD or IPA
> > domain. Because it queries for stuff like SRV and TXT records
> > concurrently (we use an async library) and needs to see those fields,
> > as well as receive multiple IP addresses in order to set up fallbacks.
> >
> > Please do not break DNS this way, if you really want to force
> > everything through a single system resolver (I think that is a worthy
> > goal) then it needs to be a thing that speaks DNS on UDP port 53 on
> > 127.0.0.X and that address needs to be in resolv.conf as the nameserver
> > address.
> >
> > Any other "solution" will just break a bunch of stuff unnecessarily.
> >
>
>
> That *is* what will happen. In this scenario, systemd-resolved creates
> a file in /run that is populated with the required information for
> applications to request name resolution from resolved through the
> standard DNS protocol. The /etc/resolv.conf file becomes a symlink to
> the file in /run so that the file in /etc is stable and regenerating
> the file in /run won't cause issues for package management. This
> system has been in use *already* for a while now in other
> distributions (see Debian and resolvconf(8), which systemd-resolved
> replaced in Ubuntu).
>
> The only thing this mechanism breaks is applications trying to *write*
> to the resolv.conf file, because systemd-resolved will just blow away
> those changes right after. If you want to modify DNS settings, you
> need to configure systemd-resolved itself, either through
> NetworkManager (as we will recommend) or directly through
> systemd-resolved's configuration interface (if not using NetworkManager).
Thanks, I guess I misunderstood because of alarmist tones.
This will work just fine, writing to resolv.conf is indeed something
advanced, and a user that can set that up will likely know how to fix
it as well.
Please note that the issue with this isn't replacing resolv.conf with a
symlink to a file in the same format that provides a local DNS server. The
issue is ignoring users' configuration and effectively doing this upon
upgrade:
rm -f /etc/resolv.conf
then putting a symlink there.
There's no reason for this. systemd-resolved has what's called "mode 1",
where
it reads from /etc/resolv.conf and everything continues to work just as you'd
expect.
--
John M. Harris, Jr.
9:21 a.m.
Once upon a time, Neal Gompa <ngompa13(a)gmail.com> said:
That *is* what will happen. In this scenario, systemd-resolved
creates
a file in /run that is populated with the required information for
applications to request name resolution from resolved through the
standard DNS protocol.
I modify that to say: through a *subset* of the standard DNS protocol;
systemd-resolved intentionally doesn't implement the full protocol.
--
Chris Adams <linux(a)cmadams.net>
7:11 a.m.
On Mo, 27.07.20 09:20, Neal Gompa (ngompa13(a)gmail.com) wrote:
That *is* what will happen. In this scenario, systemd-resolved
creates
a file in /run that is populated with the required information for
applications to request name resolution from resolved through the
standard DNS protocol. The /etc/resolv.conf file becomes a symlink to
the file in /run so that the file in /etc is stable and regenerating
the file in /run won't cause issues for package management. This
system has been in use *already* for a while now in other
distributions (see Debian and resolvconf(8), which systemd-resolved
replaced in Ubuntu).
The only thing this mechanism breaks is applications trying to *write*
to the resolv.conf file, because systemd-resolved will just blow away
those changes right after. If you want to modify DNS settings, you
need to configure systemd-resolved itself, either through
NetworkManager (as we will recommend) or directly through
systemd-resolved's configuration interface (if not using NetworkManager).
That's not quit true: if you replace th /etc/resolv.conf symlink with
a file of your own choosing, then resolved will not muck around with
that, and not modify it anymore. instead, it will start to *read* it
and use the data. i.e. depending on symlinks vs. file it either
provides or consumes the data in it.
Thus admin-provided configuration in /etc/resolv.conf takes precedence
over the stuff systemd-resolved puts there, as long as the admin
properly replaces the symlink. If the admin doesn't replace the
symlink and writes to it naively, i.e. where it points then it will
make changes to files in /run/systemd/ (because that's where the
symlink points to), i.e. files clearly owned by systemd, and
systemd-resolved will brutally overwrite them whenever it feels the
need to.
Lennart
--
Lennart Poettering, Berlin
9:46 a.m.
On Tuesday, July 28, 2020 5:11:31 AM MST Lennart Poettering wrote:
On Mo, 27.07.20 09:20, Neal Gompa (ngompa13(a)gmail.com) wrote:
> That *is* what will happen. In this scenario, systemd-resolved creates
> a file in /run that is populated with the required information for
> applications to request name resolution from resolved through the
> standard DNS protocol. The /etc/resolv.conf file becomes a symlink to
> the file in /run so that the file in /etc is stable and regenerating
> the file in /run won't cause issues for package management. This
> system has been in use *already* for a while now in other
> distributions (see Debian and resolvconf(8), which systemd-resolved
> replaced in Ubuntu).
>
>
>
> The only thing this mechanism breaks is applications trying to *write*
> to the resolv.conf file, because systemd-resolved will just blow away
> those changes right after. If you want to modify DNS settings, you
> need to configure systemd-resolved itself, either through
> NetworkManager (as we will recommend) or directly through
> systemd-resolved's configuration interface (if not using NetworkManager).
That's not quit true: if you replace th /etc/resolv.conf symlink with
a file of your own choosing, then resolved will not muck around with
that, and not modify it anymore. instead, it will start to *read* it
and use the data. i.e. depending on symlinks vs. file it either
provides or consumes the data in it.
Thus admin-provided configuration in /etc/resolv.conf takes precedence
over the stuff systemd-resolved puts there, as long as the admin
properly replaces the symlink. If the admin doesn't replace the
symlink and writes to it naively, i.e. where it points then it will
make changes to files in /run/systemd/ (because that's where the
symlink points to), i.e. files clearly owned by systemd, and
systemd-resolved will brutally overwrite them whenever it feels the
need to.
To prevent brutally overwriting configuration, it would be best not to replace
/etc/resolv.conf with a symlink on upgrade, ignoring user configuration, but
to do so on all new installs.
--
John M. Harris, Jr.
10:07 a.m.
On Tue, Jul 28, 2020 at 10:58 AM John M. Harris Jr <johnmh(a)splentity.com> wrote:
On Tuesday, July 28, 2020 5:11:31 AM MST Lennart Poettering wrote:
> On Mo, 27.07.20 09:20, Neal Gompa (ngompa13(a)gmail.com) wrote:
>
>
> > That *is* what will happen. In this scenario, systemd-resolved creates
> > a file in /run that is populated with the required information for
> > applications to request name resolution from resolved through the
> > standard DNS protocol. The /etc/resolv.conf file becomes a symlink to
> > the file in /run so that the file in /etc is stable and regenerating
> > the file in /run won't cause issues for package management. This
> > system has been in use *already* for a while now in other
> > distributions (see Debian and resolvconf(8), which systemd-resolved
> > replaced in Ubuntu).
> >
> >
> >
> > The only thing this mechanism breaks is applications trying to *write*
> > to the resolv.conf file, because systemd-resolved will just blow away
> > those changes right after. If you want to modify DNS settings, you
> > need to configure systemd-resolved itself, either through
> > NetworkManager (as we will recommend) or directly through
> > systemd-resolved's configuration interface (if not using NetworkManager).
>
>
> That's not quit true: if you replace th /etc/resolv.conf symlink with
> a file of your own choosing, then resolved will not muck around with
> that, and not modify it anymore. instead, it will start to *read* it
> and use the data. i.e. depending on symlinks vs. file it either
> provides or consumes the data in it.
>
> Thus admin-provided configuration in /etc/resolv.conf takes precedence
> over the stuff systemd-resolved puts there, as long as the admin
> properly replaces the symlink. If the admin doesn't replace the
> symlink and writes to it naively, i.e. where it points then it will
> make changes to files in /run/systemd/ (because that's where the
> symlink points to), i.e. files clearly owned by systemd, and
> systemd-resolved will brutally overwrite them whenever it feels the
> need to.
To prevent brutally overwriting configuration, it would be best not to replace
/etc/resolv.conf with a symlink on upgrade, ignoring user configuration, but
to do so on all new installs.
We can be smart here and replace the file when we detect that it's
managed by NetworkManager. Otherwise we won't replace it.
--
真実はいつも一つ！/ Always, there's only one truth!
10:36 a.m.
On 28 July 2020 17:07:14 CEST, Neal Gompa <ngompa13(a)gmail.com> wrote:
> To prevent brutally overwriting configuration, it would be best
not to replace
> /etc/resolv.conf with a symlink on upgrade, ignoring user configuration, but
> to do so on all new installs.
>
We can be smart here and replace the file when we detect that it's
managed by NetworkManager. Otherwise we won't replace it.
This sounds like a good way to do it. I very much like the smooth major version upgrades
and this would help.
Given that some changes DNS servers, for whatever reason, we have to assume that those who
have did so because of a reason.
Not breaking DNS for them is important.
Br
M
>
>
>
>
>--
>真実はいつも一つ！/ Always, there's only one truth!
>_______________________________________________
>devel mailing list -- devel(a)lists.fedoraproject.org
>To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
11:22 a.m.
I agree we should not replace /etc/resolv.conf if it's not already a
symlink (although this will not be a common case, since by default it
is a symlink managed by NetworkManager).
On Tue, Jul 28, 2020 at 11:07 am, Neal Gompa <ngompa13(a)gmail.com> wrote:
We can be smart here and replace the file when we detect that
it's
managed by NetworkManager. Otherwise we won't replace it.
Currently we actually don't touch it at all, which is not good because
it means systemd-resolved will not be managing resolv.conf on upgraded
systems. We should replace it with a symlink to systemd if (and only
if) it's managed by NetworkManager.
12:23 p.m.
On Tue, Jul 28, 2020 at 11:22:58AM -0500, Michael Catanzaro wrote:
I agree we should not replace /etc/resolv.conf if it's not
already a
symlink (although this will not be a common case, since by default
it is a symlink managed by NetworkManager).
On Tue, Jul 28, 2020 at 11:07 am, Neal Gompa <ngompa13(a)gmail.com> wrote:
>We can be smart here and replace the file when we detect that it's
>managed by NetworkManager. Otherwise we won't replace it.
Currently we actually don't touch it at all, which is not good
because it means systemd-resolved will not be managing resolv.conf
on upgraded systems. We should replace it with a symlink to systemd
if (and only if) it's managed by NetworkManager.
Right now there's the following scriptlet:
grep -q 'Generated by NetworkManager' /etc/resolv.conf 2>/dev/null &&
\
echo -e '/etc/resolv.conf was generated by NetworkManager.\nConsider removing it to
let systemd-resolved manage this file.' \
|| :
I.e. only a hint is emitted. I'm open to suggestions how to improve it.
Zbyszek
12:31 p.m.
On Tue, Jul 28, 2020 at 5:23 pm, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl> wrote:
I.e. only a hint is emitted. I'm open to suggestions how to
improve
it.
I think we should remove it if it's generated by NetworkManager, and
leave it untouched otherwise. If NetworkManager is managing DNS then it
will just push all its settings to systemd-resolved anyway after
upgrade, right?
1:47 p.m.
On 7/28/20 12:31 PM, Michael Catanzaro wrote:
I think we should remove it if it's generated by NetworkManager,
and
leave it untouched otherwise. If NetworkManager is managing DNS then it
will just push all its settings to systemd-resolved anyway after
upgrade, right?
Don't assume that the presence of the "Generated by NetworkManager"
comment means that NetworkManager is *currently* managing that file; it
just means that it did so when the file was generated.
--
========================================================================
In Soviet Russia, Google searches you!
========================================================================
6:35 p.m.
On Tuesday, July 28, 2020 11:47:27 AM MST Ian Pilcher wrote:
On 7/28/20 12:31 PM, Michael Catanzaro wrote:
> I think we should remove it if it's generated by NetworkManager, and
> leave it untouched otherwise. If NetworkManager is managing DNS then it
> will just push all its settings to systemd-resolved anyway after
> upgrade, right?
Don't assume that the presence of the "Generated by NetworkManager"
comment means that NetworkManager is *currently* managing that file; it
just means that it did so when the file was generated.
Agreed, I don't think I ever removed that from my /etc/resolv.conf on any of
my systems.
--
John M. Harris, Jr.
9:08 a.m.
On Tue, Jul 28, 2020 at 5:23 pm, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl> wrote:
Right now there's the following scriptlet:
grep -q 'Generated by NetworkManager' /etc/resolv.conf 2>/dev/null &&
\
echo -e '/etc/resolv.conf was generated by
NetworkManager.\nConsider removing it to let systemd-resolved manage
this file.' \
|| :
I.e. only a hint is emitted. I'm open to suggestions how to improve
it.
Zbyszek
Zbigniew, do you agree that we should remove the script if and only if
it is generated by NetworkManager? Otherwise, the change is only
partially-implemented for users upgrading from F32 and earlier.
11:52 a.m.
On Tue, Aug 4, 2020 at 9:08 am, Michael Catanzaro
<mcatanzaro(a)gnome.org> wrote:
Zbigniew, do you agree that we should remove the script if and only
if it is generated by NetworkManager? Otherwise, the change is only
partially-implemented for users upgrading from F32 and earlier.
We agreed to go with this approach. /etc/resolv.conf will be moved to
/etc/resolv.conf.orig-with-nm on upgrade to F33 if the 'Generated by
NetworkManager' comment is present. If you've gone to the trouble to
prevent NetworkManager from managing this file, it's likely you've also
removed the comment. If not, you can either remove the comment before
upgrade, or recover your previous configuration from the
/etc/resolv.conf.orig-with-nm backup file after upgrade, and hopefully
have only a small blip in your upgrade experience. This will make the
upgrade work properly for the 99% of users who don't mess with the
defaults and should not be too difficult for those who do.
Michael
11:46 p.m.
On Monday, August 10, 2020 9:52:42 AM MST Michael Catanzaro wrote:
On Tue, Aug 4, 2020 at 9:08 am, Michael Catanzaro
<mcatanzaro(a)gnome.org> wrote:
> Zbigniew, do you agree that we should remove the script if and only
> if it is generated by NetworkManager? Otherwise, the change is only
> partially-implemented for users upgrading from F32 and earlier.
We agreed to go with this approach. /etc/resolv.conf will be moved to
/etc/resolv.conf.orig-with-nm on upgrade to F33 if the 'Generated by
NetworkManager' comment is present. If you've gone to the trouble to
prevent NetworkManager from managing this file, it's likely you've also
removed the comment. If not, you can either remove the comment before
upgrade, or recover your previous configuration from the
/etc/resolv.conf.orig-with-nm backup file after upgrade, and hopefully
have only a small blip in your upgrade experience. This will make the
upgrade work properly for the 99% of users who don't mess with the
defaults and should not be too difficult for those who do.
That comment being there doesn't mean that is still the case. I haven't
removed that comment, I just fixed the file. It would be best to just not mess
with this file on upgrade, and, instead, change the behavior of new installs.
This wouldn't break anything, and would have all newly installed systems with
the configuration you seem to want.
There's no reason to break peoples' systems here, we can easily plan for this.
I also don't know where you're getting this estimate of 99% of users not
changing this file.
--
John M. Harris, Jr.
11:55 p.m.
On Saturday, August 29, 2020, John M. Harris Jr <johnmh(a)splentity.com>
wrote:
On Monday, August 10, 2020 9:52:42 AM MST Michael Catanzaro wrote:
> On Tue, Aug 4, 2020 at 9:08 am, Michael Catanzaro
> <mcatanzaro(a)gnome.org> wrote:
>
> > Zbigniew, do you agree that we should remove the script if and only
> > if it is generated by NetworkManager? Otherwise, the change is only
> > partially-implemented for users upgrading from F32 and earlier.
>
>
> We agreed to go with this approach. /etc/resolv.conf will be moved to
> /etc/resolv.conf.orig-with-nm on upgrade to F33 if the 'Generated by
> NetworkManager' comment is present. If you've gone to the trouble to
> prevent NetworkManager from managing this file, it's likely you've also
> removed the comment. If not, you can either remove the comment before
> upgrade, or recover your previous configuration from the
> /etc/resolv.conf.orig-with-nm backup file after upgrade, and hopefully
> have only a small blip in your upgrade experience. This will make the
> upgrade work properly for the 99% of users who don't mess with the
> defaults and should not be too difficult for those who do.
That comment being there doesn't mean that is still the case. I haven't
removed that comment, I just fixed the file. It would be best to just not
mess
with this file on upgrade, and, instead, change the behavior of new
installs.
This wouldn't break anything, and would have all newly installed systems
with
the configuration you seem to want.
There's no reason to break peoples' systems here, we can easily plan for
this.
I also don't know where you're getting this estimate of 99% of users not
changing this file.
People expect to get the new features on upgrades without having to
reinstall.
There is no reason to upgrades differently - if you have customized
configuration you should be reading the changes before doing an upgrade.
--
John M. Harris, Jr.
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.
org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.
fedoraproject.org
11:59 p.m.
On Friday, August 28, 2020 9:55:18 PM MST drago01 wrote:
On Saturday, August 29, 2020, John M. Harris Jr
<johnmh(a)splentity.com>
wrote:
> On Monday, August 10, 2020 9:52:42 AM MST Michael Catanzaro wrote:
> > On Tue, Aug 4, 2020 at 9:08 am, Michael Catanzaro
> >
> > <mcatanzaro(a)gnome.org> wrote:
> > > Zbigniew, do you agree that we should remove the script if and only
> > > if it is generated by NetworkManager? Otherwise, the change is only
> > > partially-implemented for users upgrading from F32 and earlier.
> >
> > We agreed to go with this approach. /etc/resolv.conf will be moved to
> > /etc/resolv.conf.orig-with-nm on upgrade to F33 if the 'Generated by
> > NetworkManager' comment is present. If you've gone to the trouble to
> > prevent NetworkManager from managing this file, it's likely you've
also
> > removed the comment. If not, you can either remove the comment before
> > upgrade, or recover your previous configuration from the
> > /etc/resolv.conf.orig-with-nm backup file after upgrade, and hopefully
> > have only a small blip in your upgrade experience. This will make the
> > upgrade work properly for the 99% of users who don't mess with the
> > defaults and should not be too difficult for those who do.
>
> That comment being there doesn't mean that is still the case. I haven't
> removed that comment, I just fixed the file. It would be best to just not
> mess
> with this file on upgrade, and, instead, change the behavior of new
> installs.
> This wouldn't break anything, and would have all newly installed systems
> with
> the configuration you seem to want.
>
> There's no reason to break peoples' systems here, we can easily plan for
> this.
> I also don't know where you're getting this estimate of 99% of users not
> changing this file.
People expect to get the new features on upgrades without having to
reinstall.
This isn't a new feature, it's breaking existing functionality.
There is no reason to upgrades differently - if you have customized
configuration you should be reading the changes before doing an upgrade.
The major reason that we've had different functionality on upgrade in the past
is precisely what I described: to prevent needlessly breaking the users'
systems. Regardless of the changes coming, updating should never break your
system, especially when it's easily avoided, as it is in this case.
--
John M. Harris, Jr.
6:35 p.m.
On Tuesday, July 28, 2020 9:22:58 AM MST Michael Catanzaro wrote:
I agree we should not replace /etc/resolv.conf if it's not
already a
symlink (although this will not be a common case, since by default it
is a symlink managed by NetworkManager).
I haven't found any systems where that's the case, though my systems have been
upgraded all along through from ~F24. Looking at my latest install, which has
been upgraded from F30, /etc/resolv.conf is still just a file by default.
On Tue, Jul 28, 2020 at 11:07 am, Neal Gompa
<ngompa13(a)gmail.com> wrote:
> We can be smart here and replace the file when we detect that it's
> managed by NetworkManager. Otherwise we won't replace it.
Currently we actually don't touch it at all, which is not good because
it means systemd-resolved will not be managing resolv.conf on upgraded
systems.
That's not necessarily a bad thing. Regardless of what we do here, systemd-
resolved is a consumer of NetworkManager's configuration.
We should replace it with a symlink to systemd if (and only
if) it's managed by NetworkManager.
Sounds good.
--
John M. Harris, Jr.
6:45 p.m.
On Tue, Jul 28, 2020 at 4:35 pm, John M. Harris Jr
<johnmh(a)splentity.com> wrote:
I haven't found any systems where that's the case, though my
systems
have been
upgraded all along through from ~F24. Looking at my latest install,
which has
been upgraded from F30, /etc/resolv.conf is still just a file by
default.
Sorry I'm wrong, it's managed by NetworkManager but *not* as a symlink.
It's just edited in-place.
12:45 a.m.
On Tue, Jul 28, 2020 at 06:45:06PM -0500, Michael Catanzaro wrote:
On Tue, Jul 28, 2020 at 4:35 pm, John M. Harris Jr
<johnmh(a)splentity.com>
wrote:
> I haven't found any systems where that's the case, though my systems
> have been
> upgraded all along through from ~F24. Looking at my latest install,
> which has
> been upgraded from F30, /etc/resolv.conf is still just a file by
> default.
Sorry I'm wrong, it's managed by NetworkManager but *not* as a symlink. It's
just edited in-place.
Hmm. There are different solutions in the wild:
$ exa -l /etc/resolv.conf
lrwxrwxrwx@ 35 root 28 wrz 2019 /etc/resolv.conf ->
/var/run/NetworkManager/resolv.conf
This is Fedora 32, initially installed a decade or so ago, and upgraded.
--
Tomasz Torcz “Never underestimate the bandwidth of a station
tomek(a)pipebreaker.pl wagon filled with backup tapes.” — Jim Gray
4:12 p.m.
Observations based on Fedora-Workstation-Live-x86_64-33-20200828.n.0.iso
1. The ext4+squashfs image on media has no /etc/resolv.conf at all;
this is what forms the basis of /dev/mapper/live-base, and is the
source for installations (copied by rsync).
2. The installation live environment uses /dev/mapper/live-rw as
system root; it has an /etc/resolv.conf symlink pointed to
/run/systemd/resolve/stub-resolv.conf
3. The installed system has an /etc/resolv.conf file following
installation (while still in the installation environment). First line
is:
# This file is managed by man:systemd-resolved(8). Do not edit.
4. Following a reboot, the system has an /etc/resolv.conf file. First line is:
# Generated by NetworkManager
Are these the expected behavior?
--
Chris Murphy
5:30 a.m.
On my F33 test system (new install yesterday) I can see my NAS but I can't
connect to it. Could that be due to this change?
Best regards
Andreas
3:19 p.m.
Den mån 31 aug. 2020 kl 00:55 skrev Michael Catanzaro <mcatanzaro(a)gnome.org
:
On Sun, Aug 30, 2020 at 12:30 pm, Andreas Tunek
<andreas.tunek(a)gmail.com> wrote:
> On my F33 test system (new install yesterday) I can see my NAS but I
> can't connect to it. Could that be due to this change?
Possibly! Try using 'resolvectl query' and see what it says....
I can't get that command to do anything useful in either F32 or F33.
However, if I write "http://nas-name.local in F32 in either Firefox or
Gnome Web I can connect to my NAS, but if I write the same in F33 in the
same programs I get an error.
Best regards
Andreas
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
3:39 p.m.
On Mon, Aug 31, 2020 at 10:19 pm, Andreas Tunek
<andreas.tunek(a)gmail.com> wrote:
I can't get that command to do anything useful in either F32 or
F33.
You should see something like:
$ resolvectl query example.com
example.com: 2606:2800:220:1:248:1893:25c8:1946 -- link: tun0
93.184.216.34 -- link: tun0
-- Information acquired via protocol DNS in 86.4ms.
-- Data is authenticated: no
And that should be working out-of-the-box in F33.
However, if I write "http://nas-name.local in F32 in either
Firefox
or Gnome Web I can connect to my NAS, but if I write the same in F33
in the same programs I get an error.
Ah, I bet this your NAS is mDNS, which is broken right now:
https://bugzilla.redhat.com/show_bug.cgi?id=1867830
Until the root cause is diagnosed, here is a workaround you can try. As
root, open up /etc/authselect/user-nsswitch.conf and look at the hosts
line. In a freshly-installed F33 system, it should look like this:
hosts: resolve [!UNAVAIL=return] myhostname files mdns4_minimal
[NOTFOUND=return] dns
This says: "if resolved is running, and it doesn't return a hostname,
then STOP and don't try anything else." Everything else is listed only
for the case where resolved is not running. But since resolved is
currently not resolving mDNS as expected, let's change it to check with
avahi first, then check with resolved second, like this:
hosts: mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return]
myhostname files dns
Then, as root, run:
# authselect apply-changes
and then restart your browser. That's not the configuration we want to
use in F33, but hopefully it will "fix" your problem. Please let me
know if it works!
Michael
1:49 a.m.
On Monday, August 31, 2020 1:39:37 PM MST Michael Catanzaro wrote:
On Mon, Aug 31, 2020 at 10:19 pm, Andreas Tunek
<andreas.tunek(a)gmail.com> wrote:
> I can't get that command to do anything useful in either F32 or F33.
You should see something like:
$ resolvectl query example.com
example.com: 2606:2800:220:1:248:1893:25c8:1946 -- link: tun0
93.184.216.34 -- link: tun0
-- Information acquired via protocol DNS in 86.4ms.
-- Data is authenticated: no
And that should be working out-of-the-box in F33.
> However, if I write "http://nas-name.local in F32 in either Firefox
> or Gnome Web I can connect to my NAS, but if I write the same in F33
> in the same programs I get an error.
Ah, I bet this your NAS is mDNS, which is broken right now:
https://bugzilla.redhat.com/show_bug.cgi?id=1867830
Until the root cause is diagnosed, here is a workaround you can try. As
root, open up /etc/authselect/user-nsswitch.conf and look at the hosts
line. In a freshly-installed F33 system, it should look like this:
hosts: resolve [!UNAVAIL=return] myhostname files mdns4_minimal
[NOTFOUND=return] dns
This says: "if resolved is running, and it doesn't return a hostname,
then STOP and don't try anything else." Everything else is listed only
for the case where resolved is not running. But since resolved is
currently not resolving mDNS as expected, let's change it to check with
avahi first, then check with resolved second, like this:
hosts: mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return]
myhostname files dns
Then, as root, run:
# authselect apply-changes
and then restart your browser. That's not the configuration we want to
use in F33, but hopefully it will "fix" your problem. Please let me
know if it works!
Michael
Michael,
The file is /etc/nsswitch.conf.
--
John M. Harris, Jr.
9:14 a.m.
On Mon, Aug 31, 2020 at 11:49 pm, John M. Harris Jr
<johnmh(a)splentity.com> wrote:
Michael,
The file is /etc/nsswitch.conf.
You're wasting everyone's time with these low-effort spam posts. Lest
anyone become confused, there is a big warning at the top of that file
warning you that it is managed by authselect, and that manual changes
will be overwritten.
Anyway, it seems this problem was not related to mDNS at all, so
doesn't matter.
9:21 p.m.
On Tuesday, September 1, 2020 7:14:35 AM MST Michael Catanzaro wrote:
On Mon, Aug 31, 2020 at 11:49 pm, John M. Harris Jr
<johnmh(a)splentity.com> wrote:
> Michael,
>
> The file is /etc/nsswitch.conf.
You're wasting everyone's time with these low-effort spam posts.
I don't see how this could possibly be spam. This is where the file is, is it
not?
Lest anyone become confused, there is a big warning at the top of
that file
warning you that it is managed by authselect, and that manual changes
will be overwritten.
I don't know what you're talking about here. Am I missing something? Is this a
F33 Change? Exact content of my /etc/nsswitch:
#
# /etc/nsswitch.conf
#
# An example Name Service Switch config file. This file should be
# sorted with the most-used services at the beginning.
#
# The entry '[NOTFOUND=return]' means that the search for an
# entry should stop if the search in the previous entry turned
# up nothing. Note that if the search failed due to some other reason
# (like no NIS server responding) then the search continues with the
# next entry.
#
# Valid entries include:
#
# nisplus Use NIS+ (NIS version 3)
# nis Use NIS (NIS version 2), also called YP
# dns Use DNS (Domain Name Service)
# files Use the local files in /etc
# db Use the pre-processed /var/db files
# compat Use /etc files plus *_compat pseudo-databases
# hesiod Use Hesiod (DNS) for user lookups
# sss Use sssd (System Security Services Daemon)
# [NOTFOUND=return] Stop searching if not found so far
#
# 'sssd' performs its own 'files'-based caching, so it should
# generally come before 'files'.
# To use 'db', install the nss_db package, and put the 'db' in front
# of 'files' for entries you want to be looked up first in the
# databases, like this:
#
# passwd: db files
# shadow: db files
# group: db files
passwd: sss files
shadow: sss files
group: sss files
hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname
bootparams: files
ethers: files
netmasks: files
networks: files
protocols: files
rpc: files
services: sss files
netgroup: sss
publickey: files
automount: sss files
aliases: files
--
John M. Harris, Jr.
9:29 p.m.
On 2020-09-02 10:21, John M. Harris Jr wrote:
I don't know what you're talking about here. Am I missing
something? Is this a
F33 Change? Exact content of my /etc/nsswitch:
Is your system an upgrade of an earlier version?
In my case I have an F32 system which has been around for a few years. It has the text
you cite.
I also have an F32 system which was a fresh install as well as a F31 fresh install. Both
have
# Generated by authselect on Fri Jul 31 09:40:00 2020
# Do not modify this file manually.
# If you want to make changes to nsswitch.conf please modify
# /etc/authselect/user-nsswitch.conf and run 'authselect apply-changes'.
In /etc/nsswitch.conf. So, the default use of authselect has been around since at least
F31.
--
The key to getting good answers is to ask good questions.
10:06 p.m.
On Tuesday, September 1, 2020 7:29:44 PM MST Ed Greshko wrote:
On 2020-09-02 10:21, John M. Harris Jr wrote:
> I don't know what you're talking about here. Am I missing something? Is
> this a F33 Change? Exact content of my /etc/nsswitch:
Is your system an upgrade of an earlier version?
In my case I have an F32 system which has been around for a few years. It
has the text you cite.
I also have an F32 system which was a fresh install as well as a F31
fresh
install. Both have
# Generated by authselect on Fri Jul 31 09:40:00 2020
# Do not modify this file manually.
# If you want to make changes to nsswitch.conf please modify
# /etc/authselect/user-nsswitch.conf and run 'authselect apply-changes'.
In /etc/nsswitch.conf. So, the default use of authselect has been around
since at least F31.
My system was originally F24. So, which of these is the actual configuration
file at this point?
--
John M. Harris, Jr.
10:09 p.m.
On 2020-09-02 11:06, John M. Harris Jr wrote:
On Tuesday, September 1, 2020 7:29:44 PM MST Ed Greshko wrote:
> On 2020-09-02 10:21, John M. Harris Jr wrote:
>
>> I don't know what you're talking about here. Am I missing something? Is
>> this a F33 Change? Exact content of my /etc/nsswitch:
>
> Is your system an upgrade of an earlier version?
>
> In my case I have an F32 system which has been around for a few years. It
> has the text you cite.
> I also have an F32 system which was a fresh install as well as a F31 fresh
> install. Both have
> # Generated by authselect on Fri Jul 31 09:40:00 2020
> # Do not modify this file manually.
>
> # If you want to make changes to nsswitch.conf please modify
> # /etc/authselect/user-nsswitch.conf and run 'authselect apply-changes'.
>
> In /etc/nsswitch.conf. So, the default use of authselect has been around
> since at least F31.
My system was originally F24. So, which of these is the actual configuration
file at this point?
Upgrades didn't change how things are done. I think it may have been F29 or F30 when
authselect
was introduced and made the default method to manage nsswitch.conf.
FWIW, on this old system of mine I did just run
authselect select --force sssd
to bring it forward to the current practice.
--
The key to getting good answers is to ask good questions.
9:50 p.m.
On Tue, Sep 1, 2020 at 10:21 PM John M. Harris Jr <johnmh(a)splentity.com> wrote:
On Tuesday, September 1, 2020 7:14:35 AM MST Michael Catanzaro wrote:
> On Mon, Aug 31, 2020 at 11:49 pm, John M. Harris Jr
> <johnmh(a)splentity.com> wrote:
>
> > Michael,
> >
> > The file is /etc/nsswitch.conf.
>
>
> You're wasting everyone's time with these low-effort spam posts.
I don't see how this could possibly be spam. This is where the file is, is it
not?
> Lest anyone become confused, there is a big warning at the top of that file
> warning you that it is managed by authselect, and that manual changes
> will be overwritten.
I don't know what you're talking about here. Am I missing something? Is this a
F33 Change? Exact content of my /etc/nsswitch:
Stated in the file or not, it is in fact edited by authconfig,
sometimes as part of RPM installation. Manual editing of it is not and
has never been stable without setting up some kind of configuration
management to restore RPM based modifications. Been there, done that,
with one of those 10-year solo admins who decided to hand-edit tweaks
but refused to permit management of the file.
And oh, "files" always comes first because local config files should
always take priority over upstream network based services.
10 p.m.
On Tue, Sep 1, 2020 at 10:51 PM Nico Kadel-Garcia <nkadel(a)gmail.com> wrote:
On Tue, Sep 1, 2020 at 10:21 PM John M. Harris Jr <johnmh(a)splentity.com> wrote:
>
> On Tuesday, September 1, 2020 7:14:35 AM MST Michael Catanzaro wrote:
> > On Mon, Aug 31, 2020 at 11:49 pm, John M. Harris Jr
> > <johnmh(a)splentity.com> wrote:
> >
> > > Michael,
> > >
> > > The file is /etc/nsswitch.conf.
> >
> >
> > You're wasting everyone's time with these low-effort spam posts.
>
> I don't see how this could possibly be spam. This is where the file is, is it
> not?
>
> > Lest anyone become confused, there is a big warning at the top of that file
> > warning you that it is managed by authselect, and that manual changes
> > will be overwritten.
>
> I don't know what you're talking about here. Am I missing something? Is this
a
> F33 Change? Exact content of my /etc/nsswitch:
Stated in the file or not, it is in fact edited by authconfig,
sometimes as part of RPM installation. Manual editing of it is not and
has never been stable without setting up some kind of configuration
management to restore RPM based modifications. Been there, done that,
with one of those 10-year solo admins who decided to hand-edit tweaks
but refused to permit management of the file.
And oh, "files" always comes first because local config files should
always take priority over upstream network based services.
authconfig is dead. But yes, nsswitch is managed by authselect.
--
真実はいつも一つ！/ Always, there's only one truth!
10:09 p.m.
On 2020-09-02 11:00, Neal Gompa wrote:
On Tue, Sep 1, 2020 at 10:51 PM Nico Kadel-Garcia
<nkadel(a)gmail.com> wrote:
> On Tue, Sep 1, 2020 at 10:21 PM John M. Harris Jr <johnmh(a)splentity.com>
wrote:
>> On Tuesday, September 1, 2020 7:14:35 AM MST Michael Catanzaro wrote:
>>> On Mon, Aug 31, 2020 at 11:49 pm, John M. Harris Jr
>>> <johnmh(a)splentity.com> wrote:
>>>
>>>> Michael,
>>>>
>>>> The file is /etc/nsswitch.conf.
>>>
>>> You're wasting everyone's time with these low-effort spam posts.
>> I don't see how this could possibly be spam. This is where the file is, is
it
>> not?
>>
>>> Lest anyone become confused, there is a big warning at the top of that file
>>> warning you that it is managed by authselect, and that manual changes
>>> will be overwritten.
>> I don't know what you're talking about here. Am I missing something? Is
this a
>> F33 Change? Exact content of my /etc/nsswitch:
> Stated in the file or not, it is in fact edited by authconfig,
> sometimes as part of RPM installation. Manual editing of it is not and
> has never been stable without setting up some kind of configuration
> management to restore RPM based modifications. Been there, done that,
> with one of those 10-year solo admins who decided to hand-edit tweaks
> but refused to permit management of the file.
>
> And oh, "files" always comes first because local config files should
> always take priority over upstream network based services.
authconfig is dead. But yes, nsswitch is managed by authselect.
I would state that slightly differently.
nsswitch.conf is now managed by authselect by default.
I say that since, as I've already mentioned, I have a F32 system which has been
upgraded over time
from versions without authselect. The upgrade didn't changed that.
So, to become more conforming to current practice I did just run...
authselect select --force sssd
--
The key to getting good answers is to ask good questions.
8:45 a.m.
On Tue, Sep 1, 2020 at 10:50 pm, Nico Kadel-Garcia <nkadel(a)gmail.com>
wrote:
And oh, "files" always comes first because local config
files should
always take priority over upstream network based services.
Zbigniew wound up moving files first in the end, but his justification
for putting resolve first is here:
https://github.com/authselect/authselect/pull/222#discussion_r454460745.
It actually caches the local files so they only have to be read once
globally, rather than once for each process.
But that failed due to our mDNS bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1867830#c34.
8:48 p.m.
This is just a data point:
F31 Workstation clean installed (Live ISO), then updated to current
F31, then upgraded to F33 (no interim F32).
/etc/nsswitch.conf
hosts: files mdns4_minimal [NOTFOUND=return] resolve
[!UNAVAIL=return] myhostname dns
And
lrwxrwxrwx. 1 root root 39 Sep 10 19:42 resolv.conf ->
../run/systemd/resolve/stub-resolv.conf
Chris Murphy
11:44 p.m.
New subject: This is bad, was Re: Fedora 33 System-Wide Change proposal:
systemd-resolved
Subject: Re: Fedora 33 System-Wide Change proposal: systemd-resolved
I was just hit by the first bug in systemd-resolved 4 days after I
upgraded to fedora33. I will file a bug report for that, but I wanted
to discuss something more fundamental.
systemd-resolved has a number of architectural flaws. When these were
pointed out, bugs are not accepted and closed or ignored. Worse, I
was told that systemd-resolved would not become the system DNS resolver,
so I could just choose to not use it.
Unfortunately, with my upgrade to fedora 33 I was unwittingly upgraded
to systemd-resolved. I want to remove it from my system, but I cannot
because it is not even a sub-package of systemd, it is part of the
core systemd package. This goes against promises made in the past.
Not only that, this change apparently "obsoletes" /etc/resolv.conf,
which is just not acceptable.
It is my opinion as a long time DNS RFC author and package maintainer
that systemd-resolved is not a suitable DNS resolver. Downgrading
DNSSEC allowing local DNS to bypass DNSSEC is bad enough, but I
read on:
https://fedoraproject.org/wiki/Changes/systemd-resolved
that DNSSEC is now completely disabled. Again, this is completely
unacceptable. DNSSEC is part of the core of DNS protocols. My fedora
mail server uses DNSSEC based TLSA records to prevent MITM attacks
on the STARTTLS layer, which is now completely broken. My IPsec VPN
server uses dnssec validation using the specified nameserves in
/etc/resolve.conf that now point to systemd-resolvd that does not
return DNSSEC records and is completely broken:
paul@thinkpad:~$ dig +dnssec vpn.nohats.ca @127.0.0.53
; <<>> DiG 9.11.22-RedHat-9.11.22-1.fc33 <<>> +dnssec
vpn.nohats.ca @127.0.0.53
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51669
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 65494
; OPT=5: 05 07 08 0a 0d 0e 0f (".......")
; OPT=6: 01 02 04 ("...")
; OPT=7: 01 (".")
;; QUESTION SECTION:
;vpn.nohats.ca. IN A
;; ANSWER SECTION:
vpn.nohats.ca. 10 IN A 193.110.157.148
;; Query time: 143 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Mon Sep 28 00:18:32 EDT 2020
;; MSG SIZE rcvd: 81
libreswan will see this result as an attack, and fail to resolve DNS names
in its configuration. My postfix daemon will hold on to mail because
it cannot get a DNSSEC proof of denial of existence of TLSA records if
all DNSSEC records are filtered - even for domains that don't use DNSSEC
because the denial of existence of DNSSEC for a specific domain requires
the return of DNSSEC records that systemd now does not return.
I am sorry that I did not follow the fedora list carefully enough to
notice this feature when it was proposed.
This change is harmful to network security, impacts existing installations
depending on DNSSEC security, and leaks private queries for VPN/internal
domains to the open internet, and prefers faster non-dnssec answers
over dnssec validated answers. It fails various types of queries,
misimplements part of the DNS protocol. Not only according to me, but
to 20years+ developers of the bind software as well.
The first mandatory step is to not disable DNSSEC. If I put on my
security hat, I would actually have to look into filing a CVE for Fedora
33.
A further discussion should happen on the future of systemd-resolved as
the default Fedora (and later RHEL/CentOS) system resolver.
Paul
4:25 a.m.
New subject: This is bad, was Re: Fedora 33 System-Wide Change proposal:
systemd-resolved
On 28.09.2020 06:44, Paul Wouters wrote:
Unfortunately, with my upgrade to fedora 33 I was unwittingly
upgraded
to systemd-resolved. I want to remove it from my system, but I cannot
because it is not even a sub-package of systemd, it is part of the
core systemd package.
You can always easily restore the previous behavior with Network Manager:
sudo rm -f /etc/resolv.conf
sudo ln -sf /run/NetworkManager/resolv.conf /etc/resolv.conf
sudo systemctl disable --now systemd-resolved.service
sudo systemctl mask systemd-resolved.service
sudo systemctl reboot
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
6:47 a.m.
New subject: This is bad, was Re: Fedora 33 System-Wide Change proposal:
systemd-resolved
On Mon, Sep 28, 2020 at 12:44:13AM -0400, Paul Wouters wrote:
>Subject: Re: Fedora 33 System-Wide Change proposal: systemd-resolved
I was just hit by the first bug in systemd-resolved 4 days after I
upgraded to fedora33. I will file a bug report for that, but I wanted
to discuss something more fundamental.
systemd-resolved has a number of architectural flaws. When these were
pointed out, bugs are not accepted and closed or ignored. Worse, I
was told that systemd-resolved would not become the system DNS resolver,
so I could just choose to not use it.
Unfortunately, with my upgrade to fedora 33 I was unwittingly upgraded
to systemd-resolved. I want to remove it from my system, but I cannot
because it is not even a sub-package of systemd, it is part of the
core systemd package. This goes against promises made in the past.
Hi,
in the end we decided to do a one-time "upgrade" of /etc/resolv.conf
through a scriptlet. Two reasons: one, the configuration is split between
/etc/resolv.conf, /etc/nsswitch.conf, and the enablement state of
systemd-resolved.service. We were already adjusting the other two, and
leaving old /etc/resolv.conf would likely lead to user confusion.
Also, without adjusting of /etc/resolv.conf, newly installed systems would be
different than upgraded ones in this fundamental regard. Overall, we think
it'll be better for users who don't care about the details of the dns
stack to fully swich to the new default. Power users and special setups
can undo the changes.
Instructions were already posted by Vitaly, so I won't repeat that here.
I'll just note that the scriptlet in systemd.rpm looks for
'Generated by NetworkManager' in /etc/resolv.conf as an indicator that
the file is autogenerated.
Not only that, this change apparently "obsoletes"
/etc/resolv.conf,
which is just not acceptable.
I'm not sure what you mean by that. It is true that /etc/resolv.conf
is not able to express split DNS. But it is still in place, with contents
that try to express the actual DNS configuration to the extent possible.
/etc/resolv.conf points to 127.0.0.53 as the resolver so that programs
which don't use the nss stack also go through systemd-resolved. The list
of remote dns servers can be queried from /run/systemd/resolve/resolv.conf
in the classic resolv.conf syntax, or over dbus.
It is my opinion as a long time DNS RFC author and package
maintainer
that systemd-resolved is not a suitable DNS resolver. Downgrading
DNSSEC allowing local DNS to bypass DNSSEC is bad enough, but I
read on:
https://fedoraproject.org/wiki/Changes/systemd-resolved
that DNSSEC is now completely disabled. Again, this is completely
unacceptable. DNSSEC is part of the core of DNS protocols. My fedora
mail server uses DNSSEC based TLSA records to prevent MITM attacks
on the STARTTLS layer, which is now completely broken. My IPsec VPN
server uses dnssec validation using the specified nameserves in
/etc/resolve.conf that now point to systemd-resolvd that does not
return DNSSEC records and is completely broken:
paul@thinkpad:~$ dig +dnssec vpn.nohats.ca @127.0.0.53
; <<>> DiG 9.11.22-RedHat-9.11.22-1.fc33 <<>> +dnssec
vpn.nohats.ca @127.0.0.53
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51669
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 65494
; OPT=5: 05 07 08 0a 0d 0e 0f (".......")
; OPT=6: 01 02 04 ("...")
; OPT=7: 01 (".")
;; QUESTION SECTION:
;vpn.nohats.ca. IN A
;; ANSWER SECTION:
vpn.nohats.ca. 10 IN A 193.110.157.148
;; Query time: 143 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Mon Sep 28 00:18:32 EDT 2020
;; MSG SIZE rcvd: 81
libreswan will see this result as an attack, and fail to resolve DNS names
in its configuration. My postfix daemon will hold on to mail because
it cannot get a DNSSEC proof of denial of existence of TLSA records if
all DNSSEC records are filtered - even for domains that don't use DNSSEC
because the denial of existence of DNSSEC for a specific domain requires
the return of DNSSEC records that systemd now does not return.
I am sorry that I did not follow the fedora list carefully enough to
notice this feature when it was proposed.
This change is harmful to network security, impacts existing installations
depending on DNSSEC security, and leaks private queries for VPN/internal
domains to the open internet, and prefers faster non-dnssec answers
over dnssec validated answers. It fails various types of queries,
misimplements part of the DNS protocol. Not only according to me, but
to 20years+ developers of the bind software as well.
You're mixing a few different things here. We decided to not enable
DNSSEC in resolved with this change, at least initially. For most
users, DNSSEC is problematic because various intermediary DNS servers
found in hotspots and routers don't support DNSSEC properly, leading
to hard-to-debug validation failures. DNSSEC support in resolved can
be enabled through resolved.conf. This may be a reasonable thing to do in
an environment where the configured dns servers are known to support dnssec
properly.
leaks private queries for VPN/internal domains to the open internet
It's a complicated subject, but that statement is not true in general.
systemd-resolved uses the servers it is told to use. Sometimes we're not
sure what to tell it, see https://bugzilla.redhat.com/show_bug.cgi?id=1863041
for a long discussion.
and prefers faster non-dnssec answers over dnssec validated answers
Not exactly. It uses a single server, unless the server is deemed non-responsive
and then it switches to the next one one, round-robin. Whether the server
does dnssec or not does not directly factor into this. (Except that if
resolved is configured to require dnssec, it won't want to talk to non-dnssec
servers.) If dnssec is enabled, it shall only accept validated answers.
The first mandatory step is to not disable DNSSEC. If I put on my
security hat, I would actually have to look into filing a CVE for Fedora
33.
A further discussion should happen on the future of systemd-resolved as
the default Fedora (and later RHEL/CentOS) system resolver.
Please file bugs if something is not working as it should. But please be
detailed, because there are a lot of unstated expectations based on how things
worked in the past that don't necessarily makes sense now. (Like with the name
servers accessible over vpn: some people think a server on vpn should be used
by default for *everything*, while others say that it shouldn't be used unless
configured so. Both options make sense depending on whom you trust more, but
resolved cannot guess by itself.)
Zbyszek
7:45 a.m.
New subject: This is bad, was Re: Fedora 33 System-Wide Change proposal:
systemd-resolved
On 28/09/2020 12:47, Zbigniew Jędrzejewski-Szmek wrote:
You're mixing a few different things here. We decided to not
enable
DNSSEC in resolved with this change, at least initially. For most
users, DNSSEC is problematic because various intermediary DNS servers
found in hotspots and routers don't support DNSSEC properly, leading
to hard-to-debug validation failures. DNSSEC support in resolved can
be enabled through resolved.conf. This may be a reasonable thing to do in
an environment where the configured dns servers are known to support dnssec
properly.
Well you're not just "not enabling it" really, for people like me that
have already made the switch to systemd-resolved (in large part in
search of better DNSSEC support) you're actually disabling it...
Having as I said experienced the trauma of trying to get DNSSEC working
reliably I do understand how hard a problem is it however. I just need
to remember to start adding a dropin to enable it again ;-)
Tom
--
Tom Hughes (tom(a)compton.nu)
http://compton.nu/
8:30 a.m.
New subject: This is bad, was Re: Fedora 33 System-Wide Change proposal:
systemd-resolved
On Mon, Sep 28, 2020 at 01:45:02PM +0100, Tom Hughes wrote:
On 28/09/2020 12:47, Zbigniew Jędrzejewski-Szmek wrote:
>You're mixing a few different things here. We decided to not enable
>DNSSEC in resolved with this change, at least initially. For most
>users, DNSSEC is problematic because various intermediary DNS servers
>found in hotspots and routers don't support DNSSEC properly, leading
>to hard-to-debug validation failures. DNSSEC support in resolved can
>be enabled through resolved.conf. This may be a reasonable thing to do in
>an environment where the configured dns servers are known to support dnssec
>properly.
Well you're not just "not enabling it" really, for people like me that
have already made the switch to systemd-resolved (in large part in
search of better DNSSEC support) you're actually disabling it...
Having as I said experienced the trauma of trying to get DNSSEC working
reliably I do understand how hard a problem is it however. I just need
to remember to start adding a dropin to enable it again ;-)
What was the setup you were using? If this is something that we can
reliably detect, I think it it would make sense to adjust the scriptlet
that enables systemd-resolved to print a hint about needing to set DNSSEC=yes.
(Or maybe even set that itself?).
Zbyszek
8:42 a.m.
New subject: This is bad, was Re: Fedora 33 System-Wide Change proposal:
systemd-resolved
On Monday, 28 September 2020 at 15:30, Zbigniew Jędrzejewski-Szmek wrote:
[...]
What was the setup you were using? If this is something that we can
reliably detect, I think it it would make sense to adjust the scriptlet
that enables systemd-resolved to print a hint about needing to set DNSSEC=yes.
(Or maybe even set that itself?).
Having dnssec-trigger package installed would be an indicator in my
case. Also, it does write its own comment in /etc/resolv.conf:
$ rpm -qa dnssec\*
dnssec-trigger-0.15-12.fc32.x86_64
dnssec-trigger-panel-0.15-12.fc32.x86_64
$ cat /etc/resolv.conf
# Generated by dnssec-trigger-script
nameserver 127.0.0.1
It uses a local unbound instance for local DNSSEC resolution.
Regards,
Dominik
--
Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
9:01 a.m.
New subject: This is bad, was Re: Fedora 33 System-Wide Change proposal:
systemd-resolved
On 28/09/2020 14:30, Zbigniew Jędrzejewski-Szmek wrote:
What was the setup you were using? If this is something that we can
reliably detect, I think it it would make sense to adjust the scriptlet
that enables systemd-resolved to print a hint about needing to set DNSSEC=yes.
(Or maybe even set that itself?).
Well on most systems I have replaced NetworkManager with
systemd-networkd though I don't think that's relevant here.
Other than that I have enable resolved and linked /etc/resolv.conf
to /run/systemd/resolve/stub-resolv.conf, so basically what this
change is doing.
Tom
--
Tom Hughes (tom(a)compton.nu)
http://compton.nu/
7:57 a.m.
New subject: This is bad, was Re: Fedora 33 System-Wide Change proposal:
systemd-resolved
On 9/28/20 6:47 AM, Zbigniew Jędrzejewski-Szmek wrote:
Instructions were already posted by Vitaly, so I won't repeat
that here.
I'll just note that the scriptlet in systemd.rpm looks for
'Generated by NetworkManager' in /etc/resolv.conf as an indicator that
the file is autogenerated.
Which is a terrible idea, as has been previously mentioned. It really
only indicates that the file was once touched my NetworkManager, not
that it is currently managed.
If often let Anaconda set up a new system witha NetworkManager-managed
DHCP and then convert to a legacy network scripts-managed static IP
later. This doesn't change the DNS server or domain, so I don't bother
editing resolv.conf to remove this comment. I'm relatively certain that
this is a common pattern.
--
========================================================================
In Soviet Russia, Google searches you!
========================================================================
8:32 a.m.
New subject: This is bad, was Re: Fedora 33 System-Wide Change proposal:
systemd-resolved
On Mon, Sep 28, 2020 at 07:57:13AM -0500, Ian Pilcher wrote:
On 9/28/20 6:47 AM, Zbigniew Jędrzejewski-Szmek wrote:
>Instructions were already posted by Vitaly, so I won't repeat that here.
>I'll just note that the scriptlet in systemd.rpm looks for
>'Generated by NetworkManager' in /etc/resolv.conf as an indicator that
>the file is autogenerated.
Which is a terrible idea, as has been previously mentioned. It really
only indicates that the file was once touched my NetworkManager, not
that it is currently managed.
If often let Anaconda set up a new system witha NetworkManager-managed
DHCP and then convert to a legacy network scripts-managed static IP
later. This doesn't change the DNS server or domain, so I don't bother
editing resolv.conf to remove this comment. I'm relatively certain that
this is a common pattern.
Yeah, that test is far from ideal, but we need something. If you have
a constructive proposal how to improve it, I'm all ears.
Zbyszek
10:51 a.m.
New subject: This is bad, was Re: Fedora 33 System-Wide Change proposal:
systemd-resolved
On 9/28/20 8:32 AM, Zbigniew Jędrzejewski-Szmek wrote:
Yeah, that test is far from ideal, but we need something. If you
have
a constructive proposal how to improve it, I'm all ears.
I anticipated this question. I don't have a good proposal for you ...
but I believe that it's up to the people advocating/implementing this
change to come up with that. If it isn't possible to automate this
change in a reliable way, maybe it shouldn't be automated.
--
========================================================================
In Soviet Russia, Google searches you!
========================================================================
11:03 a.m.
New subject: This is bad, was Re: Fedora 33 System-Wide Change proposal:
systemd-resolved
On Mon, Sep 28, 2020 at 10:51 am, Ian Pilcher <arequipeno(a)gmail.com>
wrote:
I anticipated this question. I don't have a good proposal for
you ...
but I believe that it's up to the people advocating/implementing this
change to come up with that. If it isn't possible to automate this
change in a reliable way, maybe it shouldn't be automated.
Of course it's impossible. :P The only way to guess whether
NetworkManager generated the file is to check if it says
"NetworkManager" at the top. There's no way to be certain.
Anyway, if you don't like this heuristic, we could decide to always
delete /etc/resolv.conf. The only other alternative I can think of
would be to leave it unchanged, such that upgraded systems don't get
fully migrated to systemd-resolved, but that's not a good option.
11:20 a.m.
New subject: This is bad, was Re: Fedora 33 System-Wide Change proposal:
systemd-resolved
On Mon, 28 Sep 2020, Michael Catanzaro wrote:
Anyway, if you don't like this heuristic, we could decide to
always delete
/etc/resolv.conf.
You will break all software linked against libunbound that uses the
ub_ctx_resolvconf() function. Most users of libunbound will use this,
because firewalls might prevent UDP 53 packets going out from anything
but the configured system resolver. It also then uses and gets use of
the system's DNS cache.
The only other alternative I can think of would be to leave
it unchanged, such that upgraded systems don't get fully migrated to
systemd-resolved, but that's not a good option.
I do not think systemd-resolved is ready for prime time, even unrelated
to the specific split DNS and DNSSEC case. A number of bugs have been
closed that affect DNS resolving despite DNS experts reporting this
as violating RFC standards and breaking things. For example:
https://github.com/systemd/systemd/issues/8967
Not migrating everything to systemd-resolved per default would not be the
worst solution.
Paul
12:04 p.m.
New subject: This is bad, was Re: Fedora 33 System-Wide Change proposal:
systemd-resolved
Dne 28. 09. 20 v 18:03 Michael Catanzaro napsal(a):
On Mon, Sep 28, 2020 at 10:51 am, Ian Pilcher
<arequipeno(a)gmail.com>
wrote:
> I anticipated this question. I don't have a good proposal for you ...
> but I believe that it's up to the people advocating/implementing this
> change to come up with that. If it isn't possible to automate this
> change in a reliable way, maybe it shouldn't be automated.
Of course it's impossible. :P The only way to guess whether
NetworkManager generated the file is to check if it says
"NetworkManager" at the top. There's no way to be certain.
I think that for the future generations, it could help if NM included
also checksum of the content.
Vít
1:20 p.m.
New subject: This is bad, was Re: Fedora 33 System-Wide Change proposal:
systemd-resolved
On Mon, 2020-09-28 at 13:32 +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Mon, Sep 28, 2020 at 07:57:13AM -0500, Ian Pilcher wrote:
> On 9/28/20 6:47 AM, Zbigniew Jędrzejewski-Szmek wrote:
> > Instructions were already posted by Vitaly, so I won't repeat that here.
> > I'll just note that the scriptlet in systemd.rpm looks for
> > 'Generated by NetworkManager' in /etc/resolv.conf as an indicator that
> > the file is autogenerated.
>
> Which is a terrible idea, as has been previously mentioned. It really
> only indicates that the file was once touched my NetworkManager, not
> that it is currently managed.
>
> If often let Anaconda set up a new system witha NetworkManager-managed
> DHCP and then convert to a legacy network scripts-managed static IP
> later. This doesn't change the DNS server or domain, so I don't bother
> editing resolv.conf to remove this comment. I'm relatively certain that
> this is a common pattern.
Yeah, that test is far from ideal, but we need something. If you have
a constructive proposal how to improve it, I'm all ears.
Check if Network Manager is actually enabled as well ?
Simo.
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc
11:35 a.m.
New subject: This is bad, was Re: Fedora 33 System-Wide Change proposal:
systemd-resolved
On Mon, Sep 28, 2020 at 02:20:46PM -0400, Simo Sorce wrote:
On Mon, 2020-09-28 at 13:32 +0000, Zbigniew Jędrzejewski-Szmek
wrote:
> On Mon, Sep 28, 2020 at 07:57:13AM -0500, Ian Pilcher wrote:
> > On 9/28/20 6:47 AM, Zbigniew Jędrzejewski-Szmek wrote:
> > > Instructions were already posted by Vitaly, so I won't repeat that
here.
> > > I'll just note that the scriptlet in systemd.rpm looks for
> > > 'Generated by NetworkManager' in /etc/resolv.conf as an indicator
that
> > > the file is autogenerated.
> >
> > Which is a terrible idea, as has been previously mentioned. It really
> > only indicates that the file was once touched my NetworkManager, not
> > that it is currently managed.
> >
> > If often let Anaconda set up a new system witha NetworkManager-managed
> > DHCP and then convert to a legacy network scripts-managed static IP
> > later. This doesn't change the DNS server or domain, so I don't
bother
> > editing resolv.conf to remove this comment. I'm relatively certain that
> > this is a common pattern.
>
> Yeah, that test is far from ideal, but we need something. If you have
> a constructive proposal how to improve it, I'm all ears.
Check if Network Manager is actually enabled as well ?
Makes sense:
https://src.fedoraproject.org/rpms/systemd/c/f3f602da25b51caaa188e02003f3...
https://src.fedoraproject.org/rpms/systemd/c/39055121170430fa599f45453354...
Zbyszek
2:03 p.m.
New subject: This is bad, was Re: Fedora 33 System-Wide Change proposal:
systemd-resolved
On Tue, 2020-09-29 at 16:35 +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Mon, Sep 28, 2020 at 02:20:46PM -0400, Simo Sorce wrote:
> On Mon, 2020-09-28 at 13:32 +0000, Zbigniew Jędrzejewski-Szmek wrote:
> > On Mon, Sep 28, 2020 at 07:57:13AM -0500, Ian Pilcher wrote:
> > > On 9/28/20 6:47 AM, Zbigniew Jędrzejewski-Szmek wrote:
> > > > Instructions were already posted by Vitaly, so I won't repeat
that here.
> > > > I'll just note that the scriptlet in systemd.rpm looks for
> > > > 'Generated by NetworkManager' in /etc/resolv.conf as an
indicator that
> > > > the file is autogenerated.
> > >
> > > Which is a terrible idea, as has been previously mentioned. It really
> > > only indicates that the file was once touched my NetworkManager, not
> > > that it is currently managed.
> > >
> > > If often let Anaconda set up a new system witha NetworkManager-managed
> > > DHCP and then convert to a legacy network scripts-managed static IP
> > > later. This doesn't change the DNS server or domain, so I don't
bother
> > > editing resolv.conf to remove this comment. I'm relatively certain
that
> > > this is a common pattern.
> >
> > Yeah, that test is far from ideal, but we need something. If you have
> > a constructive proposal how to improve it, I'm all ears.
>
> Check if Network Manager is actually enabled as well ?
Makes sense:
https://src.fedoraproject.org/rpms/systemd/c/f3f602da25b51caaa188e02003f3...
https://src.fedoraproject.org/rpms/systemd/c/39055121170430fa599f45453354...
Zbyszek
Nice job,
thanks Zbyszek!
Simo.
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc
8:52 a.m.
New subject: This is bad, was Re: Fedora 33 System-Wide Change proposal:
systemd-resolved
On Mon, Sep 28, 2020 at 07:57:13AM -0500, Ian Pilcher wrote:
On 9/28/20 6:47 AM, Zbigniew Jędrzejewski-Szmek wrote:
> Instructions were already posted by Vitaly, so I won't repeat that here.
> I'll just note that the scriptlet in systemd.rpm looks for
> 'Generated by NetworkManager' in /etc/resolv.conf as an indicator that
> the file is autogenerated.
Which is a terrible idea, as has been previously mentioned. It really
only indicates that the file was once touched my NetworkManager, not
that it is currently managed.
If often let Anaconda set up a new system witha NetworkManager-managed
DHCP and then convert to a legacy network scripts-managed static IP
later. This doesn't change the DNS server or domain, so I don't bother
editing resolv.conf to remove this comment. I'm relatively certain that
this is a common pattern.
Having read your email, I've checked my /etc/resolv.conf and _removed_
the NM comment. Never bothered to touch the comment before, as I'm using
systemd-networkd for networking on the server. I would say that leaving
the comment is a common pattern.
There's not much there actually, only search domain and 'nameserver ::1',
where dnsmasq listens, providing split-horizon for my network and pihole
blacklisting of advertisment networks.
But yeah, there are no better ideas how to handle resolv.conf on upgrades.
--
Tomasz Torcz “Never underestimate the bandwidth of a station
tomek(a)pipebreaker.pl wagon filled with backup tapes.” — Jim Gray
9:28 a.m.
New subject: This is bad, was Re: Fedora 33 System-Wide Change proposal:
systemd-resolved
On Mon, 28 Sep 2020, Zbigniew Jędrzejewski-Szmek wrote:
> This change is harmful to network security, impacts existing
installations
> depending on DNSSEC security, and leaks private queries for VPN/internal
> domains to the open internet, and prefers faster non-dnssec answers
> over dnssec validated answers. It fails various types of queries,
> misimplements part of the DNS protocol. Not only according to me, but
> to 20years+ developers of the bind software as well.
You're mixing a few different things here. We decided to not enable
DNSSEC in resolved with this change, at least initially. For most
users, DNSSEC is problematic because various intermediary DNS servers
found in hotspots and routers don't support DNSSEC properly, leading
to hard-to-debug validation failures. DNSSEC support in resolved can
be enabled through resolved.conf. This may be a reasonable thing to do in
an environment where the configured dns servers are known to support dnssec
properly.
If you want to do innovate new things with hotspot detection, the place
to do the protocol work is at the IETF Captive Portal Working Group:
https://datatracker.ietf.org/wg/capport/charter/
Work done there include an architecture docoument:
https://datatracker.ietf.org/doc/draft-ietf-capport-architecture/
Captive Portal API: https://tools.ietf.org/html/rfc8908
DHCP and RA options: https://tools.ietf.org/html/rfc8910
These are efforts with big vendor signon. These will be compatible with
new hotspots and work similar to other network devices. This is
preferred over homegrown solutions.
> leaks private queries for VPN/internal domains to the open
internet
It's a complicated subject, but that statement is not true in general.
It was true when we had a DNSSEC systemd meeting in Brno about five years
ago when I raised it as a privacy issue and was told my use case was
"not valid". And it still seems to be true.
With Tommy Pauly of Apple, I co-write Split DNS for IKEv2 VPNs, that saw
a major discusison in the security area of IETF (specifically SAAG and
TLS) to ensure every one (including browser vendors) were okay with
the resulting DNS reconfiguration requirements of VPN servers. This
is especially important now that we are storing certificates as TLSA
records in DNS, storing encrypted SNI in DNS, and the current draft SVCB
and HTTPS service binding DNS records that are used in Apple's IOS14.
These records contain information that must not be vulnerale to spoofing
or rogue DNS server redirection and should be DNSSEC signed.
The designers of systemd-resolved will find it a useful read:
https://tools.ietf.org/html/rfc8598
systemd-resolved uses the servers it is told to use. Sometimes
we're not
sure what to tell it, see https://bugzilla.redhat.com/show_bug.cgi?id=1863041
for a long discussion.
If that worked, I wouldn't have even found out that my system got
upgraded to systemd-resolved. Clearly this is broken. Furthermore,
I doubt the rhbz will take into account the various risks of
reconfiguring DNS and DNSSEC trust anchors or how to limit certain
forwarders to certain domains. We are not talking about bugs that need
fixing. We are talking about design decisions that I objected to five
years ago that are now starting to cause damage.
> and prefers faster non-dnssec answers over dnssec validated
answers
Not exactly. It uses a single server, unless the server is deemed non-responsive
and then it switches to the next one one, round-robin. Whether the server
does dnssec or not does not directly factor into this. (Except that if
resolved is configured to require dnssec, it won't want to talk to non-dnssec
servers.) If dnssec is enabled, it shall only accept validated answers.
This is better thant it was five years ago. I'm glad some things were
at least successfully conveyed in the Brno meeting. However, this still
leaks queries meant for the LAN or VPN onto the wide internet and is
still a privacy and security concern. Some of these issues might look
like minor unimportant bugs, but could be life changing for some people.
I recommend the systemd-resolved people look into the Human Rights
Protocol Considerations Research Group (https://irtf.org/hrpc) and its
draft documents.
Please file bugs if something is not working as it should. But please
be
detailed, because there are a lot of unstated expectations based on how things
worked in the past that don't necessarily makes sense now.
My servers had functional DNSSEC. After an upgrade they don't. No more
detailed reports are needed. You know what you need to do to address
this bug. I see Florian had already filed a rhbz a few days ago:
https://bugzilla.redhat.com/show_bug.cgi?id=1879028
systemd-resolved should not be a required base system package. You know
what you need to do to fix this as well. If you want to make it part of
the graphical desktop install that is okay. But it must not be included
in server installs.
(Like with the name
servers accessible over vpn: some people think a server on vpn should be used
by default for *everything*, while others say that it shouldn't be used unless
configured so. Both options make sense depending on whom you trust more, but
resolved cannot guess by itself.)
See RFC 8598 for a detailed instruction on how you must implement this
for IKEv2 / IPsec VPNs. Other VPN technologies should do something
similar. It is very clear how you should act. And yes, some of that
might depend on the VPN provisioning configuration.
libreswan already implements support for the unbound DNS server to
reconfigure DNS limited to the domains covered by the VPN. This can be
extended to support systemd-resolved if you point me to a documentation
API.
Paul
9:50 a.m.
New subject: This is bad, was Re: Fedora 33 System-Wide Change proposal:
systemd-resolved
On Mon, Sep 28, 2020 at 10:28 am, Paul Wouters <paul(a)nohats.ca> wrote:
This is better thant it was five years ago. I'm glad some things
were
at least successfully conveyed in the Brno meeting. However, this
still
leaks queries meant for the LAN or VPN onto the wide internet and is
still a privacy and security concern.
systemd-resolved is designed to prevent DNS leaks that are unfixable
with nss-mdns, not create them. DNS requests go *exactly* where you
tell systemd-resolved to send them. If you've found some case where
requests are not going where they're supposed to, then please report a
bug.
Michael
2:54 p.m.
New subject: This is bad, was Re: Fedora 33 System-Wide Change proposal:
systemd-resolved
On Mo, 28.09.20 10:28, Paul Wouters (paul(a)nohats.ca) wrote:
This is better thant it was five years ago. I'm glad some things
were
at least successfully conveyed in the Brno meeting. However, this still
leaks queries meant for the LAN or VPN onto the wide internet and is
Classic resolv.conf cannot communicate to us where what should be
routed. There's no per-domain syntax.
People have different usecases when they have multiple interfaces with
multiple sets of DNS data around. We cannot guess which one of the two
ifaces is the one to trust without explicit help.
Thing is: your LAN connection might be your trusted home network, or
some untrusted cafe wifi. your VPN connection might be your trusted
home VPN or the VPN to your company where you'd rather not send all
DNS traffic. resolved cannot possibly guess what the trust level of
ifaces and their DNS servers is, and if we'd priorize one clearly over
the other we are likely getting it wrong: if we send all DNS traffic
exclusively to the VPN then you lose resolveability of your local LAN
names, such as the router or print config UI. If we send all DNS
traffic exclusively to the local router's DHCP lease configured DNS
server you'd of course lose the ability to resolve company private
names.
So what did we opt to do? We think that working DNS is better than
non-working DNS: so in absence of any further config info we'll look
up names on all interfaces and use the first positive or the last
negative answer. This behaviour doesn't bother too much with the
security issue, i.e. everyting outside the local laptop is consider
equally trusted or untrusted. But it maximizes the chance that things
just work. And that's a inherently a *good* thing, the thing i care
about the most.
Now, of coruse it would be better to only send to the VPN what really
needs to be sent to the VPN, and conversely send to the local
DHCP-supplied DNS only what shall be sent there. For that we need
routing info. We'll synthesize some from search domains, if they are
configured, but beyond that we require you to configure them manually.
Summary: we support routing if queries, you can configure that
explicitly now, and if you don't you at least have the biggest chance
that things "just work".
Lennart
--
Lennart Poettering, Berlin
6:06 a.m.
New subject: This is bad, was Re: Fedora 33 System-Wide Change proposal:
systemd-resolved
Hi Paul,
is there any generic protocol exchanging what (sub)domains should be
targetted to specific DNS server? I know dnssec-trigger/unbound is able
to send queries only to specified search domains received by DHCP server.
Are you aware of any implementation independent way to store domains for
each interface?
I think there should be just single way for connection provider to
specify, which domains should go to its DNS server. Then any split-DNS
capable software (unbound, dnsmasq, systemd-resolved) should just
implement its layer to execute such redirection in runtime. Without
special hooks in connection provider to running DNS stub.
I doubt there is already generic interface, but it seems it SHOULD be
created. Because connection should not be pushing anything to resolved.
It should push it to (whatever) network manager and resolved should pull
it from there.
Can you point me to your support for unbound?
Regards,
Petr
On 9/28/20 4:28 PM, Paul Wouters wrote:
On Mon, 28 Sep 2020, Zbigniew Jędrzejewski-Szmek wrote:
>> This change is harmful to network security, impacts existing
>> installations
>> depending on DNSSEC security, and leaks private queries for VPN/internal
>> domains to the open internet, and prefers faster non-dnssec answers
>> over dnssec validated answers. It fails various types of queries,
>> misimplements part of the DNS protocol. Not only according to me, but
>> to 20years+ developers of the bind software as well.
>
> You're mixing a few different things here. We decided to not enable
> DNSSEC in resolved with this change, at least initially. For most
> users, DNSSEC is problematic because various intermediary DNS servers
> found in hotspots and routers don't support DNSSEC properly, leading
> to hard-to-debug validation failures. DNSSEC support in resolved can
> be enabled through resolved.conf. This may be a reasonable thing to do in
> an environment where the configured dns servers are known to support
> dnssec
> properly.
If you want to do innovate new things with hotspot detection, the place
to do the protocol work is at the IETF Captive Portal Working Group:
https://datatracker.ietf.org/wg/capport/charter/
Work done there include an architecture docoument:
https://datatracker.ietf.org/doc/draft-ietf-capport-architecture/
Captive Portal API: https://tools.ietf.org/html/rfc8908
DHCP and RA options: https://tools.ietf.org/html/rfc8910
These are efforts with big vendor signon. These will be compatible with
new hotspots and work similar to other network devices. This is
preferred over homegrown solutions.
>> leaks private queries for VPN/internal domains to the open internet
>
> It's a complicated subject, but that statement is not true in general.
It was true when we had a DNSSEC systemd meeting in Brno about five years
ago when I raised it as a privacy issue and was told my use case was
"not valid". And it still seems to be true.
With Tommy Pauly of Apple, I co-write Split DNS for IKEv2 VPNs, that saw
a major discusison in the security area of IETF (specifically SAAG and
TLS) to ensure every one (including browser vendors) were okay with
the resulting DNS reconfiguration requirements of VPN servers. This
is