Re: systemd-resolved fallback DNS servers: usability vs. GDPR
On ti, 02 maalis 2021, Zbigniew Jędrzejewski-Szmek wrote:
On Tue, Mar 02, 2021 at 11:29:21AM +0200, Alexander Bokovoy wrote:
On ma, 01 maalis 2021, Lennart Poettering wrote:
>On Fr, 26.02.21 21:01, Alexander Bokovoy (aboko...@redhat.com) wrote:
>
>>> 1. Dots (".") for separating IPV4 address bytes
>>> 2. Colons (":") for separating IPv6 address parts, as well as separating
>>> port numbers from the IP addres
>>> 3. Brackets ("[]") for separating ipv6 addresses from the rest of the
>>> construct
>>> 4. Percent ("%") characters to separate interface info from the rest
>>> 5. Hash ("#") characters to separate SNI host name specifications
>>>
>>> Now, we currently don't use "," and ";" for separators here, but as
>>> these things keep growing we might need them for something soon too.
>>
>>I understand your willingness to apply the same rules for multiple
>>options in the config files owned by systemd codebase. This, however, is
>>a content pushed out by external parties, not a part of systemd
>>proper.
>
>It's a configuration file *owned* by resolved. it's its private
>property, with defined and documented syntax. if other tools make
>changes to that config files, but they better follow the documented
>syntax then.
>
>I'd be a lot more open to a more relaxed parser if this was some
>"foreign" config file, not owned by resolved. i.e. /etc/resolv.conf is
>owned by glibc and is maybe even more generic than that. There it's
>our duty to to accept even the worst formatted files.
>
>But resolved.conf is inherently only ours, we define the contents and
>are the sole consumer of it. Hence I think we don't have to be and
>shouldn't be so lenient, so that the variances remain smaller.
>
>I mean, I#d consider the original issue here a simple bug. The
>question is simply where to fix it: in cloud-init or in systemd. Given
>that cloud-init is responsible for it, and given that either way
>there's exactly one project to fix I think it should be cloud-init
>that is fixed.
Clearly, what happened in the cases described in this thread, is that
some other configuration file was imported into resolved state and
parsing the content that came from that import was failing.
This is what I think an issue on systemd-resolved side. See below for
cloud-init part.
>
>>Digital Ocean updates pushed with cloud-init use. Cloud-init does not
>>have any native support for systemd-resolved. It means it writes
>>something that systemd-resolved imports into own state. I would argue
>>that your arguments for systemd-wide configuration rules do not apply
>>here. Either you'd need to fix cloud-init or allow for a variance in
>>input data that comes to systemd-resolved from third parties.
>
>Hmm, cloud-init has no direct support for resolved.conf? But how is it
>then that that file is modified? I don't get it?
https://github.com/canonical/cloud-init/search?q=resolved.conf --
nothing handles resolved.conf.
It is done by something else after parsing cloud-init provided content.
For example, on my Digital Ocean's node which is not affected by this
bug I have /etc/sysconfig/network-scripts/ifcfg-eth0 which was written by
cloud-init.
The network scripts update is done by
cloudinit/net/sysconfig.py:Renderer._render_subnets() method.
Additionally, render_network_state() writes down NetworkManager
configuration snippet.
Does systemd-resolved parse any of those?
No.
It seems DigitalOcean added *custom code* [1] to write
/etc/systemd/resolved.conf,
and in *that new code* they messed up the syntax. Considering that it's
new code, it seems most reasonable to just fix that.
Yes, I agree with that. How can we ensure they'd fix it? :)
[1]
https://www.digitalocean.com/community/questions/fedora-33-how-to-persist-dns-settings-via-etc-resolv-conf?comment=96290
Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
On Tue, Mar 02, 2021 at 11:29:21AM +0200, Alexander Bokovoy wrote:
> On ma, 01 maalis 2021, Lennart Poettering wrote:
> >On Fr, 26.02.21 21:01, Alexander Bokovoy (aboko...@redhat.com) wrote:
> >
> >>> 1. Dots (".") for separating IPV4 address bytes
> >>> 2. Colons (":") for separating IPv6 address parts, as well as separating
> >>> port numbers from the IP addres
> >>> 3. Brackets ("[]") for separating ipv6 addresses from the rest of the
> >>> construct
> >>> 4. Percent ("%") characters to separate interface info from the rest
> >>> 5. Hash ("#") characters to separate SNI host name specifications
> >>>
> >>> Now, we currently don't use "," and ";" for separators here, but as
> >>> these things keep growing we might need them for something soon too.
> >>
> >>I understand your willingness to apply the same rules for multiple
> >>options in the config files owned by systemd codebase. This, however, is
> >>a content pushed out by external parties, not a part of systemd
> >>proper.
> >
> >It's a configuration file *owned* by resolved. it's its private
> >property, with defined and documented syntax. if other tools make
> >changes to that config files, but they better follow the documented
> >syntax then.
> >
> >I'd be a lot more open to a more relaxed parser if this was some
> >"foreign" config file, not owned by resolved. i.e. /etc/resolv.conf is
> >owned by glibc and is maybe even more generic than that. There it's
> >our duty to to accept even the worst formatted files.
> >
> >But resolved.conf is inherently only ours, we define the contents and
> >are the sole consumer of it. Hence I think we don't have to be and
> >shouldn't be so lenient, so that the variances remain smaller.
> >
> >I mean, I#d consider the original issue here a simple bug. The
> >question is simply where to fix it: in cloud-init or in systemd. Given
> >that cloud-init is responsible for it, and given that either way
> >there's exactly one project to fix I think it should be cloud-init
> >that is fixed.
>
> Clearly, what happened in the cases described in this thread, is that
> some other configuration file was imported into resolved state and
> parsing the content that came from that import was failing.
>
> This is what I think an issue on systemd-resolved side. See below for
> cloud-init part.
>
> >
> >>Digital Ocean updates pushed with cloud-init use. Cloud-init does not
> >>have any native support for systemd-resolved. It means it writes
> >>something that systemd-resolved imports into own state. I would argue
> >>that your arguments for systemd-wide configuration rules do not apply
> >>here. Either you'd need to fix cloud-init or allow for a variance in
> >>input data that comes to systemd-resolved from third parties.
> >
> >Hmm, cloud-init has no direct support for resolved.conf? But how is it
> >then that that file is modified? I don't get it?
>
> https://github.com/canonical/cloud-init/search?q=resolved.conf --
> nothing handles resolved.conf.
>
> It is done by something else after parsing cloud-init provided content.
> For example, on my Digital Ocean's node which is not affected by this
> bug I have /etc/sysconfig/network-scripts/ifcfg-eth0 which was written by
> cloud-init.
>
> The network scripts update is done by
> cloudinit/net/sysconfig.py:Renderer._render_subnets() method.
> Additionally, render_network_state() writes down NetworkManager
> configuration snippet.
>
> Does systemd-resolved parse any of those?
No.
It seems DigitalOcean added *custom code* [1] to write
/etc/systemd/resolved.conf,
and in *that new code* they messed up the syntax. Considering that it's
new code, it seems most reasonable to just fix that.
[1]
https://www.digitalocean.com/community/questions/fedora-33-how-to-persist-dns-settings-via-etc-resolv-conf?comment=96290
Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
On 02/03/2021 17:30, Alexander Bokovoy wrote: On ti, 02 maalis 2021, Ed Greshko wrote: On 02/03/2021 06:03, Lennart Poettering wrote: On Fr, 26.02.21 21:01, Alexander Bokovoy (aboko...@redhat.com) wrote: Digital Ocean updates pushed with cloud-init use. Cloud-init does not have any native support for systemd-resolved. It means it writes something that systemd-resolved imports into own state. I would argue that your arguments for systemd-wide configuration rules do not apply here. Either you'd need to fix cloud-init or allow for a variance in input data that comes to systemd-resolved from third parties. Hmm, cloud-init has no direct support for resolved.conf? But how is it then that that file is modified? I don't get it? Pardon my "editorial" comment here. I'm rather down on Digital Ocean. Servers in their network have been responsible for the majority of sustained brute force ssh attacks on my systems. I find myself filing multiple abuse reports with them weekly. This can be said about pretty much every public cloud provider with 'cheap' systems that easy to deploy and remove. I see 'ssh' attacks everywhere to any just created machine. While I do see attacks from "everywhere" the attacks are generally short lived. With Digital Ocean I get attacks that last for hours. I would think these kind of providers could detect outgoing attacks. Oh, well. -- People who believe they don't make mistakes have already made one. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
On ti, 02 maalis 2021, Ed Greshko wrote: On 02/03/2021 06:03, Lennart Poettering wrote: On Fr, 26.02.21 21:01, Alexander Bokovoy (aboko...@redhat.com) wrote: Digital Ocean updates pushed with cloud-init use. Cloud-init does not have any native support for systemd-resolved. It means it writes something that systemd-resolved imports into own state. I would argue that your arguments for systemd-wide configuration rules do not apply here. Either you'd need to fix cloud-init or allow for a variance in input data that comes to systemd-resolved from third parties. Hmm, cloud-init has no direct support for resolved.conf? But how is it then that that file is modified? I don't get it? Pardon my "editorial" comment here. I'm rather down on Digital Ocean. Servers in their network have been responsible for the majority of sustained brute force ssh attacks on my systems. I find myself filing multiple abuse reports with them weekly. This can be said about pretty much every public cloud provider with 'cheap' systems that easy to deploy and remove. I see 'ssh' attacks everywhere to any just created machine. -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
On ma, 01 maalis 2021, Lennart Poettering wrote:
On Fr, 26.02.21 21:01, Alexander Bokovoy (aboko...@redhat.com) wrote:
> 1. Dots (".") for separating IPV4 address bytes
> 2. Colons (":") for separating IPv6 address parts, as well as separating
> port numbers from the IP addres
> 3. Brackets ("[]") for separating ipv6 addresses from the rest of the
> construct
> 4. Percent ("%") characters to separate interface info from the rest
> 5. Hash ("#") characters to separate SNI host name specifications
>
> Now, we currently don't use "," and ";" for separators here, but as
> these things keep growing we might need them for something soon too.
I understand your willingness to apply the same rules for multiple
options in the config files owned by systemd codebase. This, however, is
a content pushed out by external parties, not a part of systemd
proper.
It's a configuration file *owned* by resolved. it's its private
property, with defined and documented syntax. if other tools make
changes to that config files, but they better follow the documented
syntax then.
I'd be a lot more open to a more relaxed parser if this was some
"foreign" config file, not owned by resolved. i.e. /etc/resolv.conf is
owned by glibc and is maybe even more generic than that. There it's
our duty to to accept even the worst formatted files.
But resolved.conf is inherently only ours, we define the contents and
are the sole consumer of it. Hence I think we don't have to be and
shouldn't be so lenient, so that the variances remain smaller.
I mean, I#d consider the original issue here a simple bug. The
question is simply where to fix it: in cloud-init or in systemd. Given
that cloud-init is responsible for it, and given that either way
there's exactly one project to fix I think it should be cloud-init
that is fixed.
Clearly, what happened in the cases described in this thread, is that
some other configuration file was imported into resolved state and
parsing the content that came from that import was failing.
This is what I think an issue on systemd-resolved side. See below for
cloud-init part.
Digital Ocean updates pushed with cloud-init use. Cloud-init does not
have any native support for systemd-resolved. It means it writes
something that systemd-resolved imports into own state. I would argue
that your arguments for systemd-wide configuration rules do not apply
here. Either you'd need to fix cloud-init or allow for a variance in
input data that comes to systemd-resolved from third parties.
Hmm, cloud-init has no direct support for resolved.conf? But how is it
then that that file is modified? I don't get it?
https://github.com/canonical/cloud-init/search?q=resolved.conf --
nothing handles resolved.conf.
It is done by something else after parsing cloud-init provided content.
For example, on my Digital Ocean's node which is not affected by this
bug I have /etc/sysconfig/network-scripts/ifcfg-eth0 which was written by
cloud-init.
The network scripts update is done by
cloudinit/net/sysconfig.py:Renderer._render_subnets() method.
Additionally, render_network_state() writes down NetworkManager
configuration snippet.
Does systemd-resolved parse any of those?
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
On Mon, Mar 1, 2021 at 11:03 pm, Lennart Poettering wrote: Hmm, cloud-init has no direct support for resolved.conf? But how is it then that that file is modified? I don't get it? I think they've deployed something entirely custom. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
On 02/03/2021 06:03, Lennart Poettering wrote: On Fr, 26.02.21 21:01, Alexander Bokovoy (aboko...@redhat.com) wrote: Digital Ocean updates pushed with cloud-init use. Cloud-init does not have any native support for systemd-resolved. It means it writes something that systemd-resolved imports into own state. I would argue that your arguments for systemd-wide configuration rules do not apply here. Either you'd need to fix cloud-init or allow for a variance in input data that comes to systemd-resolved from third parties. Hmm, cloud-init has no direct support for resolved.conf? But how is it then that that file is modified? I don't get it? Pardon my "editorial" comment here. I'm rather down on Digital Ocean. Servers in their network have been responsible for the majority of sustained brute force ssh attacks on my systems. I find myself filing multiple abuse reports with them weekly. -- People who believe they don't make mistakes have already made one. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
On Fr, 26.02.21 21:01, Alexander Bokovoy (aboko...@redhat.com) wrote:
> > 1. Dots (".") for separating IPV4 address bytes
> > 2. Colons (":") for separating IPv6 address parts, as well as separating
> > port numbers from the IP addres
> > 3. Brackets ("[]") for separating ipv6 addresses from the rest of the
> > construct
> > 4. Percent ("%") characters to separate interface info from the rest
> > 5. Hash ("#") characters to separate SNI host name specifications
> >
> > Now, we currently don't use "," and ";" for separators here, but as
> > these things keep growing we might need them for something soon too.
>
> I understand your willingness to apply the same rules for multiple
> options in the config files owned by systemd codebase. This, however, is
> a content pushed out by external parties, not a part of systemd
> proper.
It's a configuration file *owned* by resolved. it's its private
property, with defined and documented syntax. if other tools make
changes to that config files, but they better follow the documented
syntax then.
I'd be a lot more open to a more relaxed parser if this was some
"foreign" config file, not owned by resolved. i.e. /etc/resolv.conf is
owned by glibc and is maybe even more generic than that. There it's
our duty to to accept even the worst formatted files.
But resolved.conf is inherently only ours, we define the contents and
are the sole consumer of it. Hence I think we don't have to be and
shouldn't be so lenient, so that the variances remain smaller.
I mean, I#d consider the original issue here a simple bug. The
question is simply where to fix it: in cloud-init or in systemd. Given
that cloud-init is responsible for it, and given that either way
there's exactly one project to fix I think it should be cloud-init
that is fixed.
> Digital Ocean updates pushed with cloud-init use. Cloud-init does not
> have any native support for systemd-resolved. It means it writes
> something that systemd-resolved imports into own state. I would argue
> that your arguments for systemd-wide configuration rules do not apply
> here. Either you'd need to fix cloud-init or allow for a variance in
> input data that comes to systemd-resolved from third parties.
Hmm, cloud-init has no direct support for resolved.conf? But how is it
then that that file is modified? I don't get it?
Lennart
--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
On 2/26/21 12:10 PM, Marius Schwarz wrote: > Am 25.02.21 um 10:51 schrieb Florian Weimer: >> >> Why do you think that? >> >> Caching DNS server availability is a commonly requested feature even in >> data center deployments. The way Fedora currently implements its DNS >> client, it more or less defeats the built-in high availability mechanism >> of DNS, and complex network-based mitigations are needed (like using >> anycast DNS resolvers). > > If you run a server farm with mailservers, you usually have antispam > services like spamhaus enabled. > > If one server from an ip adressrange is using spamhaus, spamhaus is fine > with it. > If a hundret ips from that ip addressrange ask spamhaus, you get blocked > quite fast. Nobody here requested independent iteration from root servers, right? If a machine is caching itself, it would reduce the load to upstream resolver. If local cache forwards cache misses to central DNS cache configured by network administrators, no blocking should ever happen. systemd-resolved or dnsmasq are incapable of independent resolving, they always need upstream iterative resolver doing work for them. Unbound is capable of doing that, but that was not proposed by nobody. Forwarders usage is always expected by default. It might depend on how to choose them only. Local cache is especially useful on DNS intensive service, which SMTP with various spam filters tends to be. Spamhaus wants prevention of unconfigured unbound or bind caches, which would without additional configuration iterate from root servers. Just add forwarders to shared network cache. > > The cache on the server itself, is of limit use here. Thats why you use > a central dns cache on one server, > so anyone benefits from the caching and spamhaus is happy : win-win. > > On a desktop / laptop you won't have such a scenario in the first place, > here local caching makes more sense. Multi layer caching is supported by DNS. Having local cache on the host does not prevent caching also by a big DNS cache for whole network. On the contrary. It is a bit suppressed by DNS over TLS/HTTPS, but default configuration still should obtain DNS from DHCP/autoconfiguration. On servers, clients, VMs and containers. > > best regards, > Marius Schwarz-- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
On pe, 26 helmi 2021, Lennart Poettering wrote:
On Mi, 24.02.21 22:08, Alexander Bokovoy (aboko...@redhat.com) wrote:
I think one of the issues reported in the discussion you mention was
that systemd-resolved considered invalid a DNS= line where addresses
were separated by a comma rather than space. Can systemd-resolved be
improved to allow common separators like both space and comma?
I am not a fan of such needless ambiguity, and it's not going to
retroactively fix the original reporter's configuration that has now
been fixed anyway... Moreover, across the systemd codebase in
configuration files we so far stuck to using mostly whitespace for
separating multiple values on the same config option line.
The thing is: separator characters end up being used for various other
purposes sooner or later. For example the DNS= lines in resolved.conf
already uses:
1. Dots (".") for separating IPV4 address bytes
2. Colons (":") for separating IPv6 address parts, as well as separating
port numbers from the IP addres
3. Brackets ("[]") for separating ipv6 addresses from the rest of the
construct
4. Percent ("%") characters to separate interface info from the rest
5. Hash ("#") characters to separate SNI host name specifications
Now, we currently don't use "," and ";" for separators here, but as
these things keep growing we might need them for something soon too.
I understand your willingness to apply the same rules for multiple
options in the config files owned by systemd codebase. This, however, is
a content pushed out by external parties, not a part of systemd proper.
As pointed out by Michael in this discussion, Digital Ocean uses ',' to
separate DNS servers pushed out by cloud-init. I don't think they are
alone in this.
Digital Ocean updates pushed with cloud-init use. Cloud-init does not
have any native support for systemd-resolved. It means it writes
something that systemd-resolved imports into own state. I would argue
that your arguments for systemd-wide configuration rules do not apply
here. Either you'd need to fix cloud-init or allow for a variance in
input data that comes to systemd-resolved from third parties.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
On Fri, Feb 26, 2021 at 9:06 am, Lennart Poettering wrote: Note that as I understood it the original reporter's issue wasn't even caused by concious editing of the configuration file, but was done automatically by some other tool/copy pasted from elsewhere? i.e. it's a bit much to expect people to understand enough DNS to fix up stuff manually that other tools broke for them. And the original reporter is a seasoned a Linux guy, even. Turns out DigitalOcean's agent is adding 67.207.67.2,67.207.67.3 with the comma when the system boots: https://www.digitalocean.com/community/questions/fedora-33-how-to-persist-dns-settings-via-etc-resolv-conf?comment=96290 Alas. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
Am 25.02.21 um 10:51 schrieb Florian Weimer: Why do you think that? Caching DNS server availability is a commonly requested feature even in data center deployments. The way Fedora currently implements its DNS client, it more or less defeats the built-in high availability mechanism of DNS, and complex network-based mitigations are needed (like using anycast DNS resolvers). If you run a server farm with mailservers, you usually have antispam services like spamhaus enabled. If one server from an ip adressrange is using spamhaus, spamhaus is fine with it. If a hundret ips from that ip addressrange ask spamhaus, you get blocked quite fast. The cache on the server itself, is of limit use here. Thats why you use a central dns cache on one server, so anyone benefits from the caching and spamhaus is happy : win-win. On a desktop / laptop you won't have such a scenario in the first place, here local caching makes more sense. best regards, Marius Schwarz ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
On 2/26/21 9:06 AM, Lennart Poettering wrote: > On Do, 25.02.21 23:58, Petr Menšík (pemen...@redhat.com) wrote: > >> No, I don't think so. Anyone who manages the system should have basic >> understanding how to configure it. If not obvious, needs good >> documentation at hand. Extremely high level is not writing lines into >> configuration file in documented format. I think we switched to nano >> editor to make it friendly. Sure, he won't be able to google help from >> the machine. Fortunately, most of us have got smartphone able to google >> almost anything. > > I am sorry, but I think we have to agree that we are designing > software for a different group of people. I certainly don't want to > assume a level of Linux expertise from our audience that they all can > reconfigure DNS. I think it's a general problem of developers like us > to assume that everyone has the same level of understanding of our > favourite technology as us. i.e. don't assume that because you know > DNS quite well, everyone else does too, or even just heard of DNS at all... I am not sure about it. It is not really different. People missing expertise have to fill bugs or report issues to people with appropriate level of expertise. I would not ask my mum to fix this and she would not even attempt to. She would just complain to me it does not work as it should. Because it does not hide failures, the person with expertise can check the problem and fix it properly. Sure, it will cause interruption. But makes the service more reliable for everyone. Usually auto-configuration is for people without the expertise, I hope we agree in that. > Note that as I understood it the original reporter's issue wasn't even > caused by concious editing of the configuration file, but was done > automatically by some other tool/copy pasted from elsewhere? i.e. it's > a bit much to expect people to understand enough DNS to fix up stuff > manually that other tools broke for them. And the original reporter > is a seasoned a Linux guy, even. The tool was broken by not enough tested change in F33. It should have been found during testing period. Even seasoned Linux guy haven't noticed it was broken until hidden fallback were removed. So again. Broken configuration must appear broken to be fixed. The fix should be prepared by someone with expertise, but they have to receive a bug report first. > > And the idea that "nano" was a flagship of user friendliness sounds, > …umm… a bit strange to me. I mean, maybe it's not as arcane as > vi, but come on it's admittedly just one step down from there. > >> But you forgot some decision were made for the user without his >> knowledge or his approval. That is wrong. > > We make decisions for our users all the time. *All* *the* > *time*. Fedora is a product of developer decisions. > > Lennart > I would just point you to related DNS flag day 2019 [1]. Those guys were pilling workaround over workarounds in DNS server software. After 20 years they have realized it costs a lot of unnecessary work. So, it might may sense to provide workaround, but it should always include plan, when it would be removed again. Sometimes the other party has to be pushed to follow the rules instead of bending our own. Cheers, Petr 1. https://dnsflagday.net/2019/ -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
On Mi, 24.02.21 15:08, Michael Catanzaro (mcatanz...@gnome.org) wrote: > FWIW I agree that systemd-resolved is *much* less important for servers and > containers than it is on desktops. > > That said, the benefit of having a DNS cache is very real, as is the benefit > of a unified, standardized API for controlling your DNS configuration that's > the same regardless of which type of system you are running. I agree with both these statements btw. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
On Do, 25.02.21 23:58, Petr Menšík (pemen...@redhat.com) wrote: > No, I don't think so. Anyone who manages the system should have basic > understanding how to configure it. If not obvious, needs good > documentation at hand. Extremely high level is not writing lines into > configuration file in documented format. I think we switched to nano > editor to make it friendly. Sure, he won't be able to google help from > the machine. Fortunately, most of us have got smartphone able to google > almost anything. I am sorry, but I think we have to agree that we are designing software for a different group of people. I certainly don't want to assume a level of Linux expertise from our audience that they all can reconfigure DNS. I think it's a general problem of developers like us to assume that everyone has the same level of understanding of our favourite technology as us. i.e. don't assume that because you know DNS quite well, everyone else does too, or even just heard of DNS at all... Note that as I understood it the original reporter's issue wasn't even caused by concious editing of the configuration file, but was done automatically by some other tool/copy pasted from elsewhere? i.e. it's a bit much to expect people to understand enough DNS to fix up stuff manually that other tools broke for them. And the original reporter is a seasoned a Linux guy, even. And the idea that "nano" was a flagship of user friendliness sounds, …umm… a bit strange to me. I mean, maybe it's not as arcane as vi, but come on it's admittedly just one step down from there. > > Hence, it's inherently a *good* thing to have a fallback in place, and > > I think it's a disserve to users to turn this off, as it makes systems > > much harder to fix. > > > > And yeah, call me a hypocrite, but if I have the choice between having > > no Internet at all or using some public DNS servers for DNS, and > > leaking a tiny bit of information to those DNS server providers then I > > am definitely preferring to have Internet, thank you very much. > > But you forgot some decision were made for the user without his > knowledge or his approval. That is wrong. We make decisions for our users all the time. *All* *the* *time*. Fedora is a product of developer decisions. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
On Mi, 24.02.21 22:08, Alexander Bokovoy (aboko...@redhat.com) wrote:
> I think one of the issues reported in the discussion you mention was
> that systemd-resolved considered invalid a DNS= line where addresses
> were separated by a comma rather than space. Can systemd-resolved be
> improved to allow common separators like both space and comma?
I am not a fan of such needless ambiguity, and it's not going to
retroactively fix the original reporter's configuration that has now
been fixed anyway... Moreover, across the systemd codebase in
configuration files we so far stuck to using mostly whitespace for
separating multiple values on the same config option line.
The thing is: separator characters end up being used for various other
purposes sooner or later. For example the DNS= lines in resolved.conf
already uses:
1. Dots (".") for separating IPV4 address bytes
2. Colons (":") for separating IPv6 address parts, as well as separating
port numbers from the IP addres
3. Brackets ("[]") for separating ipv6 addresses from the rest of the
construct
4. Percent ("%") characters to separate interface info from the rest
5. Hash ("#") characters to separate SNI host name specifications
Now, we currently don't use "," and ";" for separators here, but as
these things keep growing we might need them for something soon too.
Lennart
--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
I disagree and do more below :) On 2/23/21 2:49 PM, Lennart Poettering wrote: > On Mo, 22.02.21 09:45, Michael Catanzaro (mcatanz...@gnome.org) wrote: > 65;6201;1c >> On Mon, Feb 22, 2021 at 12:05 pm, Tomasz Torcz wrote: >>> 3) Configure DNS resolvers if you want to use DNS. >>> Or dig deeper: why cloud-init disabled DNS on your installation? >> >> I'm pretty sure cloud-init just doesn't know how to configure >> systemd-resolved at all. So I suspect this is a cloud-init bug. See: >> https://pagure.io/fedora-server/issue/10. >> >> I have no strong opinion on whether the fallback should have been removed or >> not. The fallback was only hiding the real problem, after all. > > BTW, just to say this clearly. I think this argument is bogus and very > user unfriendly. I think it's generally better to complain to the logs > and still make things work automatically with a fallback than to just > say "Nope, I was given invalid configuration and now I refuse to > work". Because originally this is what resolved did: we had a > last-resort fallback to provide DNS via a bunch of public DNS servers > if nothing else is available, and we log if we are given invalid > config. We use the fallback only as ultimate fallback, when the other > option is to not work at all. No, this was already discussed and consensus were reached. last-resort fallbacks MUST NOT cover bugs and they did it here. Good fallback would be extracting addresses from configuration, even when delimited by a garbage. User provided configuration must be followed. If wrong, it must say so in way user will notice. All daemons I manage do that nice and friendly way: print line number and file, where the mistake is. And print in red: FAILED to run. It is up to user to fix it, comment it out or disable non-obeying service. But has to be his decision. > > The thing is that if DNS is fucked, then this is a pretty nasty > problem: you need an extremely high level of understanding computers > to be able to fix this. And you can't even get help, because, well, > your DNS is down, you are not getting online. No, I don't think so. Anyone who manages the system should have basic understanding how to configure it. If not obvious, needs good documentation at hand. Extremely high level is not writing lines into configuration file in documented format. I think we switched to nano editor to make it friendly. Sure, he won't be able to google help from the machine. Fortunately, most of us have got smartphone able to google almost anything. > > Hence, it's inherently a *good* thing to have a fallback in place, and > I think it's a disserve to users to turn this off, as it makes systems > much harder to fix. > > And yeah, call me a hypocrite, but if I have the choice between having > no Internet at all or using some public DNS servers for DNS, and > leaking a tiny bit of information to those DNS server providers then I > am definitely preferring to have Internet, thank you very much. But you forgot some decision were made for the user without his knowledge or his approval. That is wrong. If user needs easy way to working internet, offer him simple solution. Like: systemctl start systemd-resolved-fallback or resolvectl use-fallback Print this command in red on last line in sytemctl status systemd-resolved. If he cannot find where the error is, he should ask someone to manage his machine. To protect himself. Or have to dig into system a bit and learn, where it is wrong. > > One could even go further: the privacy level using those public DNS > servers might actually be higher than using the DHCP-provided ones in > many cases, simple because we can use DoT on the former (admittedly > not yet the default in resolved though, but hopefully soon), but > almost never can on the latter, and what's worse the latter are > usually provided by crappy edge networks like Internet Cafés and such > where the fact we send stuff unencrypted is just awful. Problem is you usually have some agreement with the network you are connecting to. You usually know who provides it, you can ask under which rules they do. Not for hidden service somewhere as fallback. DoT is often just fake sense of privacy. Most TLS sessions still send unencrypted host in SNI headers, making DNS encryption not effective in hiding their real target. Target IPs can often tell a lot too. If you need real privacy, use VPN. Or better, choose a connection provider you trust. > > Now, Fedora made its choice here, and I'll accept that, but I still > think it's a bad one, that trades a misunderstood concept of privacy > against a major step forward in userfriendliness. i.e. I am not sure > it's a good choice to limit Fedora's userspace needlessly to people > who can fix their DNS configuration. It's a pretty tiny elite group of > people to be in after all... Hiding configuration errors just into logs is unfriendly. Ever since Windows 95, very basic network configuration required two steps. Configuring IP address, netmask
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
Michael Catanzaro wrote: > Servers don't need split DNS. Desktops do. Without a DNS cache, your > DNS will be slower. Without split DNS, your DNS may not work properly > at all. Not all desktops need split DNS. Most desktop users don't even have anything to split the DNS over. (It needs either at least 2 active physical connections (multihoming, very uncommon on desktops) or at least 1 VPN (more common, but only for tech-savvy users).) Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
No, this is not true. DNS servers had for ages ability to forward selected domains to specified list of addresses. All DNS caches have the ability to do it for no reason. Servers do not have automatic configuration of split DNS only, because often do not have multiple connections. But I think VPNs could be also used to interconnect networks and selected DNS forwarding might still be benefical for it. However, servers need a proper DNS service. Very often they depend on DNSSEC for mail filtering. They should protect their precious caches with signatures. DNSSEC disabled by default, even when upstream service provides perfectly working DNS, is just failure on our side. Especially on servers, when DNSSEC readines would be much more common than on crappy cheap home routers. Remote DNS does not have to be much slower. If you have dedicated resolver on the same LAN as you, your own cache might not help you much. Depends a lot on specific applications usage. On 2/25/21 4:42 PM, Michael Catanzaro wrote: > On Thu, Feb 25, 2021 at 10:51 am, Florian Weimer > wrote: >> Why do you think that? > > Servers don't need split DNS. Desktops do. Without a DNS cache, your DNS > will be slower. Without split DNS, your DNS may not work properly at all. -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
On Thu, Feb 25, 2021 at 10:51 am, Florian Weimer wrote: Why do you think that? Servers don't need split DNS. Desktops do. Without a DNS cache, your DNS will be slower. Without split DNS, your DNS may not work properly at all. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
* Michael Catanzaro: > FWIW I agree that systemd-resolved is *much* less important for > servers and containers than it is on desktops. Why do you think that? Caching DNS server availability is a commonly requested feature even in data center deployments. The way Fedora currently implements its DNS client, it more or less defeats the built-in high availability mechanism of DNS, and complex network-based mitigations are needed (like using anycast DNS resolvers). Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
> Am 24.02.2021 um 20:19 schrieb Lennart Poettering : > > On Mi, 24.02.21 12:49, Paul Wouters (p...@nohats.ca) wrote: > > > I think the caching and DoT stuff that resolved provides is useful on > any system, and that includes servers, and I think it would be good to > minimize the difference in the APIs (and that includes D-Bus APIs) > when we can. So I'd recommend doing resolved on server images too. You have a good point about caching. And I like the emphasis on usability (in an earlier post. That may be one reason for the wide acceptance of systemd, despite all the criticism). But for Fedora Server, I definitely want an unmissable indication of a configuration error (and log entries are too easy to miss, especially when I don't see a problem). So instead of (more or less silent) fallback, a fail. For Fedora Workstation, I see resolved as a real step forward. But for Fedora Server it would need a tighter integration of / cooperation with libvirt virtualisation and also NetworkManager in the medium term. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
FWIW I agree that systemd-resolved is *much* less important for servers and containers than it is on desktops. That said, the benefit of having a DNS cache is very real, as is the benefit of a unified, standardized API for controlling your DNS configuration that's the same regardless of which type of system you are running. On Wed, Feb 24, 2021 at 3:18 pm, Paul Wouters wrote: I'm confused here too, since AFAIK NM does not support tying queries for certain domains to certain nameservers, No, it does. If it didn't, we would not have working split DNS, since NetworkManager must propagate its configuration down to systemd-resolved. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
On Wed, 24 Feb 2021, Colin Walters wrote: It's trickier than that because local caching nameservers can provide real benefits in various server scenarios, and also the IoT/edge case (as usual) blurs the traditional datacenter/mobile boundary. (IoT can be servers with WiFi) We ended up enabling resolved in FCOS, although it took a bit because it broke OpenShift, see: https://github.com/openshift/okd-machine-os/pull/15 https://github.com/openshift/machine-config-operator/pull/2377 https://github.com/openshift/okd-machine-os/pull/47 etc. It's hard to read through those. It's a big nest of issues, fixes and reverts on adding/removing systemd-resolved. I couldn't figure out the DNS setup based on these reports. (It's really complex for OpenShift because we have a split between the host DNS and pod DNS which is served by CoreDNS, yet some cases span those, plus some on-premise installs differ from cloud/Iaas in this) I'm confused here too, since AFAIK NM does not support tying queries for certain domains to certain nameservers, and I was told that NM configures DNS, not systemd-resolved, so how is that done in this case then? For VPN, to support split-DNS you ran a full resolver like unbound that has this support, and does not get configured through NM. I guess I can't say more unless someone can point me to some documentation on the DNS deployment details there. However, this all changes nothing that different systems want to use different DNS solutions, and making systemd-resolved part of the init package so it is mandatory to install is not appropriate. Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
On ke, 24 helmi 2021, Lennart Poettering wrote: On Mi, 24.02.21 12:49, Paul Wouters (p...@nohats.ca) wrote: The scenario of roaming laptops/phones is completely different from this. Which is why I have argued for a long time now that systemd-resolved should not be installed by default on servers or containers. It adds complexity without any real gain in these deployments and makes DNS issues harder to troubleshoot. There are two kinds of containers: docker-style containers that only have a single process (more or less) in them, or nspawn-style containers that have a full init system in them, that may run their own network management solution and maybe sshd or so, that basically behave like a VM (except they don't do any hw/storage management themselves, but leave that to the host). I think for nspawn-style containers the difference to the host should be kept at a minimum, and thus whatever a host running the same OS would run should also run inside the container. For docker-style containers the same obviously doesn't apply: if there's no init system inside the container it doesn't really make sense to run arbitrary services (and resolved is one) in them either. We run FreeIPA in a nspawn-style containers (podman rootless containers since Fedora 33) and we actually would benefit from the ability to disable systemd-resolved for the cases when IPA is deployed with integrated DNS server. Right now we are configuring systemd-resolved during IPA installation with integrated DNS to pass-through requests for IPA-hosted primary DNS zone to the local IPA DNS server but this is not enough as users can (and probably would) add multiple DNS zones. Setting a routing domain '~.' is probably a too much of an overhead here. I think the caching and DoT stuff that resolved provides is useful on any system, and that includes servers, and I think it would be good to minimize the difference in the APIs (and that includes D-Bus APIs) when we can. So I'd recommend doing resolved on server images too. This seems contradicting? The last resort method only sends all DNS queries to google as a last resort? It still means that in 100% of the cases that the last resort is activated, it sends all traffic to google? Furthermore, since it hides that this is happening, once the network is broken, it never gets fixed, and thus leads to the fallback always kicking in. We do log on invalid configuration (such as the invalid DNS= lines discussed earlier on this ML), as mentioned. And then proceed without it, so that the fallback paths might apply (unless we can acquire DNS info from elsewhere, e.g. DHCP). I think one of the issues reported in the discussion you mention was that systemd-resolved considered invalid a DNS= line where addresses were separated by a comma rather than space. Can systemd-resolved be improved to allow common separators like both space and comma? -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
On Mi, 24.02.21 12:49, Paul Wouters (p...@nohats.ca) wrote: > The scenario of roaming laptops/phones is completely different from > this. Which is why I have argued for a long time now that > systemd-resolved should not be installed by default on servers or > containers. It adds complexity without any real gain in these > deployments and makes DNS issues harder to troubleshoot. There are two kinds of containers: docker-style containers that only have a single process (more or less) in them, or nspawn-style containers that have a full init system in them, that may run their own network management solution and maybe sshd or so, that basically behave like a VM (except they don't do any hw/storage management themselves, but leave that to the host). I think for nspawn-style containers the difference to the host should be kept at a minimum, and thus whatever a host running the same OS would run should also run inside the container. For docker-style containers the same obviously doesn't apply: if there's no init system inside the container it doesn't really make sense to run arbitrary services (and resolved is one) in them either. I think the caching and DoT stuff that resolved provides is useful on any system, and that includes servers, and I think it would be good to minimize the difference in the APIs (and that includes D-Bus APIs) when we can. So I'd recommend doing resolved on server images too. > This seems contradicting? The last resort method only sends all DNS > queries to google as a last resort? It still means that in 100% of > the cases that the last resort is activated, it sends all traffic to > google? Furthermore, since it hides that this is happening, once > the network is broken, it never gets fixed, and thus leads to the > fallback always kicking in. We do log on invalid configuration (such as the invalid DNS= lines discussed earlier on this ML), as mentioned. And then proceed without it, so that the fallback paths might apply (unless we can acquire DNS info from elsewhere, e.g. DHCP). We currently do not log on non-existing configuration, i.e. if there's networking available but no DNS server configured anywhere, and no DHCP lease and nowhere else either. If figure we could print a short log message in this case however, that would be useful I guess. I posted an RFE bug about this now, to keep track of this. https://github.com/systemd/systemd/issues/18788 Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
On Wed, Feb 24, 2021, at 12:49 PM, Paul Wouters wrote: > Which is why I have argued for a long time now that > systemd-resolved should not be installed by default on servers or > containers. It adds complexity without any real gain in these > deployments and makes DNS issues harder to troubleshoot. It's trickier than that because local caching nameservers can provide real benefits in various server scenarios, and also the IoT/edge case (as usual) blurs the traditional datacenter/mobile boundary. (IoT can be servers with WiFi) We ended up enabling resolved in FCOS, although it took a bit because it broke OpenShift, see: https://github.com/openshift/okd-machine-os/pull/15 https://github.com/openshift/machine-config-operator/pull/2377 https://github.com/openshift/okd-machine-os/pull/47 etc. (It's really complex for OpenShift because we have a split between the host DNS and pod DNS which is served by CoreDNS, yet some cases span those, plus some on-premise installs differ from cloud/Iaas in this) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
On Tue, 23 Feb 2021, Lennart Poettering wrote: And yeah, call me a hypocrite, but if I have the choice between having no Internet at all or using some public DNS servers for DNS, and leaking a tiny bit of information to those DNS server providers then I am definitely preferring to have Internet, thank you very much. In practise, this is not often the case. Almost always, the network will provide working DNS via DHCP. If not, then the network is severely broken and hacking up a DNS workaround is likely to fail anyway. Like, you can't get past hotspot/captive portal. Newly installed and booted server/cloud images should _really_ use the DHCP obtained DNS servers. It is very likely their correct functioning depends on local DNS zones and local resources pointed to by DNS not available when bypassing the local DNS for public DNS services. It is also likely that those networks even restrict DNS to only allow their own DNS servers to be used for security and compliance reasons, and using public DNS would be a violation of network policy. The scenario of roaming laptops/phones is completely different from this. Which is why I have argued for a long time now that systemd-resolved should not be installed by default on servers or containers. It adds complexity without any real gain in these deployments and makes DNS issues harder to troubleshoot. One could even go further: the privacy level using those public DNS servers might actually be higher than using the DHCP-provided ones in many cases, simple because we can use DoT on the former (admittedly not yet the default in resolved though, but hopefully soon), but almost never can on the latter, and what's worse the latter are usually provided by crappy edge networks like Internet Cafés and such where the fact we send stuff unencrypted is just awful. I agree with this, but the caveat here is that the solution should take into account isolating the hotspot/signon network from the OS, and not mix that into your caches when you later bring up more private/trustworthy DNS servers. But as I said, I'm fine with the default of systemd-resolved here, although I would strongly prefer to be able to not install or remove the package for advanced users like me with specific DNS and DNSSEC requirements that cannot have systemd-resolved interfering with the system. Now, Fedora made its choice here, and I'll accept that, but I still think it's a bad one, that trades a misunderstood concept of privacy against a major step forward in userfriendliness. i.e. I am not sure it's a good choice to limit Fedora's userspace needlessly to people who can fix their DNS configuration. It's a pretty tiny elite group of people to be in after all... It seems to have a price of network administrators having their DNS broken in a string of different ways resulting in filed bugs at systemd upstream that takes years to get addressed. It can be argued that this price is too high for the feature of helping nontechnical laptop users that stumbled into a broken network. Meanwhile, applications like firefox are absorbing DNS anyway, adding another layer in the fight over who gets to configure and process DNS: DHCP, systemd-resolved, NetworkManager, Gnome, or applications. (Oh, and I don't appreciate those people at all, who claim that "resolved sends all DNS lookups" to Google because it's a lie, we never did that, we only did that in case no better DNS configuration was available, i.e. as *last* *resort*, one step before giving up entirely). This seems contradicting? The last resort method only sends all DNS queries to google as a last resort? It still means that in 100% of the cases that the last resort is activated, it sends all traffic to google? Furthermore, since it hides that this is happening, once the network is broken, it never gets fixed, and thus leads to the fallback always kicking in. If anything, these recurring discussions, and long turnover of systemd-resolverd bugs show that systemd-resolved should be a choice and not being pushed as mandatory. And I am fine with saying that for Workstation or Desktop installs, we lean to the side of userfriendly and give them systemd-resolved. But it has no place as a default binary or service on servers, containers or cloud images launched within actively managed networks. Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
On Wed, Feb 24, 2021, at 9:19 AM, Tadej Janež wrote:
>
> This is the thing that is probably hurting users the most. They have a
> working F33 cloud instance and after systemd is upgraded, the instance
> will *probably* (i.e. if users didn't configure DNS themselves and
> relied on cloud-init) be heavily broken, i.e. DNS resolution not
> working.
For Fedora CoreOS one of our principles is that the system is identical across
bare metal and cloud; we force bare metal system installs into extra
provisioning ("install" is "dd image to disk") in order to make sure that
Ignition and everything involved runs in a uniform fashion. There's no
cloud-init vs kickstart vs something else.
We use NetworkManager across the board for the same reason.
And, we also have unified CI that tests the entire OS image (ostree commit) as
a single unit before shipping out updates to everyone. And we also do "staged
rollouts" so that if we did encounter a problem like this, we can stop the
rollout so not everyone would get hit.
We also have automatic updates on by default - we couldn't do that without the
above.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
Tadej Janež wrote: > On Tue, 2021-02-23 at 00:02 +0100, Kevin Kofler via devel wrote: >> It is unfortunate that this behavior has changed in an update. > > This is the thing that is probably hurting users the most. They have a > working F33 cloud instance and after systemd is upgraded, the instance > will *probably* (i.e. if users didn't configure DNS themselves and > relied on cloud-init) be heavily broken, i.e. DNS resolution not > working. > > I actually think it would still be beneficial to flip this change, i.e. > remove the "-Ddns-servers=" line > (https://src.fedoraproject.org/rpms/systemd/blob/f33/f/systemd.spec#_372 > ), for the next F33 systemd update. Sorry, but at this point, the update has happened, and the new state is really the desired state, so I do not believe that going back and forth would be an improvement. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
On Tue, 2021-02-23 at 00:02 +0100, Kevin Kofler via devel wrote: > Well, this silent fallback behavior is one of the reasons I have > refused to > use systemd-resolved at all so far. > > The issue with the cloud setups would also have been caught much > earlier if > it had failed right away and not silently used an external DNServer. > Ignoring broken configuration and just using the default is not > useful error > handling. I guess having a fallback is a double-edged sword. On one hand, indeed, this issue with broken cloud-init would have been caught earlier, but on the other hand, some people couldn't care less which DNS servers are being used if things "just work". > > And the real issue is that systemd-resolved has broken cloud-init, so > cloud-init needs to be fixed/updated. Yes, this is the main issue for cloud setups. However, enabling/disabling a fallback is still an issue on its own. I wouldn't add much more since I think Lennart summed that up pretty well in his post. > It is unfortunate that this behavior has changed in an update. This is the thing that is probably hurting users the most. They have a working F33 cloud instance and after systemd is upgraded, the instance will *probably* (i.e. if users didn't configure DNS themselves and relied on cloud-init) be heavily broken, i.e. DNS resolution not working. I actually think it would still be beneficial to flip this change, i.e. remove the "-Ddns-servers=" line (https://src.fedoraproject.org/rpms/systemd/blob/f33/f/systemd.spec#_372 ), for the next F33 systemd update. > This has > happened because all the complaints about the old behavior back when > the > Change proposal was discussed (i.e., BEFORE Fedora 33 was released) > were > completely ignored by the Change owners and by FESCo (even though the > fix > was apparently a one-line change that could easily have been made > before the > release). I didn't follow that so I can't comment on it. signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
Am 23.02.21 um 20:34 schrieb Zbigniew Jędrzejewski-Szmek: Everything, that is not prepresenting a person, is not regulated by GDPR, therefor it does not "need" to comply. No. GDPR is about "personally identifying information". In particular, it talks about information which may be combined with other information (now or in the future) to identify a specific person. And an IP address falls into this category in the general case. The scenario we are considering here is e.g. a company which provides computers with Fedora installed to its employees or customers. Whatever resolver is used gets the source IP information which as described above can be identifying (depending on the network setup and other circumstances). By removing the fallback, we're removing a possible information expose and violation of the law by the company. I didn't say anything else ;) If a PC in a companies network, is accessing the companies dns cache, the dns cache uses it's own ip for the root dns request, hiding the personal IP from that root dns. This is fine. If the copmanies DNS cache is failing and the PC is falling back, using IPv6 to connect to a fallback server, that is an issue. I personally think, IPv4 doesn't matter here, as most companies do use NAT to connect the lan to the outside world. Individual traceback is no possible that way. Which leads to the conclusion, that a workstation should not have fallbackservers for dns, where Cloudinstances need to check that requirement themselves as it matters how and where they do dns. It relies heavily on the service and how many people use it. Best regards, Marius Schwarz ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
On Tue, Feb 23, 2021 at 01:18:08PM +0100, Marius Schwarz wrote: > Am 22.02.21 um 11:17 schrieb Zbigniew Jędrzejewski-Szmek: > >>1) Use different defaults for different Fedora editions, e.g. container > >>and cloud images include the fallback DNS servers list while > >>workstation (and similar) images don't. > >Yes, I think this would be the way to go. > Everything, that is not prepresenting a person, is not regulated by > GDPR, therefor it does not "need" to comply. No. GDPR is about "personally identifying information". In particular, it talks about information which may be combined with other information (now or in the future) to identify a specific person. And an IP address falls into this category in the general case. The scenario we are considering here is e.g. a company which provides computers with Fedora installed to its employees or customers. Whatever resolver is used gets the source IP information which as described above can be identifying (depending on the network setup and other circumstances). By removing the fallback, we're removing a possible information expose and violation of the law by the company. > About fallbacks in general: > > Es the example shows cleary to me, having fallback dns means, that > you do not see, that your dns config is faulty > and will fail in unexpected ways. The issue was logged at warning level. So "do not see" is relative — it certainly was possible to "see", though maybe not very visible. Zbyszek P.S. I like to do 'journalctl -b -p notice' after upgrades to look for such issues, but sadly there is so much noise in the logs that issues get lost. I would love to reach a state where any entry in the logs (at notice or above) that shouldn't be there is treated as a bug to fix. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
On Tue, 2021-02-23 at 08:19 -0600, Michael Catanzaro wrote: > On Tue, Feb 23, 2021 at 10:37 am, Tadej Janež wrote: > > I guess this is a simple solution that would work, but from what I > > understand it would also disable the use of systemd-resolved? > > Nah, it should just switch systemd-resolved into a consumer mode, > where > it reads configuration from /etc/resolv.conf and uses that as its > source of truth. Applications using glibc for name resolution (i.e. > almost everything) will still talk to systemd-resolved and ignore > /etc/resolv.conf. Oh, I see. Thanks for the explanation. > That's not the default configuration in Fedora, though. Writing to a > /etc/systemd/resolved.conf.d/*cloud-init.conf would be better though, > since it would avoid major changes to how systemd-resolved works. Agreed. signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
On Tue, Feb 23, 2021 at 9:20 AM Michael Catanzaro wrote: > > On Tue, Feb 23, 2021 at 11:18 am, Petr Menšík > wrote: > > Who uses cloud-init to prepare containers? Is it end user on his > > system? > > cloud-init is designed for VPS systems. I don't think it's expected to > be used in containers. I'm sympathetic to your view that running > systemd-resolved in containers is not very useful, but that seems like > another topic entirely. (Does it really get run in containers today? > That would require systemd to be pid 1 in the container, right?) > nspawn containers typically behave a lot like VMs, just using the shared kernel. So they would start init and activate login and such. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
On Tue, Feb 23, 2021 at 11:18 am, Petr Menšík wrote: Who uses cloud-init to prepare containers? Is it end user on his system? cloud-init is designed for VPS systems. I don't think it's expected to be used in containers. I'm sympathetic to your view that running systemd-resolved in containers is not very useful, but that seems like another topic entirely. (Does it really get run in containers today? That would require systemd to be pid 1 in the container, right?) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
On Tue, Feb 23, 2021 at 10:37 am, Tadej Janež wrote: I guess this is a simple solution that would work, but from what I understand it would also disable the use of systemd-resolved? Nah, it should just switch systemd-resolved into a consumer mode, where it reads configuration from /etc/resolv.conf and uses that as its source of truth. Applications using glibc for name resolution (i.e. almost everything) will still talk to systemd-resolved and ignore /etc/resolv.conf. That's not the default configuration in Fedora, though. Writing to a /etc/systemd/resolved.conf.d/*cloud-init.conf would be better though, since it would avoid major changes to how systemd-resolved works. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
On Mo, 22.02.21 09:45, Michael Catanzaro (mcatanz...@gnome.org) wrote: 65;6201;1c > On Mon, Feb 22, 2021 at 12:05 pm, Tomasz Torcz wrote: > > 3) Configure DNS resolvers if you want to use DNS. > > Or dig deeper: why cloud-init disabled DNS on your installation? > > I'm pretty sure cloud-init just doesn't know how to configure > systemd-resolved at all. So I suspect this is a cloud-init bug. See: > https://pagure.io/fedora-server/issue/10. > > I have no strong opinion on whether the fallback should have been removed or > not. The fallback was only hiding the real problem, after all. BTW, just to say this clearly. I think this argument is bogus and very user unfriendly. I think it's generally better to complain to the logs and still make things work automatically with a fallback than to just say "Nope, I was given invalid configuration and now I refuse to work". Because originally this is what resolved did: we had a last-resort fallback to provide DNS via a bunch of public DNS servers if nothing else is available, and we log if we are given invalid config. We use the fallback only as ultimate fallback, when the other option is to not work at all. The thing is that if DNS is fucked, then this is a pretty nasty problem: you need an extremely high level of understanding computers to be able to fix this. And you can't even get help, because, well, your DNS is down, you are not getting online. Hence, it's inherently a *good* thing to have a fallback in place, and I think it's a disserve to users to turn this off, as it makes systems much harder to fix. And yeah, call me a hypocrite, but if I have the choice between having no Internet at all or using some public DNS servers for DNS, and leaking a tiny bit of information to those DNS server providers then I am definitely preferring to have Internet, thank you very much. One could even go further: the privacy level using those public DNS servers might actually be higher than using the DHCP-provided ones in many cases, simple because we can use DoT on the former (admittedly not yet the default in resolved though, but hopefully soon), but almost never can on the latter, and what's worse the latter are usually provided by crappy edge networks like Internet Cafés and such where the fact we send stuff unencrypted is just awful. Now, Fedora made its choice here, and I'll accept that, but I still think it's a bad one, that trades a misunderstood concept of privacy against a major step forward in userfriendliness. i.e. I am not sure it's a good choice to limit Fedora's userspace needlessly to people who can fix their DNS configuration. It's a pretty tiny elite group of people to be in after all... (Oh, and I don't appreciate those people at all, who claim that "resolved sends all DNS lookups" to Google because it's a lie, we never did that, we only did that in case no better DNS configuration was available, i.e. as *last* *resort*, one step before giving up entirely). Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
Am 22.02.21 um 11:17 schrieb Zbigniew Jędrzejewski-Szmek: 1) Use different defaults for different Fedora editions, e.g. container and cloud images include the fallback DNS servers list while workstation (and similar) images don't. Yes, I think this would be the way to go. Everything, that is not prepresenting a person, is not regulated by GDPR, therefor it does not "need" to comply. About fallbacks in general: Es the example shows cleary to me, having fallback dns means, that you do not see, that your dns config is faulty and will fail in unexpected ways. Best regards, Marius ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
On Tue, 2021-02-23 at 11:18 +0100, Petr Menšík wrote: > Sure, this part is more complex. But only this part can fix this > problem > from inside the container IMO. Ie. we could fix it faster for any > involved parties. > > I don't really run any container on any cloud service so this is just > my > guess. Who uses cloud-init to prepare the container? If it is used by > cloud provider, I would expect slow updates and conservative > behavior. > Even if we fix it immediately, how fast would appear on the service? > I > think the fix from within can be much sooner be used by users. I think there might be a slight confusion here. The use case I'm talking about doesn't involve any containers and how DNS resolving is performed therein. I'm thinking in terms of a vanilla Fedora Cloud image being used to provision a new VM and cloud-init performing its configuration and initialization. This use case is currently broken (i.e. DNS resolution is broken), since cloud-init doesn't properly configure DNS servers and fallback DNS servers have been removed. To fix this use case, we would just need to patch cloud-init as you described in your 1. solution: cloud-init would check the symlink and target of etc/resolv.conf. If it points to /run/systemd/resolve/*, write DNS=x y into /etc/systemd/resolved.conf.d/*cloud-init.conf And then propose the patch to cloud-init upstream and include it in Fedora's cloud-init package for Fedora 34. As I see it, this could be fixed by Fedora itself and is not blocked on any cloud provider or other external party? signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
Hi Tadej, thanks for confirmation. On 2/23/21 10:37 AM, Tadej Janež wrote: > Petr, > > thanks for looking into this. > > On Mon, 2021-02-22 at 18:30 +0100, Petr Menšík wrote: >> After a quick glance at cloud-init code, it seems to me it does not >> check /etc/resolv.conf for symlinks. >> >> It just reads /etc/resolv.conf if it is a file, then writes its own >> nameservers into target. I have seen no rm of original >> /etc/resolv.conf, >> so I guess it rewritten target of symlink on Fedora 33: >> /run/systemd/resolve/stub-resolv.conf > > Indeed, cloud-init just "blindly" amends the /etc/resolv.conf file > which is a symlink to /run/systemd/resolve/stub-resolv.conf and hence > gets overwritten by systemd-resolved. > > Here are the relevant snippets from a DigitalOcean instance's > /var/log/cloud-init.log: > > ... trimmed ... > digitalocean.py[DEBUG]: added dns servers: ['67.207.67.2', > '67.207.67.3'] > ... trimmed ... > __init__.py[DEBUG]: Selected renderer 'sysconfig' from priority list: > None > util.py[DEBUG]: Writing to /etc/sysconfig/network-scripts/ifcfg-eth1 - > wb: [644] 212 bytes > util.py[DEBUG]: Restoring selinux mode for /etc/sysconfig/network- > scripts/ifcfg-eth1 (recursive=False) > util.py[DEBUG]: Restoring selinux mode for /etc/sysconfig/network- > scripts/ifcfg-eth1 (recursive=False) > util.py[DEBUG]: Writing to /etc/sysconfig/network-scripts/ifcfg-eth0 - > wb: [644] 287 bytes > util.py[DEBUG]: Restoring selinux mode for /etc/sysconfig/network- > scripts/ifcfg-eth0 (recursive=False) > util.py[DEBUG]: Restoring selinux mode for /etc/sysconfig/network- > scripts/ifcfg-eth0 (recursive=False) > util.py[DEBUG]: Reading from /etc/resolv.conf (quiet=False) > util.py[DEBUG]: Read 729 bytes from /etc/resolv.conf > util.py[DEBUG]: Writing to /etc/resolv.conf - wb: [644] 846 bytes > util.py[DEBUG]: Restoring selinux mode for /run/systemd/resolve/stub- > resolv.conf (recursive=False) > util.py[DEBUG]: Restoring selinux mode for /run/systemd/resolve/stub- > resolv.conf (recursive=False) > util.py[DEBUG]: Writing to /etc/NetworkManager/conf.d/99-cloud- > init.conf - wb: [644] 89 bytes > util.py[DEBUG]: Restoring selinux mode for > /etc/NetworkManager/conf.d/99-cloud-init.conf (recursive=False) > util.py[DEBUG]: Restoring selinux mode for > /etc/NetworkManager/conf.d/99-cloud-init.conf (recursive=False) > util.py[DEBUG]: Writing to /etc/udev/rules.d/70-persistent-net.rules - > wb: [644] 192 bytes > util.py[DEBUG]: Restoring selinux mode for /etc/udev/rules.d/70- > persistent-net.rules (recursive=False) > util.py[DEBUG]: Restoring selinux mode for /etc/udev/rules.d/70- > persistent-net.rules (recursive=False) > ... trimmed ... > >> I think there are two possible fixes: >> * cloud-init would check the symlink and target of etc/resolv.conf. >> If >> it points to /run/systemd/resolve/*, write DNS=x y into >> /etc/systemd/resolved.conf.d/*cloud-init.conf > > I think this option would be preferred. > >> * clound-init would always delete etc/resolv.conf before it writes >> into >> it, if it was symlink. > > I guess this is a simple solution that would work, but from what I > understand it would also disable the use of systemd-resolved? Well, partially. It wouldn't disable systemd-resolved service, but would not direct DNS messages to resolved. It would still cache requests done via nss, typically via getaddrinfo() or gethostbyname() function. That was intention of cloud-init anyway. Personally I would prefer cache on the host instead of in each container. > >> * systemd-resolved would check contents of link target of >> /etc/resolv.conf on startup. If it leads to systemd, try parsing its >> contents. If it does not look like managed contents of systemd, >> assume >> it might be misdirected resolv.conf configuration. Store it and wait >> for >> DHCP configuration. If no better configuration arrives, use >> nameservers >> from misdirected file. Would have to restore original resolv.conf on >> shutdown to keep working after restarts. Should move it to >> fallback.conf >> and use it instead of built-in fallbacks? > > This seems too complex and error prone. > > Regards, > Tadej It could just always move file without its own header to /run/systemd/resolved/fallback.conf (or maybe some permanent). When no better configuration was set, use this file as nameservers source, instead of built-in defaults. It would omit saving that files. Sure, this part is more complex. But only this part can fix this problem from inside the container IMO. Ie. we could fix it faster for any involved parties. I don't really run any container on any cloud service so this is just my guess. Who uses cloud-init to prepare the container? If it is used by cloud provider, I would expect slow updates and conservative behavior. Even if we fix it immediately, how fast would appear on the service? I think the fix from within can be much sooner be used by users. Who uses cloud-init to prepare containers? Is it end user on his system?
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
Petr, thanks for looking into this. On Mon, 2021-02-22 at 18:30 +0100, Petr Menšík wrote: > After a quick glance at cloud-init code, it seems to me it does not > check /etc/resolv.conf for symlinks. > > It just reads /etc/resolv.conf if it is a file, then writes its own > nameservers into target. I have seen no rm of original > /etc/resolv.conf, > so I guess it rewritten target of symlink on Fedora 33: > /run/systemd/resolve/stub-resolv.conf Indeed, cloud-init just "blindly" amends the /etc/resolv.conf file which is a symlink to /run/systemd/resolve/stub-resolv.conf and hence gets overwritten by systemd-resolved. Here are the relevant snippets from a DigitalOcean instance's /var/log/cloud-init.log: ... trimmed ... digitalocean.py[DEBUG]: added dns servers: ['67.207.67.2', '67.207.67.3'] ... trimmed ... __init__.py[DEBUG]: Selected renderer 'sysconfig' from priority list: None util.py[DEBUG]: Writing to /etc/sysconfig/network-scripts/ifcfg-eth1 - wb: [644] 212 bytes util.py[DEBUG]: Restoring selinux mode for /etc/sysconfig/network- scripts/ifcfg-eth1 (recursive=False) util.py[DEBUG]: Restoring selinux mode for /etc/sysconfig/network- scripts/ifcfg-eth1 (recursive=False) util.py[DEBUG]: Writing to /etc/sysconfig/network-scripts/ifcfg-eth0 - wb: [644] 287 bytes util.py[DEBUG]: Restoring selinux mode for /etc/sysconfig/network- scripts/ifcfg-eth0 (recursive=False) util.py[DEBUG]: Restoring selinux mode for /etc/sysconfig/network- scripts/ifcfg-eth0 (recursive=False) util.py[DEBUG]: Reading from /etc/resolv.conf (quiet=False) util.py[DEBUG]: Read 729 bytes from /etc/resolv.conf util.py[DEBUG]: Writing to /etc/resolv.conf - wb: [644] 846 bytes util.py[DEBUG]: Restoring selinux mode for /run/systemd/resolve/stub- resolv.conf (recursive=False) util.py[DEBUG]: Restoring selinux mode for /run/systemd/resolve/stub- resolv.conf (recursive=False) util.py[DEBUG]: Writing to /etc/NetworkManager/conf.d/99-cloud- init.conf - wb: [644] 89 bytes util.py[DEBUG]: Restoring selinux mode for /etc/NetworkManager/conf.d/99-cloud-init.conf (recursive=False) util.py[DEBUG]: Restoring selinux mode for /etc/NetworkManager/conf.d/99-cloud-init.conf (recursive=False) util.py[DEBUG]: Writing to /etc/udev/rules.d/70-persistent-net.rules - wb: [644] 192 bytes util.py[DEBUG]: Restoring selinux mode for /etc/udev/rules.d/70- persistent-net.rules (recursive=False) util.py[DEBUG]: Restoring selinux mode for /etc/udev/rules.d/70- persistent-net.rules (recursive=False) ... trimmed ... > I think there are two possible fixes: > * cloud-init would check the symlink and target of etc/resolv.conf. > If > it points to /run/systemd/resolve/*, write DNS=x y into > /etc/systemd/resolved.conf.d/*cloud-init.conf I think this option would be preferred. > * clound-init would always delete etc/resolv.conf before it writes > into > it, if it was symlink. I guess this is a simple solution that would work, but from what I understand it would also disable the use of systemd-resolved? > * systemd-resolved would check contents of link target of > /etc/resolv.conf on startup. If it leads to systemd, try parsing its > contents. If it does not look like managed contents of systemd, > assume > it might be misdirected resolv.conf configuration. Store it and wait > for > DHCP configuration. If no better configuration arrives, use > nameservers > from misdirected file. Would have to restore original resolv.conf on > shutdown to keep working after restarts. Should move it to > fallback.conf > and use it instead of built-in fallbacks? This seems too complex and error prone. Regards, Tadej signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
Tadej Janež wrote: > I would argue that the change causes noticeable problems and we want to > reconsider this change. > In particular, I think cloud image users would prefer to have their > cloud instances usable out of the box, i.e. have DNS working out-of-the > box. > > Don't get me wrong, I understand the privacy concerns and I think > Fedora should strive to protect the privacy of its users as much as > possible, but at the same time, the circumstances of a cloud instance > are probably very different from a e.g. workstation instance. Well, this silent fallback behavior is one of the reasons I have refused to use systemd-resolved at all so far. The issue with the cloud setups would also have been caught much earlier if it had failed right away and not silently used an external DNServer. Ignoring broken configuration and just using the default is not useful error handling. And the real issue is that systemd-resolved has broken cloud-init, so cloud-init needs to be fixed/updated. It is unfortunate that this behavior has changed in an update. This has happened because all the complaints about the old behavior back when the Change proposal was discussed (i.e., BEFORE Fedora 33 was released) were completely ignored by the Change owners and by FESCo (even though the fix was apparently a one-line change that could easily have been made before the release). Concerns raised during the discussion required by the Change process ought to be taken more seriously in the future. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
On Mon, 2021-02-22 at 11:14 -0600, Michael Catanzaro wrote:
> On Mon, Feb 22, 2021 at 5:46 pm, Tomasz Torcz
> wrote:
> > But "dns = none" seems wrong.
>
> Well it would be the right choice if cloud-init were to manually
> configure a static list of DNS servers in /etc/systemd/resolved.conf
> (or, previously, /etc/resolv.conf), which is probably what you want
> for
> a cloud server.
Yes, cloud-init configures NetworkManager to not manage DNS if it has
DNS servers that it configures statically:
This is the relevant code snippet:
def _render_networkmanager_conf(network_state, templates=None):
content = networkmanager_conf.NetworkManagerConf("")
# If DNS server information is provided, configure
# NetworkManager to not manage dns, so that /etc/resolv.conf
# does not get clobbered.
if network_state.dns_nameservers:
content.set_section_keypair('main', 'dns', 'none')
Source:
https://github.com/canonical/cloud-init/blob/66e2d42dd1b722dc8e59f4e5990cea54f81ccd2a/cloudinit/net/sysconfig.py#L769-L776
signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
On Mon, 2021-02-22 at 09:45 -0600, Michael Catanzaro wrote: > On Mon, Feb 22, 2021 at 12:05 pm, Tomasz Torcz > wrote: > > 3) Configure DNS resolvers if you want to use DNS. > > Or dig deeper: why cloud-init disabled DNS on your installation? > > I'm pretty sure cloud-init just doesn't know how to configure > systemd-resolved at all. So I suspect this is a cloud-init bug. See: > https://pagure.io/fedora-server/issue/10. > > I have no strong opinion on whether the fallback should have been > removed or not. The fallback was only hiding the real problem, after > all. Indeed, this appears to be the case. For cloud images, I agree that the correct approach is to fix the root issue, i.e. make cloud-init understand and configure systemd-resolved. Regards, Tadej signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
After a quick glance at cloud-init code, it seems to me it does not check /etc/resolv.conf for symlinks. It just reads /etc/resolv.conf if it is a file, then writes its own nameservers into target. I have seen no rm of original /etc/resolv.conf, so I guess it rewritten target of symlink on Fedora 33: /run/systemd/resolve/stub-resolv.conf I think there are two possible fixes: * cloud-init would check the symlink and target of etc/resolv.conf. If it points to /run/systemd/resolve/*, write DNS=x y into /etc/systemd/resolved.conf.d/*cloud-init.conf * clound-init would always delete etc/resolv.conf before it writes into it, if it was symlink. * systemd-resolved would check contents of link target of /etc/resolv.conf on startup. If it leads to systemd, try parsing its contents. If it does not look like managed contents of systemd, assume it might be misdirected resolv.conf configuration. Store it and wait for DHCP configuration. If no better configuration arrives, use nameservers from misdirected file. Would have to restore original resolv.conf on shutdown to keep working after restarts. Should move it to fallback.conf and use it instead of built-in fallbacks? 1. https://github.com/canonical/cloud-init/blob/66e2d42dd1b722dc8e59f4e5990cea54f81ccd2a/cloudinit/net/sysconfig.py#L909 On 2/22/21 4:45 PM, Michael Catanzaro wrote: > On Mon, Feb 22, 2021 at 12:05 pm, Tomasz Torcz > wrote: >> 3) Configure DNS resolvers if you want to use DNS. >> Or dig deeper: why cloud-init disabled DNS on your installation? > > I'm pretty sure cloud-init just doesn't know how to configure > systemd-resolved at all. So I suspect this is a cloud-init bug. See: > https://pagure.io/fedora-server/issue/10. > > I have no strong opinion on whether the fallback should have been > removed or not. The fallback was only hiding the real problem, after all. > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
On Mon, Feb 22, 2021 at 5:46 pm, Tomasz Torcz wrote: But "dns = none" seems wrong. Well it would be the right choice if cloud-init were to manually configure a static list of DNS servers in /etc/systemd/resolved.conf (or, previously, /etc/resolv.conf), which is probably what you want for a cloud server. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
Dnia Mon, Feb 22, 2021 at 09:45:58AM -0600, Michael Catanzaro napisał(a): > On Mon, Feb 22, 2021 at 12:05 pm, Tomasz Torcz wrote: > > 3) Configure DNS resolvers if you want to use DNS. > > Or dig deeper: why cloud-init disabled DNS on your installation? > > I'm pretty sure cloud-init just doesn't know how to configure > systemd-resolved at all. So I suspect this is a cloud-init bug. See: > https://pagure.io/fedora-server/issue/10. Quoting from Tadej's email to cloud@ list; #v+ $ cat /etc/NetworkManager/conf.d/99-cloud-init.conf # Created by cloud-init on instance boot automatically, do not edit. # [main] dns = none #v- So cloud-init at least tries to configure NM. This configuration would be passed down to resolved. But "dns = none" seems wrong. -- Tomasz Torcz “(…) today's high-end is tomorrow's embedded processor.” to...@pipebreaker.pl — Mitchell Blank on LKML ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
On Mon, Feb 22, 2021 at 10:57 am, David Both wrote: do not think this is a cloud-init problem. None of my hosts are in any cloud and most failed to resolve after upgrade to F33. Only after reverting to nss resolver by disabling systemd-resolved did the problem disappear. Hi David, your issue is totally different. Let's continue to discuss your issue in the other thread. You appear to be having some problem with configuration from DHCP possibly not being propagated to systemd-resolved, which suggests either a network level problem or a NetworkManager issue. But this thread is about simple static configuration on cloud servers where no DHCP is available. In both threads, the question is "why did nobody tell systemd-resolved which DNS servers to use?" In your thread, I would expect NetworkManager to get DNS configuration from DHCP and propagate that to systemd-resolved. In this thread, I would expect the cloud provider to hardcode some DNS servers in resolved.conf. So far we don't have any evidence of a systemd-resolved bug in either thread. I would be pretty surprised if it's not sending your DNS queries exactly where it is configured to do so. The mystery is to figure out why it has been misconfigured. And in case of cloud servers, cloud-init seems like the right place to handle that. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
I do not think this is a cloud-init problem. None of my hosts are in any cloud and most failed to resolve after upgrade to F33. Only after reverting to nss resolver by disabling systemd-resolved did the problem disappear. I did investigate the new resolver but none of the options worked no matter which one I linked /etc/resolv.conf to. They all failed in one way or another. To me, this seems to be a problem with systemd-resolved not some external service. Thanks! -- * David P. Both, RHCE He/Him/His * www.both.org - My personal web site www.Linux-Databook.info - Home of the DataBook for Linux DataBook is a Registered Trademark of David Both * The value of any software lies in its usefulness not in its price. — Linus Torvalds * On Mon, 22 Feb 2021, Michael Catanzaro wrote: Date: Mon, 22 Feb 2021 10:45:58 From: Michael Catanzaro Reply-To: Development discussions related to Fedora To: Development discussions related to Fedora Cc: Tadej Janež Subject: Re: systemd-resolved fallback DNS servers: usability vs. GDPR On Mon, Feb 22, 2021 at 12:05 pm, Tomasz Torcz wrote: 3) Configure DNS resolvers if you want to use DNS. Or dig deeper: why cloud-init disabled DNS on your installation? I'm pretty sure cloud-init just doesn't know how to configure systemd-resolved at all. So I suspect this is a cloud-init bug. See: https://pagure.io/fedora-server/issue/10. I have no strong opinion on whether the fallback should have been removed or not. The fallback was only hiding the real problem, after all. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
On Mon, Feb 22, 2021 at 12:05 pm, Tomasz Torcz wrote: 3) Configure DNS resolvers if you want to use DNS. Or dig deeper: why cloud-init disabled DNS on your installation? I'm pretty sure cloud-init just doesn't know how to configure systemd-resolved at all. So I suspect this is a cloud-init bug. See: https://pagure.io/fedora-server/issue/10. I have no strong opinion on whether the fallback should have been removed or not. The fallback was only hiding the real problem, after all. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
On 2/22/21 11:17 AM, Zbigniew Jędrzejewski-Szmek wrote: > On Mon, Feb 22, 2021 at 10:58:09AM +0100, Tadej Janež wrote: >> Hi, >> >> I would like to question the decision that was made by systemd >> maintainers to remove the fallback DNS server list: >> https://src.fedoraproject.org/rpms/systemd/c/14b2fafb3688a4170a9c15235d1c3feb7ddeaf9d >> >> And then backported to F33: >> https://src.fedoraproject.org/rpms/systemd/c/ed795fb1fc9a2c20ebcac34bdf7e7c7ae17322a2?branch=f33 >> >> On F33, this actually breaks a working vanilla cloud instance by >> removing the fallback DNS server list in a systemd upgrade, effectively >> leaving the system with no DNS servers configured. >> >> I described this in more detail here: >> https://lists.fedoraproject.org/archives/list/cl...@lists.fedoraproject.org/thread/72MRKIFGPMFGBS7XJ5T5I23NVDXXWVGR/ >> >> Zbigniew Jędrzejewski-Szmek wrote the following in the commit message >> accompanying the fallback DNS server list removal: >> >>> So hopefully users will not see any effect from the change done in >>> this patch. Right now I think it is better to avoid the legal and >>> privacy risk. If it turns out this change causes noticable problems, >>> we might want to reconsider. In particular we could use the fallback >>> servers only in containers and such which are not "personal" machines >>> and there is no particular person attached to them. >> >> I would argue that the change causes noticeable problems and we want to >> reconsider this change. >> In particular, I think cloud image users would prefer to have their >> cloud instances usable out of the box, i.e. have DNS working out-of-the >> box. >> >> Don't get me wrong, I understand the privacy concerns and I think >> Fedora should strive to protect the privacy of its users as much as >> possible, but at the same time, the circumstances of a cloud instance >> are probably very different from a e.g. workstation instance. >> >> Possible solutions that come to mind: >> >> 1) Use different defaults for different Fedora editions, e.g. container >> and cloud images include the fallback DNS servers list while >> workstation (and similar) images don't. > > Yes, I think this would be the way to go. Cloud images already have > special configuration to invoke the "cloud init" services. They could > just as well add a drop-in in /usr/lib/systemd/resolved.conf/ with > FallbackDNS=. It would be even better to make sure that the cloud > config sets some appropriate dns servers in all cases. Problem with fallback is, you never know when they are appropriate. I think it should be possible to configure container without DNS access at all. It should depend on deployment configuration, not on fallback. It should obey configuration and notify user, when configuration is wrong. He should not realize that only when fallbacks were removed. > >> 2) Pick a reputable DNS resolver that preserves users' privacy and >> doesn't log anything and configure it as a fallback DNS server. >> Here is a good summary of DNS resolvers and their privacy: >> https://privacytools.io/providers/dns/#dns > > I don't think this is feasible. The laws put a lot of emphasis on > location (i.e. that the data is not processed by outside entities). > So an even perfectly good privacy-respecting provider might not be > acceptable in some locations (there's at least EU, Brazil, Japan that > have GDPR-like rules…). I don't think we want to analyze the situation > to figure out whether some provider is acceptable everywhere even once, > and promising to do that continuously as things change would be even > worse. > > Zbyszek > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
Dnia Mon, Feb 22, 2021 at 10:58:09AM +0100, Tadej Janež napisał(a): > Hi, > > I would like to question the decision that was made by systemd > maintainers to remove the fallback DNS server list: > https://src.fedoraproject.org/rpms/systemd/c/14b2fafb3688a4170a9c15235d1c3feb7ddeaf9d > > And then backported to F33: > https://src.fedoraproject.org/rpms/systemd/c/ed795fb1fc9a2c20ebcac34bdf7e7c7ae17322a2?branch=f33 > > On F33, this actually breaks a working vanilla cloud instance by > removing the fallback DNS server list in a systemd upgrade, effectively > leaving the system with no DNS servers configured. > > I described this in more detail here: > https://lists.fedoraproject.org/archives/list/cl...@lists.fedoraproject.org/thread/72MRKIFGPMFGBS7XJ5T5I23NVDXXWVGR/ Let's be careful not to go in circles. It seems you have "broken" configuration - no DNS servers are provided to the cloud image. So none are configured. Previously, systemd package provided a fallback DNS resolvers for that case. Then it stopped doing that. Now the circles - the change in systemd package was the outcome of discussion here on -devel list. In this discussion some people had a position "if I do not provide DNS servers, I don't want DNS to work". Which is resonable and expected in high-control situations. Providing the workaround again would go against wishes of those people. From their perspective your non-resolving cloud image is exactly as you want it. As you configured it. > > Possible solutions that come to mind: > 1) Use different defaults for different Fedora editions, e.g. container > and cloud images include the fallback DNS servers list while > workstation (and similar) images don't. > 2) Pick a reputable DNS resolver that preserves users' privacy and > doesn't log anything and configure it as a fallback DNS server. 3) Configure DNS resolvers if you want to use DNS. Or dig deeper: why cloud-init disabled DNS on your installation? -- Tomasz Torcz “(…) today's high-end is tomorrow's embedded processor.” to...@pipebreaker.pl — Mitchell Blank on LKML ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
Hi Tadej, I think more effort should be put to configure the instance correctly by provider. No default should save invalid configuration of container host. I think there is actually little benefit in systemd-resolved usage in a container. I would guess the container host would run proper dns cache for all its containers, sharing the cache between them. Why does it run its own cache inside? I think systemd-resolved should not be used on container at all. It needs to forward queries to any address configured by the host. It should even not be installed by default in container, could it be split to systemd-resolved package? Do you know, what are all steps done by cloud-init? Did it try to write its own /etc/resolv.conf? When it disables dns=none in NM, I guess it tried to setup static resolv.conf. Is it possible that writes went to symlink target in /run/systemd/resolve and they were overwritten later? We have to find good way to configure DNS in all releases the proper way. Don't rely on fallbacks. If you had non-working configuration from the start and relied on fallback, I think this should be fixed. If configuration were provided but did not work, it should fail hard, let you notice it. I think most daemons do that already. Is there any "standard" way to configure DNS in deployed containers? I use DHCP myself, but have only containers for development. Cheers, Petr On 2/22/21 10:58 AM, Tadej Janež wrote: > Hi, > > I would like to question the decision that was made by systemd > maintainers to remove the fallback DNS server list: > https://src.fedoraproject.org/rpms/systemd/c/14b2fafb3688a4170a9c15235d1c3feb7ddeaf9d > > And then backported to F33: > https://src.fedoraproject.org/rpms/systemd/c/ed795fb1fc9a2c20ebcac34bdf7e7c7ae17322a2?branch=f33 > > On F33, this actually breaks a working vanilla cloud instance by > removing the fallback DNS server list in a systemd upgrade, effectively > leaving the system with no DNS servers configured. > > I described this in more detail here: > https://lists.fedoraproject.org/archives/list/cl...@lists.fedoraproject.org/thread/72MRKIFGPMFGBS7XJ5T5I23NVDXXWVGR/ > > Zbigniew Jędrzejewski-Szmek wrote the following in the commit message > accompanying the fallback DNS server list removal: > >> So hopefully users will not see any effect from the change done in >> this patch. Right now I think it is better to avoid the legal and >> privacy risk. If it turns out this change causes noticable problems, >> we might want to reconsider. In particular we could use the fallback >> servers only in containers and such which are not "personal" machines >> and there is no particular person attached to them. > > I would argue that the change causes noticeable problems and we want to > reconsider this change. > In particular, I think cloud image users would prefer to have their > cloud instances usable out of the box, i.e. have DNS working out-of-the > box. > > Don't get me wrong, I understand the privacy concerns and I think > Fedora should strive to protect the privacy of its users as much as > possible, but at the same time, the circumstances of a cloud instance > are probably very different from a e.g. workstation instance. > > Possible solutions that come to mind: > > 1) Use different defaults for different Fedora editions, e.g. container > and cloud images include the fallback DNS servers list while > workstation (and similar) images don't. > > 2) Pick a reputable DNS resolver that preserves users' privacy and > doesn't log anything and configure it as a fallback DNS server. > Here is a good summary of DNS resolvers and their privacy: > https://privacytools.io/providers/dns/#dns > > Thoughts? > > Regards, > Tadej > > P.S. I'm subscribed, but please keep me in Cc so I'll notice replies > sooner. > > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list,
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
On Mon, Feb 22, 2021 at 10:58:09AM +0100, Tadej Janež wrote: > Hi, > > I would like to question the decision that was made by systemd > maintainers to remove the fallback DNS server list: > https://src.fedoraproject.org/rpms/systemd/c/14b2fafb3688a4170a9c15235d1c3feb7ddeaf9d > > And then backported to F33: > https://src.fedoraproject.org/rpms/systemd/c/ed795fb1fc9a2c20ebcac34bdf7e7c7ae17322a2?branch=f33 > > On F33, this actually breaks a working vanilla cloud instance by > removing the fallback DNS server list in a systemd upgrade, effectively > leaving the system with no DNS servers configured. > > I described this in more detail here: > https://lists.fedoraproject.org/archives/list/cl...@lists.fedoraproject.org/thread/72MRKIFGPMFGBS7XJ5T5I23NVDXXWVGR/ > > Zbigniew Jędrzejewski-Szmek wrote the following in the commit message > accompanying the fallback DNS server list removal: > > > So hopefully users will not see any effect from the change done in > > this patch. Right now I think it is better to avoid the legal and > > privacy risk. If it turns out this change causes noticable problems, > > we might want to reconsider. In particular we could use the fallback > > servers only in containers and such which are not "personal" machines > > and there is no particular person attached to them. > > I would argue that the change causes noticeable problems and we want to > reconsider this change. > In particular, I think cloud image users would prefer to have their > cloud instances usable out of the box, i.e. have DNS working out-of-the > box. > > Don't get me wrong, I understand the privacy concerns and I think > Fedora should strive to protect the privacy of its users as much as > possible, but at the same time, the circumstances of a cloud instance > are probably very different from a e.g. workstation instance. > > Possible solutions that come to mind: > > 1) Use different defaults for different Fedora editions, e.g. container > and cloud images include the fallback DNS servers list while > workstation (and similar) images don't. Yes, I think this would be the way to go. Cloud images already have special configuration to invoke the "cloud init" services. They could just as well add a drop-in in /usr/lib/systemd/resolved.conf/ with FallbackDNS=. It would be even better to make sure that the cloud config sets some appropriate dns servers in all cases. > 2) Pick a reputable DNS resolver that preserves users' privacy and > doesn't log anything and configure it as a fallback DNS server. > Here is a good summary of DNS resolvers and their privacy: > https://privacytools.io/providers/dns/#dns I don't think this is feasible. The laws put a lot of emphasis on location (i.e. that the data is not processed by outside entities). So an even perfectly good privacy-respecting provider might not be acceptable in some locations (there's at least EU, Brazil, Japan that have GDPR-like rules…). I don't think we want to analyze the situation to figure out whether some provider is acceptable everywhere even once, and promising to do that continuously as things change would be even worse. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
systemd-resolved fallback DNS servers: usability vs. GDPR
Hi, I would like to question the decision that was made by systemd maintainers to remove the fallback DNS server list: https://src.fedoraproject.org/rpms/systemd/c/14b2fafb3688a4170a9c15235d1c3feb7ddeaf9d And then backported to F33: https://src.fedoraproject.org/rpms/systemd/c/ed795fb1fc9a2c20ebcac34bdf7e7c7ae17322a2?branch=f33 On F33, this actually breaks a working vanilla cloud instance by removing the fallback DNS server list in a systemd upgrade, effectively leaving the system with no DNS servers configured. I described this in more detail here: https://lists.fedoraproject.org/archives/list/cl...@lists.fedoraproject.org/thread/72MRKIFGPMFGBS7XJ5T5I23NVDXXWVGR/ Zbigniew Jędrzejewski-Szmek wrote the following in the commit message accompanying the fallback DNS server list removal: > So hopefully users will not see any effect from the change done in > this patch. Right now I think it is better to avoid the legal and > privacy risk. If it turns out this change causes noticable problems, > we might want to reconsider. In particular we could use the fallback > servers only in containers and such which are not "personal" machines > and there is no particular person attached to them. I would argue that the change causes noticeable problems and we want to reconsider this change. In particular, I think cloud image users would prefer to have their cloud instances usable out of the box, i.e. have DNS working out-of-the box. Don't get me wrong, I understand the privacy concerns and I think Fedora should strive to protect the privacy of its users as much as possible, but at the same time, the circumstances of a cloud instance are probably very different from a e.g. workstation instance. Possible solutions that come to mind: 1) Use different defaults for different Fedora editions, e.g. container and cloud images include the fallback DNS servers list while workstation (and similar) images don't. 2) Pick a reputable DNS resolver that preserves users' privacy and doesn't log anything and configure it as a fallback DNS server. Here is a good summary of DNS resolvers and their privacy: https://privacytools.io/providers/dns/#dns Thoughts? Regards, Tadej P.S. I'm subscribed, but please keep me in Cc so I'll notice replies sooner. signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
