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

From: Klaus Malorny <[email-masked]>
Date: Tue, 18 Feb 2020 16:19:02 +0100

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

Thanks & greetings,

Klaus

---

From: Olli Vanhoja <[email-masked]>
Date: Tue, 18 Feb 2020 17:17:14 +0100

> whether the one or the other has still a measurable heartbeat, to stay

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.

---

From: Eric Orth <[email-masked]>
Date: Tue, 18 Feb 2020 13:07:02 -0500

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 <[email-masked]>
wrote:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Tommy Pauly <[email-masked]>
Date: Tue, 18 Feb 2020 18:07:12 -0800

+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 <ericorth=[email-masked]> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> 
> On Tue, Feb 18, 2020, 16:20 Klaus Malorny <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 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.
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dnsop <https://www.ietf.org/mailman/listinfo/dnsop>

---

From: Rob Sayre <[email-masked]>
Date: Tue, 18 Feb 2020 18:15:43 -0800

> 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

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 19 Feb 2020 11:13:24 -0800

> On Feb 18, 2020, at 6:15 PM, Rob Sayre <[email-masked]> wrote:
> 
> On Tue, Feb 18, 2020 at 8:17 AM Olli Vanhoja <[email-masked] <mailto:[email-masked]>> wrote:
> 
> I found this one: https://github.com/MikeBishop/dns-alt-svc <https://github.com/MikeBishop/dns-alt-svc>
> 

Yes, that is the correct GitHub.

Thanks,
Tommy

---

From: Warren Kumari <[email-masked]>
Date: Thu, 20 Feb 2020 08:12:45 +1100

> 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

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

---

From: Erik Kline <[email-masked]>
Date: Wed, 19 Feb 2020 15:29:18 -0800

> to the abstract - that way, people reading the draft know where submit
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).

---

From: Erik Nygren <[email-masked]>
Date: Wed, 19 Feb 2020 18:39:28 -0500

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

---

From: Matthijs Mekking <[email-masked]>
Date: Thu, 20 Feb 2020 09:29:31 +0100

On 2/18/20 5:17 PM, Olli Vanhoja wrote:
> 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

---

From: Klaus Malorny <[email-masked]>
Date: Thu, 20 Feb 2020 10:31:04 +0100

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

---

From: Shane Kerr <[email-masked]>
Date: Thu, 20 Feb 2020 10:59:47 +0100

Matthijs,

> 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

---

From: Matthijs Mekking <[email-masked]>
Date: Thu, 20 Feb 2020 12:09:01 +0100

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:
>>>      bit that the svcb/httpsvc draft successfully killed the aname
>>> draft,
>>>      but is now

---

From: Evan Hunt <[email-masked]>
Date: Thu, 20 Feb 2020 22:15:17 +0000

> 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 -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 20 Feb 2020 23:07:29 +0000

On Thursday, 20 February 2020 22:15:17 UTC Evan Hunt wrote:
> ...

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

---

From: Benno Overeinder <[email-masked]>
Date: Fri, 21 Feb 2020 10:08:51 +0100

Hi Karl,

On 2/20/20 10:31 AM, Klaus Malorny wrote:
> 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/

---

From: Klaus Malorny <[email-masked]>
Date: Fri, 21 Feb 2020 13:04:14 +0100

> really interested to learn from this.

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

---

From: Vladimír Čunát <[email-masked]>
Date: Fri, 21 Feb 2020 13:10:14 +0100

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

---

From: Dan York <[email-masked]>
Date: Fri, 21 Feb 2020 12:19:01 +0000

Benno,

On Feb 21, 2020, at 4:08 AM, Benno Overeinder <[email-masked]<mailto:[email-masked]>> wrote:

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<http://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<https://www.internetsociety.org/issues/open-standards-everywhere/> / Internet Society
[email-masked]<mailto:[email-masked]> | +1-603-439-0024 | @danyork<https://twitter.com/danyork>

internetsociety.org<https://www.internetsociety.org/> | @internetsociety<https://twitter.com/internetsociety>

---

From: Klaus Malorny <[email-masked]>
Date: Fri, 21 Feb 2020 14:23:29 +0100

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

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 21 Feb 2020 08:34:11 -0500

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 <[email-masked]> wrote:

> Benno,
>
> On Feb 21, 2020, at 4:08 AM, Benno Overeinder <[email-masked]> wrote:
>
> 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:
>
>
> 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.
>
> [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
> <https://www.internetsociety.org/issues/open-standards-everywhere/> /
> Internet Society
> [email-masked] | +1-603-439-0024 | @danyork <https://twitter.com/danyork>
>
>
> internetsociety.org <https://www.internetsociety.org/> | @internetsociety
> <https://twitter.com/internetsociety>
>

---

From: Vladimír Čunát <[email-masked]>
Date: Fri, 21 Feb 2020 14:44:02 +0100

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.

---

From: Klaus Malorny <[email-masked]>
Date: Fri, 21 Feb 2020 15:01:03 +0100

> 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

---

From: Vladimír Čunát <[email-masked]>
Date: Fri, 21 Feb 2020 15:52:55 +0100

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

---

From: Erik Nygren <[email-masked]>
Date: Fri, 21 Feb 2020 12:29:41 -0500

> Well, I suppose I don't really want to open a long thread around this

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/[email-masked]/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/AAAA 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

---

From: Ben Schwartz <[email-masked]>
Date: Fri, 21 Feb 2020 14:04:34 -0500

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.

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 <[email-masked]> wrote:

>     https://www.mail-archive.com/dnsop@ietf..org/msg20734.html
> <https://www.mail-archive.com/[email-masked]/msg20734.html>
>
>    for some zone apex flows, and this removes that by signalling the use
> of HTTPS.
>

---

From: Brian Dickson <[email-masked]>
Date: Fri, 21 Feb 2020 11:35:52 -0800

> existing industry practice, improving portability.

One of the key problems with ANAME (the concept, generally, and in
particular the requirement for the fallback A/AAAA 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/AAAA 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/AAAA 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/AAAA 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

>> On Fri, Feb 21, 2020 at 9:53 AM Vladimír Čunát <
>> [email-masked]> wrote:
>>

---

From: Tony Finch <[email-masked]>
Date: Sun, 23 Feb 2020 00:01:28 +0000

Evan Hunt <[email-masked]> wrote:
> 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.finch  <[email-masked]>  http://dotat.at/
Portland, Plymouth: West or southwest 6 to gale 8. Rough or very rough. Rain
and drizzle. Moderate or poor.

---

From: Brian Dickson <[email-masked]>
Date: Sat, 22 Feb 2020 17:11:47 -0800

> for the server can move it around without having to reconfigure ridiculous

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

---

From: Bob Harold <[email-masked]>
Date: Mon, 24 Feb 2020 09:50:51 -0500

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 <[email-masked]>
wrote:

> And also, that the whole semantic of CNAME usage is hidden from the
> clients (things querying DNS), rather than exposed to the applications.
> 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
> Moving a server (renumbering, etc), always requires synchronization
> between a bunch of systems, only one of which is DNS itself.
> The choice of which alternative is really an implementation question,
> which doesn't require standardization.
> It's another place where in a parallel universe, it might have been good
> to have been included in the design of DNS.
>
> Brian

---

From: Tony Finch <[email-masked]>
Date: Tue, 25 Feb 2020 00:27:37 +0000

Bob Harold <[email-masked]> wrote:

> 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.finch  <[email-masked]>  http://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.

---

From: "Andrew M. Hettinger" <[email-masked]>
Date: Tue, 25 Feb 2020 13:07:31 -0600

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" <[email-masked]> wrote on 02/24/2020 08:50:51:

> From: "Bob Harold" <[email-masked]>
> To: "[email-masked] WG" <[email-masked]>
> Date: 02/24/2020 08:51
> Subject: Re:  [External]  [DNSOP] status of the aname and svcb/httpsvc
drafts
> Sent by: "DNSOP" <[email-masked]>
>
> 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
<[email-masked]
> But the root problem with apex aliasing (CNAME/DNAME/ANAME/etc), is
> the huge deployed base.
> (E.g. should it not be the case that whatever is making the query,
> itself be aware of the aliasing?)
>
> DNS zone files are not really a good place to implement any user-
> exposed schemes for aliasing, or for maintaining server/name mapping.
>
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).
>
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

---

From: Joe Abley <[email-masked]>
Date: Tue, 25 Feb 2020 11:34:40 -0800

> On Feb 22, 2020, at 19:01, Tony Finch <[email-masked]> wrote:
>
> 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

---

From: Joe Abley <[email-masked]>
Date: Tue, 25 Feb 2020 11:36:33 -0800

> ANAME has been widely deployed in various forms for many years.

+1. Bob, you have this backwards.

Joe

---

From: Vladimír Čunát <[email-masked]>
Date: Wed, 26 Feb 2020 15:34:55 +0100

On 2/25/20 8:07 PM, Andrew M. Hettinger wrote:
> 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

---

From: Tony Finch <[email-masked]>
Date: Wed, 26 Feb 2020 17:24:32 +0000

Vladimír Čunát <[email-masked]> 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.finch  <[email-masked]>  http://dotat.at/
strengthen the democratic process and ensure that
there is a just and representative system of government

---

From: Evan Hunt <[email-masked]>
Date: Wed, 26 Feb 2020 19:01:40 +0000

On Wed, Feb 26, 2020 at 03:34:55PM +0100, Vladimír Čunát wrote:
> 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.

---

From: Olli Vanhoja <[email-masked]>
Date: Wed, 26 Feb 2020 20:32:45 +0100

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

---

From: Lanlan Pan <[email-masked]>
Date: Thu, 27 Feb 2020 03:33:54 +0800

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.

> retrospect I didn't go far enough.
+1

> there is a just and representative system of
> government_______________________________________________
> DNSOP mailing list
> [email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Wed, 26 Feb 2020 21:22:18 +0000

> sit for years. (A few years ago there were still BIND 4 instances ticking

+1.
	
-- 
Paul

---

From: Erik Nygren <[email-masked]>
Date: Wed, 26 Feb 2020 16:38:10 -0500

> 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

---

From: "Andrew M. Hettinger" <[email-masked]>
Date: Wed, 26 Feb 2020 16:28:19 -0600

"DNSOP" <[email-masked]> wrote on 02/26/2020 08:34:55:

> From: "Vladimír Čunát" <[email-masked]>
> Cc: "Andrew M. Hettinger" <[email-masked]>
> Date: 02/26/2020 08:35
drafts
> 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.

---

From: Dan York <[email-masked]>
Date: Wed, 26 Feb 2020 22:35:30 +0000

On Feb 26, 2020, at 2:01 PM, Evan Hunt <[email-masked]<mailto:[email-masked]>> wrote:

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 loooonnnngggg time before the functionality is available to a large number of users.

Dan

---

From: Joe Abley <[email-masked]>
Date: Wed, 26 Feb 2020 17:28:00 -0800

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

---

From: Lanlan Pan <[email-masked]>
Date: Thu, 27 Feb 2020 11:51:47 +0800

> containing the ANAME?  This is where we seem to get stuck.
Agree,  CDN target is high dynamic.

> and any requests the authority makes won't be fine-grained enough
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).

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

---

From: Vladimír Čunát <[email-masked]>
Date: Thu, 27 Feb 2020 10:48:40 +0100

On 2/26/20 11:28 PM, Andrew M. Hettinger wrote:
> [...]
> 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.

---

From: Vladimír Čunát <[email-masked]>
Date: Thu, 27 Feb 2020 11:00:30 +0100

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.

---

From: Tony Finch <[email-masked]>
Date: Thu, 27 Feb 2020 16:03:10 +0000

> 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.finch  <[email-masked]>  http://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.

---

From: Anthony Eden <[email-masked]>
Date: Thu, 27 Feb 2020 11:42:05 -0500

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

-- 
DNSimple.com
http://dnsimple.com/
Twitter: @dnsimple

---

From: Matthijs Mekking <[email-masked]>
Date: Thu, 27 Feb 2020 18:12:50 +0100

On 2/26/20 11:28 PM, Andrew M. Hettinger wrote:
>> From: "Vladimír Čunát" <vladimir.cunat+ietf@nic..cz>

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

---

From: "Andrew M. Hettinger" <[email-masked]>
Date: Thu, 27 Feb 2020 16:50:24 -0600

"DNSOP" <[email-masked]> wrote on 02/27/2020 11:12:50:

> From: "Matthijs Mekking" <[email-masked]>
> To: [email-masked]
> Date: 02/27/2020 11:13
drafts
> DNS, so there is no need for commitment from browser makers.

I was talking about httpssvc, obviously.

---

From: Tim Wicinski <[email-masked]>
Date: Thu, 27 Feb 2020 20:09:44 -0500

"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

---

From: Tony Finch <[email-masked]>
Date: Fri, 28 Feb 2020 20:38:01 +0000

> 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.finch  <[email-masked]>  http://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.