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
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
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
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
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
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
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.
>
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
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
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
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
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.
Am 29.09.20 um 10:19 schrieb Lennart Poettering:
>
> 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
On Mo, 28.09.20 14:11, Paul Wouters (p...@nohats.ca) wrote:
> On Mon, 28 Sep 2020, Michael Catanzaro wrote:
>
> > Well, let's amend that to "first when it's smart to be first." We can't
> > ever *require* DNSSEC validation, because Windows and macOS are not
> > going to do so.
>
>
* 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
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
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
* Michael Catanzaro:
> Of course, this problem is avoidable by unchecking "use this
> connection only for resources on its network" if you use only one
> VPN. And failing that: at least the situation is not worse than it was
> before.
Have you actually tried this with a corporate VPN recently?
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
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
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
On Mon, Sep 28, 2020 at 03:51:51PM -0500, Michael Catanzaro wrote:
> That's still the case. All this discussion about split DNS is only
> relevant to the case where the user checks the box "use this connection
> only for resources on its network" (or imports a VPN profile that
> selects that
Lennart Poettering wrote:
>On Mo, 28.09.20 18:36, Florian Weimer (fwei...@redhat.com) wrote:
>
>> * Andrew Lutomirski:
>>
>> > Paul may well have been mixing different things here, but I don't
>> > think you answered the one that seems like the most severe problem:
>> > systemd-resolved removed
On Mon, Sep 28, 2020 at 2:44 pm, Simo Sorce wrote:
No, this is wrong, DNS and traffic routing are absolutely disjoint
hitngs, and you cannot assume that DNS ought to work as traffic
routing, because it never did.
Hi Simo,
Apologies for a long reply, but I wanted to try to address at least
On Mo, 28.09.20 10:28, Paul Wouters (p...@nohats.ca) wrote:
> This is better thant it was five years ago. I'm glad some things were
> at least successfully conveyed in the Brno meeting. However, this still
> leaks queries meant for the LAN or VPN onto the wide internet and is
Classic resolv.conf
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
On Mo, 28.09.20 16:39, Florian Weimer (fwei...@redhat.com) wrote:
> * Michael Catanzaro:
>
> > If you're running mail servers or VPN servers, you can probably
> > configure the DNS to your liking, right? Either enable DNSSEC support
> > in systemd-resolved, or disable systemd-resolved. I'm not
On Mon, 2020-09-28 at 12:30 -0500, Michael Catanzaro wrote:
> On Mon, Sep 28, 2020 at 1:20 pm, Chuck Anderson
> wrote:
> > I thought Fedora was supposed to be First? How can it be if Fedora
> > chooses to use/configure software by default that is missing critical
> > DNSSEC functionality and
On Mon, 2020-09-28 at 16:59 +, Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Sep 28, 2020 at 06:36:02PM +0200, Florian Weimer wrote:
> > * Andrew Lutomirski:
> >
> > > Paul may well have been mixing different things here, but I don't
> > > think you answered the one that seems like the most
On 9/28/20 11:03 AM, Lennart Poettering wrote:
So far we side-step the DO issue by returning a clean error when
clients set DO: "not implemented", plus a log message in syslog with
more info. I'd argue that for the vast majority of users this is
perfectly enough. Because IRL client-side DNSSEC
On 9/28/20 11:21 AM, Andrew Lutomirski wrote:
> I would have expected NetworkManager to handle this kind of setup just fine.
> What went wrong?
getting offtopic, but ... a laundry list.
including broken routes, missed existing unit-file interface dependencies
particularly once bridges get
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
On Mon, 2020-09-28 at 10:51 -0500, Michael Catanzaro wrote:
> I don't think my description is misleading
>
> On Mon, Sep 28, 2020 at 5:28 pm, Florian Weimer
> wrote:
> > * The change disables protection mechanisms built into corporate VPNs
> > that require them to observe all DNS traffic.
On Mon, 28 Sep 2020, Lennart Poettering wrote:
stuff that doesn't come from classic Internet DNS cannot
possibly be DNSSEC validated.
This statement is incorrect. Please read RFC 8598 and perhaps
read up on the handling of Special Use Domain Names and DNSSEC
validation. No one expects .local
On Sunday, September 27, 2020 9:44:13 PM MST 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 w
On Mon, Sep 28, 2020 at 7:51 pm, Vitaly Zaitsev via devel
wrote:
Btw, Russian Federation is going to completely block DoT and DoH.
Forcing these technologies to end users will disrupt Internet access
for
people from such countries.
We can't require it, because most ISPs don't offer it, and
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
On Mo, 28.09.20 11:06, Andrew Lutomirski (l...@mit.edu) wrote:
> Indeed, the problem you're trying to solve is hard.
>
> > systemd-resolved is not supposed to be a real DNS *server*. It's
> > supposed to be a good, combined client for the popular name resolution
> > protocols, and the fact that
On Mon, Sep 28, 2020 at 11:19 AM PGNet Dev wrote:
> On 9/28/20 11:03 AM, Lennart Poettering wrote:
> > I have the strong suspicion that the same people who are
> > able to deploy working DNSSEC client side and are educated enough in
> > DNSSEC to know what that even means are also capable of
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
On 9/28/20 11:03 AM, Lennart Poettering wrote:
> I have the strong suspicion that the same people who are
> able to deploy working DNSSEC client side and are educated enough in
> DNSSEC to know what that even means are also capable of replacing that
> one symlink in /etc.
i'll start with: i'm
On Mon, 28 Sep 2020, Marius Schwarz wrote:
It's always a bad idea for a programm to do the dns itself, instead of
using the dns anyone on the host does. You get a inconsistent behaviour
at best, and a security nightmare at worse. DOx in a browser or any other
programm is wrong anyhow.
The
On Mo, 28.09.20 19:51, Fedora Development ML (devel@lists.fedoraproject.org)
wrote:
> On 28.09.2020 18:11, Michael Catanzaro wrote:
> > Similarly, system-resolved will allow us to enable DNS over TLS (DoT)
> > systemwide for supported providers. That's not enabled in F33, but I
> > think we
On Mon, 28 Sep 2020, Michael Catanzaro wrote:
Well, let's amend that to "first when it's smart to be first." We can't ever
*require* DNSSEC validation, because Windows and macOS are not going to do
so.
https://tools.ietf.org/id/draft-pauly-add-resolver-discovery-01.html
That draft has a
On Mon, Sep 28, 2020 at 11:07 AM Lennart Poettering
wrote:
> On Mo, 28.09.20 13:20, Chuck Anderson (c...@alum.wpi.edu) wrote:
>
> > On Mon, Sep 28, 2020 at 04:59:17PM +, Zbigniew Jędrzejewski-Szmek
> wrote:
> > > On Mon, Sep 28, 2020 at 06:36:02PM +0200, Florian Weimer wrote:
> > > > *
On Mon, Sep 28, 2020 at 10:05 AM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:
> On Mon, Sep 28, 2020 at 09:44:13AM -0700, Andrew Lutomirski wrote:
> > After reading https://github.com/systemd/systemd/issues/8967, I really
> > don't think that systemd-resolved's benefits outweigh its
On Mon, Sep 28, 2020 at 11:04 AM Lennart Poettering
wrote:
> On Mo, 28.09.20 18:36, Florian Weimer (fwei...@redhat.com) wrote:
>
> > * Andrew Lutomirski:
> >
> > > Paul may well have been mixing different things here, but I don't
> > > think you answered the one that seems like the most severe
On Mo, 28.09.20 13:20, Chuck Anderson (c...@alum.wpi.edu) wrote:
> On Mon, Sep 28, 2020 at 04:59:17PM +, Zbigniew Jędrzejewski-Szmek wrote:
> > On Mon, Sep 28, 2020 at 06:36:02PM +0200, Florian Weimer wrote:
> > > * Andrew Lutomirski:
> > >
> > > > Paul may well have been mixing different
On Mo, 28.09.20 18:36, Florian Weimer (fwei...@redhat.com) wrote:
> * Andrew Lutomirski:
>
> > Paul may well have been mixing different things here, but I don't
> > think you answered the one that seems like the most severe problem:
> > systemd-resolved removed perfectly valid DNSSEC records that
On 28.09.2020 18:11, Michael Catanzaro wrote:
> Similarly, system-resolved will allow us to enable DNS over TLS (DoT)
> systemwide for supported providers. That's not enabled in F33, but I
> think we should flip the default for F34.
Btw, Russian Federation is going to completely block DoT and
Zbigniew Jędrzejewski-Szmek writes:
> On Mon, Sep 28, 2020 at 01:14:14PM -0400, Robbie Harwood wrote:
>> Zbigniew Jędrzejewski-Szmek writes:
>>
>> > Pfff, now I'm confused. Here is a case where systemd-resolved
>> > implements the standard, and some people were unhappy because they
>> > were
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?
--
Erich Eickmeyer
Maintainer
Fedora Jam
___
devel mailing list --
Am 28.09.20 um 17:56 schrieb Paul Wouters:
>
>> 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
>>
On Mon, Sep 28, 2020 at 1:20 pm, Chuck Anderson
wrote:
I thought Fedora was supposed to be First? How can it be if Fedora
chooses to use/configure software by default that is missing critical
DNSSEC functionality and breaks DNS standards?
Well, let's amend that to "first when it's smart to
On Mon, Sep 28, 2020 at 05:26:50PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Sep 28, 2020 at 01:14:14PM -0400, Robbie Harwood wrote:
> > Zbigniew Jędrzejewski-Szmek writes:
> >
> > > Pfff, now I'm confused. Here is a case where systemd-resolved
> > > implements the standard, and some
On Mon, Sep 28, 2020 at 1:20 PM Chuck Anderson wrote:
>
> On Mon, Sep 28, 2020 at 04:59:17PM +, Zbigniew Jędrzejewski-Szmek wrote:
> > On Mon, Sep 28, 2020 at 06:36:02PM +0200, Florian Weimer wrote:
> > > * Andrew Lutomirski:
> > >
> > > > Paul may well have been mixing different things here,
On Mon, Sep 28, 2020 at 01:14:14PM -0400, Robbie Harwood wrote:
> Zbigniew Jędrzejewski-Szmek writes:
>
> > Pfff, now I'm confused. Here is a case where systemd-resolved
> > implements the standard, and some people were unhappy because they
> > were relying on sloppy implementations which don't
On Mon, Sep 28, 2020 at 6:56 pm, Tomasz Torcz
wrote:
This link second time… there's a lot of text, but no example of
configuration file for split dns. Is it because end user cannot
easily
configure split dns permanently?
You can configure custom DNS servers per-network in NetworkManager
On Mon, Sep 28, 2020 at 04:59:17PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Sep 28, 2020 at 06:36:02PM +0200, Florian Weimer wrote:
> > * Andrew Lutomirski:
> >
> > > Paul may well have been mixing different things here, but I don't
> > > think you answered the one that seems like the
On Mon, Sep 28, 2020 at 01:15:36PM -0400, Stephen John Smoogen wrote:
> On Mon, 28 Sep 2020 at 13:05, Zbigniew Jędrzejewski-Szmek
> wrote:
>
> > On Mon, Sep 28, 2020 at 09:44:13AM -0700, Andrew Lutomirski wrote:
> > > After reading https://github.com/systemd/systemd/issues/8967, I really
> > >
On Mon, 28 Sep 2020 at 13:05, Zbigniew Jędrzejewski-Szmek
wrote:
> On Mon, Sep 28, 2020 at 09:44:13AM -0700, Andrew Lutomirski wrote:
> > After reading https://github.com/systemd/systemd/issues/8967, I really
> > don't think that systemd-resolved's benefits outweigh its harms as a
> > default
Zbigniew Jędrzejewski-Szmek writes:
> Pfff, now I'm confused. Here is a case where systemd-resolved
> implements the standard, and some people were unhappy because they
> were relying on sloppy implementations which don't follow the RFC.
Yes, welcome to software development!
Sometimes people
On Mon, Sep 28, 2020 at 09:44:13AM -0700, Andrew Lutomirski wrote:
> After reading https://github.com/systemd/systemd/issues/8967, I really
> don't think that systemd-resolved's benefits outweigh its harms as a
> default resolver for Fedora. If someone wants to write a
> libfriendlydnsresolver
On Mon, Sep 28, 2020 at 06:36:02PM +0200, Florian Weimer wrote:
> * Andrew Lutomirski:
>
> > Paul may well have been mixing different things here, but I don't
> > think you answered the one that seems like the most severe problem:
> > systemd-resolved removed perfectly valid DNSSEC records that
On Mon, Sep 28, 2020 at 10:05:09AM -0500, Michael Catanzaro wrote:
> [1] https://fedoraproject.org/wiki/Changes/systemd-resolved#Split_DNS
This link second time… there's a lot of text, but no example of
configuration file for split dns. Is it because end user cannot easily
configure split dns
On Mon, Sep 28, 2020 at 9:27 AM Andrew Lutomirski wrote:
> On Mon, Sep 28, 2020 at 4:48 AM Zbigniew Jędrzejewski-Szmek <
> zbys...@in.waw.pl> wrote:
>
>> On Mon, Sep 28, 2020 at 12:44:13AM -0400, Paul Wouters wrote:
>> >
>> > >Subject: Re: Fedora 33 Sys
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
* Andrew Lutomirski:
> Paul may well have been mixing different things here, but I don't
> think you answered the one that seems like the most severe problem:
> systemd-resolved removed perfectly valid DNSSEC records that were
> supplied by the upstream server. One might reasonably debate
On Mon, Sep 28, 2020 at 12:14 pm, Paul Wouters wrote:
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.
It *can* be configured for either
* Michael Catanzaro:
> 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. Importantly, if you're looking in
> your network settings and you see a checkbox that says
On Mon, Sep 28, 2020 at 4:48 AM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:
> On Mon, Sep 28, 2020 at 12:44:13AM -0400, Paul Wouters wrote:
> >
> > >Subject: Re: Fedora 33 System-Wide Change proposal: systemd-resolved
> >
>
> > paul@thinkpad:~
On Mon, Sep 28, 2020 at 11:11:31AM -0500, Michael Catanzaro wrote:
> hardcoded list of providers that support DoH. So I believe I'm
> correct to say that only Firefox is doing that... and we have
> already patched Firefox to not do that.
Just for clarity since it confused me: configured by
On Mon, 28 Sep 2020, Michael Catanzaro wrote:
Anyway, if you don't like this heuristic, we could decide to always delete
/etc/resolv.conf.
You will break all software linked against libunbound that uses the
ub_ctx_resolvconf() function. Most users of libunbound will use this,
because
On Mon, Sep 28, 2020 at 11:11 am, Michael Catanzaro
wrote:
Florian just linked to that same chromium.org page as evidence that
Chrome is not ignoring system DNS. :) Indeed, if you read the page,
they're only using DNS over HTTPS (DoH) if system DNS matches a
hardcoded list of providers that
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
On Mon, Sep 28, 2020 at 11:56 am, Paul Wouters wrote:
And that's why DNS-Over-TLS (DoT) and DNS-over-HTTPS (DoH) are now
being deployed. And why browsers are, contrary to Michael Catanzaro's
wrong claim, overriding the system DNS already. See Mozilla's TRR
program
On 28/09/2020 16:56, Paul Wouters wrote:
On Mon, 28 Sep 2020, 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
On Mon, Sep 28, 2020 at 12:04:27PM -0400, Matthew Miller wrote:
> > 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
> Is this actually the case? I
On Mon, Sep 28, 2020 at 10:34:07AM -0500, Michael Catanzaro wrote:
> 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
Is this actually the case? I can't
On Mon, Sep 28, 2020 at 11:56:28AM -0400, Paul Wouters wrote:
> And that's why DNS-Over-TLS (DoT) and DNS-over-HTTPS (DoH) are now
> being deployed. And why browsers are, contrary to Michael Catanzaro's
> wrong claim, overriding the system DNS already. See Mozilla's TRR
> program
On Mon, Sep 28, 2020 at 11:57 AM Paul Wouters wrote:
>
> On Mon, 28 Sep 2020, 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.
> >>
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
On Mon, 28 Sep 2020, 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
On 9/28/20 8:32 AM, Zbigniew Jędrzejewski-Szmek wrote:
Yeah, that test is far from ideal, but we need something. If you have
a constructive proposal how to improve it, I'm all ears.
I anticipated this question. I don't have a good proposal for you ...
but I believe that it's up to the people
I don't think my description is misleading
On Mon, Sep 28, 2020 at 5:28 pm, Florian Weimer
wrote:
* The change disables protection mechanisms built into corporate VPNs
that require them to observe all DNS traffic. Now this may sound
rather weak as far as countermeasures go, but
* 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
>>
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
* Michael Catanzaro:
> "Fedora 33 uses systemd-resolved for name resolution. Most users will
> not notice any difference, but VPN users will benefit from safer
> defaults that ensure DNS requests are sent to the same network that
> would receive the corresponding traffic, avoiding unexpected DNS
* Michael Catanzaro:
> On Mon, Sep 28, 2020 at 4:39 pm, Florian Weimer
> wrote:
>> My understanding is that the DNS request routing in systemd-resolved
>> effectively disables any security mechanisms on the VPN side, and
>> instructs most current browsers to route DNS requests to centralized
>>
On Mon, Sep 28, 2020 at 4:32 pm, Marius Schwarz
wrote:
as one who had split horizone dns setups, it's not the client who
splits, it's the server.
It's really the client... or the server running on the client:
nss-dns (traditional): split DNS impossible. No way to ever split DNS.
dnsmasq,
On Mon, Sep 28, 2020 at 4:39 pm, Florian Weimer
wrote:
My understanding is that the DNS request routing in systemd-resolved
effectively disables any security mechanisms on the VPN side, and
instructs most current browsers to route DNS requests to centralized
DNS
servers for all requests
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
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?
Best regards,
Marius
___
devel mailing list --
On Mon, Sep 28, 2020 at 10:29 am, Matthew Miller
wrote:
On Mon, Sep 28, 2020 at 09:23:47AM -0500, Michael Catanzaro wrote:
*cannot* enable DNSSEC, where VPN users often expect split DNS, and
where we cannot expect users to configure anything manually,
systemd-resolved is solving a real
On Mon, Sep 28, 2020 at 10:28 am, Paul Wouters wrote:
This is better thant it was five years ago. I'm glad some things were
at least successfully conveyed in the Brno meeting. However, this
still
leaks queries meant for the LAN or VPN onto the wide internet and is
still a privacy and security
* Michael Catanzaro:
> If you're running mail servers or VPN servers, you can probably
> configure the DNS to your liking, right? Either enable DNSSEC support
> in systemd-resolved, or disable systemd-resolved. I'm not too
> concerned about this
What about end users who just enable a VPN
On Mon, 28 Sep 2020, Michael Catanzaro wrote:
If you're running mail servers or VPN servers, you can probably configure the
DNS to your liking, right? Either enable DNSSEC support in systemd-resolved,
or disable systemd-resolved. I'm not too concerned about this
You should be concerned
Hi,
Am 28.09.20 um 13:47 schrieb Zbigniew Jędrzejewski-Szmek:
> I'm not sure what you mean by that. It is true that /etc/resolv.conf
> is not able to express split DNS. But it is still in place, with contents
> that try to express the actual DNS configuration to the extent possible.
as one who
On Mon, Sep 28, 2020 at 09:23:47AM -0500, Michael Catanzaro wrote:
> *cannot* enable DNSSEC, where VPN users often expect split DNS, and
> where we cannot expect users to configure anything manually,
> systemd-resolved is solving a real problem that nss-dns will never
> be able to handle.
Can we
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
101 - 200 of 386 matches
Mail list logo
