On Tue, Mar 10, 2020 at 2:54 PM Paul Vixie wrote:
> httpssvc is not
> an alternate service description permitting fallback to the
> non-alternative;
> httpssvc is the service description itself.
>
7.2. Relationship to Alt-Svc
Publishing a ServiceForm HTTPSSVC record in DNS is intended to be
default host/port for the URI.
-Patrick
On Tue, Mar 10, 2020 at 12:24 PM Paul Vixie wrote:
> On Tuesday, 10 March 2020 13:30:53 UTC Patrick McManus wrote:
> > another positive feature of ports in this record is that it provides some
> > address space independent of the origin se
another positive feature of ports in this record is that it provides some
address space independent of the origin security model of the URI. By this
I mean that https://www.foo.com(implicit :443) and https://www.foo.com:555
are different origins with different web security boundaries. While two
dif
we should not limit the alias chain length across zones (other than for
loop protection which should be standardized) because there is no
administrative consistency across zones - its just a pointer. So the alias
you're pointing at now might become an alias itself later totally out of
your control.
On Fri, Dec 6, 2019 at 5:45 PM Eric Orth wrote:
>
>
>- Therefore, unless somebody comes up with a good reason that longer
>chains need to be supported, we intend to only follow 1 or 2 links before
>
>
>
I'm sure you're not trying to undermine the standards process, but that's
what happens
extended codes are pretty important in the DoH space - which doesn't
require library intermediaries. IIRC the very important use case was
disambiguating DNSSEC validation errors from other errors (as retry
behavior could very well be different). So this has been eagerly
anticipated.
On Tue, Oct 22
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 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
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
nt from my iPhone
>
> On Mar 24, 2019, at 10:42 PM, Patrick McManus
> wrote:
>
>
> On Sun, Mar 24, 2019 at 10:31 PM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
>>
>> This is important for network operators in identifying encrypted DNS
>>
On Sun, Mar 24, 2019 at 10:31 PM Brian Dickson <
brian.peter.dick...@gmail.com> wrote:
>
> This is important for network operators in identifying encrypted DNS
> traffic,
>
not all clients acknowledge a network's right to do such things at all
times. And of course it would be useful to tell the d
I want to add one thought to the general argument that goes along the lines
of "I need to enforce a policy on my network, and doh will just encourage
more https interception - we have gotten nowhere."
This argument assumes a scenario where the network is trusted by the
application and can require/
On Fri, Mar 22, 2019 at 11:15 AM Winfield, Alister wrote:
>
> Don't overplay the privacy provided by DoH it has no effect on the DNS
> provider
The major effect of the transport security on the privacy practices of the
provider is that it allows the client to authenticate the provider. Trust
in
for their indulgence) -
future communications should move to the new list.
New List Info
---
https://www.ietf.org/mailman/listinfo/resolverless-dns
-Patrick
On Mon, Jul 9, 2018 at 10:49 PM, Patrick McManus
wrote:
> Hi All,
>
> I am organizing an ad-hoc Sid
On Thu, Jul 19, 2018 at 3:07 PM, Patrick McManus
wrote:
>
> Am I correct in saying that what you're getting at is not so much a wire
> issue as a convention among configuration and implementations? i.e.
> wildcards are synthesized - they aren't actually sent as responses
convention among configuration and implementations? i.e.
wildcards are synthesized - they aren't actually sent as responses that
clients use in some kind of short-cut kind of way?
Thanks for the help.
> Jan
> On Thu, Jul 19, 2018 at 2:27 PM Patrick McManus
> wrote:
> >
> >
> On Thu, Jul 19, 2018 at 1:47 PM, Patrick McManus
> wrote:
>
>>
>> On Thu, Jul 19, 2018 at 1:36 PM, Jan Včelák wrote:
>>
>>> Hey,
>>>
>>> I just scanned the draft and focused mainly on the DNS bits. The
>>> described method for publishi
On Thu, Jul 19, 2018 at 1:36 PM, Jan Včelák wrote:
> Hey,
>
> I just scanned the draft and focused mainly on the DNS bits. The
> described method for publishing encryption keys for SNI in DNS won't
> allow use of wildcard domain names.
>
>
Thanks!
I believe the draft is OK on this point because
I will say that maprg has become my favorite "value added" event of IETF
week - terrific opportunity to learn about how the Internet really works in
ways a bit beyond (but relevant to) our usual focuses. (whatever those
focuses might be). Highly recommend.
On Wed, Jul 18, 2018 at 2:21 PM, Tim Wi
yes; and.. dns has always provided a point of indirection that is useful.
dynamically rewriting markup might be infeasible.. and many fetch() like
things are driven from script where the markup changes are not obvious or
perhaps ill fitting.. and of course there are questions of cached content
that
n, Jul 9, 2018 at 7:49 PM Patrick McManus
> wrote:
>
>>
>> *We'll do the meeting over 1 hour in the Dorchester room from 16:30 to
>> 17:30 on Monday July 16th.*
>>
>
> Will it be recorded and will there be everything set for remote
> participants?
>
&
> Assuming that in the context of DoH reply size is not an issue, is seems to
> me that this use case is already solved by DNSSEC. Just push all required
> signatures, key material and DS records that allow the receiving side to
> validate the additional information.
>
>
that validates its a valid
unapproved bof. The reason we don’t do
> those is that they tend to make it hard for people to participate. Why
> isn’t this in scope for dnsop?
>
> On Mon, Jul 9, 2018 at 10:49 PM Patrick McManus
> wrote:
>
>> Hi All,
>>
>> I am organizing an ad-hoc Side Meeti
Hi All,
I am organizing an ad-hoc Side Meeting regarding 'Resolverless DNS' in
Montreal.
We have often talked about the benefits and concerns of DNS information
obtained from sources that are, shall we say, less globally trusted than a
recursive a resolver. The central use case is DoH when pushed
Hi All,
We've had quite a thread re the -05 optional parameter to the
dns-udpwireformat registration.
The parameter is defined as having no meaning for DoH, but was included to
accommodate a use case the dnsop wg is considering. Future proofing, if you
like.
Upon consideration (and a read of 683
On Mon, Nov 14, 2016 at 7:52 AM, Patrick McManus
wrote:
> Our Bar BOF will be Tuesday evening at 6:45 in Studio 7 on the 6th Floor
> of the Conrad. See you there!
I should have mentioned - plan on a duration of 1 hour.
___
DNSOP mailing list
Our Bar BOF will be Tuesday evening at 6:45 in Studio 7 on the 6th Floor of
the Conrad. See you there!
as a reminder - this is our scope:
DNS over HTTP comes up again and again - each time the context is a bit
different. Some efforts try and extract information from the DNS via HTTP,
others try a
1, 2016 at 7:42 PM, Paul Hoffman
wrote:
> On Oct 20, 2016, at 9:57 AM, Patrick McManus wrote:
> > We're planning an informal Bar BOF on this topic Tuesday night in Seoul.
> The place is TBD - but I'll reply to this mail as we get closer with the
> detail. Just hold th
ssion there and
even a draft (thanks Paul and Joe!) - check it out on the archives.
-Patrick
On Tue, Sep 13, 2016 at 11:22 AM, Patrick McManus
wrote:
> Hi All -
>
> DNS over HTTP comes up again and again - each time the context is a bit
> different. Some efforts try and extract inform
Hi All -
DNS over HTTP comes up again and again - each time the context is a bit
different. Some efforts try and extract information from the DNS via HTTP,
others try and modify the DNS information via HTTP, others try and use HTTP
as a tunnel for the DNS protocol, and still others aim to integrat
30 matches
Mail list logo
