Re: This is bad, was Re: Fedora 33 System-Wide Change proposal:?? systemd-resolved

[Marius Schwarz]

Am 06.10.20 um 23:21 schrieb Solomon Peachy:
>> It's one thing to contact your repo or distro servers, and another if
>> it's a known dataminer, that gets all domainnames you visit.
> So.. given that both Google and Cloudfare have actual European business 
> offices, aren't they bound by the GPDR too?  
>
> I get that it's fashionable these days to dump all over $Big_Tech, but 
> we're better off basing our arguments on actual facts and logic?

If you have a contract with them, which you don't have, and the data
stays in europe, it would be another thing.

As a matter of fact, I have mailed our federal dp office and my
statewise dp office for a dp statement.

As soon as a statement, no matter which opinion they have, arrives, i
will post the result here on the list, so we all have a better
understanding of the matter.
Due to the complexity of this matter, I dont expect an answere soon ;)

Most likely i will receive a consultative call first and than it will
takes months before something happens. Had it already for article 32 1a
GDPR and the enforcement of TLS1_2 with SMTP in 2018. (btw.. i was right
;) )

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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal:?? systemd-resolved

[Solomon Peachy]

On Tue, Oct 06, 2020 at 11:00:23PM +0200, Marius Schwarz wrote:
> It's one thing to contact your repo or distro servers, and another if
> it's a known dataminer, that gets all domainnames you visit.

So.. given that both Google and Cloudfare have actual European business 
offices, aren't they bound by the GPDR too?  

I get that it's fashionable these days to dump all over $Big_Tech, but 
we're better off basing our arguments on actual facts and logic?

Indeed, is there even a legal "Fedora" entity in Europe?  Shouldn't we 
all be getting up in arms about Red Hat, especially now that it's wholly 
owned by, which is itself another massive data miner?

This seems to be a strange hill to fight over, especially for a 
last-ditch fallback that will only get used under an intentional 
[mis-]configuration of the network and/or Fedora system.

 - Solomon
-- 
Solomon Peachypizza at shaftnet dot org (email)
  @pizza:shaftnet dot org   (matrix)
High Springs, FL  speachy (freenode)



signature.asc
Description: PGP 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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal:?? systemd-resolved

[Marius Schwarz]

Am 05.10.20 um 11:12 schrieb Petr Menšík:
>> * Immediately after you connect to the network, Fedora connects to
>> http://fedoraproject.org/static/hotspot.txt to see if you're behind a
>> captive portal
> Fedora is contacting fedora server, seems predictable.

It's one thing to contact your repo or distro servers, and another if
it's a known dataminer, that gets all domainnames you visit.

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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal:?? systemd-resolved

[Zbigniew Jędrzejewski-Szmek]

OK, you convinced me: 
https://src.fedoraproject.org/rpms/systemd/pull-request/37.
Let's see what others say.

Zbyszek


On Fri, Oct 02, 2020 at 12:34:32AM +0200, Marius Schwarz wrote:
> Am 01.10.20 um 16:36 schrieb Alexander Bokovoy:
> >
> > You can also drop a configuration snippet in
> > /etc/systemd/resolved.conf.d/ to contain
> >
> >   FallbackDNS=
> >
> > This will disable global DNS servers for any case.
> >
> if that would be the default, it would be ok.
> 
> Am 01.10.20 um 16:03 schrieb Michael Catanzaro:
> > We are not going to patch out fallback to Cloudflare or Google because
> > it is a non-issue. Fallback only happens when you have zero other DNS
> > servers configured. When was the last time you connected to a network
> > and there's no DHCP, no nothing? The number of users without some
> > other working DNS is probably under 0.1%.
> 
> BTW: thumbs up for the DOT proposal.
> 
> I will make it very clear and easy:  
> 
> O== Situation for Germany
> 
> GDPR is in place as a EU LAW. The protection rules are only active for
> companies or organizations, not for private people.
> 
> 2013 a german court (Kammergericht Berlin) ruled, that IP addresses are
> Personal Data. It has never been overruled.
> 
> Personal Data can only be send to none eu countries and corporations, if
> there is a data protection law in place that has the same or better
> level of protection as the eu law has ( or if it's necessary to buy
> stuff (a house, car, whatever ). The pact the EU did with the US was
> called Privacy Shield. It imploded (for the second time) a few months
> ago. From the moment the eu court rule was public, transfer of personal
> data into the us was illegal.
> 
> If you send a DNS REQUEST to a US DNS server from within a company
> network, and with ipv6 the internal ip is sent out i learned lately, you
> have sent personal data which is protected under the GDRP. It's not
> unlikely to use company pcs for private webvisits while having a meal
> break.
> 
> Therefor, a os that has google and cloudflare as a default, even if it's
> unlikely to happen as you point out, which sends out dns with personal
> data in it to a us dns server, brings the company in great trouble with
> the law. In the end, this means, you as a company/org need to pay a
> (possibly) shitload of money as a fine and therefor they can't use this
> os anymore. (someone else on the list pointed this out too.) The
> consequence is, Fedora is a juristic risk. [The fine is higher, if you
> as corp/org did not document this data transfer in your data protection
> memos] Of course a working dns setup will prevent this problem, but
> thats not the point. Activists in germany and other countries try to get
> more and more gov projects to OSS due to privacy issues with M$. It
> would be a shame if Fedora would also count as a potential problem.
> 
> Do we all really want this, for the benefit on 0.1%(as you say) have a
> dns lookup instead of a hint, that their systems are broken?
> 
> Pls remember: I'm just the messenger, Í didn't write the laws ;)
> 
> Funfact: last time I checked the northern germany police pc in my city,
> they used a fedora based desktop system. I like that fact :D But i'm
> pretty sure, they don't like a cloudflare fallback dns once they reach
> F33 ( if ever ).
> 
> 
> 
> 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
___
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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Denys Vlasenko]

On 9/28/20 6:44 AM, Paul Wouters wrote:



Subject: Re: Fedora 33 System-Wide Change proposal: systemd-resolved


I was just hit by the first bug in systemd-resolved 4 days after I
upgraded to fedora33. I will file a bug report for that, but I wanted
to discuss something more fundamental.

systemd-resolved has a number of architectural flaws. When these were
pointed out, bugs are not accepted and closed or ignored. Worse, I
was told that systemd-resolved would not become the system DNS resolver,
so I could just choose to not use it.

Unfortunately, with my upgrade to fedora 33 I was unwittingly upgraded
to systemd-resolved. I want to remove it from my system, but I cannot
because it is not even a sub-package of systemd, it is part of the
core systemd package. This goes against promises made in the past.


First time?
It's standard operating procedure for systemd from the inception
of that project.
___
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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal:?? systemd-resolved

[Petr Menšík]

On 10/2/20 2:16 PM, Michael Catanzaro wrote:
> On Fri, Oct 2, 2020 at 12:34 am, Marius Schwarz 
> wrote:
>> If you send a DNS REQUEST to a US DNS server from within a company
>> network, and with ipv6 the internal ip is sent out i learned lately, you
>> have sent personal data which is protected under the GDRP. It's not
>> unlikely to use company pcs for private webvisits while having a meal
>> break.
> 
> Hm, thanks for the explanation. I guess the DNS request would indeed be
> the *first* way you lose, because you have to do DNS before you do
> anything else. But you are going to lose immediately after anyway:
> 
> * Immediately after you connect to the network, Fedora connects to
> http://fedoraproject.org/static/hotspot.txt to see if you're behind a
> captive portal
Fedora is contacting fedora server, seems predictable.
> * Next, GNOME Software starts checking for updates in the background.
> You've leaked "personal data" to fedoraproject.org again, and also fwupd.
It checks also to Fedora servers, right?
> * You open Firefox, it downloads Safe Browsing data from Google.
> (Admittedly this one is probably only behind a European CDN, but maybe
> Google is having a bad day, or maybe IP address logs are sent to the
> US.) Oh yeah, it also displays news from Pocket. Probably it does more
> connections to the US that I don't know about.
> * You switch to Financial Mode in Calculator, it downloads exchange rate
> data.
Might ask question to user, whether that is okay. Can you please fill a
RFE bug?
> * Anything crashes. A truncated stack trace gets sent to Fedora.
> 
> I'm sure my list is missing quite a lot. If your interpretation is
> correct, then I suppose German companies should immediately discontinue
> use of Fedora, and also most other computer operating systems

I think you are missing one important detail. When you choose to install
Fedora, you are likely to accept it sends something to its servers.
Anyway, they would usually have your IP somewhere, when you downloaded
system image.

However, forwarding queries to every name you visit online to some
party, which you never agreed to or maybe heard its name, is something
different. It just provides your site history to company never mentioned
even in configuration files. It is only mentioned by resolvectl, which
normal user would never hear about.

It seems this should be easily configurable on installation (kickstart
default or something), but by default should be empty.

Prepared commented out FallbackDNS=8.8.8.8,... would work well.

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB



signature.asc
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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal:???? systemd-resolved

[Solomon Peachy]

On Fri, Oct 02, 2020 at 03:37:21PM +0200, Eugene Syromiatnikov wrote:
> > FFS, if Fedora is "bad" for doing these things, how is MacOS, iOS, 
> > Android, or even Windows acceptible?
> > 
> > (out-of-the-box, that is.  because that's what we're talking about here)
> 
> They are not, and that is why people use Linux.

In other words, this has nothing to do with legal (eg GPDR) compliance.

 - Solomon
-- 
Solomon Peachypizza at shaftnet dot org (email)
  @pizza:shaftnet dot org   (matrix)
High Springs, FL  speachy (freenode)


signature.asc
Description: PGP 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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Simo Sorce]

On Fri, 2020-10-02 at 00:50 +0200, Marius Schwarz wrote:
> Am 01.10.20 um 19:36 schrieb Simo Sorce:
> > That said,
> > if it really is an internal DNS and there are strong policies around it
> > I assume that the perimeter or the local machine firewall will be
> > configured to block UDP packets to port 53 to any other external
> > servers ...
> > 
> > This leaves out only some machines or some cases where a
> > misconfiguration may cause this fallback to kick in. The occurrence is
> > probably rare enough not to be a problem in practice at least from the
> > pov of GDPR.
> you know, that you contradict yourself here? :)
> 
> If the corp has blocked port 53 except for the internal dns server, how
> should the fallback packet get out?

It will not, that's the point, I do not see any contradiction.

> I think, it's not important how often the default is used, it's the fact
> that it's hidden and therefor surprising for the corp itself,
> which makes it even more risky to run the os, than it's worth giving (
> or in your example not to give ) the 0.1% a fallback answere.

I guess then corporations will immediately ban both Microsfot Windows
and Apple MacOS because they connect to the respective motherships as
well as dozen of other random IP addresses all the time ...

> IRL admins who know about it, as we all do now, we can avoid the
> problem. But for a company, which has to justify the surprising result
> of a DP audit, it will not be an easy talk with the dp buero. Just for
> the lols, I will ask our highest federal dp advocate tomorrow, what he
> thinks about this.

IRL any admin knows that there is the potential for a networked machine
to connect to random place, if they have a concern about that they take
appropriate measures to prevent it, either via firewalling or by
enforcing specific configurations.

I am not thrilled by this fallback either, but I think there are enough
assurances that in any reasonably configured (and functional) network
this fallback will not be triggered, and therefore there isn't a
persistent privacy leak threat to be concerned about.

But both mine and yours are opinions, and I am pretty sure Fedora will
do what's needed if there is some judicial determination that binds
this specific kind of issue one way or another.

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



___
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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal:???? systemd-resolved

[Eugene Syromiatnikov]

On Fri, Oct 02, 2020 at 09:23:12AM -0400, Solomon Peachy wrote:
> On Fri, Oct 02, 2020 at 02:34:15PM +0200, Eugene Syromiatnikov wrote:
> > Only those that think that they are smarter that a user and ignore her/his
> > privacy.  
> 
> In other words, all of them?
> 
> FFS, if Fedora is "bad" for doing these things, how is MacOS, iOS, 
> Android, or even Windows acceptible?
> 
> (out-of-the-box, that is.  because that's what we're talking about here)

They are not, and that is why people use Linux.

> > The things in the list above definitely either shouldn't be
> > done at all (like captive portla checks and checks for updates), or ask
> > for explicit user consent (everything else).
> 
> Great, more things for the user to click through *every single time*.

The great UX invention of "do not ask this question again" saves the
day again.
___
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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal:???? systemd-resolved

[Solomon Peachy]

On Fri, Oct 02, 2020 at 02:34:15PM +0200, Eugene Syromiatnikov wrote:
> Only those that think that they are smarter that a user and ignore her/his
> privacy.  

In other words, all of them?

FFS, if Fedora is "bad" for doing these things, how is MacOS, iOS, 
Android, or even Windows acceptible?

(out-of-the-box, that is.  because that's what we're talking about here)

> The things in the list above definitely either shouldn't be
> done at all (like captive portla checks and checks for updates), or ask
> for explicit user consent (everything else).

Great, more things for the user to click through *every single time*.

 - Solomon
-- 
Solomon Peachypizza at shaftnet dot org (email)
  @pizza:shaftnet dot org   (matrix)
High Springs, FL  speachy (freenode)


signature.asc
Description: PGP 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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal:???? systemd-resolved

[Eugene Syromiatnikov]

On Fri, Oct 02, 2020 at 07:16:38AM -0500, Michael Catanzaro wrote:
> On Fri, Oct 2, 2020 at 12:34 am, Marius Schwarz 
> wrote:
> >If you send a DNS REQUEST to a US DNS server from within a company
> >network, and with ipv6 the internal ip is sent out i learned lately, you
> >have sent personal data which is protected under the GDRP. It's not
> >unlikely to use company pcs for private webvisits while having a meal
> >break.
> 
> Hm, thanks for the explanation. I guess the DNS request would indeed be the
> *first* way you lose, because you have to do DNS before you do anything
> else. But you are going to lose immediately after anyway:
> 
> * Immediately after you connect to the network, Fedora connects to
> http://fedoraproject.org/static/hotspot.txt to see if you're behind a
> captive portal
> * Next, GNOME Software starts checking for updates in the background. You've
> leaked "personal data" to fedoraproject.org again, and also fwupd.
> * You open Firefox, it downloads Safe Browsing data from Google. (Admittedly
> this one is probably only behind a European CDN, but maybe Google is having
> a bad day, or maybe IP address logs are sent to the US.) Oh yeah, it also
> displays news from Pocket. Probably it does more connections to the US that
> I don't know about.
> * You switch to Financial Mode in Calculator, it downloads exchange rate
> data.
> * Anything crashes. A truncated stack trace gets sent to Fedora.
> 
> I'm sure my list is missing quite a lot.
> If your interpretation is correct,
> then I suppose German companies should immediately discontinue use of
> Fedora, and also most other computer operating systems

Only those that think that they are smarter that a user and ignore her/his
privacy.  The things in the list above definitely either shouldn't be
done at all (like captive portla checks and checks for updates), or ask
for explicit user consent (everything else).
___
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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal:?? systemd-resolved

[Michael Catanzaro]

On Fri, Oct 2, 2020 at 12:34 am, Marius Schwarz 
 wrote:

If you send a DNS REQUEST to a US DNS server from within a company
network, and with ipv6 the internal ip is sent out i learned lately, 
you

have sent personal data which is protected under the GDRP. It's not
unlikely to use company pcs for private webvisits while having a meal
break.


Hm, thanks for the explanation. I guess the DNS request would indeed be 
the *first* way you lose, because you have to do DNS before you do 
anything else. But you are going to lose immediately after anyway:


* Immediately after you connect to the network, Fedora connects to 
http://fedoraproject.org/static/hotspot.txt to see if you're behind a 
captive portal
* Next, GNOME Software starts checking for updates in the background. 
You've leaked "personal data" to fedoraproject.org again, and also 
fwupd.
* You open Firefox, it downloads Safe Browsing data from Google. 
(Admittedly this one is probably only behind a European CDN, but maybe 
Google is having a bad day, or maybe IP address logs are sent to the 
US.) Oh yeah, it also displays news from Pocket. Probably it does more 
connections to the US that I don't know about.
* You switch to Financial Mode in Calculator, it downloads exchange 
rate data.

* Anything crashes. A truncated stack trace gets sent to Fedora.

I'm sure my list is missing quite a lot. If your interpretation is 
correct, then I suppose German companies should immediately discontinue 
use of Fedora, and also most other computer operating systems


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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Marius Schwarz]

Am 01.10.20 um 19:36 schrieb Simo Sorce:
> That said,
> if it really is an internal DNS and there are strong policies around it
> I assume that the perimeter or the local machine firewall will be
> configured to block UDP packets to port 53 to any other external
> servers ...
>
> This leaves out only some machines or some cases where a
> misconfiguration may cause this fallback to kick in. The occurrence is
> probably rare enough not to be a problem in practice at least from the
> pov of GDPR.
you know, that you contradict yourself here? :)

If the corp has blocked port 53 except for the internal dns server, how
should the fallback packet get out?

I think, it's not important how often the default is used, it's the fact
that it's hidden and therefor surprising for the corp itself,
which makes it even more risky to run the os, than it's worth giving (
or in your example not to give ) the 0.1% a fallback answere.

IRL admins who know about it, as we all do now, we can avoid the
problem. But for a company, which has to justify the surprising result
of a DP audit, it will not be an easy talk with the dp buero. Just for
the lols, I will ask our highest federal dp advocate tomorrow, what he
thinks about this.

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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal:?? systemd-resolved

[Marius Schwarz]

Am 01.10.20 um 16:36 schrieb Alexander Bokovoy:
>
> You can also drop a configuration snippet in
> /etc/systemd/resolved.conf.d/ to contain
>
>   FallbackDNS=
>
> This will disable global DNS servers for any case.
>
if that would be the default, it would be ok.

Am 01.10.20 um 16:03 schrieb Michael Catanzaro:
> We are not going to patch out fallback to Cloudflare or Google because
> it is a non-issue. Fallback only happens when you have zero other DNS
> servers configured. When was the last time you connected to a network
> and there's no DHCP, no nothing? The number of users without some
> other working DNS is probably under 0.1%.

BTW: thumbs up for the DOT proposal.

I will make it very clear and easy:  

O== Situation for Germany

GDPR is in place as a EU LAW. The protection rules are only active for
companies or organizations, not for private people.

2013 a german court (Kammergericht Berlin) ruled, that IP addresses are
Personal Data. It has never been overruled.

Personal Data can only be send to none eu countries and corporations, if
there is a data protection law in place that has the same or better
level of protection as the eu law has ( or if it's necessary to buy
stuff (a house, car, whatever ). The pact the EU did with the US was
called Privacy Shield. It imploded (for the second time) a few months
ago. From the moment the eu court rule was public, transfer of personal
data into the us was illegal.

If you send a DNS REQUEST to a US DNS server from within a company
network, and with ipv6 the internal ip is sent out i learned lately, you
have sent personal data which is protected under the GDRP. It's not
unlikely to use company pcs for private webvisits while having a meal
break.

Therefor, a os that has google and cloudflare as a default, even if it's
unlikely to happen as you point out, which sends out dns with personal
data in it to a us dns server, brings the company in great trouble with
the law. In the end, this means, you as a company/org need to pay a
(possibly) shitload of money as a fine and therefor they can't use this
os anymore. (someone else on the list pointed this out too.) The
consequence is, Fedora is a juristic risk. [The fine is higher, if you
as corp/org did not document this data transfer in your data protection
memos] Of course a working dns setup will prevent this problem, but
thats not the point. Activists in germany and other countries try to get
more and more gov projects to OSS due to privacy issues with M$. It
would be a shame if Fedora would also count as a potential problem.

Do we all really want this, for the benefit on 0.1%(as you say) have a
dns lookup instead of a hint, that their systems are broken?

Pls remember: I'm just the messenger, Í didn't write the laws ;)

Funfact: last time I checked the northern germany police pc in my city,
they used a fedora based desktop system. I like that fact :D But i'm
pretty sure, they don't like a cloudflare fallback dns once they reach
F33 ( if ever ).



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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal:?? systemd-resolved

[Zbigniew Jędrzejewski-Szmek]

On Wed, Sep 30, 2020 at 11:50:00AM -0500, Michael Catanzaro wrote:
> On Wed, Sep 30, 2020 at 6:43 pm, Dominik 'Rathann' Mierzejewski
>  wrote:
> >What if I'm using NetworkManager and dnssec-trigger? This has been
> >working very well for me for the last couple of releases and I'd hate
> >to be forced to manually reconfigure things so that it starts working
> >again.
> 
> The upgrade process is designed to do the right thing for users who
> stick with our defaults. Manual intervention is required for unusual
> cases like this. You'll need to manually disable systemd-resolved
> after upgrade, restore /etc/resolv.conf from the backup file that
> will be created during upgrade, and restart NetworkManager. That
> would look something like:
> 
> # systemctl disable systemd-resolved.service
> # systmectl stop systemd-resolved.service
> # mv /etc/resolv.conf.orig-with-nm /etc/resolv.conf
> # systemctl restart NetworkManager.service

After the latest updates, this should not necessary (though it will still work).
Instead, specify a preset (before the upgrade):

 sudo bash -c 'mkdir -p /etc/systemd/system-preset && echo "disable 
systemd-resolved.service" 
>/etc/systemd/system-preset/20-systemd-resolved-disable.preset'

This is also described in
https://fedoraproject.org/wiki/Changes/systemd-resolved#Fully_opting_out_of_systemd-resolved_use

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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Simo Sorce]

On Thu, 2020-10-01 at 09:03 -0500, Michael Catanzaro wrote:
> On Thu, Oct 1, 2020 at 3:32 pm, Marius Schwarz  
> wrote:
> > I think, he meant the systemd-resolved fiallback to Cloudflare and
> > Google. Is that in the fedora build? If so, i suggest to patch it out.
> > That will fix the issue for me in perspective of the GDPR.
> 
> Unless you explain this *very* clearly, I'm going to ignore it, because 
> it seems farfetched. Fedora is not operating its own DNS server or 
> collecting any sort of DNS-related data from you.
> 
> We are not going to patch out fallback to Cloudflare or Google because 
> it is a non-issue. Fallback only happens when you have zero other DNS 
> servers configured. When was the last time you connected to a network 
> and there's no DHCP, no nothing? The number of users without some other 
> working DNS is probably under 0.1%. Even then, I think you also have to 
> disable NetworkManager for systemd-resolved to ever use its fallback 
> DNS, because NetworkManager will configure a ~. DNS domain, causing 
> systemd-resolved to never use its global DNS settings. (I think. That's 
> my reading of the manpage. Testing welcome from anyone who wants to 
> confirm that.)
> 
> So (if I'm right) we are talking about the exceeding rare combination 
> of (a) no DNS set by DHCP, and also (b) user manually disabled 
> NetworkManager. If you're really going to do (b) you will probably also 
> disable systemd-resolved, right? Or make the one-line config file 
> change to remove the fallback DNS? Or just manually set some DNS 
> server? Seriously, this is a silly thing to worry about.
> 
> Finally, in the extremely unlikely event you do somehow wind up with 
> Cloudflare and Google DNS, then you should *celebrate*, because they 
> have extremely strong privacy policies for their DNS. Unless you think 
> they are just lying about their data collection practices -- which they 
> are not -- you have nothing to worry about from their DNS [1][2]. In 
> contrast, your ISP is probably selling your DNS queries to advertisers. 
> If you disagree, doesn't matter, because you're probably never going to 
> see this fallback.

Michael,
I think the issue here is not Google DNS vs ISP DNS, but internal DNS
vs spilling it out to Google/Cloudflare.

That said,
if it really is an internal DNS and there are strong policies around it
I assume that the perimeter or the local machine firewall will be
configured to block UDP packets to port 53 to any other external
servers ...

This leaves out only some machines or some cases where a
misconfiguration may cause this fallback to kick in. The occurrence is
probably rare enough not to be a problem in practice at least from the
pov of GDPR.

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



___
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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal:?? systemd-resolved

[Alexander Bokovoy]

On to, 01 loka 2020, Michael Catanzaro wrote:
On Thu, Oct 1, 2020 at 3:32 pm, Marius Schwarz 
 wrote:

I think, he meant the systemd-resolved fiallback to Cloudflare and
Google. Is that in the fedora build? If so, i suggest to patch it out.
That will fix the issue for me in perspective of the GDPR.


Unless you explain this *very* clearly, I'm going to ignore it, 
because it seems farfetched. Fedora is not operating its own DNS 
server or collecting any sort of DNS-related data from you.


We are not going to patch out fallback to Cloudflare or Google because 
it is a non-issue. Fallback only happens when you have zero other DNS 
servers configured. When was the last time you connected to a network 
and there's no DHCP, no nothing? The number of users without some 
other working DNS is probably under 0.1%. Even then, I think you also 
have to disable NetworkManager for systemd-resolved to ever use its 
fallback DNS, because NetworkManager will configure a ~. DNS domain, 
causing systemd-resolved to never use its global DNS settings. (I 
think. That's my reading of the manpage. Testing welcome from anyone 
who wants to confirm that.)


We use the drop-in snippet configuration file in
/etc/systemd/resolved.conf.d/zzz-ipa.conf to configure this behavior on
IPA servers which deploy integrated DNS server. It works, so there is a
confirmation.

So (if I'm right) we are talking about the exceeding rare combination 
of (a) no DNS set by DHCP, and also (b) user manually disabled 
NetworkManager. If you're really going to do (b) you will probably 
also disable systemd-resolved, right? Or make the one-line config file 
change to remove the fallback DNS? Or just manually set some DNS 
server? Seriously, this is a silly thing to worry about.


You can also drop a configuration snippet in
/etc/systemd/resolved.conf.d/ to contain

  FallbackDNS=

This will disable global DNS servers for any case.

--
/ 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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Michael Catanzaro]

On Thu, Oct 1, 2020 at 3:32 pm, Marius Schwarz  
wrote:

I think, he meant the systemd-resolved fiallback to Cloudflare and
Google. Is that in the fedora build? If so, i suggest to patch it out.
That will fix the issue for me in perspective of the GDPR.


Unless you explain this *very* clearly, I'm going to ignore it, because 
it seems farfetched. Fedora is not operating its own DNS server or 
collecting any sort of DNS-related data from you.


We are not going to patch out fallback to Cloudflare or Google because 
it is a non-issue. Fallback only happens when you have zero other DNS 
servers configured. When was the last time you connected to a network 
and there's no DHCP, no nothing? The number of users without some other 
working DNS is probably under 0.1%. Even then, I think you also have to 
disable NetworkManager for systemd-resolved to ever use its fallback 
DNS, because NetworkManager will configure a ~. DNS domain, causing 
systemd-resolved to never use its global DNS settings. (I think. That's 
my reading of the manpage. Testing welcome from anyone who wants to 
confirm that.)


So (if I'm right) we are talking about the exceeding rare combination 
of (a) no DNS set by DHCP, and also (b) user manually disabled 
NetworkManager. If you're really going to do (b) you will probably also 
disable systemd-resolved, right? Or make the one-line config file 
change to remove the fallback DNS? Or just manually set some DNS 
server? Seriously, this is a silly thing to worry about.


Finally, in the extremely unlikely event you do somehow wind up with 
Cloudflare and Google DNS, then you should *celebrate*, because they 
have extremely strong privacy policies for their DNS. Unless you think 
they are just lying about their data collection practices -- which they 
are not -- you have nothing to worry about from their DNS [1][2]. In 
contrast, your ISP is probably selling your DNS queries to advertisers. 
If you disagree, doesn't matter, because you're probably never going to 
see this fallback.


Michael

[1] https://developers.google.com/speed/public-dns/privacy
[2] 
https://developers.cloudflare.com/1.1.1.1/privacy/public-dns-resolver/


___
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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Marius Schwarz]

Am 30.09.20 um 17:13 schrieb Michael Catanzaro:
>
> On Wed, Sep 30, 2020 at 3:14 pm, Graham Leggett  wrote:
>> Regulations like the GDPR exist, and ignorance of them is not a defence.
>>
>> I am required by these regulations and many other regulations in
>> multiple jurisdictions to make sure my users comply. If you have gone
>> out of your way to break secure operation on Fedora, we will have to
>> ban the use of Fedora by our users. I do not want to do that.
>>
>> As I said, this is not a technical discussion. You need to defer this
>> to compliance people, who I predict will simply tell you “comply”.
>
> Sorry, but I have not the faintest clue how your comment is relevant
> to this discussion regarding systemd-resolved.

I think, he meant the systemd-resolved fiallback to Cloudflare and
Google. Is that in the fedora build? If so, i suggest to patch it out.
That will fix the issue for me in perspective of the GDPR.

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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Vít Ondruch]

Dne 01. 10. 20 v 0:10 Michael Catanzaro napsal(a):
> On Wed, Sep 30, 2020 at 11:49 pm, Björn Persson
>  wrote:
>> So there's no need to revert any changes to /etc/nsswitch.conf? I've
>> seen some discussion about that file in relation to systemd-resolved.
>> It seemed far from easy to understand how to make it work correctly.
>
> You don't have to touch /etc/nsswitch.conf because it's designed to
> work with or without systemd-resolved running: resolve
> [!UNAVAIL=return]. If it's not running it will fall back to
> nss-myhostname and then nss-dns.
>
> WARNING: Do not make manual changes to /etc/nsswitch.conf! Remember to
> edit /etc/authselect/user-sswitch.conf instead, then run 'sudo
> authselect apply-changes'


I would appreciate if somebody took care about authselect tickets:


https://bugzilla.redhat.com/show_bug.cgi?id=1878752


The file you have referenced apparently lives in vacuum. You refer to
it, but nobody owns it.


Vít

___
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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[John M. Harris Jr]

On Tuesday, September 29, 2020 9:36:38 AM MST Dan Williams wrote:
> On Tue, 2020-09-29 at 09:18 -0700, John M. Harris Jr wrote:
> 
> > On Tuesday, September 29, 2020 5:13:48 AM MST Zbigniew Jędrzejewski-
> > Szmek 
> > wrote:
> > 
> > > On Mon, Sep 28, 2020 at 11:41:12PM -0700, John M. Harris Jr wrote:
> > > 
> > > 
> > > > On Monday, September 28, 2020 9:39:17 AM MST Michael Catanzaro
> > > > wrote:
> > > > 
> > > > 
> > > > > You can do this, but again, you need to use the command line.
> > > > > E.g. 
> > > > > 'resolvectl dns tun0 8.8.8.8'
> > > > > 
> > > > > We're actually no longer debating how systemd-resolved works;
> > > > > rather, 
> > > > > we're now debating how NetworkManager chooses to configure 
> > > > > systemd-resolved. systemd-resolved just does what it's told to
> > > > > do. It's
> > > > > 
> > > > > actually NetworkManager that decides to split DNS according to
> > > > > routing 
> > > > > by default as a matter of policy. It could do otherwise if it
> > > > > wanted 
> > > > > to, but I think this is a good default. Nothing stops you from
> > > > > changing
> > > > > 
> > > > > it though. :)
> > > > 
> > > > 
> > > > Michael,
> > > > By what mechanism does NetworkManager "split DNS according to
> > > > routing"? If
> > > > it  hasn't already made a request from both your cleartext and
> > > > your VPN
> > > > connection's DNS servers, it has no way of knowing what network
> > > > should be
> > > > used to get the right results. Routing and DNS are unrelated.
> > > 
> > > 
> > > NetworkManager pushes DNS server configuration (and associated bits
> > > like
> > > domain search and routing domains) over dbus to resolved. That way
> > > it
> > > "[tells resolved how to] split DNS according to routing". Of
> > > course, after
> > > the name has been resolved to an IP address, the packets to that IP
> > > address
> > > are routed too. So there is "routing" in the sense of deciding
> > > which
> > > interface is appropriate for a given DNS name and "routing" in the
> > > sense of
> > > deciding which interface is appropriate for a given IP address.
> > 
> > 
> > It seems that the terminology is fairly confusing, considering it's
> > right 
> > alongside actual routing configuration.. Okay, so "routing" means
> > something 
> > wildly different than you'd think with systemd-resolved, got it.
> > 
> > In most cases, in order to get to a DNS server inside a VPN, your
> > packets have 
> > to have a route which can reach the IP of that server for that
> > interface, 
> > which is configured using NetworkManager (or a VPN config file,
> > imported into 
> > NM). Anyone that understands basic networking will likely be confused
> > by this 
> > terminology.
> > 
> > That aside, where in NetworkManager do these "routing domains" get
> > specified?
> 
> 
> In the connection itself (GUI or CLI), or they come from DHCP or SLAAC
> or the VPN.
> 
> nmcli con mod rh-openvpn ipv4.dns-search "foobar.com"
> nmcli con mod rh-openvpn ipv4.never-default true
> 
> combined with having a local caching DNS server (or resolved) enabled
> will route queries for those search domains only to the VPN-provided
> DNS servers.
> 
> There are corresponding GUI boxes for these in nm-connection-editor,
> GNOME network settings, and KDE.

Dan,

This would require a list of search domains a mile long, and for the end user 
to know what needs to go over the VPN anyway. Additionally, this may well 
break scripts that expect a given short name complication, but end up getting 
it from a different domain, since they're all in search domains now.

-- 
John M. Harris, Jr.

___
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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Michael Catanzaro]

On Wed, Sep 30, 2020 at 11:49 pm, Björn Persson 
 wrote:

So there's no need to revert any changes to /etc/nsswitch.conf? I've
seen some discussion about that file in relation to systemd-resolved.
It seemed far from easy to understand how to make it work correctly.


You don't have to touch /etc/nsswitch.conf because it's designed to 
work with or without systemd-resolved running: resolve 
[!UNAVAIL=return]. If it's not running it will fall back to 
nss-myhostname and then nss-dns.


WARNING: Do not make manual changes to /etc/nsswitch.conf! Remember to 
edit /etc/authselect/user-sswitch.conf instead, then run 'sudo 
authselect apply-changes'


___
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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Björn Persson]

Michael Catanzaro wrote:
> On Wed, Sep 30, 2020 at 6:43 pm, Dominik 'Rathann' Mierzejewski 
>  wrote:
> > What if I'm using NetworkManager and dnssec-trigger? This has been
> > working very well for me for the last couple of releases and I'd hate
> > to be forced to manually reconfigure things so that it starts working
> > again.  
> 
> The upgrade process is designed to do the right thing for users who 
> stick with our defaults. Manual intervention is required for unusual 
> cases like this. You'll need to manually disable systemd-resolved after 
> upgrade, restore /etc/resolv.conf from the backup file that will be 
> created during upgrade, and restart NetworkManager. That would look 
> something like:
> 
> # systemctl disable systemd-resolved.service
> # systmectl stop systemd-resolved.service
> # mv /etc/resolv.conf.orig-with-nm /etc/resolv.conf
> # systemctl restart NetworkManager.service

So there's no need to revert any changes to /etc/nsswitch.conf? I've
seen some discussion about that file in relation to systemd-resolved.
It seemed far from easy to understand how to make it work correctly.

Björn Persson


pgp5_2mAhEYOs.pgp
Description: OpenPGP digital signatur
___
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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Michael Catanzaro]

On Wed, Sep 30, 2020 at 9:58 pm, Petr Menšík  
wrote:

Shouldn't it change resolv.conf only in case NM is active AND
resolv.conf is generated by Network Manager?


Correct, that's indeed what it does. (Since Zbigniew changed it 
yesterday. Previously, it did not check if NM is active.)


The systemd RPM scriplet will run sed, sed will see "Generated by 
dnssec-trigger-script" and say "that's not "Generated by 
NetworkManager" and it will leave your resolv.conf alone. So you're 
right, you don't need to worry about resolv.conf.


Even if it did try to remove the immutable /etc/resolv.conf, the 
upgrade script ignores failures, so you would see an error message in 
the middle of the transaction about rm failing but it wouldn't fail the 
whole upgrade.


It *will* still 'systemctl enable systemd-resolved.service', though, so 
you'll still need to disable that or you'll indeed have a battle for 
port 53. It will indeed probably break any local resolver you have 
configured.


___
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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Petr Menšík]

On 9/30/20 7:11 PM, Michael Catanzaro wrote:
> On Wed, Sep 30, 2020 at 9:54 am, PGNet Dev  wrote:
>> So the upgrade WILL ignore current F32 state -- systemd-resolved
>> DISABLED + 'my' /etc/resolv.conf -- and enable + overwrite
>> (respectively) each, regardless of whether we're _using_
>> NetworkManager (afaict it's impossible to completely remove all NM*
>> cruft)?
> 
> It only touches your /etc/resolv.conf if you are using NetworkManager,
> but I think it enables systemd-resolved regardless. You'll have to
> disable it if you don't want it.

Shouldn't it change resolv.conf only in case NM is active AND
resolv.conf is generated by Network Manager?

resolv.conf with dnssec-trigger is generated anyway, there is little
need to backup it. It looks like:

# Generated by dnssec-trigger-script
nameserver 127.0.0.1

I haven't tested upgrade to f33 yet. dnssec-trigger also tries protect
resolv.conf for overwriting by chattr +i /etc/resolv.conf. I think it
would break upgrade if change was attempted by systemd.

Also, it would battle for port 53 for anyone having already local
resolver. It would just fail to start, if user enabled listening on any
address. Which is now unfortunately default for dnsmasq. It might be a
little random, which one would win on machine start. I guess
systemd-resolved would win, because unlike named(bind) or unbound, it
has before nss-lookup.target and network.target. Normal dns services
start After=network.target.

Fortunately, it would not conflict with resolvers listening on localhost
only, because it listens on different IP address. But it is before dns
in nsswitch.conf, so every query would be done before "proper" dns
resolvers. I don't this that is correct, when resolved has serious
limitations in security.

I expect it would break any local resolver configured, unless it can
detect existing resolver and avoid activation of systemd-resolved.

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB



signature.asc
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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Michael Catanzaro]

On Wed, Sep 30, 2020 at 9:54 am, PGNet Dev  wrote:
So the upgrade WILL ignore current F32 state -- systemd-resolved 
DISABLED + 'my' /etc/resolv.conf -- and enable + overwrite 
(respectively) each, regardless of whether we're _using_ 
NetworkManager (afaict it's impossible to completely remove all NM* 
cruft)?


It only touches your /etc/resolv.conf if you are using NetworkManager, 
but I think it enables systemd-resolved regardless. You'll have to 
disable it if you don't want it.


___
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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[PGNet Dev]

On 9/30/20 9:50 AM, Michael Catanzaro wrote:
> You'll need to manually disable systemd-resolved after upgrade, restore 
> /etc/resolv.conf from the backup file that will be created during upgrade
So the upgrade WILL ignore current F32 state -- systemd-resolved DISABLED + 
'my' /etc/resolv.conf -- and enable + overwrite (respectively) each, regardless 
of whether we're _using_ NetworkManager (afaict it's impossible to completely 
remove all NM* cruft)?
___
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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Michael Catanzaro]

On Wed, Sep 30, 2020 at 6:43 pm, Dominik 'Rathann' Mierzejewski 
 wrote:

What if I'm using NetworkManager and dnssec-trigger? This has been
working very well for me for the last couple of releases and I'd hate
to be forced to manually reconfigure things so that it starts working
again.


The upgrade process is designed to do the right thing for users who 
stick with our defaults. Manual intervention is required for unusual 
cases like this. You'll need to manually disable systemd-resolved after 
upgrade, restore /etc/resolv.conf from the backup file that will be 
created during upgrade, and restart NetworkManager. That would look 
something like:


# systemctl disable systemd-resolved.service
# systmectl stop systemd-resolved.service
# mv /etc/resolv.conf.orig-with-nm /etc/resolv.conf
# systemctl restart NetworkManager.service

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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Dominik 'Rathann' Mierzejewski]

On Wednesday, 30 September 2020 at 18:16, Neal Gompa wrote:
[...]
> If you're not using NetworkManager, this change has _zero_ impact.

What if I'm using NetworkManager and dnssec-trigger? This has been
working very well for me for the last couple of releases and I'd hate
to be forced to manually reconfigure things so that it starts working
again.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[PGNet Dev]

On 9/30/20 9:16 AM, Neal Gompa wrote:
> If you're not using NetworkManager, this change has _zero_ impact.

perfect.

clearly, i've missed or lost the obviousness of that incredibly useful tidbit 
in this novella :-/

thx!
___
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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Neal Gompa]

On Wed, Sep 30, 2020 at 12:15 PM PGNet Dev  wrote:
>
> Reading along, it's _at_best_ unclear what the eventual 'resolution' of this^ 
> is.
>
> What _is_ clear is that there's significant disagreement -- which, 
> unfortunately, has at times here become nasty & personal -- about needed vs 
> planned functionality, and, of late, regulatory compliance.
>
> And, iiuc, though obviously very much up in the air, this is all relevant to 
> F33 release, coming in weeks?
>
> Can someone please clarify, ideally with some level of certainty:
>
> If we've F32 systems in place, that do NOT use systemd-resolved &/or 
> NetworkManager, but rather our own/preferred DNS client implementations with 
> systemd-networkd,
>
> will a system *upgrade*, from F32 to F33, force/require any changes to those 
> configurations?  or will systems be left as-is, and we can expect 
> uninterrupted functionality?
>
> which of these proposed systemd-resolved system-wide changes are NON-optional 
> in _usage_?  can they _all_ be turned-off/disabled?
>
> bottom-line -- how much system breakage of existing infrastructure, if any, 
> should we be planning for with a F32 -> F33 upgrade path?

If you're not using NetworkManager, this change has _zero_ impact.


-- 
真実はいつも一つ！/ 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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[PGNet Dev]

Reading along, it's _at_best_ unclear what the eventual 'resolution' of this^ 
is.

What _is_ clear is that there's significant disagreement -- which, 
unfortunately, has at times here become nasty & personal -- about needed vs 
planned functionality, and, of late, regulatory compliance.

And, iiuc, though obviously very much up in the air, this is all relevant to 
F33 release, coming in weeks?

Can someone please clarify, ideally with some level of certainty:

If we've F32 systems in place, that do NOT use systemd-resolved &/or 
NetworkManager, but rather our own/preferred DNS client implementations with 
systemd-networkd,

will a system *upgrade*, from F32 to F33, force/require any changes to those 
configurations?  or will systems be left as-is, and we can expect uninterrupted 
functionality?

which of these proposed systemd-resolved system-wide changes are NON-optional 
in _usage_?  can they _all_ be turned-off/disabled?

bottom-line -- how much system breakage of existing infrastructure, if any, 
should we be planning for with a F32 -> F33 upgrade path?
___
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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Michael Catanzaro]

On Wed, Sep 30, 2020 at 10:05 am, Gerd Hoffmann  
wrote:

Sorry, but that is not correct.

NetworkManager can handle split-dns just fine, by using dnsmasq and
reconfiguring it via dbus when vpn connections come and go.  I can
easily add more servers + zones by dropping a config file snippet into
the /etc/NetworkManager/dnsmasq.d/ directory, for example to resolve 
the

hostnames for my kvm guests on the libvirt network.

That works for ages on my RHEL-7 workstation where systemd-resolved
doesn't even exist ...


We actually considered dnsmasq, but NetworkManager developers 
recommended systemd-resolved. See: 
https://pagure.io/fedora-workstation/issue/123#comment-621603


I agree dnsmasq would have been a lot better than the status quo prior 
to F33. We would probably have used that if systemd-resolved didn't 
exist. If we could have a do-over, we should have started using it long 
ago.



 So sending the requests to all available DNS servers in absence of
 better routing info is a great enabler:


I fail to see why sending queries to all servers is a good plan.  The
redhat vpn dns servers surely can't resolve the hostnames for my local
lan, and frankly they shouldn't even know which hosts I try to access.
Likewise my ISP shouldn't know which non-public RH servers I try to
access.


I've tried to stop this line of discussion a bit earlier, since it's 
based on a misunderstanding of how NetworkManager uses 
systemd-resolved. I agree we should prioritize avoiding DNS leaks, and 
that's actually the primary motivating factor for the switch to 
systemd-resolved (you can see how much more attention I devote to this 
topic in the change proposal compared to the other benefits of 
systemd-resolved). NetworkManager will not configure systmed-resolved 
to send queries all over the place. We need a local resolver 
(systemd-resolved, dnsmasq, etc.) to ensure DNS queries go where users 
expect; it's not something we can do with traditional resolv.conf 
managed by NetworkManager.


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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Michael Catanzaro]

On Wed, Sep 30, 2020 at 3:14 pm, Graham Leggett  
wrote:
Regulations like the GDPR exist, and ignorance of them is not a 
defence.


I am required by these regulations and many other regulations in 
multiple jurisdictions to make sure my users comply. If you have gone 
out of your way to break secure operation on Fedora, we will have to 
ban the use of Fedora by our users. I do not want to do that.


As I said, this is not a technical discussion. You need to defer this 
to compliance people, who I predict will simply tell you “comply”.


Sorry, but I have not the faintest clue how your comment is relevant to 
this discussion regarding systemd-resolved.


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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Solomon Peachy]

On Wed, Sep 30, 2020 at 03:14:10PM +0200, Graham Leggett wrote:
> I am required by these regulations and many other regulations in 
> multiple jurisdictions to make sure my users comply. If you have gone 
> out of your way to break secure operation on Fedora, we will have to 
> ban the use of Fedora by our users. I do not want to do that.

Then don't ban them, and do your job instead?

The fact of the matter is that using out-of-the-box Fedora 
configurations *today* can leak "private" DNS queries, and if VPNs are 
in use, it is a virtual certainty.

To make Fedora "Compliant" using your definition, one already has to 
adjust the system configuration.  This new approach, at worst, requires 
a slightly different configuration change to achieve the same results.

> As I said, this is not a technical discussion. You need to defer this 
> to compliance people, who I predict will simply tell you “comply”.

My $dayjob is headquartered in Europe and is in a _highly_ regulated, 
risk-adverse industry, with compliance officers coming out of the 
woodwork.  Suffice it to say that what it means to "Comply" is highly 
context-sensitive.

But you are correct, this is not a problem that can be solved via 
technical means -- Many legitimate use cases have diametrically-opposed 
needs, and there is no way for Fedora to know out-of-the-box which use 
case should apply as the general default.  Moreover, at the granularity 
of specific DNS lookups, the general default can easily be wrong.

 - Solomon
-- 
Solomon Peachypizza at shaftnet dot org (email)
  @pizza:shaftnet dot org   (matrix)
High Springs, FL  speachy (freenode)


signature.asc
Description: PGP 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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Graham Leggett]

On 29 Sep 2020, at 23:44, Michael Catanzaro  wrote:

> This is either a very strange misunderstanding, or trolling. I will assume 
> positive intent. Internet RFCs are not regulatory requirements. If you're 
> aware of some government regulation that requires us to forward RRSEC 
> records, I would be very surprised, but please do let us know.

Regulations like the GDPR exist, and ignorance of them is not a defence.

I am required by these regulations and many other regulations in multiple 
jurisdictions to make sure my users comply. If you have gone out of your way to 
break secure operation on Fedora, we will have to ban the use of Fedora by our 
users. I do not want to do that.

As I said, this is not a technical discussion. You need to defer this to 
compliance people, who I predict will simply tell you “comply”.

Regards,
Graham
—
___
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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Björn Persson]

Neal Gompa wrote:
> On Tue, Sep 29, 2020 at 7:48 AM Björn Persson  wrote:
> >
> > Lennart Poettering wrote:  
> > > On Mo, 28.09.20 22:54, Björn Persson (Bjorn@rombobjörn.se) wrote:
> > >  
> > > > It can work in company-scope if the company has competent network
> > > > admins. My local DNS server at home resolves local hostnames to private
> > > > IPv4 addresses in the 192.168/16 block. Clients on the Internet see
> > > > another view. Both views are DNSsec-signed, and validation works fine.
> > > > There's no reason why this setup wouldn't work on a corporate network.
> > > > The key is to use a domain that is actually registered to the company,
> > > > not some made-up TLD like "internal" or whatever the incompetent
> > > > network admins come up with.  
> > >
> > > You never take your laptop outside to a cafe or so? You never
> > > connected it to something that is not your home or office network?  
> >
> > A cafe is company-scope? I'm not sure whether that counts as moving the
> > goalposts or changing the subject, but neither is a constructive way to
> > discuss a technical topic.
> 
> If you're a remote employee, it absolutely is. And especially in this
> pandemic, this kind of thing is now the *default* experience.

So we're assuming that we have successfully connected to the company
VPN, as the company-scope DNS isn't involved unless we have access to
the company network. The cafe's network may be crappy, but evidently not
so bad that our VPN can't work. Now, how exactly does the cafe prevent
us from sending queries with the DO bit set through the VPN tunnel to
the company-scope DNS server and receiving security records in the
response?

Lennart claimed that "propagating DO stuff as is cannot work for [...]
company-scope DNS". I'm saying that claim is false. If you can't use
the cafe scenario to prove me wrong, then the cafe is irrelevant. To
have a constructive technical discussion it is necessary to keep
separate issues separate.

Björn Persson


pgpvq986NjQ8p.pgp
Description: OpenPGP digital signatur
___
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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Marius Schwarz]

Am 30.09.20 um 10:05 schrieb Gerd Hoffmann:
>> So sending the requests to all available DNS servers in absence of
>> better routing info is a great enabler:
> I fail to see why sending queries to all servers is a good plan.  The
> redhat vpn dns servers surely can't resolve the hostnames for my local
> lan, and frankly they shouldn't even know which hosts I try to access.
> Likewise my ISP shouldn't know which non-public RH servers I try to
> access.
>
Your absolutly right, the described scenario would be a privacy and
security nightmare.

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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Gerd Hoffmann]

  Hi,

> For example, if I have my laptop in my home wifi, connected to RH VPN,
> then there are some names resolvable only via the local
> DNS. Specifically: my router's, my printer's and my NAS' address. And
> there are other names only resolvable via RH VPN. systemd-resolved for
> the first time gives me a chance for this to just work: it will send
> requests to both the RH DNS servers and the local ones, and uses the
> first successful reply, or the last failed reply. And that's quite
> frankly awesome, because that *never* worked before.

Sorry, but that is not correct.

NetworkManager can handle split-dns just fine, by using dnsmasq and
reconfiguring it via dbus when vpn connections come and go.  I can
easily add more servers + zones by dropping a config file snippet into
the /etc/NetworkManager/dnsmasq.d/ directory, for example to resolve the
hostnames for my kvm guests on the libvirt network.

That works for ages on my RHEL-7 workstation where systemd-resolved
doesn't even exist ...

> So sending the requests to all available DNS servers in absence of
> better routing info is a great enabler:

I fail to see why sending queries to all servers is a good plan.  The
redhat vpn dns servers surely can't resolve the hostnames for my local
lan, and frankly they shouldn't even know which hosts I try to access.
Likewise my ISP shouldn't know which non-public RH servers I try to
access.

> Key, take-away here:
> 
> 1. Ideally we'd just route company DNS traffic to VPN, and everything
>else to local LAN DNS. But that requires explicit routing info to
>be configured, we cannot auto-detect this info (beyond some minor
>inference from the search domains)

Well, if auto-detect doesn't work we should (a) fix the vpn
protocols/implementations and (b) fallback to manually configuring
things until this is done.

>VPN use, then sending to everything in parallel and taking the
>first positive reply and the last negative one is the best chance
>to make things "just work".

At the expense of leaking information, which I don't consider a good
trade-off.

take care,
  Gerd
___
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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Gordon Messmer]

On 9/29/20 9:18 AM, Lennart Poettering wrote:

So let me ExecSum what I wrote here. For systemd-resolved to become
a high quality DNS solution:

1) Remove custom DNS/DNSSEC resolving code and use a well maintained
DNS library.

"Custom" is in the eye of the beholder. It appears to me you mean that
in a derogatory way. I mean, given that Ubuntu has been enabling
systemd-resolved since quite some time by default I have the suspicion
our codebase is more often deployed IRL than the ones you listed?



Ubuntu enables it by default, but we don't know how many people use it.  
My employer does not.  Our AD domain has a LOT of controllers, due to a 
large number of offices around the world. systemd-resolved couldn't 
handle resolving the A record for our domain, so we had to turn it off.


I believe that was fixed in PR 11993, but that bug was enough to 
convince me very solidly that systemd-resolved should have re-used an 
existing protocol implementation rather than writing another one.


You're right that DNS has of quirks and compatibility issues, and that's 
exactly why writing another protocol implementation is such a poor decision.

___
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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Simo Sorce]

On Tue, 2020-09-29 at 17:50 -0400, Neal Gompa wrote:
> On Tue, Sep 29, 2020 at 5:44 PM Michael Catanzaro  
> wrote:
> > On Tue, Sep 29, 2020 at 11:33 pm, Graham Leggett 
> > wrote:
> > > To step in here, regulatory compliance is a non optional requirement
> > > around the world.
> > > 
> > > Regulatory compliance applies to everybody in a jurisdiction, there
> > > is no such thing as a “specialized deployment” or environments
> > > where it “will not matter”. Compliance doesn’t care about an
> > > arbitrary freeze.
> > > 
> > > This is not a technical decision.
> > 
> > This is either a very strange misunderstanding, or trolling. I will
> > assume positive intent. Internet RFCs are not regulatory requirements.
> > If you're aware of some government regulation that requires us to
> > forward RRSEC records, I would be very surprised, but please do let us
> > know.
> > 
> 
> Also, in case folks weren't aware, IETF RFCs are *intentionally* not
> described as standards. They are designed to be subject to revision at
> more or less any time. That's why they are titled as a "Request for
> Comments" (or RFC). The fact that they are used as standards
> documentation is sort of the nature of how things developed from an
> era where it was impossible to publish standards for free
> (organizations like the ISO require paying money for standards
> documentation).

Sorry Neal, but this is not correct, in IETF there are several RFC
types:
- standard
- informational
- experimental
- best current practice
etc..

There are *definitely* officially defined by IETF "Standard" RFC, but
not all RFC are standard for sure.

> But this also has the consequence that IETF RFCs do not have a
> requirement to be evaluated in the context of others and determined to
> be fully satisfiable along others. That is, it's possible to have
> mutually exclusive RFCs for a system that you have to implement.

This is true, but much less so for standard RFCs.

> So please keep that in mind when considering discussing DNS.

Always use a grain of salt with *any* standards, even ISO standards are
often made by mandatory and optional parts, and sometimes they are
conflicting too ... and then there are standards from different
organizations that may be in partial conflict as well, welcome to the
world :-)

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



___
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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Marius Schwarz]

Am 29.09.20 um 14:38 schrieb Neal Gompa:
> If you're a remote employee, it absolutely is. And especially in this
> pandemic, this kind of thing is now the *default* experience.

Company network - check
Fedora 31 Laptops - check
VPN users - check
Androids - check
Windows Laptops - check
internal dns - check
private domains - check

Not every company network is complicated.

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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Neal Gompa]

On Tue, Sep 29, 2020 at 5:44 PM Michael Catanzaro  wrote:
>
> On Tue, Sep 29, 2020 at 11:33 pm, Graham Leggett 
> wrote:
> > To step in here, regulatory compliance is a non optional requirement
> > around the world.
> >
> > Regulatory compliance applies to everybody in a jurisdiction, there
> > is no such thing as a “specialized deployment” or environments
> > where it “will not matter”. Compliance doesn’t care about an
> > arbitrary freeze.
> >
> > This is not a technical decision.
>
> This is either a very strange misunderstanding, or trolling. I will
> assume positive intent. Internet RFCs are not regulatory requirements.
> If you're aware of some government regulation that requires us to
> forward RRSEC records, I would be very surprised, but please do let us
> know.
>

Also, in case folks weren't aware, IETF RFCs are *intentionally* not
described as standards. They are designed to be subject to revision at
more or less any time. That's why they are titled as a "Request for
Comments" (or RFC). The fact that they are used as standards
documentation is sort of the nature of how things developed from an
era where it was impossible to publish standards for free
(organizations like the ISO require paying money for standards
documentation).

But this also has the consequence that IETF RFCs do not have a
requirement to be evaluated in the context of others and determined to
be fully satisfiable along others. That is, it's possible to have
mutually exclusive RFCs for a system that you have to implement.

So please keep that in mind when considering discussing DNS.



-- 
真実はいつも一つ！/ 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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Michael Catanzaro]

On Tue, Sep 29, 2020 at 11:33 pm, Graham Leggett  
wrote:
To step in here, regulatory compliance is a non optional requirement 
around the world.


Regulatory compliance applies to everybody in a jurisdiction, there 
is no such thing as a “specialized deployment” or environments 
where it “will not matter”. Compliance doesn’t care about an 
arbitrary freeze.


This is not a technical decision.


This is either a very strange misunderstanding, or trolling. I will 
assume positive intent. Internet RFCs are not regulatory requirements. 
If you're aware of some government regulation that requires us to 
forward RRSEC records, I would be very surprised, but please do let us 
know.


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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Graham Leggett]

On 29 Sep 2020, at 22:04, Michael Catanzaro  wrote:

> On Tue, Sep 29, 2020 at 4:51 pm, Petr Menšík  wrote:
>> Anyway, we might forgive working dnssec validation. What we cannot
>> forgive is lack of DNSSEC information passtrough in 2020.
> 
> I agree this should be fixed. See 
> https://bugzilla.redhat.com/show_bug.cgi?id=1879028.
> 
> However, since this only matters for specialized server deployments, and will 
> not matter for desktop usage or most server deployments, and since the 
> workaround is very easy (just edit /etc/resolv.conf) it's really extreme to 
> suggest it should be a release blocker when we have one week to go before 
> final freeze. That timeframe is way too tight.

To step in here, regulatory compliance is a non optional requirement around the 
world.

Regulatory compliance applies to everybody in a jurisdiction, there is no such 
thing as a “specialized deployment” or environments where it “will not matter”. 
Compliance doesn’t care about an arbitrary freeze.

This is not a technical decision.

Regards,
Graham
—
___
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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Michael Catanzaro]

On Tue, Sep 29, 2020 at 10:58 pm, David Sommerseth  
wrote:

Ubuntu 20.04 has also enabled systemd-resolved
by default, but it seems it has not gone as far as Fedora 33.


Ubuntu has enabled systemd-resolved by default since Ubuntu 16.10, but 
it doesn't use nss-resolve, so getaddrinfo() uses traditional nss-dns 
that reads /etc/resolv.conf. In contrast, Fedora is using nss-resolve 
as recommended by upstream, so getaddrinfo() bypasses /etc/resolv.conf 
and instead talks directly 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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[David Sommerseth]

On 29/09/2020 17:21, Paul Wouters wrote:
> 
> For the VPN scenario, it is just a little bit more complicated.
> 
> For those with proper standards, such as "Cisco IPsec", L2TP/IPsec",
> the VPN confiuration is dictated by the server to either send all or
> some traffic to the VPN server. If it is not "everything", then these
> VPNs convey 1 domain name and one or more IP's of DNS servers to use
> to resolve that domain.
> 
> For IKEv2 IPsec based VPNs, any number of domain names can be specified
> by the server to be used by the client. When doing split-DNS with DNSSEC
> trust anchors, these can be conveyed and there are strict rules on when
> to allow these to override public DNSSEC trust anchors as per RFC 8598.
> 
> For VPN protocols with no real standard, things are more complicated.
> 
> OpenVPN can do custom things. It all depends on the provisioning. 

As an OpenVPN developer, I can't resist giving a few details here :)

OpenVPN 2.x using the openvpn-client@.service unit files depends entirely on
the OpenVPN configuration.  So you are right here.

OpenVPN 2.x using NetworkManager, will let NetworkManager pick up changes and
apply them accordingly to the abilities of the NetworkManager-openvpn plugin.

OpenVPN 3 Linux can be enabled with systemd-resolved support [0], but
out-of-the-box it will modify /etc/resolv.conf directly.  Enabling
systemd-resolved support, you will get fairly close to a split-DNS setup but
not completely - but this integration is still considered tech-preview and
we're using the v10_beta release to gain more experience with systemd-resolved
across various distributions.  Ubuntu 20.04 has also enabled systemd-resolved
by default, but it seems it has not gone as far as Fedora 33.

Common to all of these alternatives, the VPN server must push DNS options or
the client configuration file must include the appropriate --dhcp-options.


[0]



-- 
kind regards,

David Sommerseth
OpenVPN Inc
___
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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Michael Catanzaro]

On Tue, Sep 29, 2020 at 8:01 pm, Lennart Poettering 
 wrote:

So, I defer to Michael here: I didn't actually check what NM opted
there. It might very well be that they default to configuring "." as
routing domain for VPNs.


Yes, this is what happens.

Qualification: it's what should happen, sans bugs. We do have one known 
bug, https://bugzilla.redhat.com/show_bug.cgi?id=1863041, but we only 
know of one affected user, and the NetworkManager developers have 
figured out know how to fix it. This bug probably doesn't affect most 
users (at least it works properly for me).


___
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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Petr Menšík]

On 9/29/20 10:05 PM, Michael Catanzaro wrote:
> 
> 
> On Tue, Sep 29, 2020 at 4:28 pm, Petr Menšík  wrote:
>> nss-dns is allright. All you need to have is dns server with domain
>> configurable servers.
>>
>> Those are:
>> - unbound (with dnssec-trigger autoconfigured)
>> - dnsmasq
>> - systemd-resolved
>> - probably knot-resolver
>> - bind (not more difficult to reconfigure runtime)
>>
>> Maybe more. It is not about nss, because /etc/resolv.conf does not
>> support any domain:server-ip tuples. It would work better with local
>> cache. resolved is not the only possibility. Just use /etc/resolv.conf
>> set to localhost and confi
> 
> Great, that will work wonderfully for those of us who run our own DNS
> server and configure it to split DNS as we prefer, and who never use
> VPNs, and who own zero laptops. For the rest of the world, nss-dns is
> not alright.
Isn't the whole issue just to have that server configured correctly?
Just omit manual configuration. VPNs are not solved only by resolved.
dnssec-trigger solves it the same way. It needs only integration with NM.

systemd-resolved is also just dns server with few more options. Bundled
into single package with more features, that might have been separate. I
own a laptop, connect VPN everyday and it works just fine. Did you know
dnsmasq can be configured in very similar way?

I think systemd-resolved mixed too many bits together.
> -- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
___
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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Michael Catanzaro]

On Tue, Sep 29, 2020 at 6:32 pm, Petr Menšík  
wrote:

Are you sure? Can it?


It cannot: https://bugzilla.redhat.com/show_bug.cgi?id=1879028

___
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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Petr Menšík]

On 9/29/20 6:18 PM, Lennart Poettering wrote:
> On Di, 29.09.20 11:21, Paul Wouters (p...@nohats.ca) wrote:
> 
>> No further magic should be needed. The user selects this once when
>> joining a new network.
> 
> This is terrible UI. It was on Windows, and it would be on Linux.
> 
> You shouldn't ask questions people cannot possibly answer
> correctly. There's a reason why Windows remained the only big OS doing
> that... (And do current version still do that even, I think they hid
> it in some secondary menu now, and do not prompt anymore?)
> 
>>> Corporate networks tend to define local zones. Home wifi routers all
>>> do, too. There's no clear way to know what can go directly to well-known
>>> good DNS servers and what needs to be resolved locally.
>>
>> Generally, resolve the names from the DHCP obtained domain name with
>> the DHCP obtained name servers. Yes, this is limited to one domain name,
>> which might not be ideal, but in general when you connect to a home or
>> corporate network directly (no VPN) then you should use their DNS
>> servers regardless. Enterprise is likely blocking port 53 (or DoT or
>> trying to block DoH) for security reasons. And your home network you
>> trust?
> 
> resolved is doing just this. Note that with today's DHCP you can have
> many domains listed in the lease.
> 
>> What is important with all of the VPN cases is that you properly flush
>> the cache when the VPN estalishes and terminates, so avoid having
>> unreachable IP's in your DNS cache. It's important not to flush other
>> DNS data to avoid DNS fingerprinting users across different
>> networks.
> 
> We maintain a per-interface cache anyway. If an interface goes down
> its cache ceases to exist altogether. There's no flushing necessary,
> since it just stops existing.
> 
>> In short, I don't understand the issue raised here of "How do you
>> determine local resources".
>>
>> For each and every domain name in the above scenario it is obvious what
>> nameserver to send it to. There is never a need to broadcast this over
>> a mix of public / private DNS servers.
> 
> One example: As mentioned by someone else somewhere in this thread,
> apparently some private jboss domains are only resolvable via RH VPN
> but not listed as search domains in the server-provided VPN config.
> 
>> So let me ExecSum what I wrote here. For systemd-resolved to become
>> a high quality DNS solution:
>>
>> 1) Remove custom DNS/DNSSEC resolving code and use a well maintained
>>DNS library.
> 
> "Custom" is in the eye of the beholder. It appears to me you mean that
> in a derogatory way. I mean, given that Ubuntu has been enabling
> systemd-resolved since quite some time by default I have the suspicion
> our codebase is more often deployed IRL than the ones you listed? I
> mean, maybe I am wrong, but it's certainly not that this is exotic
> stuff as you imply.
Is it relevant here who's the biggest? Ask any vendor of DNS software.
All them would say, don't reinvent the wheel. It's harder than it seems.
Yet you dont listen for 5 years.
> 
> I have the suspicion this is a territorial thing, no? It feels as if
> you believe that DNS clients that people wo are not core members of
> the DNS community are inherently a bad thing, and should go away, and
> leave the real work to the people who actually know how things work,
> right? I got that kind of behaviour once before when people told us to
> just leave service management to the real holy men of UNIX.
May it be because they struggle to make it all working well together,
where you just say this is okay? They struggle with validation and
privacy, you just throw queries to whomever would respond. There were
already said countless issues. You don't want to hear them.
> 
> I mean, let's not forget: last time this came up, 5 years ago, I was
> so fed with dealing with this attitude of yours I just stepped away,
> and stopped pushing for systemd-resolved in Fedora. You and some other
> peeps then had your shot with dnssec-triggerd, but afaiu that didn't
> really go anywhere, we are still at square one, even though "millions
> of dollars" are behind things, as you say.
Because they cared for DNSSEC functionality. Most of implemented in
resolved is already there in dnssec-trigger and unbound. It has to be
admitted, resolved has better integration with NM.
> 
> So we actually have a chance of delivering something now, but you just
> fight against it, just like 5y ago and nothing changed.
They said their arguments 5 years ago and you are still refusing them.
Problems which we failed to solve but you failed as well. But we just
admit our implementation has limitations.

> 
> The reason systemd-resolved exists and that people have adopted it in
> some distros already and are now doing the same on Fedora is that is
> solves real problems, it improves things. It adds local caching, sane
> per-interface behaviour, makes VPN DNS mostly just work and so on,
> integrates LLMNR/mDNS and other sources of truth 

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Michael Catanzaro]

On Tue, Sep 29, 2020 at 4:28 pm, Petr Menšík  
wrote:

nss-dns is allright. All you need to have is dns server with domain
configurable servers.

Those are:
- unbound (with dnssec-trigger autoconfigured)
- dnsmasq
- systemd-resolved
- probably knot-resolver
- bind (not more difficult to reconfigure runtime)

Maybe more. It is not about nss, because /etc/resolv.conf does not
support any domain:server-ip tuples. It would work better with local
cache. resolved is not the only possibility. Just use /etc/resolv.conf
set to localhost and confi


Great, that will work wonderfully for those of us who run our own DNS 
server and configure it to split DNS as we prefer, and who never use 
VPNs, and who own zero laptops. For the rest of the world, nss-dns is 
not alright.


___
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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Michael Catanzaro]

On Tue, Sep 29, 2020 at 4:51 pm, Petr Menšík  
wrote:

Anyway, we might forgive working dnssec validation. What we cannot
forgive is lack of DNSSEC information passtrough in 2020.


I agree this should be fixed. See 
https://bugzilla.redhat.com/show_bug.cgi?id=1879028.


However, since this only matters for specialized server deployments, 
and will not matter for desktop usage or most server deployments, and 
since the workaround is very easy (just edit /etc/resolv.conf) it's 
really extreme to suggest it should be a release blocker when we have 
one week to go before final freeze. That timeframe is way too tight.


___
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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Michael Catanzaro]

On Tue, Sep 29, 2020 at 4:06 pm, Nikos Mavrogiannopoulos 
 wrote:

It is not an exotic one, but this behavior was in the past considered
a vulnerability (information disclosure) [0]. Are we re-introducing
it? I guess yes, and it can be that the benefits of it outweigh the
vulnerability, but we should be explicit about it in our release
notes.

[0]. CVE-2018-1000135 
https://bugzilla.redhat.com/show_bug.cgi?id=1558238


If all I knew about this was what Lennart just wrote, I would be very 
concerned, because preventing DNS leaks is very important. But Lennart 
is not considering that NetworkManager is not going to configure 
systemd-resolved to operate like this. Lennart's described behavior 
only applies if you give systemd-resolved absolutely no information for 
how to route the DNS. But NetworkManager will not do that, it will do 
the right thing. E.g. if you have one "primary VPN" configured that 
accepts all traffic, your DNS goes to that VPN. It's not going to leak 
DNS queries to your router or to your ISP. If you have a VPN that only 
accepts traffic on its own network, it gets that DNS and not more. This 
is way better than the status quo prior to systemd-resolved where 
unexpected behavior was the norm.


In particular, if you have a VPN that does not select "use this 
connection only for resources on its network," then NetworkManager will 
configure a DNS domain ~. corresponding to the VPN's tun interface. All 
DNS goes there and only there unless it matches another search domain.


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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Michael Catanzaro]

On Tue, Sep 29, 2020 at 5:21 pm, Lennart Poettering 
 wrote:

Yes, I too would prefer if my regular, non-RH DNS traffic never goes
to RH servers while I am in the VPN, and I can easily configure things
that way. But if I am pretty sure the majority of people probably put
more emphasis "please please work" than on "i'd rather have not
working DNS than have DNS queries end up on RH's DNS servers".


For clarity, if you check the box "Use this connection only for 
resources on its network," then NetworkManager will configure a search 
domain to ensure that non-RH DNS traffic will not go to RH servers. 
Lennart is describing systemd-resolved's default mode of operation on 
systems without NetworkManager, but NetworkManager is default is all 
Fedora editions.


___
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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Dan Williams]

On Tue, 2020-09-29 at 15:14 -0400, Simo Sorce wrote:
> On Tue, 2020-09-29 at 11:20 -0500, Dan Williams wrote:
> > On Mon, 2020-09-28 at 16:40 -0500, Michael Catanzaro wrote:
> > > On Mon, Sep 28, 2020 at 5:18 pm, Chuck Anderson  > > > 
> > > wrote:
> > > > I think the VPN plugin and VPN server has some input, no?  All
> > > > the
> > > > VPN
> > > > servers I've used send routes to the VPN client to determine
> > > > which
> > > > traffic the client should send via the VPN.  How does that
> > > > interact
> > > > with "use this connection only for resources on its
> > > > network"?  Does
> > > > the user preference take precendence over the VPN server-
> > > > provided
> > > > routes?  What if the VPN server doesn't send any route other
> > > > than
> > > > 0.0.0.0/0?
> > > 
> > > Good question! So good that I don't know the answer. Yes, the
> > > VPN 
> > > plugin indeed gets to make decision based on configuration pushed
> > > by 
> > > the VPN server. The NetworkManager developers are experts in how
> > > these 
> > > settings interact. I *think* the routes provided by the VPN take 
> > > precedence over the checkbox (but only for routing, not for DNS)?
> > > But 
> > > this would certainly be good to document and explore more fully.
> > 
> > If you check "Use this connection..." then NetworkManager will:
> > 
> > (a) never set the default route through the VPN
> > (b) enable split DNS using the VPN-provided (or manually
> > configured)
> > DNS search domains
> > 
> > If you do not check that box, then the VPN will become the default
> > route and all your non-local traffic will be sent to it.
> > 
> > Unfortunately you cannot rely on VPNs to "do the right thing" and
> > always pass back 0.0.0.0 when it wants all the traffic. Plus the
> > user
> > may not want to pass all traffic to the VPN, regardless of what the
> > VPN
> > wants. If you have a corporate laptop and the company wants all
> > your
> > data to go through the VPN, then that laptop is presumably well-
> > managed 
> > and the IT admin will enforce that "Use this connection..." is
> > unchecked.
> 
> Dan,
> I think that unfortunately we cannot conflate "Use this
> connection..."
> to both decide on packet routing and well as DNS routing.

I'm not disagreeing that in a perfect world we'd actually differentiate
two different things.

But it's been this way for 12+ years with NM and (even though I've been
out of NetworkManager for a long time) I've never seen this much
discussion about the topic. Clearly something has worked for the
majority of users for a long, long time.

But perhaps it's time to evaluate improvements.

> There are definitely VPNs where routing allows only to reach internal
> networks and does not allow passthrough, and at the same time VPN
> expects that all DNS resolution happens through the VPN DNS server as
> they selectively override names so some traffic is routed over VPN
> when
> connected but over the regular internet when not (via DNS views).
> 
> I am not saying this is good or bad, it just is, and if we conflate
> this setting we cannot express that setup, which is common (for
> example
> this is the recommended/required configuration for our RH VPN IIRC).

Sure, those setups are not possible with the binary option we have to
day with NM.

> I am also *not* saying we should have two flags that read the same
> but
> just add "for DNS" in one and "for packets" in the other, as most
> users
> would probably be confused.
> 
> In general I would say that for the common case the default should be
> to send queries to the VPN even if there is packet routing split,
> especially if we are thinking about the "café case" I would
> definitely
> trust more the DNS server via the VPN than the one spoofed by the
> café
> broken wifi.

That is the current default, if you leave "Use this connection..."
unchecked. Of course that also sends your traffic to the VPN, which may
not actually work depending on your VPN config.

> Maybe the way to do this is to provide a different switch that say
> something like "I trust this connection to protect my privacy". Then
> if
> you do not want to trust the DNS provided by the VPN for everything,
> you can toggle that one off (default would be on), and that will
> cause
> split DNS as well based on configured domains.

Well... I trust this connection to protect my privacy in some ways, but
not others. I don't think it's that clear-cut.

I honestly don't expect most users to understand or care about the
difference bewteen split IP routing and split DNS routing. But for
those that do, perhaps there should be additional configuration
possible. That's an RFE for the NM team.

Dan

> WDYT ?
> 
> Simo.
> 
> -- 
> Simo Sorce
> RHEL Crypto Team
> Red Hat, Inc
> 
> 
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> 

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Simo Sorce]

On Tue, 2020-09-29 at 20:01 +0200, Lennart Poettering wrote:
> On Di, 29.09.20 13:56, Simo Sorce (s...@redhat.com) wrote:
> 
> > On Tue, 2020-09-29 at 12:59 +0200, Lennart Poettering wrote:
> > > On Di, 29.09.20 03:49, John M. Harris Jr (joh...@splentity.com) wrote:
> > > 
> > > > Search domains have absolutely nothing to do with routing. Search 
> > > > domains are
> > > > specifically used for resolving non-FQDN to FQDN. This isn't a reliable 
> > > > way to
> > > > see what domains are handled by a VPN, or by any DNS server.
> > > > 
> > > > The Red Hat VPN is a good example of this, as not every internal 
> > > > subdomain is
> > > > in search domains. That's the case for many VPNs, corporate or personal.
> > > 
> > > Please read what I wrote: we have nothing better. And no it's not a
> > > perfectly complete solution, I am aware of that. Configure the routes
> > > explicitly if you want, it's easy, and add the extra domains to the
> > > per-interface route and all will be jolly. If you don't, then things
> > > will still work, but mean that queries that aren't listed in any
> > > search domains will be sent to both the VPN and the main iface DNS,
> > > thus the RH VPN will work perfectly fine — only drawback is that
> > > those internal domains not listed as search domains might be seen on
> > > the internet. But what would expect here happens? If you don't tell us
> > > the routing we cannot do fully perfect routing to your wishes, you
> > > need to give us something.
> > > 
> > > Search domains on VPNs are an indicator that these domains are handled
> > > by the VPN, that's why we use them also as routing domains. But this
> > > doesn't mean it's the *only* routing domains we use. We use the ones
> > > you configure, primarily. But since the concept didn't previously exist
> > > we make the best from what we have.
> > 
> > I see conflicting information here from you and Michael Catanzaro.
> > 
> > You have mentioned quite a few times a fan out and leakage of name
> > searches on all interfaces, while Michael said in response to me that
> > if you do not select the magic option to do split DNS routing that all
> > queries should go to the VPN only, which is it ?
> 
> It might the latter. It's up to NM really: it depends what they tell
> resolved. If they default to associating the "." routing domain with a
> VPN this has the effect that all lookups will be preferably routed
> over that.
> 
> If they don't do that, and define no routing domains, then the
> interface it will be in the regular pool of ifaces where we send stuff
> for which no routing domain is defined anywhere.
> 
> So, I defer to Michael here: I didn't actually check what NM opted
> there. It might very well be that they default to configuring "." as
> routing domain for VPNs.

Ah thanks,
this is good to know, it is hard to figure out what is going on when
there is conflicting information.

If NM does configure resolved this way it is a better option as a default.

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



___
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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Simo Sorce]

On Tue, 2020-09-29 at 11:20 -0500, Dan Williams wrote:
> On Mon, 2020-09-28 at 16:40 -0500, Michael Catanzaro wrote:
> > On Mon, Sep 28, 2020 at 5:18 pm, Chuck Anderson  
> > wrote:
> > > I think the VPN plugin and VPN server has some input, no?  All the
> > > VPN
> > > servers I've used send routes to the VPN client to determine which
> > > traffic the client should send via the VPN.  How does that interact
> > > with "use this connection only for resources on its network"?  Does
> > > the user preference take precendence over the VPN server-provided
> > > routes?  What if the VPN server doesn't send any route other than
> > > 0.0.0.0/0?
> > 
> > Good question! So good that I don't know the answer. Yes, the VPN 
> > plugin indeed gets to make decision based on configuration pushed by 
> > the VPN server. The NetworkManager developers are experts in how
> > these 
> > settings interact. I *think* the routes provided by the VPN take 
> > precedence over the checkbox (but only for routing, not for DNS)?
> > But 
> > this would certainly be good to document and explore more fully.
> 
> If you check "Use this connection..." then NetworkManager will:
> 
> (a) never set the default route through the VPN
> (b) enable split DNS using the VPN-provided (or manually configured)
> DNS search domains
> 
> If you do not check that box, then the VPN will become the default
> route and all your non-local traffic will be sent to it.
> 
> Unfortunately you cannot rely on VPNs to "do the right thing" and
> always pass back 0.0.0.0 when it wants all the traffic. Plus the user
> may not want to pass all traffic to the VPN, regardless of what the VPN
> wants. If you have a corporate laptop and the company wants all your
> data to go through the VPN, then that laptop is presumably well-managed 
> and the IT admin will enforce that "Use this connection..." is
> unchecked.

Dan,
I think that unfortunately we cannot conflate "Use this connection..."
to both decide on packet routing and well as DNS routing.

There are definitely VPNs where routing allows only to reach internal
networks and does not allow passthrough, and at the same time VPN
expects that all DNS resolution happens through the VPN DNS server as
they selectively override names so some traffic is routed over VPN when
connected but over the regular internet when not (via DNS views).

I am not saying this is good or bad, it just is, and if we conflate
this setting we cannot express that setup, which is common (for example
this is the recommended/required configuration for our RH VPN IIRC).

I am also *not* saying we should have two flags that read the same but
just add "for DNS" in one and "for packets" in the other, as most users
would probably be confused.

In general I would say that for the common case the default should be
to send queries to the VPN even if there is packet routing split,
especially if we are thinking about the "café case" I would definitely
trust more the DNS server via the VPN than the one spoofed by the café
broken wifi.

Maybe the way to do this is to provide a different switch that say
something like "I trust this connection to protect my privacy". Then if
you do not want to trust the DNS provided by the VPN for everything,
you can toggle that one off (default would be on), and that will cause
split DNS as well based on configured domains.

WDYT ?

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



___
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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Simo Sorce]

On Tue, 2020-09-29 at 16:35 +, Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Sep 28, 2020 at 02:20:46PM -0400, Simo Sorce wrote:
> > On Mon, 2020-09-28 at 13:32 +, Zbigniew Jędrzejewski-Szmek wrote:
> > > On Mon, Sep 28, 2020 at 07:57:13AM -0500, Ian Pilcher wrote:
> > > > On 9/28/20 6:47 AM, Zbigniew Jędrzejewski-Szmek wrote:
> > > > > Instructions were already posted by Vitaly, so I won't repeat that 
> > > > > here.
> > > > > I'll just note that the scriptlet in systemd.rpm looks for
> > > > > 'Generated by NetworkManager' in /etc/resolv.conf as an indicator that
> > > > > the file is autogenerated.
> > > > 
> > > > Which is a terrible idea, as has been previously mentioned.  It really
> > > > only indicates that the file was once touched my NetworkManager, not
> > > > that it is currently managed.
> > > > 
> > > > If often let Anaconda set up a new system witha  NetworkManager-managed
> > > > DHCP and then convert to a legacy network scripts-managed static IP
> > > > later.  This doesn't change the DNS server or domain, so I don't bother
> > > > editing resolv.conf to remove this comment.  I'm relatively certain that
> > > > this is a common pattern.
> > > 
> > > Yeah, that test is far from ideal, but we need something. If you have
> > > a constructive proposal how to improve it, I'm all ears.
> > 
> > Check if Network Manager is actually enabled as well ?
> 
> Makes sense:
> https://src.fedoraproject.org/rpms/systemd/c/f3f602da25b51caaa188e02003f3db94a0dfadec?branch=f33
> https://src.fedoraproject.org/rpms/systemd/c/39055121170430fa599f454533543cec89a79a58?branch=master
> 
> Zbyszek

Nice job,
thanks Zbyszek!

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



___
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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Petr Menšík]

On 9/29/20 5:21 PM, Lennart Poettering wrote:
> On Di, 29.09.20 16:03, Petr Menšík (pemen...@redhat.com) wrote:
> 
>>> For example, if I have my laptop in my home wifi, connected to RH VPN,
>>> then there are some names resolvable only via the local
>>> DNS. Specifically: my router's, my printer's and my NAS' address. And
>>> there are other names only resolvable via RH VPN. systemd-resolved for
>>> the first time gives me a chance for this to just work: it will send
>>> requests to both the RH DNS servers and the local ones, and uses the
>>> first successful reply, or the last failed reply. And that's quite
>>> frankly awesome, because that *never* worked before.
>> Would you please try dnssec-trigger? It does exactly this thing. Unlike
>> resolved, it can do that also with DNSSEC support on client side. But it
>> is not system default.
> 
> Hmm? resolved can do DNSSEC too, as mentioned. DNSSEC support is
> opt-in though.
> 
>> So no, that is not as fresh as you say. Just have to specify subdomains,
>> that should be sent to specific server. Not just trying anyone that
>> works. Mind my privacy, not everyone has to know what am I
>> resolving.
> 
> I move my laptop around, I want something that just works. And I am
> pretty sure that's the same for Fedora: a DNSSEC implementation that
> is opt-out but requires manual config is a no-go.
No-one demands 100% working validation. We just need 100% working DNSSEC
passthru via resolved, so proper validators can ensure results. There
are problems with DNSSEC. Most of them have known solutions. Just
because your café and modem vendor haven't use any of them.

DNSSEC blocking resolver on fully DNSSEC aware network in year 2020 is
NO-GO to me. It is simple, just don't stand in the way.
> 
>>> So sending the requests to all available DNS servers in absence of
>>> better routing info is a great enabler: it makes DNS "just work" for
>>> many cases, including my own, and I doubt it's a particularly exotic
>>> one.
>>
>> It takes privacy from you and make it much worse. Just because it does
>> 'just work'. Wouldn't it make sense to let corporate admins specify,
>> what should be routed there? Do you know enterprise VPN, which is
>> configured by BFU?
> 
> It provides the same privacy guarantees as your solution — as long as
> you tell it the routing domains. The only difference: if you don't
> tell it anything resolved's behaviour "just works", while your
> solution means things do not just work.
It "works", but provides the other party whole information about what I
visit. Did you know this was the reason for invention of DNS over TLS
and DNS over HTTPS? Even with such encrypted channel, you would leak it
out. If that's the price for "I do not know how but it works", then I
say no, thank you.

It it does not know, you can find a way to make it work. When it works
and leaks, you just won't know.
> 
> You know that meme, "It's not DNS. There's no way it's DNS. It was
> DNS"?
"It's not systemd. There's no way it's systemd. It was
systemd"? Ever heard this version?

> I am pretty sure we shouldn't adopt defaults that break for the
> common cases out-of-the-box. Hence, in absence of more explicit
> routing info I am very sure "just works" is better than "just fails".
I have no problem with proper autoconfiguration. Throwing queries to
every connection I have is plain wrong and always was. That's the reason
why others let it fail in this case.
> 
> Yes, the logic does potentially allow more than you#d want onto some
> interfaces, but I don't think a (fake?) sense of "privacy" is a good
> excuse for "let's ship something that cannot work by default".>
> Yes, I too would prefer if my regular, non-RH DNS traffic never goes
> to RH servers while I am in the VPN, and I can easily configure things
> that way. But if I am pretty sure the majority of people probably put
> more emphasis "please please work" than on "i'd rather have not
> working DNS than have DNS queries end up on RH's DNS servers".But you omit 
> easy configuration on RH VPN server, which would just fix
it. Way to autoconfigure the service without special configuration done
by mere mortal.
> 
>>> Key, take-away here:
>>>
>>> 1. Ideally we'd just route company DNS traffic to VPN, and everything
>>>else to local LAN DNS. But that requires explicit routing info to
>>>be configured, we cannot auto-detect this info (beyond some minor
>>>inference from the search domains)
>> Let company configure it via VPN, allow local override for power
>>users.
> 
> VPNs generally do not propagate domain routing info. They do provide
> search domain info, which — as mentioned — we infer routing info
> from. And yes, we of course allow local override.
> 
> So: check and check? (to the level this is possible)
> 
>>> 2. In some cases hence routing all DNS traffic via VPN and nothing via
>>>local might be a workable option. In others this would be
>>>wrong.
>>
>> Can you please be more specific? Example we can 

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Andrew Lutomirski]

On Tue, Sep 29, 2020 at 4:00 AM Lennart Poettering 
wrote:

> On Di, 29.09.20 03:49, John M. Harris Jr (joh...@splentity.com) wrote:
>
> > Search domains have absolutely nothing to do with routing. Search
> domains are
> > specifically used for resolving non-FQDN to FQDN. This isn't a reliable
> way to
> > see what domains are handled by a VPN, or by any DNS server.
> >
> > The Red Hat VPN is a good example of this, as not every internal
> subdomain is
> > in search domains. That's the case for many VPNs, corporate or personal.
>
> Please read what I wrote: we have nothing better. And no it's not a
> perfectly complete solution, I am aware of that. Configure the routes
> explicitly if you want, it's easy, and add the extra domains to the
> per-interface route and all will be jolly. If you don't, then things
> will still work, but mean that queries that aren't listed in any
> search domains will be sent to both the VPN and the main iface DNS,
> thus the RH VPN will work perfectly fine — only drawback is that
> those internal domains not listed as search domains might be seen on
> the internet. But what would expect here happens? If you don't tell us
> the routing we cannot do fully perfect routing to your wishes, you
> need to give us something.
>
> Search domains on VPNs are an indicator that these domains are handled
> by the VPN, that's why we use them also as routing domains. But this
> doesn't mean it's the *only* routing domains we use. We use the ones
> you configure, primarily. But since the concept didn't previously exist
> we make the best from what we have.
>

These heuristics seem fairly problematic, but this is solvable.  Fedora has
a considerable amount of influence on GNOME and NetworkManager.  How about
adjusting the UI to actually cover these cases? The idea that the VPN
configuration would go off into the weeds if a new checkbox showed up seems
silly — setting up a VPN is fundamentally a power user operation.

This could all be first class parts of VPN config. There could be a set of
options: use this VPN to look up all DNS domains or use this VPN to look up
the following domains. Each domain in the list could have an optional
indication that the user *also* wants it to be a “search domain” to get the
behavior that a query with no trailing dot will try that domain as a
suffix.  And the behavior of broadcasting queries in parallel to the
non-VPN network should be configurable as well.  As someone who has
configured corporate and personal VPNs, I would have made use of these
options, and my various VPNs would all be configured differently.

Right now we have a situation where the underlying system is quite
configurable, but (in networking and elsewhere) GNOME likes to hide
detailed configuration in gsettings or otherwise make it very hard to
discover.  For things like touchpad config, I respect GNOME’s goal of
keeping it simple even if I disagree. For networking, I think that the
genuinely simple cases (connect to WiFi, use that WiFI) should be
approachable to non-technical users, but setting up something like a VPN is
inherently complex, and trying to hide that complexity makes everything
harder.
___
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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Lennart Poettering]

On Di, 29.09.20 13:56, Simo Sorce (s...@redhat.com) wrote:

> On Tue, 2020-09-29 at 12:59 +0200, Lennart Poettering wrote:
> > On Di, 29.09.20 03:49, John M. Harris Jr (joh...@splentity.com) wrote:
> >
> > > Search domains have absolutely nothing to do with routing. Search domains 
> > > are
> > > specifically used for resolving non-FQDN to FQDN. This isn't a reliable 
> > > way to
> > > see what domains are handled by a VPN, or by any DNS server.
> > >
> > > The Red Hat VPN is a good example of this, as not every internal 
> > > subdomain is
> > > in search domains. That's the case for many VPNs, corporate or personal.
> >
> > Please read what I wrote: we have nothing better. And no it's not a
> > perfectly complete solution, I am aware of that. Configure the routes
> > explicitly if you want, it's easy, and add the extra domains to the
> > per-interface route and all will be jolly. If you don't, then things
> > will still work, but mean that queries that aren't listed in any
> > search domains will be sent to both the VPN and the main iface DNS,
> > thus the RH VPN will work perfectly fine — only drawback is that
> > those internal domains not listed as search domains might be seen on
> > the internet. But what would expect here happens? If you don't tell us
> > the routing we cannot do fully perfect routing to your wishes, you
> > need to give us something.
> >
> > Search domains on VPNs are an indicator that these domains are handled
> > by the VPN, that's why we use them also as routing domains. But this
> > doesn't mean it's the *only* routing domains we use. We use the ones
> > you configure, primarily. But since the concept didn't previously exist
> > we make the best from what we have.
>
> I see conflicting information here from you and Michael Catanzaro.
>
> You have mentioned quite a few times a fan out and leakage of name
> searches on all interfaces, while Michael said in response to me that
> if you do not select the magic option to do split DNS routing that all
> queries should go to the VPN only, which is it ?

It might the latter. It's up to NM really: it depends what they tell
resolved. If they default to associating the "." routing domain with a
VPN this has the effect that all lookups will be preferably routed
over that.

If they don't do that, and define no routing domains, then the
interface it will be in the regular pool of ifaces where we send stuff
for which no routing domain is defined anywhere.

So, I defer to Michael here: I didn't actually check what NM opted
there. It might very well be that they default to configuring "." as
routing domain for VPNs.

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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Simo Sorce]

On Tue, 2020-09-29 at 12:59 +0200, Lennart Poettering wrote:
> On Di, 29.09.20 03:49, John M. Harris Jr (joh...@splentity.com) wrote:
> 
> > Search domains have absolutely nothing to do with routing. Search domains 
> > are
> > specifically used for resolving non-FQDN to FQDN. This isn't a reliable way 
> > to
> > see what domains are handled by a VPN, or by any DNS server.
> > 
> > The Red Hat VPN is a good example of this, as not every internal subdomain 
> > is
> > in search domains. That's the case for many VPNs, corporate or personal.
> 
> Please read what I wrote: we have nothing better. And no it's not a
> perfectly complete solution, I am aware of that. Configure the routes
> explicitly if you want, it's easy, and add the extra domains to the
> per-interface route and all will be jolly. If you don't, then things
> will still work, but mean that queries that aren't listed in any
> search domains will be sent to both the VPN and the main iface DNS,
> thus the RH VPN will work perfectly fine — only drawback is that
> those internal domains not listed as search domains might be seen on
> the internet. But what would expect here happens? If you don't tell us
> the routing we cannot do fully perfect routing to your wishes, you
> need to give us something.
> 
> Search domains on VPNs are an indicator that these domains are handled
> by the VPN, that's why we use them also as routing domains. But this
> doesn't mean it's the *only* routing domains we use. We use the ones
> you configure, primarily. But since the concept didn't previously exist
> we make the best from what we have.

I see conflicting information here from you and Michael Catanzaro.

You have mentioned quite a few times a fan out and leakage of name
searches on all interfaces, while Michael said in response to me that
if you do not select the magic option to do split DNS routing that all
queries should go to the VPN only, which is it ?

And how do you configure domains that are not provided as search domain
by the VPN so that they automatically are searched for via the VPN (and
flushed at the time) when the VPN comes up?

In split DNS situation fan out is quite bad because you can get
completely different answers, where generally the VPN has the correct
answer for you but the local DNS server will probably win the latency
game ...

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



___
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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Simo Sorce]

On Tue, 2020-09-29 at 10:19 +0200, Lennart Poettering wrote:
> On Mo, 28.09.20 14:29, Simo Sorce (s...@redhat.com) wrote:
> 
> > On Mon, 2020-09-28 at 16:02 +0100, Tom Hughes via devel wrote:
> > > On 28/09/2020 15:57, Marius Schwarz wrote:
> > > > Am 28.09.20 um 13:47 schrieb Zbigniew Jędrzejewski-Szmek:
> > > > > DNSSEC support in resolved can be enabled through resolved.conf.
> > > > Why isn't that the default, if this resolver can do it?
> > > 
> > > Because DNSSEC is a disaster area and if you try and use it
> > > on random networks you're going to get failed lookups on a
> > > reasonable number - it's fine if you're on a known network
> > > with decent upstream servers but once you start going out
> > > and using random WiFi hotspots and things it's a very
> > > different story.
> > 
> > Surely this is better solved by using DoH toward known good servers for
> > anything but the local resources ?
> 
> Well, but how do you determine "local resources"?

The same way you do now for "routing", if a name is in the search for
an interface it is "local", of course other better methods can come in
the future via better NM integration.

> Corporate networks tend to define local zones. Home wifi routers all
> do, too. There's no clear way to know what can go directly to well-known
> good DNS servers and what needs to be resolved locally.

This is in contradiction with other mentions about routing here ?

> Also, people would react very allergic if we'd start sending all DNS
> traffic to google or so. I mean, you can't believe how pissed people
> are that we have a fallback in place that if no DNS servers have been
> configured at all or acquired via DHCP we fall back to Cloudflare +
> Google DNS servers.

I would be quite pissed too if you disclosed my DNS lookups to parties
I do not trust with that data, and I definitely do not trust Google DNS
servers as those queries are often hijacked at the local ISP level
exactly because those are known IP addresses.

>  Downstream distros (Debian…) tend to patch that
> fallback out even... I wouldn't want to know what happens if you start
> telling them we should now *prefer* them over local DNS servers, which
> is what you are saying here...

Nah, I am not saying you should use DoT to random servers, it should
still be user configured or discovered through things like DHCP if that
information will ever be populated there.

> > I mean the whole point of systemd-resolved should be to make things
> > better including DNSSEC ?
> 
> Yes, resolved implements DNSSEC. But from my experience I can tell you
> it's very hard to do in a way resonably compatible with DNS servers
> deployed out there in particular edge ones. Things mostly work, but
> DNS servers are all broken in different ways, and we can't possibly
> test things on all possible cheap wifi hw...
> 
> (One thing I definitely want to add is an option to only do DNSSEC if
> DoT is also done, under the assumption that a DNS server that is good
> enough and new enough to implement the latter also should be able to
> do the former sanely.)

I think this is fine as an option. But let's not mix DNSSEC resolution
with DNSSEC validation, they are very separate things.

> > As it was already pointed out it is also reasonably simple to detect if
> > the local network have bad DNS servers ...
> 
> No, it's not. It's extremely difficult. Cheap wifi router DNS servers
> are broken in so many ways. They return errors in some cases, freeze
> in others, return rubbish in others, or not at all in even others. If
> you ask the wrong questions anything can happen. We pretty carefully
> tests and probe DNS servers but this still comes at the price that on
> a particular bad implementation we might take a long time until we
> figure out that DNSSEC simply is not possible.

I did not mean to trivialize the technical means, but current DNS
libraries tend to do a reasonable job already, you could simply just
use one of them to offload the problem from your shoulders.
There is little value for systemd-resolved to re-implement all of DNS
handling any way, the value is in the central caching and smart
resolving features.

> The simple fact that some DNS servers don't respond at all if you ask
> the "wrong" questions is already a problem: it means you have to wait
> for a timeout (which means super long lookups initially) or do queries
> in parallel. That however is a problem too since other DNS servers
> really don#t like it if you ask them multiple questions at
> once. Bombarding DNS servers with multiple questions all at once and
> see if one "sticks" isn't a workable strategy hence either.
> 
> And then, when you figured out that the local DNS server can do some
> thing but not others, and are happy you will eventually notice that
> many "edge" DNS servers have a split personality: for some domains
> they are just a proxy for the upstream DNS servers and other domains
> they implement things locally, which means the feature set you can
> 

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Vít Ondruch]

Dne 28. 09. 20 v 18:03 Michael Catanzaro napsal(a):
> On Mon, Sep 28, 2020 at 10:51 am, Ian Pilcher 
> wrote:
>> I anticipated this question.  I don't have a good proposal for you ...
>> but I believe that it's up to the people advocating/implementing this
>> change to come up with that.  If it isn't possible to automate this
>> change in a reliable way, maybe it shouldn't be automated.
>
> Of course it's impossible. :P The only way to guess whether
> NetworkManager generated the file is to check if it says
> "NetworkManager" at the top. There's no way to be certain.


I think that for the future generations, it could help if NM included
also checksum of the content.


Vít

___
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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Paul Wouters]

On Tue, 29 Sep 2020, Lennart Poettering wrote:


"Custom" is in the eye of the beholder. It appears to me you mean that
in a derogatory way.


I went out of my way to compare the systemd-resolved team to te DNS teams
consisting of dozens of full time senior people working 20+ years on
DNS with annual budgets of millions of dollars. I even pointed out these
dedicated people spend weeks per year at dedicated DNS conferences and
the IETF. I did this to specifically show that purely from a resource
based point of view, the systemd-resolved team cannot ever match these
resources. I did this specifically to prevent being seen as derogatory.

As we share the same employer, I encourage you to escalate my
"derogatory behaviour" to our magenement.

I did not read the rest of your email. I will not read or respond to
further emails from you on mailing lists.

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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Zbigniew Jędrzejewski-Szmek]

On Tue, Sep 29, 2020 at 07:27:37AM -0700, Kevin Fenzi wrote:
> On Mon, Sep 28, 2020 at 10:38:27AM -0700, Erich Eickmeyer wrote:
> > 
> > 
> > This entire discussion is generating enough emails per hour to be an IRC
> > discussion. Could we please move this discussion to #fedora-devel or
> > someplace more appropriate?
> 
> Well, not everyone is on IRC, and email is sometimes a better medium for
> longer discussions. 
> 
> Sometimes this list just has a really high volume of emails. ;( 

Yeah. This is a complicated subject. IRC is not good for multi paragraph
questions and answers and clarifications.

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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Dan Williams]

On Tue, 2020-09-29 at 09:18 -0700, John M. Harris Jr wrote:
> On Tuesday, September 29, 2020 5:13:48 AM MST Zbigniew Jędrzejewski-
> Szmek 
> wrote:
> > On Mon, Sep 28, 2020 at 11:41:12PM -0700, John M. Harris Jr wrote:
> > 
> > > On Monday, September 28, 2020 9:39:17 AM MST Michael Catanzaro
> > > wrote:
> > > 
> > > > You can do this, but again, you need to use the command line.
> > > > E.g. 
> > > > 'resolvectl dns tun0 8.8.8.8'
> > > > 
> > > > We're actually no longer debating how systemd-resolved works;
> > > > rather, 
> > > > we're now debating how NetworkManager chooses to configure 
> > > > systemd-resolved. systemd-resolved just does what it's told to
> > > > do. It's
> > > > 
> > > > actually NetworkManager that decides to split DNS according to
> > > > routing 
> > > > by default as a matter of policy. It could do otherwise if it
> > > > wanted 
> > > > to, but I think this is a good default. Nothing stops you from
> > > > changing
> > > > 
> > > > it though. :)
> > > 
> > > Michael,
> > > By what mechanism does NetworkManager "split DNS according to
> > > routing"? If
> > > it  hasn't already made a request from both your cleartext and
> > > your VPN
> > > connection's DNS servers, it has no way of knowing what network
> > > should be
> > > used to get the right results. Routing and DNS are unrelated.
> > 
> > NetworkManager pushes DNS server configuration (and associated bits
> > like
> > domain search and routing domains) over dbus to resolved. That way
> > it
> > "[tells resolved how to] split DNS according to routing". Of
> > course, after
> > the name has been resolved to an IP address, the packets to that IP
> > address
> > are routed too. So there is "routing" in the sense of deciding
> > which
> > interface is appropriate for a given DNS name and "routing" in the
> > sense of
> > deciding which interface is appropriate for a given IP address.
> 
> It seems that the terminology is fairly confusing, considering it's
> right 
> alongside actual routing configuration.. Okay, so "routing" means
> something 
> wildly different than you'd think with systemd-resolved, got it.
> 
> In most cases, in order to get to a DNS server inside a VPN, your
> packets have 
> to have a route which can reach the IP of that server for that
> interface, 
> which is configured using NetworkManager (or a VPN config file,
> imported into 
> NM). Anyone that understands basic networking will likely be confused
> by this 
> terminology.
> 
> That aside, where in NetworkManager do these "routing domains" get
> specified?

In the connection itself (GUI or CLI), or they come from DHCP or SLAAC
or the VPN.

nmcli con mod rh-openvpn ipv4.dns-search "foobar.com"
nmcli con mod rh-openvpn ipv4.never-default true

combined with having a local caching DNS server (or resolved) enabled
will route queries for those search domains only to the VPN-provided
DNS servers.

There are corresponding GUI boxes for these in nm-connection-editor,
GNOME network settings, and KDE.

Dan


> -- 
> John M. Harris, Jr.
> 
> ___
> 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
___
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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Zbigniew Jędrzejewski-Szmek]

On Mon, Sep 28, 2020 at 02:20:46PM -0400, Simo Sorce wrote:
> On Mon, 2020-09-28 at 13:32 +, Zbigniew Jędrzejewski-Szmek wrote:
> > On Mon, Sep 28, 2020 at 07:57:13AM -0500, Ian Pilcher wrote:
> > > On 9/28/20 6:47 AM, Zbigniew Jędrzejewski-Szmek wrote:
> > > > Instructions were already posted by Vitaly, so I won't repeat that here.
> > > > I'll just note that the scriptlet in systemd.rpm looks for
> > > > 'Generated by NetworkManager' in /etc/resolv.conf as an indicator that
> > > > the file is autogenerated.
> > > 
> > > Which is a terrible idea, as has been previously mentioned.  It really
> > > only indicates that the file was once touched my NetworkManager, not
> > > that it is currently managed.
> > > 
> > > If often let Anaconda set up a new system witha  NetworkManager-managed
> > > DHCP and then convert to a legacy network scripts-managed static IP
> > > later.  This doesn't change the DNS server or domain, so I don't bother
> > > editing resolv.conf to remove this comment.  I'm relatively certain that
> > > this is a common pattern.
> > 
> > Yeah, that test is far from ideal, but we need something. If you have
> > a constructive proposal how to improve it, I'm all ears.
> 
> Check if Network Manager is actually enabled as well ?

Makes sense:
https://src.fedoraproject.org/rpms/systemd/c/f3f602da25b51caaa188e02003f3db94a0dfadec?branch=f33
https://src.fedoraproject.org/rpms/systemd/c/39055121170430fa599f454533543cec89a79a58?branch=master

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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Petr Menšík]

On 9/29/20 5:21 PM, Lennart Poettering wrote:
> On Di, 29.09.20 16:03, Petr Menšík (pemen...@redhat.com) wrote:
> 
>>> For example, if I have my laptop in my home wifi, connected to RH VPN,
>>> then there are some names resolvable only via the local
>>> DNS. Specifically: my router's, my printer's and my NAS' address. And
>>> there are other names only resolvable via RH VPN. systemd-resolved for
>>> the first time gives me a chance for this to just work: it will send
>>> requests to both the RH DNS servers and the local ones, and uses the
>>> first successful reply, or the last failed reply. And that's quite
>>> frankly awesome, because that *never* worked before.
>> Would you please try dnssec-trigger? It does exactly this thing. Unlike
>> resolved, it can do that also with DNSSEC support on client side. But it
>> is not system default.
> 
> Hmm? resolved can do DNSSEC too, as mentioned. DNSSEC support is
> opt-in though.

Are you sure? Can it?

# systemctl restart systemd-resolved
$ resolvectl | grep DNSSEC
  DNSSEC setting: allow-downgrade
DNSSEC supported: yes

# delv @127.0.0.53
;; validating ./NS: got insecure response; parent indicates it should be
secure
;; insecurity proof failed resolving './NS/IN': 127.0.0.53#53
;; resolution failed: insecurity proof failed

# delv
; fully validated
.   503266  IN  NS  a.root-servers.net.
.   503266  IN  NS  b.root-servers.net.
.   503266  IN  NS  c.root-servers.net.
.   503266  IN  NS  d.root-servers.net.
.   503266  IN  NS  e.root-servers.net.
.   503266  IN  NS  f.root-servers.net.
.   503266  IN  NS  g.root-servers.net.
.   503266  IN  NS  h.root-servers.net.
.   503266  IN  NS  i.root-servers.net.
.   503266  IN  NS  j.root-servers.net.
.   503266  IN  NS  k.root-servers.net.
.   503266  IN  NS  l.root-servers.net.
.   503266  IN  NS  m.root-servers.net.
.   503266  IN  RRSIG   NS 8 0 518400 2020101205 
2020092904 46594 .
EUNUgwVVvcgdX6JRCPfmhFPuIJW8DZf7ww1hQAgek0GPDT7kc75fER5Z
NpASxPhrTQKentVt/C5ptwa0Z58i8O7XyN6Pu5ZIZrOpG5zV6y0FqLnI
B7L01ugkmTdZIxfqTxbyiTh8hTWspskbAYQrnrSPiotX0+POYlw7ZIwX
R6V7Y2mF48wFclaejrPRQy/ee03QKYyT9nYPahe7i0qnbmvk1JAfDiCw
dR6Aa2hm/RSuW+7nJRqCbeDZZ4mU1lAZDiyUQ1ezAl/HcCCcpBud8iae
DBYFXDX86EP0hXQexpzN5MLUQZuTCIq5Ihz9Vqk0orXmeaZ/k56t/2td /ak8sw==


# rpm -q systemd
systemd-246.6-2.fc34.x86_64

How can I tell it works? Is servfail on dnssec-failed.org enough?

> 
>> So no, that is not as fresh as you say. Just have to specify subdomains,
>> that should be sent to specific server. Not just trying anyone that
>> works. Mind my privacy, not everyone has to know what am I
>> resolving.
> 
> I move my laptop around, I want something that just works. And I am
> pretty sure that's the same for Fedora: a DNSSEC implementation that
> is opt-out but requires manual config is a no-go.
> 
>>> So sending the requests to all available DNS servers in absence of
>>> better routing info is a great enabler: it makes DNS "just work" for
>>> many cases, including my own, and I doubt it's a particularly exotic
>>> one.
>>
>> It takes privacy from you and make it much worse. Just because it does
>> 'just work'. Wouldn't it make sense to let corporate admins specify,
>> what should be routed there? Do you know enterprise VPN, which is
>> configured by BFU?
> 
> It provides the same privacy guarantees as your solution — as long as
> you tell it the routing domains. The only difference: if you don't
> tell it anything resolved's behaviour "just works", while your
> solution means things do not just work.
> 
> You know that meme, "It's not DNS. There's no way it's DNS. It was
> DNS"? I am pretty sure we shouldn't adopt defaults that break for the
> common cases out-of-the-box. Hence, in absence of more explicit
> routing info I am very sure "just works" is better than "just fails".
> 
> Yes, the logic does potentially allow more than you#d want onto some
> interfaces, but I don't think a (fake?) sense of "privacy" is a good
> excuse for "let's ship something that cannot work by default".
> 
> Yes, I too would prefer if my regular, non-RH DNS traffic never goes
> to RH servers while I am in the VPN, and I can easily configure things
> that way. But if I am pretty sure the majority of people probably put
> more emphasis "please please work" than on "i'd rather have not
> working DNS than have DNS queries end up on RH's DNS servers".
> 
>>> Key, take-away here:
>>>
>>> 1. Ideally we'd just route company DNS traffic to VPN, and everything
>>>else to local LAN DNS. But that requires explicit routing info to
>>>be configured, we cannot auto-detect this info 

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Petr Menšík]

On 9/29/20 5:23 PM, Lennart Poettering wrote:
> On Di, 29.09.20 16:51, Petr Menšík (pemen...@redhat.com) wrote:
> 
>>> I am just saying: Fedora cannot be focussed on just working for people
>>> who have a competent company admin and use their laptops in
>>> company networks only. We must have something that works well in
>>> company networks, as in home networks as in cafe wifis and suchlike.
>>>
>>> Client-side DNSSEC only works in a subset of the "competent network
>>> admin" scenario, but not in the cafe wifi scenario or the home lan
>>> scenario.
>> Can you prove this claim somehow?
>>
>> Is there list of cafe wifi scenarios and home lan scenarios, you are
>> referring to?
> 
> I can give you an address of a local Cafe here with a non-working
> DNSSEC. I am pretty sure where you live they have plenty of those
> cafes too.
Define please what is non-working DNSSEC. Does it use few internal
names, which fail to validate? Does it refuse DNSSEC enabled query like
resolved does? Is there any link describing their connection, which
could you share? dig answers, traffic dumps or similar stuff?
> 
> Or German ICE trains public wifi doesn't allow DNSSEC.

What does that mean? Is there any bug/ticket related to it?

What does it reply to dig +dnssec? I have worked few times on Regiojet
here in Czechia. Aside from few connections dropped, it worked just fine.

I think only login web dashboards are frequent reasons for dnssec
failures. After they allow you internet access, it usually works fine
(to me). Could this be also your case?

But I admit I connect most often just by smartphone, which does not have
dnssec enabled. I have it just on my laptop and I never noticed such
problem on it. I will check few myself.

> 
>> With explanation how resolved fixes them if possible?
> 
> Our fix: we do not do DNSSEC by default.
That is incorrect. You do NOT ALLOW DNSSEC by default. Which is big
difference. It even refuses to ask with DNSSEC when I make request for
it. It refuses to pass me unmodified answer. I makes it the most broken
DNS resolver I know about.

Have you tried asking them to fix it?

Note: DNS flag day 2019[1] made guessing due timeouts obsolete.
According to DNS people, it was quite success, misbehaving servers are
quite minimal. It should be enough to resend query with DNSSEC disabled
just on FORMERR response.


> 
> Lennart
> 
> --
> Lennart Poettering, Berlin

1. https://dnsflagday.net/2019/#experts

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB



signature.asc
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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Dan Williams]

On Mon, 2020-09-28 at 16:40 -0500, Michael Catanzaro wrote:
> On Mon, Sep 28, 2020 at 5:18 pm, Chuck Anderson  
> wrote:
> > I think the VPN plugin and VPN server has some input, no?  All the
> > VPN
> > servers I've used send routes to the VPN client to determine which
> > traffic the client should send via the VPN.  How does that interact
> > with "use this connection only for resources on its network"?  Does
> > the user preference take precendence over the VPN server-provided
> > routes?  What if the VPN server doesn't send any route other than
> > 0.0.0.0/0?
> 
> Good question! So good that I don't know the answer. Yes, the VPN 
> plugin indeed gets to make decision based on configuration pushed by 
> the VPN server. The NetworkManager developers are experts in how
> these 
> settings interact. I *think* the routes provided by the VPN take 
> precedence over the checkbox (but only for routing, not for DNS)?
> But 
> this would certainly be good to document and explore more fully.

If you check "Use this connection..." then NetworkManager will:

(a) never set the default route through the VPN
(b) enable split DNS using the VPN-provided (or manually configured)
DNS search domains

If you do not check that box, then the VPN will become the default
route and all your non-local traffic will be sent to it.

Unfortunately you cannot rely on VPNs to "do the right thing" and
always pass back 0.0.0.0 when it wants all the traffic. Plus the user
may not want to pass all traffic to the VPN, regardless of what the VPN
wants. If you have a corporate laptop and the company wants all your
data to go through the VPN, then that laptop is presumably well-managed 
and the IT admin will enforce that "Use this connection..." is
unchecked.

Dan

> This is actually at issue in 
> https://bugzilla.redhat.com/show_bug.cgi?id=1863041 where we
> currently 
> wind up doing the wrong thing by default. See e.g. comment #81 where 
> the VPN plugin is constructing routing information to pass to 
> NetworkManager.
> 
> ___
> 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
___
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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[John M. Harris Jr]

On Tuesday, September 29, 2020 5:13:48 AM MST Zbigniew Jędrzejewski-Szmek 
wrote:
> On Mon, Sep 28, 2020 at 11:41:12PM -0700, John M. Harris Jr wrote:
> 
> > On Monday, September 28, 2020 9:39:17 AM MST Michael Catanzaro wrote:
> > 
> > > You can do this, but again, you need to use the command line. E.g. 
> > > 'resolvectl dns tun0 8.8.8.8'
> > > 
> > > We're actually no longer debating how systemd-resolved works; rather, 
> > > we're now debating how NetworkManager chooses to configure 
> > > systemd-resolved. systemd-resolved just does what it's told to do. It's
> > > 
> > > actually NetworkManager that decides to split DNS according to routing 
> > > by default as a matter of policy. It could do otherwise if it wanted 
> > > to, but I think this is a good default. Nothing stops you from changing
> > > 
> > > it though. :)
> > 
> > 
> > Michael,
> > By what mechanism does NetworkManager "split DNS according to routing"? If
> > it  hasn't already made a request from both your cleartext and your VPN
> > connection's DNS servers, it has no way of knowing what network should be
> > used to get the right results. Routing and DNS are unrelated.
> 
> 
> NetworkManager pushes DNS server configuration (and associated bits like
> domain search and routing domains) over dbus to resolved. That way it
> "[tells resolved how to] split DNS according to routing". Of course, after
> the name has been resolved to an IP address, the packets to that IP address
> are routed too. So there is "routing" in the sense of deciding which
> interface is appropriate for a given DNS name and "routing" in the sense of
> deciding which interface is appropriate for a given IP address.

It seems that the terminology is fairly confusing, considering it's right 
alongside actual routing configuration.. Okay, so "routing" means something 
wildly different than you'd think with systemd-resolved, got it.

In most cases, in order to get to a DNS server inside a VPN, your packets have 
to have a route which can reach the IP of that server for that interface, 
which is configured using NetworkManager (or a VPN config file, imported into 
NM). Anyone that understands basic networking will likely be confused by this 
terminology.

That aside, where in NetworkManager do these "routing domains" get specified?

-- 
John M. Harris, Jr.

___
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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Lennart Poettering]

On Di, 29.09.20 11:21, Paul Wouters (p...@nohats.ca) wrote:

> No further magic should be needed. The user selects this once when
> joining a new network.

This is terrible UI. It was on Windows, and it would be on Linux.

You shouldn't ask questions people cannot possibly answer
correctly. There's a reason why Windows remained the only big OS doing
that... (And do current version still do that even, I think they hid
it in some secondary menu now, and do not prompt anymore?)

> > Corporate networks tend to define local zones. Home wifi routers all
> > do, too. There's no clear way to know what can go directly to well-known
> > good DNS servers and what needs to be resolved locally.
>
> Generally, resolve the names from the DHCP obtained domain name with
> the DHCP obtained name servers. Yes, this is limited to one domain name,
> which might not be ideal, but in general when you connect to a home or
> corporate network directly (no VPN) then you should use their DNS
> servers regardless. Enterprise is likely blocking port 53 (or DoT or
> trying to block DoH) for security reasons. And your home network you
> trust?

resolved is doing just this. Note that with today's DHCP you can have
many domains listed in the lease.

> What is important with all of the VPN cases is that you properly flush
> the cache when the VPN estalishes and terminates, so avoid having
> unreachable IP's in your DNS cache. It's important not to flush other
> DNS data to avoid DNS fingerprinting users across different
> networks.

We maintain a per-interface cache anyway. If an interface goes down
its cache ceases to exist altogether. There's no flushing necessary,
since it just stops existing.

> In short, I don't understand the issue raised here of "How do you
> determine local resources".
>
> For each and every domain name in the above scenario it is obvious what
> nameserver to send it to. There is never a need to broadcast this over
> a mix of public / private DNS servers.

One example: As mentioned by someone else somewhere in this thread,
apparently some private jboss domains are only resolvable via RH VPN
but not listed as search domains in the server-provided VPN config.

> So let me ExecSum what I wrote here. For systemd-resolved to become
> a high quality DNS solution:
>
> 1) Remove custom DNS/DNSSEC resolving code and use a well maintained
>DNS library.

"Custom" is in the eye of the beholder. It appears to me you mean that
in a derogatory way. I mean, given that Ubuntu has been enabling
systemd-resolved since quite some time by default I have the suspicion
our codebase is more often deployed IRL than the ones you listed? I
mean, maybe I am wrong, but it's certainly not that this is exotic
stuff as you imply.

I have the suspicion this is a territorial thing, no? It feels as if
you believe that DNS clients that people wo are not core members of
the DNS community are inherently a bad thing, and should go away, and
leave the real work to the people who actually know how things work,
right? I got that kind of behaviour once before when people told us to
just leave service management to the real holy men of UNIX.

I mean, let's not forget: last time this came up, 5 years ago, I was
so fed with dealing with this attitude of yours I just stepped away,
and stopped pushing for systemd-resolved in Fedora. You and some other
peeps then had your shot with dnssec-triggerd, but afaiu that didn't
really go anywhere, we are still at square one, even though "millions
of dollars" are behind things, as you say.

So we actually have a chance of delivering something now, but you just
fight against it, just like 5y ago and nothing changed.

The reason systemd-resolved exists and that people have adopted it in
some distros already and are now doing the same on Fedora is that is
solves real problems, it improves things. It adds local caching, sane
per-interface behaviour, makes VPN DNS mostly just work and so on,
integrates LLMNR/mDNS and other sources of truth into one thing. If
there was already something doing that we wouldn't have done
resolved. But to my knowledge this doesn't exist. There are solutions
to very specific problems, i.e. resolves for DNS with DNSSEC for
example, but that is just one part of the problem and you cannot just
ignore the rest.

> 2) Maintain a per interface DNS cache using these libraries

We maintain per-interface DNS caches, but with our code.

> 3) Use the above sketched out process to improve your process of
>deciding which interface to send the query to. This is the core
>of what systemd-resolved should give to the user. It is probably
>already pretty close to this when we work on integrating VPN
>supprt.

I understand you love the network "zone" concept. I am not a fan of
the concept, but this doesn't really matter: we provide all the right
IPC APIs to NM and friends to configure per-interface individually
what to do. Hence, if you can convince GNOME and NM to ask people that
zone question 

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Dan Williams]

On Mon, 2020-09-28 at 23:37 -0700, John M. Harris Jr wrote:
> On Monday, September 28, 2020 12:42:32 PM MST Lennart Poettering
> wrote:
> > On Mo, 28.09.20 12:14, Paul Wouters (p...@nohats.ca) wrote:
> > 
> > 
> > > On Mon, 28 Sep 2020, Michael Catanzaro wrote:
> > > 
> > > 
> > > 
> > > > I don't think it would be smart for employees to voluntarily
> > > > opt-in to
> > > > sending all DNS to their employer anyway... there's little
> > > > benefit to
> > > > the employee, and a lot of downside.
> > > 
> > > 
> > > Again, it is not up to systemd to limit valid use cases.
> > > 
> > > 
> > > 
> > > Perhaps Listen or read to Paul Vixie, father of many Bind
> > > software
> > > releases:
> > > 
> > > https://www.youtube.com/watch?v=ZxTdEEuyxHU
> > > 
> > > 
> > > 
> > > https://www.theregister.com/2018/10/23/paul_vixie_slaps_doh_as_dns_privacy
> > > _feature_becomes_a_standard/
> > > 
> > > There are use cases for and against routing all DNS over your
> > > VPN. If
> > > systemd wants to play system resolver, it needs to be able to be
> > > configured for either use case. You don't get to limit our use
> > > cases.
> > 
> > Configure "." as "routing domain" on a specific iface and the
> > lookups
> > wil go there preferably. If you put that on your VPN iface this
> > means
> > DNS traffic goes there preferably. If you put that ont he main
> > iface this
> > means DNS traffic goes there preferably.
> > 
> > Ideally you'd use more fine grained routing domains however.
> > 
> > Lennart
> 
> Lennart,
> 
> Is that a NetworkManager setting or a systemd-resolved setting? Is
> that going 
> to be exposed in the GUI, or is it something that gets hidden away?

NM gets "routing domains" for a given connection (eg, network
interface) from a couple different sources:

1) DHCP
2) SLAAC RDNSS
3) VPN
4) manually configured in the connection info, eg:

nmcli con mod rh-openvpn ipv4.dns-search "foobar.com"

It passes this information on to resolved or its own local caching DNS
configuration which uses dnsmasq, which both use it for directing
lookups for those domains to the DNS servers detected/configured for
that interface.

Dan

> How does systemd-resolved figure out what domains "should" be sent to
> a given 
> connection's DNS server without some arcane incantation from the
> systemd docs?
> 
> -- 
> John M. Harris, Jr.
> 
> ___
> 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
___
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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[John M. Harris Jr]

On Tuesday, September 29, 2020 6:41:12 AM MST Lennart Poettering wrote:
> On Di, 29.09.20 04:03, John M. Harris Jr (joh...@splentity.com) wrote:
> 
> 
> > > Search domains on VPNs are an indicator that these domains are handled
> > > by the VPN, that's why we use them also as routing domains. But this
> > > doesn't mean it's the *only* routing domains we use. We use the ones
> > > you configure, primarily. But since the concept didn't previously exist
> > > we make the best from what we have.
> >
> >
> >
> > If you really must send DNS queries to both (which defeats the purpose of
> > 'Split DNS'), then it may be better to just use the DNS server of the VPN
> > when connected to VPN, then only check the LAN interface when the
> > response is NXDOMAIN.
> 
> 
> As mentioned in this thread already: this policy makes sense for some
> cases but not for others.
> 
> For example, if I have my laptop in my home wifi, connected to RH VPN,
> then there are some names resolvable only via the local
> DNS. Specifically: my router's, my printer's and my NAS' address. And
> there are other names only resolvable via RH VPN. systemd-resolved for
> the first time gives me a chance for this to just work: it will send
> requests to both the RH DNS servers and the local ones, and uses the
> first successful reply, or the last failed reply. And that's quite
> frankly awesome, because that *never* worked before.
> 
> So sending the requests to all available DNS servers in absence of
> better routing info is a great enabler: it makes DNS "just work" for
> many cases, including my own, and I doubt it's a particularly exotic
> one.

There seems to be some confusion in this thread as to how exactly that works. 
It seems that the individual pushing this change is under the assumption that 
this implements 'Split DNS', that only requests for VPN resources are queried 
from the VPN's DNS server(s).

> Key, take-away here:
> 
> 1. Ideally we'd just route company DNS traffic to VPN, and everything
>else to local LAN DNS. But that requires explicit routing info to
>be configured, we cannot auto-detect this info (beyond some minor
>inference from the search domains)

Well, we have the routing information, unless the VPN is one flat network. 
However, routing has absolutely nothing to do with DNS. Routing is a layer 
below, and is most likely required for your DNS queries to actually get to the 
DNS server(s) inside the VPN.

> 2. In some cases hence routing all DNS traffic via VPN and nothing via
>local might be a workable option. In others this would be wrong.
> 
> 3. In others routing all DNS traffic via local DNS and nothing via VPN
>might be workable option. In others this would be wrong.
> 
> 4. In all cases where we can't do #1 because we lack the info, and
>don't know whether to do #2 or #3 because it depends on the type of
>VPN use, then sending to everything in parallel and taking the
>first positive reply and the last negative one is the best chance
>to make things "just work".

This seems to be the part where the Change Owner is confused as to how this 
works, which is concerning at best. We need to be very careful when changing 
functionality that is so essential to the way Fedora systems use network 
resources, this is a pretty big change in functionality, and doesn't provide 
'Split DNS', the issue the Change was originally created to solve.

-- 
John M. Harris, Jr.

___
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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Paul Wouters]

On Tue, 29 Sep 2020, Petr Menšík wrote:


is there any generic protocol exchanging what (sub)domains should be
targetted to specific DNS server?


The search domains are usually the only signal available and used for
this. RFC 7296 (IKEv2) and split-DNS (RFC 8598) defines the sent domain
name list as having a meaning of INTERNAL_DNS_DOMAIN. So it is no longer
a 'search domain' but officially a "name to resolve via the nameserver's
specified by the VPN". Whether to accept these or not is a local policy,
but usually there is a trust relationship that trusts the VPN server.


I know dnssec-trigger/unbound is able
to send queries only to specified search domains received by DHCP server.


Yes, dnssec-trigger tests the nameservers and when they pass, it calls
calls "unbound-control forward_add". This is similar to what
systemd-resolved has adopted via resolvectl.


Are you aware of any implementation independent way to store domains for
each interface?


There is none that I know of.


I think there should be just single way for connection provider to
specify, which domains should go to its DNS server. Then any split-DNS
capable software (unbound, dnsmasq, systemd-resolved) should just
implement its layer to execute such redirection in runtime. Without
special hooks in connection provider to running DNS stub.


I think using the 'search domain' from DHCP is fine. And the VPN use
cases are clear too. As long as "public network" connections never
target specific domains (eg avoid reconfiguring paypal.com)


I doubt there is already generic interface, but it seems it SHOULD be
created.


These discussions are now happening at the IETF ADD and DPRIVE working
groups. While focused on DoT and DoH, the problem is identical. We might
see a "list of domains to resolve via XXX nameserver" in the near
future. Once that happens, it should be trivial to use that with things
like resolvectl or unbound-control.


Can you point me to your support for unbound?


The support for unbound in libreswan is also really easy, as all the
lifting is done by the unbound daemon/library code. We just relay
the domain list and nameserver IPs to forward_add/delete and flush
the related zone names:

https://github.com/libreswan/libreswan/blob/main/programs/_updown.xfrm/_updown.xfrm.in

If we find a running unbound, we reconfigure it. If we don't find it, we
rewrite resolv.conf and send all queries over the VPN. As I said, I'll
work on adding systemd-resolved support here for the next version of
libreswan.

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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Lennart Poettering]

On Di, 29.09.20 16:51, Petr Menšík (pemen...@redhat.com) wrote:

> > I am just saying: Fedora cannot be focussed on just working for people
> > who have a competent company admin and use their laptops in
> > company networks only. We must have something that works well in
> > company networks, as in home networks as in cafe wifis and suchlike.
> >
> > Client-side DNSSEC only works in a subset of the "competent network
> > admin" scenario, but not in the cafe wifi scenario or the home lan
> > scenario.
> Can you prove this claim somehow?
>
> Is there list of cafe wifi scenarios and home lan scenarios, you are
> referring to?

I can give you an address of a local Cafe here with a non-working
DNSSEC. I am pretty sure where you live they have plenty of those
cafes too.

Or German ICE trains public wifi doesn't allow DNSSEC.

> With explanation how resolved fixes them if possible?

Our fix: we do not do DNSSEC by default.

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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Lennart Poettering]

On Di, 29.09.20 16:03, Petr Menšík (pemen...@redhat.com) wrote:

> > For example, if I have my laptop in my home wifi, connected to RH VPN,
> > then there are some names resolvable only via the local
> > DNS. Specifically: my router's, my printer's and my NAS' address. And
> > there are other names only resolvable via RH VPN. systemd-resolved for
> > the first time gives me a chance for this to just work: it will send
> > requests to both the RH DNS servers and the local ones, and uses the
> > first successful reply, or the last failed reply. And that's quite
> > frankly awesome, because that *never* worked before.
> Would you please try dnssec-trigger? It does exactly this thing. Unlike
> resolved, it can do that also with DNSSEC support on client side. But it
> is not system default.

Hmm? resolved can do DNSSEC too, as mentioned. DNSSEC support is
opt-in though.

> So no, that is not as fresh as you say. Just have to specify subdomains,
> that should be sent to specific server. Not just trying anyone that
> works. Mind my privacy, not everyone has to know what am I
> resolving.

I move my laptop around, I want something that just works. And I am
pretty sure that's the same for Fedora: a DNSSEC implementation that
is opt-out but requires manual config is a no-go.

> > So sending the requests to all available DNS servers in absence of
> > better routing info is a great enabler: it makes DNS "just work" for
> > many cases, including my own, and I doubt it's a particularly exotic
> > one.
>
> It takes privacy from you and make it much worse. Just because it does
> 'just work'. Wouldn't it make sense to let corporate admins specify,
> what should be routed there? Do you know enterprise VPN, which is
> configured by BFU?

It provides the same privacy guarantees as your solution — as long as
you tell it the routing domains. The only difference: if you don't
tell it anything resolved's behaviour "just works", while your
solution means things do not just work.

You know that meme, "It's not DNS. There's no way it's DNS. It was
DNS"? I am pretty sure we shouldn't adopt defaults that break for the
common cases out-of-the-box. Hence, in absence of more explicit
routing info I am very sure "just works" is better than "just fails".

Yes, the logic does potentially allow more than you#d want onto some
interfaces, but I don't think a (fake?) sense of "privacy" is a good
excuse for "let's ship something that cannot work by default".

Yes, I too would prefer if my regular, non-RH DNS traffic never goes
to RH servers while I am in the VPN, and I can easily configure things
that way. But if I am pretty sure the majority of people probably put
more emphasis "please please work" than on "i'd rather have not
working DNS than have DNS queries end up on RH's DNS servers".

> > Key, take-away here:
> >
> > 1. Ideally we'd just route company DNS traffic to VPN, and everything
> >else to local LAN DNS. But that requires explicit routing info to
> >be configured, we cannot auto-detect this info (beyond some minor
> >inference from the search domains)
> Let company configure it via VPN, allow local override for power
>users.

VPNs generally do not propagate domain routing info. They do provide
search domain info, which — as mentioned — we infer routing info
from. And yes, we of course allow local override.

So: check and check? (to the level this is possible)

> > 2. In some cases hence routing all DNS traffic via VPN and nothing via
> >local might be a workable option. In others this would be
> >wrong.
>
> Can you please be more specific? Example we can argue about?
> _gateway is just bare name, it would make sense to send it to LAN.
> Anything else?

This is what the person I replied to asked for: if VPN is up send all
DNS traffic to VPN, none to local DNS server.

> > 3. In others routing all DNS traffic via local DNS and nothing via VPN
> >might be workable option. In others this would be wrong.
> Never heard about this. Can you provide an example, where is this
> configuration desired? Is there public product or company, that
> configures it service like this? Do they offer DNS server in
> DHCP/autoconfiguration, when they do not want it to be used?

You appear to one of those who wants that, i.e. no have DNS traffic
end up at RH that shouldn't go there if you are in the VPN.

What this boils down to: there are primarily two usecases for VPN I see:

1. employee talks to company VPN to access very specific servers. For
   cases like this ideally only company DNS traffic goes to VPN and
   nothing else. i.e. porn domain lookups only go to local LAN DNS.

2. user uses public VPN services such as mozilla VPN or Private
   Internet Access or a similar service to obstruct the view on what
   they are doing to the local network. In this case all DNS traffic
   should go to VPN and nothing to local LAN DNS.

Both usecases are equally valid and probably equally popular. We can't
guess what is right.

In the 

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Paul Wouters]

On Tue, 29 Sep 2020, Lennart Poettering wrote:


Well, but how do you determine "local resources"?


This is not the proper question. The proper question is "what are you
trying to do". The .local domain discovery clearly is something meant
to be local.

I assume the real question is: How to convey my custom local network
domain to my local infrastructure. In the old days, it was what DHCP
gave you as domain. If you do that with your own network, then it is
pretty obvious. If you do it differently, you will have to coney this
somehow via configuration. This is why 20 years ago Microsoft added
"zones" to their network configuration. Is this a "home zone" or a "work
zone" or a "public wifi".

So I expect the information of "what is local" to live in
NetworkManager or systemd-networkd via configuration.

No further magic should be needed. The user selects this once when
joining a new network.


Corporate networks tend to define local zones. Home wifi routers all
do, too. There's no clear way to know what can go directly to well-known
good DNS servers and what needs to be resolved locally.


Generally, resolve the names from the DHCP obtained domain name with
the DHCP obtained name servers. Yes, this is limited to one domain name,
which might not be ideal, but in general when you connect to a home or
corporate network directly (no VPN) then you should use their DNS
servers regardless. Enterprise is likely blocking port 53 (or DoT or
trying to block DoH) for security reasons. And your home network you
trust?

Most home routers these days allow configuration of a guest network
along with the native home network. For those not requiring services
on the home network, and who just need internet. It is the same as
using a public wifi in a coffeeshop or guest network at an enterprise
network. You might need to authenticate a captive portal and then you
should not trust the network for anything else and ideally only give
it encrypted packets (TLS, DoT to trusted DNS servers, VPN). If no
trusted DNS servers are configured on your device, you have no choice
but to trust their DNS servers.

For what the user deems is a "public wifi", there are simply never
any "local resources" other than an internet uplink to your own
remote resources.

In all the above scenario's, I see no ambiguity on which DNS servers
to use, except when multiple domain names exist within only the LAN,
which is rarely the case.

For the VPN scenario, it is just a little bit more complicated.

For those with proper standards, such as "Cisco IPsec", L2TP/IPsec",
the VPN confiuration is dictated by the server to either send all or
some traffic to the VPN server. If it is not "everything", then these
VPNs convey 1 domain name and one or more IP's of DNS servers to use
to resolve that domain.

For IKEv2 IPsec based VPNs, any number of domain names can be specified
by the server to be used by the client. When doing split-DNS with DNSSEC
trust anchors, these can be conveyed and there are strict rules on when
to allow these to override public DNSSEC trust anchors as per RFC 8598.

For VPN protocols with no real standard, things are more complicated.

OpenVPN can do custom things. It all depends on the provisioning.

WireGuard has nothing related to DNS, it is all hidden in the per-vendor
proprietary provisioning code. Perhaps the "wg-dynamic" userland
protocol will address this. Let's hope they read RFC 8598 for
inspiration to avoid the mistakes of IPsec 20 years ago.

What is important with all of the VPN cases is that you properly flush
the cache when the VPN estalishes and terminates, so avoid having
unreachable IP's in your DNS cache. It's important not to flush other
DNS data to avoid DNS fingerprinting users across different networks.

It seems resolvectl is the API to support this with systemd-resolved.

In short, I don't understand the issue raised here of "How do you
determine local resources".

For each and every domain name in the above scenario it is obvious what
nameserver to send it to. There is never a need to broadcast this over
a mix of public / private DNS servers.


Also, people would react very allergic if we'd start sending all DNS
traffic to google or so.


So this feature has no purpose as far as I can see and is never ever a
good idea, unless the user is specifically told their choice is to
disconnect from a broken network or try to use the broken network with
well known public DNS servers as a last resort.


Yes, resolved implements DNSSEC. But from my experience I can tell you
it's very hard to do in a way resonably compatible with DNS servers
deployed out there in particular edge ones. Things mostly work, but
DNS servers are all broken in different ways, and we can't possibly
test things on all possible cheap wifi hw...


Which is why the DNSSEC validation code should have been left to the
large DNS teams at ISC, NLnetlabs, nic.cz, powerdns, IETF/ICANN
communities etc. For any of the problems that systemd-resolved
claims to have 

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Petr Menšík]

On 9/29/20 3:44 PM, Lennart Poettering wrote:
> On Di, 29.09.20 13:47, Björn Persson (Bjorn@rombobjörn.se) wrote:
> 
>> Lennart Poettering wrote:
>>> On Mo, 28.09.20 22:54, Björn Persson (Bjorn@rombobjörn.se) wrote:
>>>
 It can work in company-scope if the company has competent network
 admins. My local DNS server at home resolves local hostnames to private
 IPv4 addresses in the 192.168/16 block. Clients on the Internet see
 another view. Both views are DNSsec-signed, and validation works fine.
 There's no reason why this setup wouldn't work on a corporate network.
 The key is to use a domain that is actually registered to the company,
 not some made-up TLD like "internal" or whatever the incompetent
 network admins come up with.
>>>
>>> You never take your laptop outside to a cafe or so? You never
>>> connected it to something that is not your home or office network?
>>
>> A cafe is company-scope? I'm not sure whether that counts as moving the
>> goalposts or changing the subject, but neither is a constructive way to
>> discuss a technical topic.
> 
> I am just saying: Fedora cannot be focussed on just working for people
> who have a competent company admin and use their laptops in
> company networks only. We must have something that works well in
> company networks, as in home networks as in cafe wifis and suchlike.
> 
> Client-side DNSSEC only works in a subset of the "competent network
> admin" scenario, but not in the cafe wifi scenario or the home lan
> scenario.
Can you prove this claim somehow?

Is there list of cafe wifi scenarios and home lan scenarios, you are
referring to? With explanation how resolved fixes them if possible?

Anyway, we might forgive working dnssec validation. What we cannot
forgive is lack of DNSSEC information passtrough in 2020. For me, this
would be blocker to Fedora release. Default installation cannot be
supressing DNSSEC usability. It might not enforce it, but not disallow it.

If you want home lan to work, just accept local answers without
signature, which then prove non-existing under DNSSEC. But do not allow
changed addresses, other than localhost (for blocklist inclusion).

I am dnsmasq maintainer, which is found in most of cheap boxes you were
referring to. It can proxy DNSSEC, unlike resolved with turned off
support. Quite similar to resolved, it is not full-fledged DNS server,
it just forwards (and optionally caches) queries forward. It fixed
DNSSEC support some year back. Is your favourite café network broken so
much?

> 
> Lennart
> 
> --
> Lennart Poettering, Berlin

Thanks,

Petr
-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB



signature.asc
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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Petr Menšík]

nss-dns is allright. All you need to have is dns server with domain
configurable servers.

Those are:
- unbound (with dnssec-trigger autoconfigured)
- dnsmasq
- systemd-resolved
- probably knot-resolver
- bind (not more difficult to reconfigure runtime)

Maybe more. It is not about nss, because /etc/resolv.conf does not
support any domain:server-ip tuples. It would work better with local
cache. resolved is not the only possibility. Just use /etc/resolv.conf
set to localhost and configure forwarders in your server from NM (or
networkd).

On 9/28/20 5:43 PM, Florian Weimer wrote:
> * Michael Catanzaro:
> 
>> On Mon, Sep 28, 2020 at 5:18 pm, Florian Weimer 
>> wrote:
>>> But the DNS view provided by the Red Hat VPN is what disables the
>>> centralized DNS resolvers in browsers in these configurations.  The
>>> magic browser probe no longer fails with the change in DNS routing
>>> (which the proposal confusingly names “Split DNS”) because it goes
>>> out over the public Internet, where it is not filtered, unlike the
>>> Red Hat VPN.
>>
>> Hm, I'm pretty sure this is a Firefox-specific issue, right? Fedora's
>> Firefox is patched to use system DNS, so it shouldn't matter for us. 
>> I'm not aware of any other browser that ignores system DNS; at least,
>> I'm fairly certain Chrome and Epiphany will both never do this.
> 
> It seems that you are right about Chromium:
> 
> | We have no plans to support this approach. We believe that our
> | deployment model is significantly different from Mozilla's, and as a
> | result canary domains won't be needed.
> 
> 
> 
> However, you wrote earlier that “split DNS” is not available over
> nss_dns, so I think Chromium is still impacted because it uses the same
> interfaces that nss_dns would use in this mode (i.e., not nss_resolve).
> 
> Thanks,
> Florian
> 

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB



signature.asc
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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Kevin Fenzi]

On Mon, Sep 28, 2020 at 10:38:27AM -0700, Erich Eickmeyer wrote:
> 
> 
> This entire discussion is generating enough emails per hour to be an IRC
> discussion. Could we please move this discussion to #fedora-devel or
> someplace more appropriate?

Well, not everyone is on IRC, and email is sometimes a better medium for
longer discussions. 

Sometimes this list just has a really high volume of emails. ;( 

kevin


signature.asc
Description: PGP 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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Nikos Mavrogiannopoulos]

On Tue, Sep 29, 2020 at 3:43 PM Lennart Poettering  wrote:
>
> On Di, 29.09.20 04:03, John M. Harris Jr (joh...@splentity.com) wrote:
>
> > > Search domains on VPNs are an indicator that these domains are handled
> > > by the VPN, that's why we use them also as routing domains. But this
> > > doesn't mean it's the *only* routing domains we use. We use the ones
> > > you configure, primarily. But since the concept didn't previously exist
> > > we make the best from what we have.
> >
> > If you really must send DNS queries to both (which defeats the purpose of
> > 'Split DNS'), then it may be better to just use the DNS server of the VPN 
> > when
> > connected to VPN, then only check the LAN interface when the response is
> > NXDOMAIN.
>
> As mentioned in this thread already: this policy makes sense for some
> cases but not for others.
>
> For example, if I have my laptop in my home wifi, connected to RH VPN,
> then there are some names resolvable only via the local
> DNS. Specifically: my router's, my printer's and my NAS' address. And
> there are other names only resolvable via RH VPN. systemd-resolved for
> the first time gives me a chance for this to just work: it will send
> requests to both the RH DNS servers and the local ones, and uses the
> first successful reply, or the last failed reply. And that's quite
> frankly awesome, because that *never* worked before.
>
> So sending the requests to all available DNS servers in absence of
> better routing info is a great enabler: it makes DNS "just work" for
> many cases, including my own, and I doubt it's a particularly exotic
> one.

It is not an exotic one, but this behavior was in the past considered
a vulnerability (information disclosure) [0]. Are we re-introducing
it? I guess yes, and it can be that the benefits of it outweigh the
vulnerability, but we should be explicit about it in our release
notes.

[0]. CVE-2018-1000135 https://bugzilla.redhat.com/show_bug.cgi?id=1558238

>
> Key, take-away here:
>
> 1. Ideally we'd just route company DNS traffic to VPN, and everything
>else to local LAN DNS. But that requires explicit routing info to
>be configured, we cannot auto-detect this info (beyond some minor
>inference from the search domains)

Do we know which fedora shipped VPNs work well with split-dns and
which will lead to leaking the web sites accessed?

regards,
Nikos
___
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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Petr Menšík]

Hi Lennart,

more below...

On 9/29/20 3:41 PM, Lennart Poettering wrote:
> On Di, 29.09.20 04:03, John M. Harris Jr (joh...@splentity.com) wrote:
> 
>>> Search domains on VPNs are an indicator that these domains are handled
>>> by the VPN, that's why we use them also as routing domains. But this
>>> doesn't mean it's the *only* routing domains we use. We use the ones
>>> you configure, primarily. But since the concept didn't previously exist
>>> we make the best from what we have.
>>
>> If you really must send DNS queries to both (which defeats the purpose of
>> 'Split DNS'), then it may be better to just use the DNS server of the VPN 
>> when
>> connected to VPN, then only check the LAN interface when the response is
>> NXDOMAIN.
> 
> As mentioned in this thread already: this policy makes sense for some
> cases but not for others.
> 
> For example, if I have my laptop in my home wifi, connected to RH VPN,
> then there are some names resolvable only via the local
> DNS. Specifically: my router's, my printer's and my NAS' address. And
> there are other names only resolvable via RH VPN. systemd-resolved for
> the first time gives me a chance for this to just work: it will send
> requests to both the RH DNS servers and the local ones, and uses the
> first successful reply, or the last failed reply. And that's quite
> frankly awesome, because that *never* worked before.
Would you please try dnssec-trigger? It does exactly this thing. Unlike
resolved, it can do that also with DNSSEC support on client side. But it
is not system default.

So no, that is not as fresh as you say. Just have to specify subdomains,
that should be sent to specific server. Not just trying anyone that
works. Mind my privacy, not everyone has to know what am I resolving.
> 
> So sending the requests to all available DNS servers in absence of
> better routing info is a great enabler: it makes DNS "just work" for
> many cases, including my own, and I doubt it's a particularly exotic
> one.

It takes privacy from you and make it much worse. Just because it does
'just work'. Wouldn't it make sense to let corporate admins specify,
what should be routed there? Do you know enterprise VPN, which is
configured by BFU?
> 
> Key, take-away here:
> 
> 1. Ideally we'd just route company DNS traffic to VPN, and everything
>else to local LAN DNS. But that requires explicit routing info to
>be configured, we cannot auto-detect this info (beyond some minor
>inference from the search domains)
Let company configure it via VPN, allow local override for power users.

> 
> 2. In some cases hence routing all DNS traffic via VPN and nothing via
>local might be a workable option. In others this would be wrong.
Can you please be more specific? Example we can argue about?
_gateway is just bare name, it would make sense to send it to LAN.
Anything else?

> 
> 3. In others routing all DNS traffic via local DNS and nothing via VPN
>might be workable option. In others this would be wrong.
Never heard about this. Can you provide an example, where is this
configuration desired? Is there public product or company, that
configures it service like this? Do they offer DNS server in
DHCP/autoconfiguration, when they do not want it to be used?

> 
> 4. In all cases where we can't do #1 because we lack the info, and
>don't know whether to do #2 or #3 because it depends on the type of
>VPN use, then sending to everything in parallel and taking the
>first positive reply and the last negative one is the best chance
>to make things "just work".
Then work on getting the info. If you don't know which variant, choose
the same as without resolved. That usually would be #2, right? If that
VPN specified server and it has higher priority, route there. Use any
place default route is sent to.

> 
> Anyway, I think I am repeating myself here.
Sure, you repeat yourself. But turn the deaf ear to arguments of others.
Please use smart defaults, only when they don't endanger user's privacy
nor security.
> 
> Lennart
> 
> --
> Lennart Poettering, Berlin
Petr, Brno
-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB



signature.asc
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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Petr Menšík]

On 9/29/20 10:01 AM, Lennart Poettering wrote:
> On Mo, 28.09.20 23:37, John M. Harris Jr (joh...@splentity.com) wrote:
> 
>>> Configure "." as "routing domain" on a specific iface and the lookups
>>> wil go there preferably. If you put that on your VPN iface this means
>>> DNS traffic goes there preferably. If you put that ont he main iface this
>>> means DNS traffic goes there preferably.
>>
>> Is that a NetworkManager setting or a systemd-resolved setting? Is that going
>> to be exposed in the GUI, or is it something that gets hidden away?
> 
> I am not an NM guy, but I think they expose this these days. I can
> tell you definitely though that this is easily accessible via
> "resolvectl domain " from the command line and from .network
> networkd configuration files.
> 
>> How does systemd-resolved figure out what domains "should" be sent to a given
>> connection's DNS server without some arcane incantation from the systemd 
>> docs?
> 
> As mentioned elsewhere:
> 
> 1) Search domains are implicitly routing domains: if an interface has
>"redhat.com" as search domain we also use that as routing domain,
>i.e. all *.redhat.com lookups will go to this interface and not to
>others.

This is the same algorithm dnssec-trigger uses for this purpose. Because
nothing better is there. dnssec-trigger ignores search domain in user
configuration, using it exclusively to "route" domain requests to
correct servers.

Anyway, there exist at least three implementations able to do split DNS
scenario, systemd-resolved, dnsmasq and dnssec-trigger+unbound. For some
reason, there is no common layer of configuring it inside Network
Manager. I think routed domains should be configured there and any split
DNS provider should get it from there. No VPN should put it to specific
implementation, be it systemd or unbound.
> 
> 2) If neither search domains nor routing domains are configured on any
>interface for a domain, lookups are routed to all interfaces in
>parallel, and the first positive and last negative answer is used.

This is very tragic way of doing it for privacy. You just shout out
every request you have to all parties without any priority. This is not
how it was done without systemd-resolved. This is much worse. Please
reconsider it. If no split view configuration known, all names should be
handled to VPN. If more of them, use priority of NM connection or manual
configuration. Allow local override.

As was said, search is done used for something else by default.

Please don't force me share my porn sites with both employer AND ISP.
Just one of them is enough. Wait for timeout from the first one before
trying next one.
> 
> i.e. focus is primarily on "let's make DNS work" and "let's make the
> best of the little information we traditionally have", and any
> further, more complex routing requires additional configuration in NM,
> networkd or directly with resolvectl commands.

Use any information provided by network administrators, but allow local
overrides. But stay secure at the same time. Put complexity to network
configuration, resolved should fetch it from there.
> 
> 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
> 

Petr
-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB



signature.asc
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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Lennart Poettering]

On Di, 29.09.20 13:47, Björn Persson (Bjorn@rombobjörn.se) wrote:

> Lennart Poettering wrote:
> > On Mo, 28.09.20 22:54, Björn Persson (Bjorn@rombobjörn.se) wrote:
> >
> > > It can work in company-scope if the company has competent network
> > > admins. My local DNS server at home resolves local hostnames to private
> > > IPv4 addresses in the 192.168/16 block. Clients on the Internet see
> > > another view. Both views are DNSsec-signed, and validation works fine.
> > > There's no reason why this setup wouldn't work on a corporate network.
> > > The key is to use a domain that is actually registered to the company,
> > > not some made-up TLD like "internal" or whatever the incompetent
> > > network admins come up with.
> >
> > You never take your laptop outside to a cafe or so? You never
> > connected it to something that is not your home or office network?
>
> A cafe is company-scope? I'm not sure whether that counts as moving the
> goalposts or changing the subject, but neither is a constructive way to
> discuss a technical topic.

I am just saying: Fedora cannot be focussed on just working for people
who have a competent company admin and use their laptops in
company networks only. We must have something that works well in
company networks, as in home networks as in cafe wifis and suchlike.

Client-side DNSSEC only works in a subset of the "competent network
admin" scenario, but not in the cafe wifi scenario or the home lan
scenario.

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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Lennart Poettering]

On Di, 29.09.20 04:03, John M. Harris Jr (joh...@splentity.com) wrote:

> > Search domains on VPNs are an indicator that these domains are handled
> > by the VPN, that's why we use them also as routing domains. But this
> > doesn't mean it's the *only* routing domains we use. We use the ones
> > you configure, primarily. But since the concept didn't previously exist
> > we make the best from what we have.
>
> If you really must send DNS queries to both (which defeats the purpose of
> 'Split DNS'), then it may be better to just use the DNS server of the VPN when
> connected to VPN, then only check the LAN interface when the response is
> NXDOMAIN.

As mentioned in this thread already: this policy makes sense for some
cases but not for others.

For example, if I have my laptop in my home wifi, connected to RH VPN,
then there are some names resolvable only via the local
DNS. Specifically: my router's, my printer's and my NAS' address. And
there are other names only resolvable via RH VPN. systemd-resolved for
the first time gives me a chance for this to just work: it will send
requests to both the RH DNS servers and the local ones, and uses the
first successful reply, or the last failed reply. And that's quite
frankly awesome, because that *never* worked before.

So sending the requests to all available DNS servers in absence of
better routing info is a great enabler: it makes DNS "just work" for
many cases, including my own, and I doubt it's a particularly exotic
one.

Key, take-away here:

1. Ideally we'd just route company DNS traffic to VPN, and everything
   else to local LAN DNS. But that requires explicit routing info to
   be configured, we cannot auto-detect this info (beyond some minor
   inference from the search domains)

2. In some cases hence routing all DNS traffic via VPN and nothing via
   local might be a workable option. In others this would be wrong.

3. In others routing all DNS traffic via local DNS and nothing via VPN
   might be workable option. In others this would be wrong.

4. In all cases where we can't do #1 because we lack the info, and
   don't know whether to do #2 or #3 because it depends on the type of
   VPN use, then sending to everything in parallel and taking the
   first positive reply and the last negative one is the best chance
   to make things "just work".

Anyway, I think I am repeating myself here.

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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Neal Gompa]

On Tue, Sep 29, 2020 at 7:48 AM Björn Persson  wrote:
>
> Lennart Poettering wrote:
> > On Mo, 28.09.20 22:54, Björn Persson (Bjorn@rombobjörn.se) wrote:
> >
> > > It can work in company-scope if the company has competent network
> > > admins. My local DNS server at home resolves local hostnames to private
> > > IPv4 addresses in the 192.168/16 block. Clients on the Internet see
> > > another view. Both views are DNSsec-signed, and validation works fine.
> > > There's no reason why this setup wouldn't work on a corporate network.
> > > The key is to use a domain that is actually registered to the company,
> > > not some made-up TLD like "internal" or whatever the incompetent
> > > network admins come up with.
> >
> > You never take your laptop outside to a cafe or so? You never
> > connected it to something that is not your home or office network?
>
> A cafe is company-scope? I'm not sure whether that counts as moving the
> goalposts or changing the subject, but neither is a constructive way to
> discuss a technical topic.
>

If you're a remote employee, it absolutely is. And especially in this
pandemic, this kind of thing is now the *default* experience.



-- 
真実はいつも一つ！/ 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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Zbigniew Jędrzejewski-Szmek]

On Tue, Sep 29, 2020 at 10:27:37AM +0200, Florian Weimer wrote:
> * Zbigniew Jędrzejewski-Szmek:
> 
> > https://www.iab.org/documents/correspondence-reports-documents/2013-2/iab-statement-dotless-domains-considered-harmful/
> > in this particular case.
> 
> I looked at this extensively a couple of months ago.  There is also an
> ICANN recommendation along similar lines, but focusing more on stub
> resolver configuration and search path processing, which is a better fit
> for systemd-resolved.
> 
> The feedback I received from subject matter experts is that complying
> with these ICANN recommendations (for search path processing) would
> break about 60% of all deployed Kubernetes clusters (and not just inside
> containers).  I think some people have since started on updating
> Kubernetes practices and recommendations, but I expect that it will be a
> few more months until we see first effects.

No, I don't think anyone did this kind of research. But Kubernetes was a (the?)
primary motivation to optionally allow dotless lookups. (The assumption is
that if you're running k8s, you are not just going to install latest Fedora
there, but would do local configuration for the deployment anyway and can
include the override.)

> One problem with DNS is that you cannot take the standards and official
> recommendations and use them as a reference for a new DNS
> implementation.  Many of the specifications are very old, some are quite
> poor, several of the sub-protocols are very badly designed (like using
> timeouts for protocol version negotiation; obviously that one never made
> it into an RFC, but was still widely deployed), and the entire space is
> extremely politicized.  Not just by governments, but also by groups of
> individuals who for some reason cannot get along at all.

Yes, sadly.

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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Cuckoo's Calling via devel]

Hi,

> NetworkManager pushes DNS server configuration (and associated bits like 
> domain
> search and routing domains) over dbus to resolved. That way it "[tells 
> resolved how
> to] split DNS according to routing". Of course, after the name has been 
> resolved
> to an IP address, the packets to that IP address are routed too. So there is
> "routing" in the sense of deciding which interface is appropriate for a given
> DNS name and "routing" in the sense of deciding which interface is appropriate
> for a given IP address.

This explain how this issue came in the first place.
https://gnuguix-drive.mycozy.cloud/public?sharecode=YvERPGX14g5S

Cheers,
Cuckoo's Calling.
___
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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Zbigniew Jędrzejewski-Szmek]

On Mon, Sep 28, 2020 at 11:41:12PM -0700, John M. Harris Jr wrote:
> On Monday, September 28, 2020 9:39:17 AM MST Michael Catanzaro wrote:
> > You can do this, but again, you need to use the command line. E.g. 
> > 'resolvectl dns tun0 8.8.8.8'
> > 
> > We're actually no longer debating how systemd-resolved works; rather, 
> > we're now debating how NetworkManager chooses to configure 
> > systemd-resolved. systemd-resolved just does what it's told to do. It's 
> > actually NetworkManager that decides to split DNS according to routing 
> > by default as a matter of policy. It could do otherwise if it wanted 
> > to, but I think this is a good default. Nothing stops you from changing 
> > it though. :)
> 
> Michael,
> By what mechanism does NetworkManager "split DNS according to routing"? If it 
> hasn't already made a request from both your cleartext and your VPN 
> connection's DNS servers, it has no way of knowing what network should be 
> used 
> to get the right results. Routing and DNS are unrelated.

NetworkManager pushes DNS server configuration (and associated bits like domain
search and routing domains) over dbus to resolved. That way it "[tells resolved 
how
to] split DNS according to routing". Of course, after the name has been resolved
to an IP address, the packets to that IP address are routed too. So there is
"routing" in the sense of deciding which interface is appropriate for a given
DNS name and "routing" in the sense of deciding which interface is appropriate
for a given IP address.

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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Björn Persson]

Lennart Poettering wrote:
> On Mo, 28.09.20 22:54, Björn Persson (Bjorn@rombobjörn.se) wrote:
> 
> > It can work in company-scope if the company has competent network
> > admins. My local DNS server at home resolves local hostnames to private
> > IPv4 addresses in the 192.168/16 block. Clients on the Internet see
> > another view. Both views are DNSsec-signed, and validation works fine.
> > There's no reason why this setup wouldn't work on a corporate network.
> > The key is to use a domain that is actually registered to the company,
> > not some made-up TLD like "internal" or whatever the incompetent
> > network admins come up with.  
> 
> You never take your laptop outside to a cafe or so? You never
> connected it to something that is not your home or office network?

A cafe is company-scope? I'm not sure whether that counts as moving the
goalposts or changing the subject, but neither is a constructive way to
discuss a technical topic.

Björn Persson


pgpCpXVpKWKG2.pgp
Description: OpenPGP digital signatur
___
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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Petr Menšík]

Hi Paul,

is there any generic protocol exchanging what (sub)domains should be
targetted to specific DNS server? I know dnssec-trigger/unbound is able
to send queries only to specified search domains received by DHCP server.

Are you aware of any implementation independent way to store domains for
each interface?

I think there should be just single way for connection provider to
specify, which domains should go to its DNS server. Then any split-DNS
capable software (unbound, dnsmasq, systemd-resolved) should just
implement its layer to execute such redirection in runtime. Without
special hooks in connection provider to running DNS stub.

I doubt there is already generic interface, but it seems it SHOULD be
created. Because connection should not be pushing anything to resolved.
It should push it to (whatever) network manager and resolved should pull
it from there.

Can you point me to your support for unbound?

Regards,
Petr

On 9/28/20 4:28 PM, Paul Wouters wrote:
> On Mon, 28 Sep 2020, Zbigniew Jędrzejewski-Szmek wrote:
> 
>>> This change is harmful to network security, impacts existing
>>> installations
>>> depending on DNSSEC security, and leaks private queries for VPN/internal
>>> domains to the open internet, and prefers faster non-dnssec answers
>>> over dnssec validated answers.  It fails various types of queries,
>>> misimplements part of the DNS protocol. Not only according to me, but
>>> to 20years+ developers of the bind software as well.
>>
>> You're mixing a few different things here. We decided to not enable
>> DNSSEC in resolved with this change, at least initially. For most
>> users, DNSSEC is problematic because various intermediary DNS servers
>> found in hotspots and routers don't support DNSSEC properly, leading
>> to hard-to-debug validation failures. DNSSEC support in resolved can
>> be enabled through resolved.conf. This may be a reasonable thing to do in
>> an environment where the configured dns servers are known to support
>> dnssec
>> properly.
> 
> If you want to do innovate new things with hotspot detection, the place
> to do the protocol work is at the IETF Captive Portal Working Group:
> 
> https://datatracker.ietf.org/wg/capport/charter/
> 
> Work done there include an architecture docoument:
> 
> https://datatracker.ietf.org/doc/draft-ietf-capport-architecture/
> 
> Captive Portal API: https://tools.ietf.org/html/rfc8908
> 
> DHCP and RA options: https://tools.ietf.org/html/rfc8910
> 
> These are efforts with big vendor signon. These will be compatible with
> new hotspots and work similar to other network devices. This is
> preferred over homegrown solutions.
> 
>>> leaks private queries for VPN/internal domains to the open internet
>>
>> It's a complicated subject, but that statement is not true in general.
> 
> It was true when we had a DNSSEC systemd meeting in Brno about five years
> ago when I raised it as a privacy issue and was told my use case was
> "not valid". And it still seems to be true.
> 
> With Tommy Pauly of Apple, I co-write Split DNS for IKEv2 VPNs, that saw
> a major discusison in the security area of IETF (specifically SAAG and
> TLS)  to ensure every one (including browser vendors) were okay with
> the resulting DNS reconfiguration requirements of VPN servers. This
> is especially important now that we are storing certificates as TLSA
> records in DNS, storing encrypted SNI in DNS, and the current draft SVCB
> and HTTPS service binding DNS records that are used in Apple's IOS14.
> These records contain information that must not be vulnerale to spoofing
> or rogue DNS server redirection and should be DNSSEC signed.
> 
> The designers of systemd-resolved will find it a useful read:
> 
> https://tools.ietf.org/html/rfc8598
> 
>> systemd-resolved uses the servers it is told to use. Sometimes we're not
>> sure what to tell it, see
>> https://bugzilla.redhat.com/show_bug.cgi?id=1863041
>> for a long discussion.
> 
> If that worked, I wouldn't have even found out that my system got
> upgraded to systemd-resolved. Clearly this is broken. Furthermore,
> I doubt the rhbz will take into account the various risks of
> reconfiguring DNS and DNSSEC trust anchors or how to limit certain
> forwarders to certain domains. We are not talking about bugs that need
> fixing. We are talking about design decisions that I objected to five
> years ago that are now starting to cause damage.
> 
>>> and prefers faster non-dnssec answers over dnssec validated answers
>>
>> Not exactly. It uses a single server, unless the server is deemed
>> non-responsive
>> and then it switches to the next one one, round-robin. Whether the server
>> does dnssec or not does not directly factor into this. (Except that if
>> resolved is configured to require dnssec, it won't want to talk to
>> non-dnssec
>> servers.) If dnssec is enabled, it shall only accept validated answers.
> 
> This is better thant it was five years ago. I'm glad some things were
> at least successfully conveyed in the Brno 

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[John M. Harris Jr]

On Tuesday, September 29, 2020 3:59:14 AM MST Lennart Poettering wrote:
> On Di, 29.09.20 03:49, John M. Harris Jr (joh...@splentity.com) wrote:
> 
> 
> > Search domains have absolutely nothing to do with routing. Search domains
> > are specifically used for resolving non-FQDN to FQDN. This isn't a
> > reliable way to see what domains are handled by a VPN, or by any DNS
> > server.
> >
> >
> >
> > The Red Hat VPN is a good example of this, as not every internal subdomain
> > is in search domains. That's the case for many VPNs, corporate or
> > personal.
> 
> Please read what I wrote: we have nothing better. And no it's not a
> perfectly complete solution, I am aware of that. Configure the routes
> explicitly if you want, it's easy, and add the extra domains to the
> per-interface route and all will be jolly. If you don't, then things
> will still work, but mean that queries that aren't listed in any
> search domains will be sent to both the VPN and the main iface DNS,
> thus the RH VPN will work perfectly fine — only drawback is that
> those internal domains not listed as search domains might be seen on
> the internet. But what would expect here happens? If you don't tell us
> the routing we cannot do fully perfect routing to your wishes, you
> need to give us something.
> 
> Search domains on VPNs are an indicator that these domains are handled
> by the VPN, that's why we use them also as routing domains. But this
> doesn't mean it's the *only* routing domains we use. We use the ones
> you configure, primarily. But since the concept didn't previously exist
> we make the best from what we have.
> 
> Lennart

If you really must send DNS queries to both (which defeats the purpose of 
'Split DNS'), then it may be better to just use the DNS server of the VPN when 
connected to VPN, then only check the LAN interface when the response is 
NXDOMAIN.

-- 
John M. Harris, Jr.

___
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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Lennart Poettering]

On Di, 29.09.20 03:49, John M. Harris Jr (joh...@splentity.com) wrote:

> Search domains have absolutely nothing to do with routing. Search domains are
> specifically used for resolving non-FQDN to FQDN. This isn't a reliable way to
> see what domains are handled by a VPN, or by any DNS server.
>
> The Red Hat VPN is a good example of this, as not every internal subdomain is
> in search domains. That's the case for many VPNs, corporate or personal.

Please read what I wrote: we have nothing better. And no it's not a
perfectly complete solution, I am aware of that. Configure the routes
explicitly if you want, it's easy, and add the extra domains to the
per-interface route and all will be jolly. If you don't, then things
will still work, but mean that queries that aren't listed in any
search domains will be sent to both the VPN and the main iface DNS,
thus the RH VPN will work perfectly fine — only drawback is that
those internal domains not listed as search domains might be seen on
the internet. But what would expect here happens? If you don't tell us
the routing we cannot do fully perfect routing to your wishes, you
need to give us something.

Search domains on VPNs are an indicator that these domains are handled
by the VPN, that's why we use them also as routing domains. But this
doesn't mean it's the *only* routing domains we use. We use the ones
you configure, primarily. But since the concept didn't previously exist
we make the best from what we have.

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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Nicolas Mailhot via devel]

Le 2020-09-29 12:37, Lennart Poettering a écrit :


This is not the reality I live in though. New-style high level
programming languages tend to avoid being just a wrapper around C
APIs. And thus they implement minimal DNS clients themselves, ignoring
the LLMNR, mDNS and so on.


Not just for DNS. For SMTP, HTTP, etc.

The modern way of coding apps is minimal marginally-compliant and secure 
built-in network client (so things sort of work on the dev system and in 
CI/CD unit tests), with the OS interposing a full-featured protocol 
proxy in “production” deployments.


The problem is that this software dev trend conflicts with the 
traditional end-to-end IETF view. When the end-to-end view wins you end 
up with a single canonical network client like chrome or firefox because 
coding a full-featured secure network client implementation is hard and 
devs want their apps to do network-like IPC not depend on libs that may 
or may not have the correct legal or language requirements


Regards,

--
Nicolas Mailhot
___
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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[John M. Harris Jr]

On Tuesday, September 29, 2020 1:01:23 AM MST Lennart Poettering wrote:
> On Mo, 28.09.20 23:37, John M. Harris Jr (joh...@splentity.com) wrote:
> 
> 
> > > Configure "." as "routing domain" on a specific iface and the lookups
> > > wil go there preferably. If you put that on your VPN iface this means
> > > DNS traffic goes there preferably. If you put that ont he main iface
> > > this
> > > means DNS traffic goes there preferably.
> >
> >
> >
> > Is that a NetworkManager setting or a systemd-resolved setting? Is that
> > going to be exposed in the GUI, or is it something that gets hidden
> > away?
> 
> I am not an NM guy, but I think they expose this these days. I can
> tell you definitely though that this is easily accessible via
> "resolvectl domain " from the command line and from .network
> networkd configuration files.
> 
> 
> > How does systemd-resolved figure out what domains "should" be sent to a
> > given connection's DNS server without some arcane incantation from the
> > systemd docs?
> 
> As mentioned elsewhere:
> 
> 1) Search domains are implicitly routing domains: if an interface has
>"redhat.com" as search domain we also use that as routing domain,
>i.e. all *.redhat.com lookups will go to this interface and not to
>others.
> 
> 2) If neither search domains nor routing domains are configured on any
>interface for a domain, lookups are routed to all interfaces in
>parallel, and the first positive and last negative answer is used.
> 
> i.e. focus is primarily on "let's make DNS work" and "let's make the
> best of the little information we traditionally have", and any
> further, more complex routing requires additional configuration in NM,
> networkd or directly with resolvectl commands.
> 
> Lennart

Lennart,

Search domains have absolutely nothing to do with routing. Search domains are 
specifically used for resolving non-FQDN to FQDN. This isn't a reliable way to 
see what domains are handled by a VPN, or by any DNS server.

The Red Hat VPN is a good example of this, as not every internal subdomain is 
in search domains. That's the case for many VPNs, corporate or personal.

-- 
John M. Harris, Jr.

___
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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Lennart Poettering]

On Mo, 28.09.20 20:52, Björn Persson (Bjorn@rombobjörn.se) wrote:

> Zbigniew Jędrzejewski-Szmek skrev:
> >On Mon, Sep 28, 2020 at 01:15:36PM -0400, Stephen John Smoogen wrote:
> >> Hey for those of us in the peanuts gallery watching this play out.. could
> >> each of you point out which standards and RFC you are complying too. There
> >> are a lot of ones and funny enough.. they don't all agree with each other
> >> at times.
> >
> >https://www.iab.org/documents/correspondence-reports-documents/2013-2/iab-statement-dotless-domains-considered-harmful/
> >in this particular case.
>
> That IAB statement isn't itself a standard, but it references several
> standards. It even quotes RFC 3397 as saying:
>
>  [2]   Resolve a name that contains any dots by first trying it as an
>FQDN and if that fails, with the local domain name (or
>searchlist if specified) appended.
>
>  [3]   Resolve a name containing no dots by appending with the
>searchlist right away, but once again, no implicit searchlists
>should be used.
>
> The name "dk." contains one dot, while "dk" contains no dots. According
> to the quoted rules those two shall be resolved differently. "dk."
> shall be treated as a fully qualified domain name. Now people are
> saying in this thread that systemd-resolved treats both as local names
> and doesn't even try to look them up in DNS. So does systemd-resolved
> comply with this standard or not?

https://github.com/systemd/systemd/pull/17194

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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Lennart Poettering]

On Mo, 28.09.20 11:10, Andrew Lutomirski (l...@mit.edu) wrote:

> > If the other big OSes would enable DNSSEC client-side by default
> > things might change, but neither Windows nor MacOS or Android do.
> >
> >
> The old unbound-resolveconf actually worked quite well when I played with
> it.  The only problem I had was that I couldn't load google.com from one
> particular network.  Upon a bit of investigation, I discovered that the ISP
> was maliciously replacing the A records for google.com with its own servers
> to inject JavaScript.  So unbound-resolveconf's behavior was arguably
> correct.  A better solution might have been to pop up some kind of
> notification like "your network is attempting to tamper with google.com.
> You can use the tampered version of google.com at your own risk by
> following these instructions, or you could try to access the real google.com
> by doing this other thing".

That's terrible UI. The thing is: this stuff should just work and not
pester users with questions they couldn#t possibly understand or
answer properly.

I mean, let's face it. DNSSEC is great, but does it actually make your
bank transfer safer? not really, SSL certs validate domains too in a
way, so DNSSEC isn't strictly necessary because trusting a SSL CA
isn't much different than trusting the DNSSEC root.

hence: client-side DNSSEC is certainly something we should support if
we can: but it's not deployable as default as it stands now, simply
because it breaks more stuff than it helps.

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