On Wed, Jul 24, 2024 at 10:18 AM Shumon Huque wrote:
>
> On your last point, yes, I think we can say that if a verifier sees
> multiple
> validation records, they can abort.
>
>
I'd think it would be better to allow looking at the full RRset and
succeeding if any of the records match?
This seems
I think mTLS (client certs) makes sense as a recommendation in
draft-tjjk-cared, but is critical to call out the privacy issues with TLS
client certs in TLS versions prior to TLS 1.3. (ie, in TLS 1.2 and before
the client certificates are sent in-the-clear in the handshake unless
renegotiation is
Thank you for writing this up! I think this is long-overdue
and I'd be supportive of the dnsop working group adopting this.
(It seems to make more sense for me to do this in dnsop while keeping v6ops
informed.)
We likely will want to cover the concerns that Geoff raises around
fragmentation,
but
It does seem like it would be good to document the "Authoritative Forwarding
Proxy" use-case as it is more common. There are a number of commercial
services doing this now, both for performance, DDoS defense, and other
use-cases.
An important thing we really should define is safeguards for loop
pr
Hello,
Thank you for pulling together this draft! Having worked on related
systems a number of times it will be valuable to have something here
standardized.
A number of comments and suggestions:
1) APEX domains, and hostnames vs domains
You define APEX but don't then reference this. This is
ocess.
Best, Erik
On Thu, Sep 29, 2022 at 9:16 AM Erik Nygren wrote:
> One item discussed above that the authors would like to clarify is to be
> consistent
> about whether the alternative endpoint name (TargetName) is a hostname
> or a domain name. In all but one place in the d
tances[0].
>
> W
>
> [0]: I'm not convinced that this situation rose to the "exceptional
> circumstances" bar, but seeing as I'd already paused it (not knowing what
> all the issues were) and because the changes are clarifications, I'm
> willing to acceptin
There seem to be two topics:
1) Victor's clarification makes sense, although the wording is a little
awkward and perhaps we can improve that sentence.
The section was already implying that meaning (ie, that the fallback
addition of the QNAME was for the AliasMode case)
but clarifying this
Catching up on this thread, I agree with Ben Schwartz, Tommy Pauly, and
Eric Orth
that the current behavior makes sense and that no fundamental technical
change is needed.
No matter what we do, odd faults and misconfigurations will happen and
Postel's law applies.
Client implementers will try and b
I think Expert Review makes sense (with the expert reviewing the SHOULD
around the specification).
On Tue, Mar 22, 2022 at 8:34 PM Martin Thomson wrote:
> I agree with Tommy.
>
> Selecting an expert who is able to recognize when wider review might help
> is a far lower bar than the one Ray sugge
On Wed, May 19, 2021 at 7:01 PM Brian Dickson
wrote:
>
>
> On Wed, May 19, 2021 at 3:00 PM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
>>
>>
>> On Wed, May 19, 2021 at 2:50 PM Paul Hoffman
>> wrote:
>>
>>> Are these still just idle ideas you are tossing out (as you indicated
>>> ea
On Wed, May 19, 2021 at 5:12 PM Tommy Pauly wrote:
>
>
> On May 19, 2021, at 1:34 PM, Brian Dickson
> wrote:
>
>
>
> On Wed, May 19, 2021 at 7:49 AM Tommy Pauly wrote:
>
>> I wanted to chime in on this discussion as a client-side implementor who
>> has already widely deployed support for SVCB/H
On Mon, May 17, 2021 at 5:36 PM Ben Schwartz wrote:
>
>
> On Sat, May 15, 2021 at 12:48 PM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
>>
>>
>> On Thu, May 13, 2021 at 10:25 AM Ben Schwartz wrote:
>>
>>>
>>>
>>> On Thu, May 13, 2021 at 12:51 AM Brian Dickson <
>>> brian.peter.dick.
On Wed, May 12, 2021 at 4:44 PM Brian Dickson
wrote:
>
> Having multiple AliasMode records within an RRset (with either the same or
> different Priority) would provide an avenue for dealing with resolution
> failure - which is one of the main reasons for any CDN customer to use
> multiple CDNs, i
We have a very incomplete list of work-in-progress SVCB/HTTPS RR
implementations here
for people who wish to do interop testing:
https://github.com/MikeBishop/dns-alt-svc/blob/master/svcb-implementations.md
Feel free to submit PRs to add to that list. At some point we may convert
it to something
er to avoid future ones needing to be artificially constrained. Is
there a reason we'd
want to decrease this (eg, to 31)?
On Wed, Jul 15, 2020 at 1:07 PM Ólafur Guðmundsson
wrote:
> How about 2 or 10 ?
> why do the names to need to be long ?
>
> Olafur
>
>
> On Thu, Jul
Would this be better as a SHOULD NOT? Or just better to remove this,
or replace with non-normative txt?
Opened: https://github.com/MikeBishop/dns-alt-svc/issues/221
On Mon, Jul 13, 2020 at 8:03 PM Mark Andrews wrote:
> Section 2.4.1. AliasMode paragraph 2. Why have "MUST NOT" here?
>
>
>T
Or 64?
- Erik
[Sent from my IPv6 connected T-Mobile 4G LTE mobile device]
On Thu, Jul 9, 2020, 9:40 PM Ben Schwartz wrote:
> How about 255 characters?
>
> On Thu, Jul 9, 2020 at 9:25 PM Mark Andrews wrote:
>
>> Can we please have a length limit on key names? At the moment they could
>
As discussed in a previous thread, we've renamed the HTTPSSVC RR to be the
"HTTPS" RR.
The SVCB RR is keeping its name.
A new version of the draft has been published with this change as well as
with other changes:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/
(We separated the
balancing information in a IP
>> constrained
>> > space. Just like the address is distinct from the URL, the port
>> separates
>> > the 'what' from the 'how' and that's good.
>>
>> your reply above precisely demonstrates the risk o
On Mon, Mar 9, 2020 at 10:32 PM Paul Vixie wrote:
> On Monday, 9 March 2020 20:56:39 UTC Ben Schwartz wrote:
> > It occurs to me that I hit "publish" on this draft without updating the
> > release notes, so I'll mention some of the many changes since -01 here
> > instead:
> >
> > ...
> >
> > As
On Wed, Feb 26, 2020 at 2:34 PM Lanlan Pan wrote:
> My option:
> 1) ANAME just configured in zonefile, and anlayzed by authoritative server.
> 2) Authoritative server response to recursive (or resolver) on its policy
> as before, such as geo-ip, GSLB, ...
> 3) No upgrade on recursive and resolve
On Fri, Feb 21, 2020 at 9:53 AM Vladimír Čunát
wrote:
> In this case however, I personally believe it's much better design *not*
> to put the link-following work on authoritative servers (or their
> provisioning) but further down the chain (resolvers and/or clients).
> Well, I suppose I don't rea
Good idea. Created a PR:
https://github.com/MikeBishop/dns-alt-svc/pull/110
But yes, we're actively working through issues on SVCB with the hope of
publishing
a new version shortly, and would certainly like to discuss in Vancouver.
Erik
On Wed, Feb 19, 2020 at 4:13 PM Warren Kumari wrote:
It is time to finalize names for HTTPSSVC and SVCB. Following a thread on
the DNSOP list that Tommy started, I created a poll incorporating some of
the ideas. After we get some feedback here, the WG chairs and authors will
pick a set to propose and see if we can get consensus. Here is a poll to
f
Some of my current leanings:
SVCB and HTTPB (SVCB and HTTPSB)
Of even shorter: "SB" and "HSB"
(I also prefer SVCHTTPS over HTTPSSVC as the latter is way too easy to
leave out one of the S's.)
I'd considered just calling "SVCB" as "B" but that makes it harder to
search for.
This is also why "H
- Forwarded message -
From:
Date: Mon, Sep 23, 2019 at 7:01 PM
Subject: New Version Notification for
draft-nygren-dnsop-svcb-httpssvc-00.txt
To: Mike Bishop , Erik Nygren ,
Benjamin Schwartz
A new version of I-D, draft-nygren-dnsop-svcb-httpssvc-00.txt
has been successfully submit
The device could also have an IPv6 interface via a tunnel or VPN client.
- Erik
[Sent from my IPv6 connected T-Mobile 4G LTE mobile device]
On Thu, Aug 29, 2019, 5:44 AM Naveen Kottapalli
wrote:
> My query was about the behavior we observed on a gateway where a pure v4
> subscriber (no
The need to bootstrap ESNI (encrypted SNI) keys via DNS is the forcing
function here for clients. They need to do something new here to address
that, and if that requires an additional lookup then there is opportunity
if other problems can be solved at the same time as long as we don't slow
down E
meservers, but also ones that effectively have
to be resolvers in-order to do inline sibling record resolution (and
caching)
and sending ECS.
Erik
On Mon, Jul 15, 2019 at 4:56 AM Matthijs Mekking
wrote:
> Hi Erik,
>
> Thanks for sharing this perspective.
>
> On 7/12/19 7:
One of the intended goals of ANAME is to improve interoperability of
onboarding onto CDNs for URLs at a zone apex, such as “http(s)://example.com
”.
The TL;DR is that ANAME is unlikely to allow interoperability here unless
authorities are willing to effectively and scalablely do recursion-with-ECS
ise, I think many of us would very much love to see this
> implemented, as much of ANAME is fundamentally incapable of meeting the
> intended goals, which this does very nicely.
>
> Brian
>
> On Mon, Jul 8, 2019 at 2:20 PM Erik Nygren wrote:
>
>> Ray, thanks for i
2019 18:46:25 +
> Resent-From:ietf-http...@w3.org
> Date: Wed, 3 Jul 2019 14:45:47 -0400
> From: Erik Nygren
> To: ietf-http...@w3.org Group , Mike Bishop
> , Erik Nygren , Benjamin
> Schwartz , Erik Nygren - Work
>
>
>
>
> Ben, Mike, and I have s
Some comments:
* We should define what TLS SNI value gets sent. Perhaps the first value
of "domain-to-match" when present, but preferably the hostname of the URL
when it's not an IP?
* Should clients consider the templates list to be ordered or unordered?
We may wish to define the behavior for h
How does draft-schwartz-httpbis-dns-alt-svc-02 with some changes to make it
more DNS-aligned (e.g. the name as a separate field in the record) not help
here? It comes from the HTTP world and is aligned with the existing AltSvc
feature and thus is useful in other ways (such as perhaps solving the D
On Thu, Nov 1, 2018 at 6:34 PM Brian Dickson
wrote:
> ...
>
> Third, there is an issue with the impact to anycast operation of zones
> with ANAMEs, with respect to differentiated answers, based on topological
> locations of anycast instances.
>
> There is currently an expectation on resolving a g
On Tue, Jun 19, 2018 at 11:24 AM, Ray Bellis wrote:
> On 19/06/2018 15:43, tjw ietf wrote:
>
> > I find it personally appalling we can spend so many cycles injecting
> > dns into http but we can’t be bothered to fix what end users want.
>
> It's the HTTP folks that are putting most of those cycle
On Fri, Jun 15, 2018 at 8:12 PM, Shumon Huque wrote:
> On Fri, Jun 15, 2018 at 6:40 PM Mark Andrews wrote:
>
>> What we should be asking is why a service that needs multiple machines
>> isn’t using SRV. It has randomisation between servers explicitly defined
>> along with proportional load balan
On Fri, Jun 15, 2018 at 3:52 PM, Mukund Sivaraman wrote:
> On Fri, Jun 15, 2018 at 02:38:00PM -0400, Bob Harold wrote:
> > Round-robin is a documented feature that many applications use. Removing
> > it from DNS resolvers, and then having to add it to a much larger number
> of
> > applications,
A number of folks have been bitten by a bug in bind 9.12 where it silently
changes the default sorting of rrsets to always be sorted (even if the
authoritative response wasn't sorted). This causes problems for services
assuming at least some degree of round-robin behavior by clients as now
many cl
On Mon, Aug 7, 2017 at 4:41 AM, Mike West wrote:
>
> I poked at the draft a bit over the weekend, reworking it into a
> stand-alone document in https://tools.ietf.org/
> html/draft-west-let-localhost-be-localhost-04. I think it ends up being
> clearer overall, and hopefully y'all agree.
>
This
I wrote a similar draft a few years ago which I've been considering
resurrecting if there is interest:
https://tools.ietf.org/html/draft-nygren-service-bindings-00
One of the big challenges that at least in the web context, browsers want
to make as few DNS lookups as possible prior to making
42 matches
Mail list logo
