On Sun, 24 Mar 2019, Vittorio Bertola wrote:
In today's "plain DNS" world, I choose a DNS resolver that provides that
kind of filters for me, I set it up on my router, and my router pushes it to
my smart TV via DHCP. What is the "existing configuration mechanism" that
allows me to set this pol
> On 25 Mar 2019, at 6:06 pm, Daniel Stenberg wrote:
>
> On Sun, 24 Mar 2019, Vittorio Bertola wrote:
>
>> In today's "plain DNS" world, I choose a DNS resolver that provides that
>> kind of filters for me, I set it up on my router, and my router pushes it to
>> my smart TV via DHCP. What is
I'm not pushing against DoT per se in this thread, I am pushing against the
notion that a client has an obligation to the network to provide a clear
channel for traffic analysis and downgrade triggers.
One of the notions presented here is that unauthenticated RST injection
forgery is an acceptable
On Mon, Mar 25, 2019 at 8:52 AM Patrick McManus
wrote:
> I'm not pushing against DoT per se in this thread, I am pushing against
> the notion that a client has an obligation to the network to provide a
> clear channel for traffic analysis and downgrade triggers.
>
> fwiw - there are lots of reaso
One way DoH may be faster than DoT in the near future is that DoH can go
over HTTP/3 via QUIC and avoid head of line blocking like Do53.
On Mon, Mar 25, 2019 at 4:15 AM Brian Dickson
wrote:
>
>
> On Mon, Mar 25, 2019 at 8:52 AM Patrick McManus
> wrote:
>
>> I'm not pushing against DoT per se in
On Mon, Mar 25, 2019 at 8:52 AM Patrick McManus
wrote:
> I'm not pushing against DoT per se in this thread, I am pushing against
> the notion that a client has an obligation to the network to provide a
> clear channel for traffic analysis and downgrade triggers.
>
I think it would be better to n
> Il 24 marzo 2019 alle 7.42 Paul Hoffman ha scritto:
>
>
> Greetings again. As y'all have seen over the past few weeks, the discussion
> of where DNS resolution should happen and over what transports has caused
> some people to use conflicting terms. As a possible solution to the
> terminolo
> The DoH operators who have made public statements (google and cloudflare
> are two I am aware of), have specifically indicated that NO OTHER HTTPS
> TRAFFIC will be shared on the IPv{46} addresses serving Do{HT}.
I have seen such a public statement from Google. Where have you seen a
similar stat
On Mon, 25 Mar 2019 at 09:15, Brian Dickson
wrote:
>
>
> On Mon, Mar 25, 2019 at 8:52 AM Patrick McManus
> wrote:
>
>> I'm not pushing against DoT per se in this thread, I am pushing against
>> the notion that a client has an obligation to the network to provide a
>> clear channel for traffic an
Bonjour uses DNS or mDNS. If it’s using DNS, it can in principle use DoT or
DoH, and indeed “Back to my Mac” was using DoT before it was specified in
an RFC. That functionality is still in the open source mDNSResponder code.
I realize that this is somewhat tangential to the point you were making b
On 25/03/2019 09:28, Ian Swett wrote:
One way DoH may be faster than DoT in the near future is that DoH can go
over HTTP/3 via QUIC and avoid head of line blocking like Do53.
Head of line blocking shouldn't happen on a modern Do53 server.
See RFC 7766 §6.2.1.1
Ray
_
On Mon, Mar 25, 2019 at 9:52 AM Valentin Gosu
wrote:
> On Mon, 25 Mar 2019 at 09:15, Brian Dickson
> wrote:
>
>>
>>
>> On Mon, Mar 25, 2019 at 8:52 AM Patrick McManus
>> wrote:
>>
>>> I'm not pushing against DoT per se in this thread, I am pushing against
>>> the notion that a client has an obl
Hi,
> On 24 Mar 2019, at 23:25, Paul Wouters wrote:
>
>> The blocking of DoT to a given provider should be interpreted as an explicit
>> policy. Users should be informed
>> that they may, and very likely will, be violating someone’s policy, if they
>> choose to use DoH in that
>> circumstance,
ts nice to have a thread where bike shedding of terms is actually on topic,
and the point of the draft.
On Mon, Mar 25, 2019 at 9:39 AM Vittorio Bertola wrote:
> >
> I don't know if these terms are already defined somewhere else, but the
> distinction that I've found most useful in the DoH discu
Hiya,
On 25/03/2019 09:13, Eliot Lear wrote:
> Putting aside legal language, but Brian’s basic notion is that the
> user can make an informed decision and the network can express its
> policies, with which the user can agree or not agree (and go
> elsewhere). Having the protocol elements to perm
On 25 Mar 2019, at 10:25, Stephen Farrell wrote:
> I see a problem with the above argument. DNS means nothing to
> most people, so I can't see how they can ever make the informed
> decision you mention.
I view that as a research question (I don’t accept your assertion, but neither
can I disprov
On Mon, Mar 25, 2019 at 9:37 AM Brian Dickson
wrote:
>
>
>>
>> \Other than blocking all-but-a-few (or all, or a few) DoT servers, I do
> not believe anyone has proposed explicit downgrade triggers.
>
that's the downgrade I am referring to
> Or do you mean, when a DoT connection is blocked by
On Mon, Mar 25, 2019 at 9:58 AM Ray Bellis wrote:
>
>
> On 25/03/2019 09:28, Ian Swett wrote:
> > One way DoH may be faster than DoT in the near future is that DoH can go
> > over HTTP/3 via QUIC and avoid head of line blocking like Do53.
>
> Head of line blocking shouldn't happen on a modern Do5
On Mon, Mar 25, 2019 at 10:31 AM Patrick McManus
wrote:
>
>
> On Mon, Mar 25, 2019 at 9:37 AM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
>>
>>
>>>
>>> \Other than blocking all-but-a-few (or all, or a few) DoT servers, I do
>> not believe anyone has proposed explicit downgrade trigg
This is equally an argument for doing DNS over DTLS. This would give
similar performance to DoH over QUIC.
On Mon, Mar 25, 2019 at 10:43 Brian Dickson
wrote:
>
>
> On Mon, Mar 25, 2019 at 10:31 AM Patrick McManus
> wrote:
>
>>
>>
>> On Mon, Mar 25, 2019 at 9:37 AM Brian Dickson <
>> brian.peter
DoT and DoH seem fine. But maybe skip the acronym for Do53 - just call it
conventional DNS or unencrypted DNS, or DNS over Port 53. Compared to
RDoT/ADoT/DaT/DaO however, Do53 is the least offensive IMO.
I don’t think you do much for clarity with RDoT and ADoT - seems mostly to be
used because
On 25/03/2019 10:41, Patrick McManus wrote:
I've seen this confusion before, so I can clear it up!
Ray is (I believe) referring to the flexible re-ordering of DNS
request-reply pairs of a TCP channel.. similar to HTTP/2 (though with
less flexibility in granularity iirc). That addresses hol
On Mar 24, 2019, at 07:42, Paul Hoffman wrote:
> Greetings again. As y'all have seen over the past few weeks, the discussion
> of where DNS resolution should happen and over what transports has caused
> some people to use conflicting terms. As a possible solution to the
> terminology problems,
On Wed, 13 Feb 2019 at 22:56, Wessels, Duane wrote:
> The only change to this document since -05 is to note that ZONEMD has been
> allocated RR type code 63 by IANA following an expert review back in
> December.
>
I haven't reviewed this for a couple of revisions, so some notes here that
don't a
nusenu wrote:
>
> https works also without names it is just less common.
It's difficult to get a certificate for an IP address.
Tony.
--
f.anthony.n.finchhttp://dotat.at/
Forties, Cromarty, Forth, Tyne: Northwest 5 or 6, backing west 4 or 5,
occasionally 7 at first in Forties. Rough, occasi
Ian Swett wrote:
> One way DoH may be faster than DoT in the near future is that DoH can go
> over HTTP/3 via QUIC and avoid head of line blocking like Do53.
It ought to be better to have native DoQ to eliminate the overhead of the
http layer. Dunno whether this should use yet another port (all
On Mon, Mar 25, 2019 at 2:54 PM Matthew Pounsett wrote:
>
>
>
> Section 3.2. discussion: Unless there's a potential benefit to non-apex
> ZONEMD records that I'm not seeing, I think it makes sense to forbid them.
> Was there a particular thing that could be enabled by that, which prompted
>
Reposting to the list what I shared with Richard Bennett earlier.
The Google Public DNS privacy policy is at
https://developers.google.com/speed/public-dns/privacy. Maybe I should
have included a link to it in the earlier email. If you have comments
on it, please share.
We are following https://t
Ted Lemon wrote:
> This is equally an argument for doing DNS over DTLS. This would give
> similar performance to DoH over QUIC.
If I understand it correctly, DTLS leaves MTU and fragmentation up to the
application protocol. The DNS has horrible packet size problems, so it
needs a lot more help t
On Mar 25, 2019, at 4:04 PM, Tony Finch wrote:
> If I understand it correctly, DTLS leaves MTU and fragmentation up to the
> application protocol. The DNS has horrible packet size problems, so it
> needs a lot more help than DTLS provides. QUIC is much better.
Indeed. My point was simply that t
On 25/03/2019 16:08, Puneet Sood wrote:
you mean lots of changes or lots of agreement with the quoted text?
They mean very different things.
I was agreeing with the quoted text - I believe that any serving of
stale records must be predicated on the presence of a valid delegation
from the
This update contains a few minor wording changes to try to make the
applicability clearer.
We've also added Peter van Dijk from PowerDNS as a co-author.
Ray
Forwarded Message
Subject: New Version Notification for draft-bellis-dnsop-edns-tags-01.txt
Date: Mon, 25 Mar 2019 07:0
Ted Lemon wrote:
> On Mar 25, 2019, at 4:04 PM, Tony Finch wrote:
> > If I understand it correctly, DTLS leaves MTU and fragmentation up to the
> > application protocol. The DNS has horrible packet size problems, so it
> > needs a lot more help than DTLS provides. QUIC is much better.
>
> Indeed.
It seems like SACK would make the problem less bad in theory, but wouldn’t
eliminate the problem. With DNS-over-DTLS, if a packet is lost, the next
packet still gets an immediate answer, because DTLS is a datagram protocol, not
a stream protocol. The retry strategy for DNS-over-DTLS would be
On Mon, Mar 25, 2019 at 04:30:01PM +0100, Ray Bellis wrote:
>
>
> On 25/03/2019 16:08, Puneet Sood wrote:
>
> > you mean lots of changes or lots of agreement with the quoted text?
> > They mean very different things.
>
> I was agreeing with the quoted text - I believe that any serving of
> sta
Peter J. Philipp wrote:
>
> I'm in contact with the original RFC 2845 authors for clarifications
> on what is meant in section 4.4 for the meaning of "Prior MAC
> (running)". In the bis draft this is in section 6.4 and seems
> unchanged. I'm having a hard time understanding this as an
> implement
Paul Vixie writes:
> i would withdraw that objection if this draft incorporates section 2 of
> https://tools.ietf.org/html/draft-vixie-dnsext-resimprove-00, to wit:
I always liked resimprove. Warren and I were talking about it, and if
you would like we'd be quite happy to pick it up and get it m
bert hubert writes:
> I too object. This is partially due to the apparently unresolved IPR issue
> from Akamai, who are known not to be shy asserting their IPR.
This is definitely a problem. Even though Akamai had previously
agreed to specify under what IETF-acceptable terms the IPR would be
mad
> On Mar 25, 2019, at 3:47 PM, Olli Vanhoja wrote:
>
>> Section 3.2. discussion: Unless there's a potential benefit to non-apex
>> ZONEMD records that I'm not seeing, I think it makes sense to forbid them.
>> Was there a particular thing that could be enabled by that, which prompted
>> the
Ray Bellis writes:
> Serve stael must not become a vector whereby malware can keep its C&C
> systems artificially alive even if the parent has removed the C&C domain
> name.
I wholeheartedly agree with this ideal, and am very open to
considering text improvements.
The document already has guida
40 matches
Mail list logo
