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

[Olli Vanhoja]

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
> insight
> whether the one or the other has still a measurable heartbeat, to stay
> with the
> allegories ;-)
>

SVCB is active almost every day of the week in GitHub.

I can't talk on behalf of the authors of the ANAME draft, but to me it
seems that SVCB is getting more traction and it addresses the core problems
that ANAME was supposed to solve.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tommy Pauly]

+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 much lately on this list (I keep meaning to get back to 
> the chain-length discussion from a month or so back), but SVCB is definitely 
> very much still alive.  Lots of work is going on in its github to prepare the 
> next draft, so I assume we'll have another round of discussions here soon 
> whenever that is ready.
> 
> On Tue, Feb 18, 2020 at 11:17 AM 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 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 measurable heartbeat, to stay with 
> the 
> allegories ;-)
> 
> SVCB is active almost every day of the week in GitHub.
> 
> I can't talk on behalf of the authors of the ANAME draft, but to me it seems 
> that SVCB is getting more traction and it addresses the core problems that 
> ANAME was supposed to solve.
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org 
> https://www.ietf.org/mailman/listinfo/dnsop 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Rob Sayre]

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,
Rob
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tommy Pauly]

> 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 one: https://github.com/MikeBishop/dns-alt-svc 
> 
> 
> But I'm not sure that's the right one.

Yes, that is the correct GitHub.

Thanks,
Tommy
> 
> thanks,
> Rob
>  
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Warren Kumari]

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 relevant?
>
> I found this one: https://github.com/MikeBishop/dns-alt-svc
>
> But I'm not sure that's the right one.
>
>
> Yes, that is the correct GitHub.

Could I suggest adding something like:
[ RFC Editor - please remove before publication. This document is being
collaborated on in Github at:
https://github.com/MikeBishop/dns-alt-svc.  The most
recent version of the document, open issues, etc should all be
available here.  The authors (gratefully) accept pull requests.]

to the abstract - that way, people reading the draft know where submit PRs, etc.
W



>
> Thanks,
> Tommy
>
>
> thanks,
> Rob
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Erik Kline]

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 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.
> >
> >
> > Yes, that is the correct GitHub.
>
> Could I suggest adding something like:
> [ RFC Editor - please remove before publication. This document is being
> collaborated on in Github at:
> https://github.com/MikeBishop/dns-alt-svc.  The most
> recent version of the document, open issues, etc should all be
> available here.  The authors (gratefully) accept pull requests.]
>
> to the abstract - that way, people reading the draft know where submit
> PRs, etc.
> W
>
>
Seems like something worth noting in draft-ietf-git-using-github too (I
scanned the two wg docs and no existing text jumped out at me).


> >
> > Thanks,
> > Tommy
> >
> >
> > thanks,
> > Rob
> >
> > ___
> > DNSOP mailing list
> > DNSOP@ietf.org
> > https://www.ietf.org/mailman/listinfo/dnsop
> >
> >
> > ___
> > DNSOP mailing list
> > DNSOP@ietf.org
> > https://www.ietf.org/mailman/listinfo/dnsop
>
>
>
> --
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair
> of pants.
>---maf
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Erik Nygren]

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:

> 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 relevant?
> >
> > I found this one: https://github.com/MikeBishop/dns-alt-svc
> >
> > But I'm not sure that's the right one.
> >
> >
> > Yes, that is the correct GitHub.
>
> Could I suggest adding something like:
> [ RFC Editor - please remove before publication. This document is being
> collaborated on in Github at:
> https://github.com/MikeBishop/dns-alt-svc.  The most
> recent version of the document, open issues, etc should all be
> available here.  The authors (gratefully) accept pull requests.]
>
> to the abstract - that way, people reading the draft know where submit
> PRs, etc.
> W
>
>
>
> >
> > Thanks,
> > Tommy
> >
> >
> > thanks,
> > Rob
> >
> > ___
> > DNSOP mailing list
> > DNSOP@ietf.org
> > https://www.ietf.org/mailman/listinfo/dnsop
> >
> >
> > ___
> > DNSOP mailing list
> > DNSOP@ietf.org
> > https://www.ietf.org/mailman/listinfo/dnsop
>
>
>
> --
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair
> of pants.
>---maf
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Matthijs Mekking]

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 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 measurable heartbeat, to
> stay with the
> allegories ;-)
> 
> 
> SVCB is active almost every day of the week in GitHub.
> 
> I can't talk on behalf of the authors of the ANAME draft, but to me it
> seems that SVCB is getting more traction and it addresses the core
> problems that ANAME was supposed to solve.

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.

But yeah, the draft is pretty much dead due to lack of interest.

- Matthijs

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Klaus Malorny]

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.


Regards,

Klaus

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Shane Kerr]

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 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 measurable heartbeat, to
 stay with the
 allegories ;-)


SVCB is active almost every day of the week in GitHub.

I can't talk on behalf of the authors of the ANAME draft, but to me it
seems that SVCB is getting more traction and it addresses the core
problems that ANAME was supposed to solve.


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.

But yeah, the draft is pretty much dead due to lack of interest.


Is there a lack of interest? That's not clear to me. I think rather 
there are DNS folks who don't like ANAME for philosophical reasons and 
actively strive to prevent it moving forward.


Cheers,

--
Shane

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Matthijs Mekking]

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,
  Matthijs

On 2/20/20 10:59 AM, Shane Kerr wrote:
> 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 >> > 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 insight
>>>  whether the one or the other has still a measurable heartbeat, to
>>>  stay with the
>>>  allegories ;-)
>>>
>>>
>>> SVCB is active almost every day of the week in GitHub.
>>>
>>> I can't talk on behalf of the authors of the ANAME draft, but to me it
>>> seems that SVCB is getting more traction and it addresses the core
>>> problems that ANAME was supposed to solve.
>>
>> 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.
>>
>> But yeah, the draft is pretty much dead due to lack of interest.
> 
> Is there a lack of interest? That's not clear to me. I think rather
> there are DNS folks who don't like ANAME for philosophical reasons and
> actively strive to prevent it moving forward.
> 
> Cheers,
> 
> -- 
> Shane
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Evan Hunt]

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 from the right CDN server was the problem. CNAME at the apex was a
hackish nonstandard solution that we were forced to adopt by browser
vendors' failure to do anything more sensible.

If browser folks *are* doing something more sensible now, as appears to
be the case, then we no longer have the problem ANAME was meant to solve,
and I'm content to let it pass into history.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Vixie]

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.
> 
> ...
> 
> If browser folks *are* doing something more sensible now, as appears to
> be the case, then we no longer have the problem ANAME was meant to solve,
> and I'm content to let it pass into history.

noting that i am about to ask the browser community to remove their port 
number from httpsvc, i otherwise agree entirely with evan's words above.

-- 
Paul


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Benno Overeinder]

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 solution. So now I have to rethink our strategy.

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 problem."

If there is a specific use case for CNAME in the APEX (ANAME), I am
really interested to learn from this.

Thanks,

-- Benno

-- 
Benno J. Overeinder
NLnet Labs
https://www.nlnetlabs.nl/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Klaus Malorny]

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 problem."

If there is a specific use case for CNAME in the APEX (ANAME), I am
really interested to learn from this.

Thanks,

-- Benno



Hi Benno,

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 
promotions etc. The content for these domains are hosted by CDNs and not by us 
(we are not in that business right now). They want their domains to work also 
without a "www." prefix, and for now we use a web redirection service. This has 
some disadvantages, e.g. a "heavy" extra roundtrip to an HTTP server and in 
respect with HTTPS support. So our problem is exactly the "CNAME in the apex" 
problem. HTH.


Regard,

Klaus

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Vladimír Čunát]

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 promotions etc. The content for these
> domains are hosted by CDNs and not by us (we are not in that business
> right now). They want their domains to work also without a "www."
> prefix, and for now we use a web redirection service. This has some
> disadvantages, e.g. a "heavy" extra roundtrip to an HTTP server and in
> respect with HTTPS support. So our problem is exactly the "CNAME in
> the apex" problem. HTH. 

To me that sounds exactly like one of the main points addressed by
HTTPSSVC (draft).

--Vladimir

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Dan York]

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 display
content from the right CDN server was the problem."

If there is a specific use case for CNAME in the APEX (ANAME), I am
really interested to learn from this.

Similar to Karl’s customers, I want to use domains name without any subdomains 
to point to a CDN address and have the appropriate CDN edge node respond. I had 
outlined my perspective in a draft last year:

https://tools.ietf.org/html/draft-york-dnsop-cname-at-apex-publisher-view-01

What Evan says is true… it’s not so much that I “need” to have “CNAME at apex”. 
I just need some method that becomes widely available that allows web browsers 
(and other web endpoints) to go from “example.com” to a CDN 
node.

If HTTPSVC can do that, and browser vendors will implement it [1], then that 
use case can be satisfied.

Dan

[1] And, of course, to get “the DNS infrastructure” to allow domain registrants 
to get the HTTPSVC records updated with their DNS hosting operator, which often 
means upgrading those DNS operators to support the new record. But that is an 
issue with ALL of the various “new DNS record” solutions we’ve come up with.

--
Dan York, Director, Web Strategy / Project Leader, Open Standards 
Everywhere / 
Internet Society
y...@isoc.org | +1-603-439-0024 | 
@danyork

[cid:image001.png@01D5D03B.DF736FF0]
internetsociety.org | 
@internetsociety

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Klaus Malorny]

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 than the ANAME (as it 
addresses other problems, too), 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 specified in the ANAME draft. The 
question would be whether it needs to be addressed in the HTTPSSVC/SVCB 
specification in an appropriate manner.


Regards,

Klaus

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tim Wicinski]

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.  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 problem."
>
> If there is a specific use case for CNAME in the APEX (ANAME), I am
> really interested to learn from this.
>
>
> Similar to Karl’s customers, I want to use domains name without any
> subdomains to point to a CDN address and have the appropriate CDN edge node
> respond. I had outlined my perspective in a draft last year:
>
>
> https://tools.ietf.org/html/draft-york-dnsop-cname-at-apex-publisher-view-01
>
> What Evan says is true… it’s not so much that I “need” to have “CNAME at
> apex”. I just need some method that becomes widely available that allows
> web browsers (and other web endpoints) to go from “example.com” to a CDN
> node.
>
> If HTTPSVC can do that, and browser vendors will implement it [1], then
> that use case can be satisfied.
>
> Dan
>
> [1] And, of course, to get “the DNS infrastructure” to allow domain
> registrants to get the HTTPSVC records updated with their DNS hosting
> operator, which often means upgrading those DNS operators to support the
> new record. But that is an issue with ALL of the various “new DNS record”
> solutions we’ve come up with.
>
> --
> *Dan York*, Director, Web Strategy / Project Leader, Open Standards
> Everywhere
>  /
> Internet Society
> y...@isoc.org | +1-603-439-0024 | @danyork 
>
>
> internetsociety.org  | @internetsociety
> 
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Vladimír Čunát]

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 specified in the ANAME
> draft. The question would be whether it needs to be addressed in the
> HTTPSSVC/SVCB specification in an appropriate manner.

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.


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Klaus Malorny]

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 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)?


Regards,

Klaus

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Vladimír Čunát]

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 something like the apex CNAMEs one-sidedly
without workarounds (just on authoritative DNS servers).  That's
basically what the proprietary flattening schemes do today.

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 really want to open a long thread around this
topic again :-)

Your question: the benefit I see is that you make the processing
"better" for up-to-date clients, if I simplify it.  I think the browser
side will generally be well-incentivized to deploy httpssvc support
relatively widely/quickly (compared to usual DNS pace).

--Vladimir

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Erik Nygren]

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 really want to open a long thread around this
> topic again :-)
>

This is my perspective as well.  Some of the "proprietary CNAME flattening"
approaches done by CDNs are proprietary not because it wouldn't better
to standardize but because the design and implementation constraints
get insanely complex and not what we wanting to put into
authoritatives+recursives.
See this mail for some more context:
https://www.mail-archive.com/dnsop@ietf.org/msg20734.html

The HTTPSSVC record will help for new clients and it's hopeful that
major clients will have good incentives to implement it.
Some of the caveats (to not over-sell this approach and to set
expectations appropriately):

1) As mentioned, this only helps new clients.  (There is nothing preventing
   API clients from also implementing this, and they may have benefits as
well.)
   But this means the A/ fallback records may still be needed for some
   significant time for legacy clients.  Perhaps if traffic levels from
those
   get small enough that a complementary less-performant ANAME
   solution might be easier.

2) Some major web clients have indicated that they may only
support and query HTTPSSVC when received via
a secured transport such as DoH, at least initially.

3) The HTTPSSVC record also indicates that the site is only
   available over HTTPS, so won't be applicable for insecure
   HTTP-only sites.  Hopefully not a problem with HTTPS
   becoming the new default for most sites.
   It also will help performance for the common zone apex cases,
   especially where a user enters "example.com" into a browser.
   Right now browsers default to http (port 80) and (most now?) servers
   then redirect to https port 443.  So a HTTPS redirect is often in the
loop
   for some zone apex flows, and this removes that by signalling the use of
HTTPS.

One option might be to shelve ANAME for the time-being and then return back
to it in a few years if it still seems needed at that point?

   Erik
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Brian Dickson]

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 at the authoritative.  This would essentially standardize the
> existing industry practice, improving portability.
>

One of the key problems with ANAME (the concept, generally, and in
particular the requirement for the fallback A/ records) is the locality
problem:

Outside of the existing, proprietary CNAME flattening environments (where
the recursive and authoritative operator are the same), there is an
"impedance mismatch" problem with the ANAME left-hand-side and
right-hand-side DNS server locations.

The LHS (where the ANAME record would live) is on one DNS provider's
infrastructure.
The RHS (where the ANAME target would live) is on another DNS provider's
infrastructure, most typically a CDN operator.

The resolver is in a third location, and the ultimate client (stub, and web
browser typically) are in a fourth location.

The correct result can only be obtained from the CDN, if the resolver
location is closely aligned with the LHS, or if the LHS is closely aligned
with the RHS, in terms of whatever mechanism the CDN uses for selecting its
subset of responses (e.g. A/ records).

Put simply: unless one of those two things (resolver/LHS or LHS/RHS) are
about 1:1, the CDN *cannot* give the right answer reliably.

It isn't that ANAME couldn't give an answer, it is that it isn't guaranteed
to give the *right* answer.

HTTPSSVC/SVCB fixes this problem, by having either the stub or the resolver
be the one to get the A/ from the CDN (RHS) directly, and thus get the
*right* answer.

Or, in other words, the ANAME standardization is standardization in name
only, with the result being that good answers still only could be obtained
if the LHS was also the CDN operator.
It literally has no operational or functional benefit to DNS providers or
recursive operators or end users.

It's fundamental to the need for ANAME authorities to be the ones doing the
"fetch" of the A/ records to populate the fallback components.

In the absence of the fallback records, it devolves to being exactly what
the HTTPSSVC/SVCB drafts provide, with the caveat that it applies only the
web rather than handling all types of traffic.

(And, IMHO, this is a feature, not a bug.)

Brian



>
> Zone files containing ANAME would be portable only among
> authoritative servers that enable ANAME, but I think this is an unavoidable
> consideration due to long update cycles even if ANAME support were
> "mandatory", and is an easy criterion to understand for zone owners who
> choose to use ANAME.
>
> I believe this approach is nicely complementary to SVCB, for the reasons
> Erik mentioned.
>
> On Fri, Feb 21, 2020 at 12:30 PM Erik Nygren  wrote:
>
>> On Fri, Feb 21, 2020 at 9:53 AM Vladimír Čunát <
>> vladimir.cunat+i...@nic.cz> 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 really want to open a long thread around this
>>> topic again :-)
>>>
>>
>> This is my perspective as well.  Some of the "proprietary CNAME
>> flattening"
>> approaches done by CDNs are proprietary not because it wouldn't better
>> to standardize but because the design and implementation constraints
>> get insanely complex and not what we wanting to put into
>> authoritatives+recursives.
>> See this mail for some more context:
>> https://www.mail-archive.com/dnsop@ietf..org/msg20734.html
>> 
>>
>> The HTTPSSVC record will help for new clients and it's hopeful that
>> major clients will have good incentives to implement it.
>> Some of the caveats (to not over-sell this approach and to set
>> expectations appropriately):
>>
>> 1) As mentioned, this only helps new clients.  (There is nothing
>> preventing
>>API clients from also implementing this, and they may have benefits as
>> well.)
>>But this means the A/ fallback records may still be needed for some
>>significant time for legacy clients.  Perhaps if traffic levels from
>> those
>>get small enough that a complementary less-performant ANAME
>>solution might be easier.
>>
>> 2) Some major web clients have indicated that they may only
>> support and query HTTPSSVC when received via
>> a secured transport such as DoH, at least initially.
>>
>> 3) The HTTPSSVC record also indicates that the site is only
>>available over HTTPS, so won't be applicable for insecure
>>HTTP-only sites.  Hopefully not a problem with HTTPS
>>becoming the new default for most sites.
>>It also will help performance for the common zone ap

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

[Tony Finch]

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
with incomprehensible restrictions. ("It's always a DNS problem") Ideally
they should be able to configure aliases by name so that those responsible
for the server can move it around without having to reconfigure ridiculous
numbers of aliases.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Portland, Plymouth: West or southwest 6 to gale 8. Rough or very rough. Rain
and drizzle. Moderate or poor.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Brian Dickson]

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 able to configure aliases by name or address without having to deal
> with incomprehensible restrictions. ("It's always a DNS problem") Ideally
> they should be able to configure aliases by name so that those responsible
> for the server can move it around without having to reconfigure ridiculous
> numbers of aliases.
>

I'm not sure if this is a philosophical thing, or a pragmatic thing.

But the root problem with apex aliasing (CNAME/DNAME/ANAME/etc), is the
huge deployed base.
Also, that the original design of DNS didn't have this built in.
And also, that the whole semantic of CNAME usage is hidden from the clients
(things querying DNS), rather than exposed to the applications.
(E.g. should it not be the case that whatever is making the query, itself
be aware of the aliasing?)

Ultimately, I think this boils down to this observation:
DNS zone files are not really a good place to implement any user-exposed
schemes for aliasing, or for maintaining server/name mapping.

Those two things are UI and provisioning, respectively, and both are
probably handled with systems above or outside of DNS, rather than DNS
itself.

UI for the former (that deals with the DNS oddities), and automation or
APIs that deal with the latter.
Whenever there is a need for a bunch of names, plus the apex itself, to be
treated as synonymous, why does it matter which of those is the "target"?
That's really a bike-shed issue, IMHO.
The only time it is a problem, is if the target is external to the zone, in
which case the single instance at the apex is the problem (i.e. the main
issue of the ANAME or HTTPSSVC alias-form).

Moving a server (renumbering, etc), always requires synchronization between
a bunch of systems, only one of which is DNS itself.
E.g. certificate management, networking, etc.
Keeping those in sync requires some tooling.
Thus, adding the DNS component into the tooling doesn't seem to be
cumbersome.
It is perhaps a place where more infrastructure development to handle
scaling is required.

I.e., it'd be nice if DNS could deal with these things better, but it
can't, and it isn't the only possible solution, so, pretty much any other
solution can be made to work.
The choice of which alternative is really an implementation question, which
doesn't require standardization.
It's analogous to meta-data stuff, which also relates to provisioning of
DNS itself.
It's another place where in a parallel universe, it might have been good to
have been included in the design of DNS.

Brian
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Bob Harold]

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, 2020 at 8:12 PM Brian Dickson 
wrote:

>
>
> 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 able to configure aliases by name or address without having to deal
>> with incomprehensible restrictions. ("It's always a DNS problem") Ideally
>> they should be able to configure aliases by name so that those responsible
>> for the server can move it around without having to reconfigure ridiculous
>> numbers of aliases.
>>
>
> I'm not sure if this is a philosophical thing, or a pragmatic thing.
>
> But the root problem with apex aliasing (CNAME/DNAME/ANAME/etc), is the
> huge deployed base.
> Also, that the original design of DNS didn't have this built in.
> And also, that the whole semantic of CNAME usage is hidden from the
> clients (things querying DNS), rather than exposed to the applications.
> (E.g. should it not be the case that whatever is making the query, itself
> be aware of the aliasing?)
>
> Ultimately, I think this boils down to this observation:
> DNS zone files are not really a good place to implement any user-exposed
> schemes for aliasing, or for maintaining server/name mapping.
>
> Those two things are UI and provisioning, respectively, and both are
> probably handled with systems above or outside of DNS, rather than DNS
> itself.
>
> UI for the former (that deals with the DNS oddities), and automation or
> APIs that deal with the latter.
> Whenever there is a need for a bunch of names, plus the apex itself, to be
> treated as synonymous, why does it matter which of those is the "target"?
> That's really a bike-shed issue, IMHO.
> The only time it is a problem, is if the target is external to the zone,
> in which case the single instance at the apex is the problem (i.e. the main
> issue of the ANAME or HTTPSSVC alias-form).
>
> Moving a server (renumbering, etc), always requires synchronization
> between a bunch of systems, only one of which is DNS itself.
> E.g. certificate management, networking, etc.
> Keeping those in sync requires some tooling.
> Thus, adding the DNS component into the tooling doesn't seem to be
> cumbersome.
> It is perhaps a place where more infrastructure development to handle
> scaling is required.
>
> I.e., it'd be nice if DNS could deal with these things better, but it
> can't, and it isn't the only possible solution, so, pretty much any other
> solution can be made to work.
> The choice of which alternative is really an implementation question,
> which doesn't require standardization.
> It's analogous to meta-data stuff, which also relates to provisioning of
> DNS itself.
> It's another place where in a parallel universe, it might have been good
> to have been included in the design of DNS.
>
> Brian
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tony Finch]

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, Portland, Plymouth: West 5 to 7, increasing gale 8 later,
occasionally severe gale 9 in Portland and Plymouth, and perhaps in Wight.
Moderate or rough, becoming rough or very rough except in Dover, then becoming
very rough or high later in west Portland and in Plymouth. Squally showers.
Good, occasionally poor.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Andrew M. Hettinger]

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. Considering how much push-back was given from that world
on just letting svc entries be an option, I don't really believe that buy
in is going to happen let alone quickly.

Rather then a "quick win" I fear httpssvc is going to be a "slow loss."

Andrew Hettinger
http://Prominic.NET | Skype: AndrewProminic
Tel: 866.339.3169 (toll free) -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] status of the aname and svcb/httpsvc
drafts
> Sent by: "DNSOP" 
>
> 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, 2020 at 8:12 PM Brian Dickson
 > wrote:
>
> 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 able to configure aliases by name or address without having to deal
> with incomprehensible restrictions. ("It's always a DNS problem") Ideally
> they should be able to configure aliases by name so that those
responsible
> for the server can move it around without having to reconfigure
ridiculous
> numbers of aliases.
>
> I'm not sure if this is a philosophical thing, or a pragmatic thing.
>
> But the root problem with apex aliasing (CNAME/DNAME/ANAME/etc), is
> the huge deployed base.
> Also, that the original design of DNS didn't have this built in.
> And also, that the whole semantic of CNAME usage is hidden from the
> clients (things querying DNS), rather than exposed to the applications.
> (E.g. should it not be the case that whatever is making the query,
> itself be aware of the aliasing?)
>
> Ultimately, I think this boils down to this observation:
> DNS zone files are not really a good place to implement any user-
> exposed schemes for aliasing, or for maintaining server/name mapping.
>
> Those two things are UI and provisioning, respectively, and both are
> probably handled with systems above or outside of DNS, rather than DNS
itself.
>
> UI for the former (that deals with the DNS oddities), and automation
> or APIs that deal with the latter.
> Whenever there is a need for a bunch of names, plus the apex itself,
> to be treated as synonymous, why does it matter which of those is
> the "target"? That's really a bike-shed issue, IMHO.
> The only time it is a problem, is if the target is external to the
> zone, in which case the single instance at the apex is the problem
> (i.e. the main issue of the ANAME or HTTPSSVC alias-form).
>
> Moving a server (renumbering, etc), always requires synchronization
> between a bunch of systems, only one of which is DNS itself.
> E.g. certificate management, networking, etc.
> Keeping those in sync requires some tooling.
> Thus, adding the DNS component into the tooling doesn't seem to be
cumbersome.
> It is perhaps a place where more infrastructure development to
> handle scaling is required.
>
> I.e., it'd be nice if DNS could deal with these things better, but
> it can't, and it isn't the only possible solution, so, pretty much
> any other solution can be made to work.
> The choice of which alternative is really an implementation
> question, which doesn't require standardization.
> It's analogous to meta-data stuff, which also relates to
> provisioning of DNS itself.
> It's another place where in a parallel universe, it might have been
> good to have been included in the design of DNS.
>
> Brian
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Joe Abley]

> 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 configure aliases by name or address without having to deal
> with incomprehensible restrictions.

I had a customer once who was interested in ANAME-like behaviour as a
means of pushing DNS responses from their authority servers located in
their own data centres to commercial DNS provider authority servers,
where resolvers might find them more reliably.

The data centre/origin authority servers in question were load
balancers ("GSLB") that synthesised responses based on real-time
parameters that were not trivial to reproduce in commercial enterprise
DNS services.

In effect, queries from the world would be handled by the enterprise
DNS service infrastructure and the responses would be provisioned from
the customer-maintained origin servers using exactly the DNS protocol.

This provided a mechanism to de-risk the customer-maintained origin
servers which were otherwise seen as at risk from DDoS.


Joe

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Joe Abley]

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 have this backwards.


Joe

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Vladimír Čunát]

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 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.  Also I'm unsure how big a part of
authoritative implementations will want to do ANAME expansion.  (It
seems unlikely for "our" Knot DNS, for example.)

Of course, none of this will really prevent anyone from deploying it,
even though it won't be ideal, e.g. often without more precise answers
due to non-supporting resolvers.  Clearly we do have deployments even
now :-)

--Vladimir

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tony Finch]

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 future,
and not necessary for deployment. Existing ANAME implementations
work fine without it.

The ANAME draft is far too complicated. I tried to simplify it but in
retrospect I didn't go far enough.

There might still be some value in an ANAME draft that simply specifies
the syntax of the record, just to provide portability of zone files
between implementations that currently have non-standard ANAME or ALIAS
records. In this boiled-dry draft, ANAME would have absolutely no special
normative semantics, just an informative description of the relationship
between the sibling and target address records with no description of how
that should be achieved. (Note a domain might have more than one ANAME,
for existing implementations that support round-robin ANAMEs.) So the
codepoint could be allocated via expert review rather than standards
action.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
strengthen the democratic process and ensure that
there is a just and representative system of government___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Evan Hunt]

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 these days; resolvers
sit for years. (A few years ago there were still BIND 4 instances ticking
away out there.)

And, people who want their browsers to work better will have a specific
reason to upgrade. Resolver operators' motiivation is rather less direct.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Olli Vanhoja]

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 is far too complicated. I tried to simplify it but in
> retrospect I didn't go far enough.
>

That's actually why I was very interested in the draft last year. I had to
make exporting and importing Zone files with ANAMEs possible. Since
an ANAME would have caused a syntax error with any parser not
written by me, I ended up adding a semicolon at the beginning of every
such line. That worked just fine enough because it's very unlikely that
someone would accidentally write a comment looking exactly like an
ANAME RR.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Lanlan Pan]

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  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 future,
> and not necessary for deployment. Existing ANAME implementations
> work fine without it.
>
> The ANAME draft is far too complicated. I tried to simplify it but in
> retrospect I didn't go far enough.
>
+1

>
> There might still be some value in an ANAME draft that simply specifies
> the syntax of the record, just to provide portability of zone files
> between implementations that currently have non-standard ANAME or ALIAS
> records. In this boiled-dry draft, ANAME would have absolutely no special
> normative semantics, just an informative description of the relationship
> between the sibling and target address records with no description of how
> that should be achieved. (Note a domain might have more than one ANAME,
> for existing implementations that support round-robin ANAMEs.) So the
> codepoint could be allocated via expert review rather than standards
> action.
>
> Tony.
> --
> f.anthony.n.finchhttp://dotat.at/
> strengthen the democratic process and ensure that
> there is a just and representative system of
> government___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Vixie]

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 in browsers.
> 
> I agree with this. Browsers often upgrade themselves these days; resolvers
> sit for years. (A few years ago there were still BIND 4 instances ticking
> away out there.)

+1.

-- 
Paul


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Erik Nygren]

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 resolver.
>

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 (involving geo-ip, GSLB, etc)
is often highly dynamic and proprietary.  How does this get conveyed
from the authorities for the ANAME target to the authorities for the zone
containing the ANAME?  This is where we seem to get stuck.

CNAMEs provide an abstraction here given that they're implemented
and followed by recursives so policies can be implemented based
on the recursive IP and/or the ECS sent by the recursive IP.

With an authority-only ANAME, the geo-ip/GSLB/etc policy can't
be implemented by the authority for the zone containing the ANAME
and any requests the authority makes won't be fine-grained enough
to be useful.

If the customer problem is "I want to be able to CNAME example.com to
example.com.some-example-cdn.net" then ANAME won't solve if
it users don't get directed to the right place or if the service provider
for the target of the ANAME makes it clear that this configuration
voids any performance+availability SLAs.

   Erik
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Andrew M. Hettinger]

"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: "DNSOP" 
>
> 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 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.  Also I'm unsure how big a part of
> authoritative implementations will want to do ANAME expansion.  (It
> seems unlikely for "our" Knot DNS, for example.)
>

Is there actually a commitment from browser makers to implement it?

That's was the whole reason we don't just use the existing svc entries for
http/https: browsers refused to implement it. This will be the second time
trying to push a solution of this nature on the browser makers. Why is it
going to work this time? I mean, if it does, great. I will joyously hold my
hat and admit I was wrong.

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.

> Of course, none of this will really prevent anyone from deploying it,
> even though it won't be ideal, e.g. often without more precise answers
> due to non-supporting resolvers.  Clearly we do have deployments even
> now :-)
>
> --Vladimir
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Dan York]

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 browsers.

I agree with this. Browsers often upgrade themselves these days; resolvers
sit for years. (A few years ago there were still BIND 4 instances ticking
away out there.)

Very much agree with this. A few years ago a couple of us wrote a draft about 
all the pieces of the DNS infrastructure that need to be updated to support a 
new DNSSEC algorithm: 
https://tools.ietf.org/html/draft-york-dnsop-deploying-dnssec-crypto-algs-06

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
- authoritative servers need to upgraded to process the ANAME record
- DNS hosting providers (which can often also be registrars) need to have 
updated software to allow customers to enter ANAME records
- DNSSEC signing software may need to be updated to sign the ANAME record 
(section 4.2 in the ANAME draft notes the sibling resolution that must occur 
before signing)

All of that will take some time, and probably a long time in the case of 
resolvers and the GUIs of DNS hosting providers.

Now, some element of this will ALSO be true for rolling out the HTTPSVC record, 
(ex. DNS configuration GUIs) but it may not be quite as challenging as getting 
resolvers updated. (For example, all the resolvers found in “home routers” 
distributed by ISPs.)

Which is not to say that we shouldn’t pursue ANAME or other new RR types… we 
just have to acknowledge that it may be a l time before the 
functionality is available to a large number of users.

Dan



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Joe Abley]

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 ANAME-like ALIAS
functionality that were implemented on authority servers and have not
needed any changes on recursive servers.

(Recursive servers also don't generally need upgrades to support new RRTypes.)

> - authoritative servers need to upgraded to process the ANAME record

Yes. In the ALIAS cases that I know of that happened in the form of
product offerings from commercial operators who had a commercial
reason to make them.

> - DNS hosting providers (which can often also be registrars) need to have 
> updated software to allow customers to enter ANAME records

In the enterprise case where its non-trivial to use multiple providers
because of all the Stupid DNS Tricks you need as a customer, this is
the same as the previous point.

> - DNSSEC signing software may need to be updated to sign the ANAME record 
> (section 4.2 in the ANAME draft notes the sibling resolution that must occur 
> before signing)

DNSSEC wasn't implemented in the cases I'm aware of (at least while I
was paying attention) but if you can generate signatures at response
time I don't think ANAME makes anything more complicated.


Joe

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Lanlan Pan]

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, GSLB, ...
>> 3) No upgrade on recursive and resolver.
>>
>
> 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 (involving geo-ip, GSLB, etc)
> is often highly dynamic and proprietary.  How does this get conveyed
> from the authorities for the ANAME target to the authorities for the zone
> containing the ANAME?  This is where we seem to get stuck.
>
Agree,  CDN target is high dynamic.

>
>
> CNAMEs provide an abstraction here given that they're implemented
> and followed by recursives so policies can be implemented based
> on the recursive IP and/or the ECS sent by the recursive IP.
>

> With an authority-only ANAME, the geo-ip/GSLB/etc policy can't
> be implemented by the authority for the zone containing the ANAME
> and any requests the authority makes won't be fine-grained enough
> to be useful.
>
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).

>
> If the customer problem is "I want to be able to CNAME example.com to
> example.com.some-example-cdn.net" then ANAME won't solve if
> it users don't get directed to the right place or if the service provider
> for the target of the ANAME makes it clear that this configuration
> voids any performance+availability SLAs.
>
Yes, the common problem is no more clear information to select the best IP.

I think ANAME is not a "must" upgrade for recursive. Public recursive has
designed many policies to deal with multiple CNAME RRs response (from ECS
queries, or different resolve servers receive different CNAME from
authoritative).


>Erik
>
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Vladimír Čunát]

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.

Sure; this topic recurs once a while.  There were more parties, but I'm
lazy so I'm only sending one reference for Chrome/ium:
https://mailarchive.ietf.org/arch/msg/dnsop/eAyMNJkPMLYrQ--ItMTM9wV94kg/

I really appreciate that the HTTPSSVC authors put effort into working
with multiple client vendors from the very start.


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Vladimír Čunát]

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 case of a
zone apex.  From my point of view, one of the main reasons for all the
ANAME variants is that *this* is causing problems, although it kind-of
works in many cases.


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tony Finch]

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 (involving geo-ip, GSLB, etc)
> is often highly dynamic and proprietary.  How does this get conveyed
> from the authorities for the ANAME target to the authorities for the zone
> containing the ANAME?  This is where we seem to get stuck.

I imagine a boiled-dry draft would leave this unspecified, allowing
implementations to be as lazy or eager as they want. I think this
enthusiasm to accurately reproduce all the crazy DNS tricks is doomed to
failure, and not actually necessary. If a domain owner really truly wants
to spread their domain with Brand X secret sauce they can get Brand X to
host it, and if they can live with a cheap 3rd party ANAME knock-off then
that can be done much more simply.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Fisher, German Bight: Cyclonic mainly southwesterly, becoming westerly, 4 to
6. Slight or moderate becoming moderate or rough. Wintry showers. Good,
occasionally poor.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Anthony Eden]

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 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 (involving geo-ip, GSLB, etc)
> > is often highly dynamic and proprietary.  How does this get conveyed
> > from the authorities for the ANAME target to the authorities for the zone
> > containing the ANAME?  This is where we seem to get stuck.
>
> I imagine a boiled-dry draft would leave this unspecified, allowing
> implementations to be as lazy or eager as they want. I think this
> enthusiasm to accurately reproduce all the crazy DNS tricks is doomed to
> failure, and not actually necessary. If a domain owner really truly wants
> to spread their domain with Brand X secret sauce they can get Brand X to
> host it, and if they can live with a cheap 3rd party ANAME knock-off then
> that can be done much more simply.
>
> Tony.
> --
> f.anthony.n.finchhttp://dotat.at/
> Fisher, German Bight: Cyclonic mainly southwesterly, becoming westerly, 4
> to
> 6. Slight or moderate becoming moderate or rough. Wintry showers. Good,
> occasionally poor.
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>


-- 
DNSimple.com
http://dnsimple.com/
Twitter: @dnsimple
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Matthijs Mekking]

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:  [External]  [DNSOP] status of the aname and svcb/httpsvc
> drafts
>> Sent by: "DNSOP" 
>>
>> 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 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.  Also I'm unsure how big a part of
>> authoritative implementations will want to do ANAME expansion.  (It
>> seems unlikely for "our" Knot DNS, for example.)
>>
> 
> Is there actually a commitment from browser makers to implement it?

ANAME and its proprietary friends try to solve the issue it within the
DNS, so there is no need for commitment from browser makers.

- Matthijs

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tim Wicinski]

"ANAME and its proprietary friends try to solve the issue it within the DNS"

Matthijs sums this wonderfully.  As a Chair, I would say ANAME is using DNS
to solve a DNS problem.
I felt Tony did an admirable job trying to simplify the current draft, but
it does seem like it's still too much.
The current draft covers Zone Transfers and DNSSEC, two issues which the WG
signaled out as
being crucial.  It is also a solution which works for whatever technology
replaces browsers.

As a chair, I stepped back and let the working group has this out as DNSOP
does best.  T

I've been happy to see the engagement on the svcb draft, as well as the
browser community.  The chairs
have felt that level of engagement was important for us to move svcb
forward.

Neither solution fully replaces the other, which makes a working group vote
of "A vs B" as not so simple.

tim


On Thu, Feb 27, 2020 at 12:13 PM Matthijs Mekking 
wrote:

>
>
> 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:  [External]  [DNSOP] status of the aname and svcb/httpsvc
> > drafts
> >> Sent by: "DNSOP" 
> >>
> >> 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 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.  Also I'm unsure how big a part of
> >> authoritative implementations will want to do ANAME expansion.  (It
> >> seems unlikely for "our" Knot DNS, for example.)
> >>
> >
> > Is there actually a commitment from browser makers to implement it?
>
> ANAME and its proprietary friends try to solve the issue it within the
> DNS, so there is no need for commitment from browser makers.
>
> - Matthijs
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tony Finch]

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 recursive lookups by
authoritative servers, which isn't possible for many implementations or
for many deployments (in particular signed zones where the auth servers
cannot have the private keys). And (as I've been arguing) dynamic lookups
aren't really necesasry for ANAME to work.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Fair Isle, Faeroes, Southeast Iceland: Mainly easterly 7 to severe gale 9,
occasionally storm 10 later, but cyclonic 3 for a time in southwest. Very
rough or high. Rain or wintry showers. Good, occasionally poor.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop