Re: [DNSOP] status of the aname and svcb/httpsvc drafts

Anthony Eden wrote: > My intention with the original draft I wrote > https://tools.ietf.org/html/draft-dnsop-eden-alias-rr-type-00 was to > provide just the basics. If anyone is interested we can always try to > resuscitate that draft at some point. Thanks for that :-) Unfortunately it requires

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

: "Andrew M. Hettinger" > >> Date: 02/26/2020 08:35 > >> Subject: Re: [External] [DNSOP] status of the aname and svcb/httpsvc > > drafts > >> Sent by: "DNSOP" > >> > >> On 2/25/20 8:07 PM, Andrew M. Hettinger wrote: > >> >

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

On 2/26/20 11:28 PM, Andrew M. Hettinger wrote: > "DNSOP" wrote on 02/26/2020 08:34:55: > >> From: "Vladimír Čunát" >> To: "dnsop@ietf.org WG" >> Cc: "Andrew M. Hettinger" >> Date: 02/26/2020 08:35 >> Subject: Re

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

My intention with the original draft I wrote https://tools.ietf.org/html/draft-dnsop-eden-alias-rr-type-00 was to provide just the basics. If anyone is interested we can always try to resuscitate that draft at some point. -Anthony On Thu, Feb 27, 2020 at 11:03 AM Tony Finch wrote: > Erik

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

Erik Nygren wrote: > I don't follow how this works for the non-trivial static case. > You have two authoritative parties, one for the authoritative zone > and one authoritative for the ANAME target. > Both are operated by different entities. > > The logic and policy for the ANAME target

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

On 2/27/20 4:51 AM, Lanlan Pan wrote: > [...] > Just configure ANAME in the zonefile,  authortitative return response > is CNAME, no ANAME. > If enable DNSSEC, this will cause some dynamic signature > calculation（ECDSA will be better). I would (generally) NOT recommend sending CNAME in answer in

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

On 2/26/20 11:28 PM, Andrew M. Hettinger wrote: > Is there actually a commitment from browser makers to implement it? > [...] > But let's be clear, the biggest group that we need buy-in from are the > chromium devs. Without them, this isn't worth the bits we've sent down > the wire discussing it.

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

Erik Nygren 于2020年2月27日周四 上午5:38写道： > 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,

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

On Feb 26, 2020, at 14:35, Dan York wrote: > While a new RR type is obviously different from a crypto algorithm, the > “system upgrade” is similar: > > - resolvers have to be upgraded to support the new behavior of the ANAME > record For what it's worth, there are numerous examples of

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

On Feb 26, 2020, at 2:01 PM, Evan Hunt mailto:e...@isc.org>> wrote: On Wed, Feb 26, 2020 at 03:34:55PM +0100, Vladimír Čunát wrote: I don't think it's so simple. The current ANAME draft specifies new behavior for resolvers, and there I'd expect even slower overall upgrades/deployment than in

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

"DNSOP" wrote on 02/26/2020 08:34:55: > From: "Vladimír Čunát" > To: "dnsop@ietf.org WG" > Cc: "Andrew M. Hettinger" > Date: 02/26/2020 08:35 > Subject: Re: [External] [DNSOP] status of the aname and svcb/httpsvc drafts > Sent by:

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

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

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

On Wednesday, 26 February 2020 19:01:40 UTC Evan Hunt wrote: > On Wed, Feb 26, 2020 at 03:34:55PM +0100, Vladimír Čunát wrote: > > I don't think it's so simple. The current ANAME draft specifies new > > behavior for resolvers, and there I'd expect even slower overall > > upgrades/deployment than

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

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 resolver. Tony Finch 于2020年2月27日周四 上午1:25写道： > Vladimír Čunát

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

On Wed, Feb 26, 2020 at 6:25 PM Tony Finch wrote: > > From my point of view that was the least important part of it, > an optional extra that might help out CDNs some time in the future, > and not necessary for deployment. Existing ANAME implementations > work fine without it. > > The ANAME draft

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

On Wed, Feb 26, 2020 at 03:34:55PM +0100, Vladimír Čunát wrote: > I don't think it's so simple.  The current ANAME draft specifies new > behavior for resolvers, and there I'd expect even slower overall > upgrades/deployment than in browsers. I agree with this. Browsers often upgrade themselves

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

Vladimír Čunát wrote: > > The current ANAME draft specifies new behavior for resolvers, and there > I'd expect even slower overall upgrades/deployment than in browsers.  From my point of view that was the least important part of it, an optional extra that might help out CDNs some time in the

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

On 2/25/20 8:07 PM, Andrew M. Hettinger wrote: > Frankly, you've got it exactly the wrong way around: even with httpsvc > speced out completely, it will take time for it to be deployed to > browsers. That's assuming you can get enough buying from (mostly) > google to even make it happen at all. I

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

On Feb 24, 2020, at 19:27, Tony Finch wrote: > Bob Harold wrote: > >> Just my opinion, but I would like to focus on HTTPSSVC first, for a quick >> win. Then work on ANAME - it might not be used much anytime soon, > > ANAME has been widely deployed in various forms for many years. +1. Bob, you

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

> On Feb 22, 2020, at 19:01, Tony Finch wrote: > > Evan Hunt wrote: >> >> CNAME at the apex wasn't really the problem. Getting browsers to display >> content from the right CDN server was the problem. > > My interest in ANAME is basically nothing to do with CDNs. I want my users > to be able to

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

-or- 1.217.356.2888 x. 110 (int'l) Fax: 866.372.3356 (toll free) -or- 1.217.356.3356(int'l) "DNSOP" wrote on 02/24/2020 08:50:51: > From: "Bob Harold" > To: "dnsop@ietf.org WG" > Date: 02/24/2020 08:51 > Subject: Re: [External] [DNSOP]

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

Bob Harold wrote: > Just my opinion, but I would like to focus on HTTPSSVC first, for a quick > win. Then work on ANAME - it might not be used much anytime soon, ANAME has been widely deployed in various forms for many years. Tony. -- f.anthony.n.finchhttp://dotat.at/ Dover, Wight,

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

Just my opinion, but I would like to focus on HTTPSSVC first, for a quick win. Then work on ANAME - it might not be used much anytime soon, but if it reaches 99% of the DNS servers in 10 or 20 years, it could solve the problem at the apex for future generations. -- Bob Harold On Sat, Feb 22,

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

On Sat, Feb 22, 2020 at 4:01 PM Tony Finch wrote: > Evan Hunt wrote: > > > > CNAME at the apex wasn't really the problem. Getting browsers to display > > content from the right CDN server was the problem. > > My interest in ANAME is basically nothing to do with CDNs. I want my users > to be

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

Evan Hunt wrote: > > CNAME at the apex wasn't really the problem. Getting browsers to display > content from the right CDN server was the problem. My interest in ANAME is basically nothing to do with CDNs. I want my users to be able to configure aliases by name or address without having to deal

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

On Fri, Feb 21, 2020 at 11:05 AM Ben Schwartz wrote: > I agree with Erik's characterization of the problem. Personally, I favor > an _optional_, authoritative-only specification for ANAME, so that ANAME > can be present in zone files if the server supports it, and it is processed > 100% locally

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

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

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

On 2/21/20 3:01 PM, Klaus Malorny wrote: > simply that I want to get rid of it. IMHO one aim of a new technology > should be to make old technology obsolete, esp. such workarounds. If I > have to keep them (forever?), where is the benefit (for me as a company)? I see.  You'd like to deploy

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

On 21.02.20 14:44, Vladimír Čunát wrote: On 2/21/20 2:23 PM, Klaus Malorny wrote: My understanding of the plan is that for fallbacks we'll have what people are using now, e.g. that http redirect.  Perhaps you can elaborate on why that doesn't seem sufficient. Hi Vladimir, simply that I want

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

On 2/21/20 2:23 PM, Klaus Malorny wrote: > I see a major drawback in comparison to the ANAME draft, namely that > there seems to be no fallback for old browsers (and robot software > accessing websites) being defined. Of course, authoritative name > servers could implement a similar mechanism as

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

Similar to Dan, I have HTTPS based API services whose endpoints are at a zone apex. Tim On Fri, Feb 21, 2020 at 7:19 AM Dan York wrote: > Benno, > > On Feb 21, 2020, at 4:08 AM, Benno Overeinder wrote: > > I am interested to learn what the problem is that the customer wants to > solve.

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

On 21.02.20 13:19, Dan York wrote: If HTTPSVC can do that, and browser vendors will implement it [1], then that use case can be satisfied. Dan Hi all, I have to admit that I haven't worked through the HTTPSSVC/SVCB draft in detail, but while it seems to provide much more functionality

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

Benno, On Feb 21, 2020, at 4:08 AM, Benno Overeinder mailto:be...@nlnetlabs.nl>> wrote: I am interested to learn what the problem is that the customer wants to solve. Quoting from the email from Evan Hunt in this thread: "CNAME at the apex wasn't really the problem. Getting browsers to

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

On 2/21/20 1:04 PM, Klaus Malorny wrote: > according to my colleagues, who are in contact with the customers, the > use case is mostly in the context of CDNs. Some of them maintain a > larger set of domains with alternate spellings of their product names, > with different ccTLDs, some for

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

On 21.02.20 10:08, Benno Overeinder wrote: I am interested to learn what the problem is that the customer wants to solve. Quoting from the email from Evan Hunt in this thread: "CNAME at the apex wasn't really the problem. Getting browsers to display content from the right CDN server was the

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

Hi Karl, On 2/20/20 10:31 AM, Klaus Malorny wrote: > thanks all for responding, this was very informative for me. The lack of > interest for the ANAME draft is a bit pity. We have some customer > requests in this direction and I was hoping to be able to offer them a > standards compliant

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

On Thursday, 20 February 2020 22:15:17 UTC Evan Hunt wrote: > On Thu, Feb 20, 2020 at 09:29:31AM +0100, Matthijs Mekking wrote: > > ANAME was supposed to solve the CNAME at the apex problem and mitigate > > against DNS vendor lock in. Both SVCB and HTTPSSCV do not fix this > > problem. > > ... >

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

On Thu, Feb 20, 2020 at 09:29:31AM +0100, Matthijs Mekking wrote: > ANAME was supposed to solve the CNAME at the apex problem and mitigate > against DNS vendor lock in. Both SVCB and HTTPSSCV do not fix this problem. CNAME at the apex wasn't really the problem. Getting browsers to display content

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

Shane, There has been no discussions and no progress on ANAME since July 2019. If ANAME is something that (part of) the working group wants to work on, it requires more interaction, discussion to solve the final issues (see the github page https://github.com/each/draft-aname/). Best regards,

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

Matthijs, On 20/02/2020 09.29, Matthijs Mekking wrote: On 2/18/20 5:17 PM, Olli Vanhoja wrote: On Tue, Feb 18, 2020, 16:20 Klaus Malorny mailto:klaus.malo...@knipp.de>> wrote: I asked myself about the status of the two drafts. I got the impression a little bit that the

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

Hi, thanks all for responding, this was very informative for me. The lack of interest for the ANAME draft is a bit pity. We have some customer requests in this direction and I was hoping to be able to offer them a standards compliant solution. So now I have to rethink our strategy.

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

On 2/18/20 5:17 PM, Olli Vanhoja wrote: > > On Tue, Feb 18, 2020, 16:20 Klaus Malorny > wrote: > > > I asked myself about the status of the two drafts. I got the > impression a little > bit that the svcb/httpsvc draft successfully killed the aname

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

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:

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

On Wed, Feb 19, 2020 at 1:13 PM Warren Kumari wrote: > On Thu, Feb 20, 2020 at 6:13 AM Tommy Pauly > wrote: > > > > > > > > On Feb 18, 2020, at 6:15 PM, Rob Sayre wrote: > > > > On Tue, Feb 18, 2020 at 8:17 AM Olli Vanhoja > wrote: > >> > >> > >> SVCB is active almost every day of the week in

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

On Thu, Feb 20, 2020 at 6:13 AM Tommy Pauly wrote: > > > > On Feb 18, 2020, at 6:15 PM, Rob Sayre wrote: > > On Tue, Feb 18, 2020 at 8:17 AM Olli Vanhoja wrote: >> >> >> SVCB is active almost every day of the week in GitHub. > > > If someone wanted to follow this work, which GitHub repo is

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

> On Feb 18, 2020, at 6:15 PM, Rob Sayre wrote: > > On Tue, Feb 18, 2020 at 8:17 AM Olli Vanhoja > wrote: > > SVCB is active almost every day of the week in GitHub. > > If someone wanted to follow this work, which GitHub repo is relevant? > > I found this

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

On Tue, Feb 18, 2020 at 8:17 AM Olli Vanhoja wrote: > > SVCB is active almost every day of the week in GitHub. > If someone wanted to follow this work, which GitHub repo is relevant? I found this one: https://github.com/MikeBishop/dns-alt-svc But I'm not sure that's the right one. thanks,

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

+1 to the liveness of SVCB. As seen in the work on GitHub, there’s engagement from people working on ESNI and other use cases. I’ve been following the draft on GitHub and testing implementations, for example. Tommy > On Feb 18, 2020, at 10:07 AM, Eric Orth > wrote: > > Hasn't been discussed

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

On Tue, Feb 18, 2020, 16:20 Klaus Malorny wrote: > > I asked myself about the status of the two drafts. I got the impression a > little > bit that the svcb/httpsvc draft successfully killed the aname draft, but > is now > dying slowly itself. It would be great if somebody could give me some >

[DNSOP] status of the aname and svcb/httpsvc drafts

Hi all, I asked myself about the status of the two drafts. I got the impression a little bit that the svcb/httpsvc draft successfully killed the aname draft, but is now dying slowly itself. It would be great if somebody could give me some insight whether the one or the other has still a