Le samedi 09 novembre 2019 à 12:46 +0100, Marius Schwarz a écrit :
> Am 09.11.19 um 10:12 schrieb Nicolas Mailhot via devel:
> > That’s why DoH is intrinsically centralized and rotten to the core.
> >
> > DoH supporters are perfectly happy with a world where there is no
> > standard for
Am 09.11.19 um 10:12 schrieb Nicolas Mailhot via devel:
> That’s why DoH is intrinsically centralized and rotten to the core.
>
> DoH supporters are perfectly happy with a world where there is no
> standard for delegation. And if there is no standard, classical network
> effects will favor the
Le samedi 09 novembre 2019 à 12:04 +0100, Nicolas Mailhot a écrit :
> Le samedi 09 novembre 2019 à 11:09 +0100, Tomasz Torcz a écrit :
> > On Thu, Nov 07, 2019 at 06:18:46PM +0100, Nicolas Mailhot via devel
> > wrote:
> > Here's a network management lesson for you:
> > - run DoH resolver* not on
Le samedi 09 novembre 2019 à 11:09 +0100, Tomasz Torcz a écrit :
> On Thu, Nov 07, 2019 at 06:18:46PM +0100, Nicolas Mailhot via devel
> wrote:
> > > >
> Here's a network management lesson for you:
> - run DoH resolver* not on ::1, but on IP available on your LAN
> - put above IP in DHCP and RA
On Thu, Nov 07, 2019 at 06:18:46PM +0100, Nicolas Mailhot via devel wrote:
> > >
> > > DoH has zero integration and manageability. “It’s not centralized”
> > > (but
> > > you have to set manually DoH settings in all apps *or* rely on a
> > > centralized Google DoH whitelist) is an utter joke.
> >
Le samedi 09 novembre 2019 à 01:15 +0100, Sheogorath via devel a
écrit :
> And the owner should be able to delegate this decision to the
> network
> > manager.
> >
>
> Then let's talk on how we properly implement this delegation process
> instead of asking ourselves whenever we want DoH or DoT
On Thu, 2019-11-07 at 21:25 +0100, Nicolas Mailhot via devel wrote:
> Le jeudi 07 novembre 2019 à 18:32 +0100, Sheogorath via devel a écrit
> :
> > The talk is right on many points, but I think it dismisses the most
> > essential point DoH does right: DNS is a decision of the device
> > owner.
>
Le jeudi 07 novembre 2019 à 18:32 +0100, Sheogorath via devel a écrit :
>
> The talk is right on many points, but I think it dismisses the most
> essential point DoH does right: DNS is a decision of the device
> owner.
And the owner should be able to delegate this decision to the network
On Thu, Nov 7, 2019 at 12:20 pm, David Sommerseth
wrote:
Please just watch the talk by Paul Vixie (who is one of the really
big DNS
gurus these days, even ISC BIND maintainer for quite some years).
And you
will see that DoH is pointless when you have DoT.
Looks like we're headed towards a
On Thu, 2019-11-07 at 07:47 -0700, stan via devel wrote:
> On Thu, 7 Nov 2019 12:20:50 +0100
> David Sommerseth wrote:
>
> > Please just watch the talk by Paul Vixie (who is one of the really
> > big DNS gurus these days, even ISC BIND maintainer for quite some
> > years). And you will see
Le mercredi 06 novembre 2019 à 07:11 +0100, Tomasz Torcz a écrit :
> On Tue, Nov 05, 2019 at 10:00:17PM +0100, Nicolas Mailhot via devel
> wrote:
> > Le mardi 05 novembre 2019 à 19:45 +0100, Tomasz Torcz a écrit :
> > >
> > > I don't agree with centralisation. You should run your own DoH
> > >
On Thu, 7 Nov 2019 12:20:50 +0100
David Sommerseth wrote:
> Please just watch the talk by Paul Vixie (who is one of the really
> big DNS gurus these days, even ISC BIND maintainer for quite some
> years). And you will see that DoH is pointless when you have DoT.
> But DoT can also go much
On 06/11/2019 18:56, Michael Catanzaro wrote:
> On Wed, Nov 6, 2019 at 4:54 pm, David Sommerseth wrote:
>> Yes, TLSv1.3 with encrypted SNI will help to some degree, but still there IP
>> addresses you connect to will still provide meta data which can be used to
>> profile you and give an
On 11/6/19 7:11 AM, Tomasz Torcz wrote:
On Tue, Nov 05, 2019 at 10:00:17PM +0100, Nicolas Mailhot via devel wrote:
Le mardi 05 novembre 2019 à 19:45 +0100, Tomasz Torcz a écrit :
I don't agree with centralisation. You should run your own DoH
endpoint,
using Google's, Cloudflare's or
Hi Marius,
I maintain BIND and some similar stuff. More or less, there is already
implementation quite similar to what you have described. Already in
Fedora: stubby [1]. It has central list of several resolvers and uses
them in round-robin fashion. Does not make specific order.
However, the
Am 06.11.19 um 21:59 schrieb Kevin Fenzi:
>
> In any case, I will note here that firefox in Fedora is not going to
> enable DoH like upstream firefox. I don't know about chromium.
>
>
> kevin
That's good news, as it takes about half an hour to make ff privacy
conform again. Each step less helps.
On Wed, Nov 06, 2019 at 11:56:13AM -0600, Michael Catanzaro wrote:
> On Wed, Nov 6, 2019 at 4:54 pm, David Sommerseth wrote:
> > Yes, TLSv1.3 with encrypted SNI will help to some degree, but still
> > there IP
> > addresses you connect to will still provide meta data which can be used
> > to
> >
On Wed, Nov 6, 2019 at 4:54 pm, David Sommerseth
wrote:
Yes, TLSv1.3 with encrypted SNI will help to some degree, but still
there IP
addresses you connect to will still provide meta data which can be
used to
profile you and give an indication of what kind of sites you visit.
Well that's the
On 05/11/2019 22:00, Nicolas Mailhot via devel wrote:
> Le mardi 05 novembre 2019 à 19:45 +0100, Tomasz Torcz a écrit :
[]
>
> The day DoH actually gets decentralized the nowheristan state and its
> ISPs will run DoH servers like everyone else and influence their
> results exactly like today,
On Tue, Nov 05, 2019 at 10:00:17PM +0100, Nicolas Mailhot via devel wrote:
> Le mardi 05 novembre 2019 à 19:45 +0100, Tomasz Torcz a écrit :
> >
> >
> > I don't agree with centralisation. You should run your own DoH
> > endpoint,
> > using Google's, Cloudflare's or Quad9's servers is a
Le mardi 05 novembre 2019 à 19:45 +0100, Tomasz Torcz a écrit :
>
>
> I don't agree with centralisation. You should run your own DoH
> endpoint,
> using Google's, Cloudflare's or Quad9's servers is a shortcut.
DoH has zero integration and manageability. “It’s not centralized” (but
you have
On Tue, Nov 05, 2019 at 03:07:53PM +0100, Marius Schwarz wrote:
>
> I personally favor DoT as it would make use of the millions of dns
> server available on the net. DoH is too centralized to implement for now.
>
I don't agree with centralisation. You should run your own DoH endpoint,
using
Am 05.11.19 um 16:01 schrieb Stephen John Smoogen:
>
>> To an extend in bandwidth, you could send out parallel queries and
>> check, if they match or if someone has tampered
>> with them. Would be a nice sideeffect.
> This breaks down for multiple reasons.
>
> I do a parallel query and I get two
On Tue, 5 Nov 2019 at 09:51, Marius Schwarz wrote:
>
> Am 05.11.19 um 15:17 schrieb Florian Weimer:
> > I categorically reject your notion that you can increase privacy by
> > sending queries to more servers. As a result, you will end up with a
> > larger set of servers you must trust, not a
Am 05.11.19 um 15:17 schrieb Florian Weimer:
> I categorically reject your notion that you can increase privacy by
> sending queries to more servers. As a result, you will end up with a
> larger set of servers you must trust, not a smaller one.
>
You don't need to trust them for your privacy,
Am 05.11.19 um 14:38 schrieb Tomasz Torcz:
> On Tue, Nov 05, 2019 at 02:09:31PM +0100, Marius Schwarz wrote:
>> DoH is IMHO a waste of resources and as Browsers implement it, useless
>> at best, but mostly a centralization of control of users under a false
>> protection umbrella.
>>
>> Any modern
* Marius Schwarz:
> Am 05.11.19 um 14:21 schrieb Florian Weimer:
>>
>>> ahm.. in which way, does the use of encryption, make a sourcelist for
>>> dns names to ask, obsolete?
>> Names or servers?
> "names of domainnameservers"
>
>>> nscd i.e. uses resolv.conf as source for the round robin server
Am 05.11.19 um 14:21 schrieb Florian Weimer:
>
>> ahm.. in which way, does the use of encryption, make a sourcelist for
>> dns names to ask, obsolete?
> Names or servers?
"names of domainnameservers"
>> nscd i.e. uses resolv.conf as source for the round robin server list.
> With encryption, the
On 05/11/2019 13:42, Tom Hughes wrote:
I don't think one CDN deploying a non-standard extension can reasonably
be described as meaning that SNI is now encrypted.
Yes it is encrypted if you're using a special test version of one
specific browser and you access a site run by one of a handful of
On 05/11/2019 13:38, Tomasz Torcz wrote:
On Tue, Nov 05, 2019 at 02:09:31PM +0100, Marius Schwarz wrote:
DoH is IMHO a waste of resources and as Browsers implement it, useless
at best, but mostly a centralization of control of users under a false
protection umbrella.
Any modern Browser will do
On Tue, Nov 05, 2019 at 02:09:31PM +0100, Marius Schwarz wrote:
> DoH is IMHO a waste of resources and as Browsers implement it, useless
> at best, but mostly a centralization of control of users under a false
> protection umbrella.
>
> Any modern Browser will do this sequence:
>
> User enters
* Marius Schwarz:
> Am 04.11.19 um 23:52 schrieb Michael Cronenworth:
>> cryptographic library into every process that queries an Internet host
>>> name. That also applies to DNSSEC.
>>
>> The transition to DoT/DoH makes the resolv.conf file obsolete. Any
>> discussion on removing it entirely?
Am 04.11.19 um 23:52 schrieb Michael Cronenworth:
> cryptographic library into every process that queries an Internet host
>> name. That also applies to DNSSEC.
>
> The transition to DoT/DoH makes the resolv.conf file obsolete. Any
> discussion on removing it entirely? Default to looking at a
Am 04.11.19 um 17:40 schrieb Michael Cronenworth:
> Hi,
>
> Is there any project or team involved with improving encrypted DNS
> support in Fedora? Any movement in Red Hat corporate?
>
> - Glibc team?
> The /etc/resolv.conf file needs some love. AFAIK it still doe
dnsmasq can include the real dns server ips from a external file
19/11/5 12:51(e)an, Sam Varshavchik igorleak idatzi zuen:
> Florian Weimer writes:
>
>> * Michael Cronenworth:
>>
>> > On 11/4/19 2:17 PM, Florian Weimer wrote:
>> >> We are not going to implement this directly in glibc. You should
Florian Weimer writes:
* Michael Cronenworth:
> On 11/4/19 2:17 PM, Florian Weimer wrote:
>> We are not going to implement this directly in glibc. You should talk
>> to a stub resolver on 127.0.0.1 instead. We do not want to link a
>> cryptographic library into every process that queries an
* Michael Cronenworth:
> On 11/4/19 2:17 PM, Florian Weimer wrote:
>> We are not going to implement this directly in glibc. You should talk
>> to a stub resolver on 127.0.0.1 instead. We do not want to link a
>> cryptographic library into every process that queries an Internet host
>> name.
On 04/11/2019 23:51, Michael Cronenworth wrote:
> On 11/4/19 2:18 PM, Michael Catanzaro wrote:
>> On Mon, Nov 4, 2019 at 12:04 pm, Stephen John Smoogen
>> wrote:
>>> https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
>>
>> Just in case of any possible confusion: this change
On 11/4/19 2:18 PM, Michael Catanzaro wrote:
On Mon, Nov 4, 2019 at 12:04 pm, Stephen John Smoogen wrote:
https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
Just in case of any possible confusion: this change proposal was never
successfully implemented.
Based on the
On 11/4/19 2:17 PM, Florian Weimer wrote:
We are not going to implement this directly in glibc. You should talk
to a stub resolver on 127.0.0.1 instead. We do not want to link a
cryptographic library into every process that queries an Internet host
name. That also applies to DNSSEC.
The
On Mon, Nov 4, 2019 at 12:04 pm, Stephen John Smoogen
wrote:
https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
Just in case of any possible confusion: this change proposal was never
successfully implemented.
___
devel mailing list
* Michael Cronenworth:
> Hi,
>
> Is there any project or team involved with improving encrypted DNS
> support in Fedora? Any movement in Red Hat corporate?
>
> - Glibc team?
> The /etc/resolv.conf file needs some love. AFAIK it still does not
> verify D
On 04/11/19 10:40 -0600, Michael Cronenworth wrote:
> IMHO, this should be our number one priority over modules, new
> spins, or whatever paint color the bike shed needs to be today.
> I would like to see DNS over TLS (DoT) with DTLS at the very least.
I may be wrong, but it seems to me the usual
On Mon, 4 Nov 2019 at 11:44, Michael Cronenworth wrote:
>
> Hi,
>
> Is there any project or team involved with improving encrypted DNS support in
> Fedora? Any movement in Red Hat corporate?
>
> - Glibc team?
> The /etc/resolv.conf file needs some love. AFAIK it
On Mon, Nov 04, 2019 at 10:40:47AM -0600, Michael Cronenworth wrote:
> Hi,
>
> Is there any project or team involved with improving encrypted DNS support
> in Fedora? Any movement in Red Hat corporate?
>
> - Glibc team?
> The /etc/resolv.conf file needs some love
Hi,
Is there any project or team involved with improving encrypted DNS support in
Fedora? Any movement in Red Hat corporate?
- Glibc team?
The /etc/resolv.conf file needs some love. AFAIK it still does not verify
DNSSEC.
- Bind team?
Using 'stunnel' is not a real option.
- DHCP(d &am
46 matches
Mail list logo
