Subject: [DNSOP] ANAME high-level benefit question

From: Brian Dickson <[email-masked]>
Date: Fri, 10 May 2019 14:12:51 +0700

I know a lot of folks are spending a lot of time working on ANAME.

At the risk of offending those well-intentioned folks, the question I have
is a follows:

Have any "closed system" implementations of non-standard apex-CNAME hacks,
committed publicly to neutral ANAME operations, presuming ANAME as
currently envisioned?

I.e. If each such provider will ONLY support ANAME with targets on their
own infrastructure, I don't think the standardization effort will have any
real value.
On the other hand, if a substantial proportion of those providers have
committed to an even playing field support for ANAME targets and sibling
records, then the current ANAME proposal would have some value.

Reason for asking:
The effort of deploying ANAME might have a negative second-order effect, in
terms of resolver- or client-side (sibling-free) ANAME handling. The
sibling records would reduce or remove the impetus for deprecation of
sibling records, with all the scaling/performance issues that siblings
create.

If the "hack" providers won't do the sibling handling (with service parity)
for ANAME, then I'd prefer seeing the effort made on a non-sibling ANAME
instead.

Apologies in advance for any offense by use of terms "hack", or any
perceived aspersions to providers of such service.

Also, in the absence of such commitments, I think it would be fair to
presume non-parity (but nothing specific beyond that).

Brian

---

From: Vladimír Čunát <[email-masked]>
Date: Fri, 10 May 2019 10:57:02 +0200

On 5/10/19 9:12 AM, Brian Dickson wrote:
> Have any "closed system" implementations of non-standard apex-CNAME
> hacks, committed publicly to neutral ANAME operations, presuming ANAME
> as currently envisioned?

The #41 thread is what you'd like, I guess?  But so far there's only a
single provider's feedback (though it's positive), so there's certainly
lots of room for improvement.  It might prove hard to motivate those
that already do have some solution, but I can't really know.

https://github.com/each/draft-aname/issues/41

--Vladimir

---

From: Dave Lawrence <[email-masked]>
Date: Sat, 11 May 2019 04:54:46 -0400

Brian Dickson writes:
> hacks, committed publicly to neutral ANAME operations, presuming
> ANAME as currently envisioned?  I.e. If each such provider will
> ONLY support ANAME with targets on their own infrastructure, I don't
> think the standardization effort will have any real value.

I have a related question ... is allowing only targets on their own
infrastructure currently a limitation most such providers have?

I can't speak to Akamai's plans for implementing ANAME, but can say
that one of their apex-CNAME features allows any name to be used as a
target.  Their other feature allows only a subset of names on their
platform to be a target but that's an efficiency issue, not a policy
one, and I would expect their handling of ANAME to use that method
when appropriate or fall back to the general case otherwise.

---

From: Ray Bellis <[email-masked]>
Date: Sat, 11 May 2019 16:34:49 +0700

> infrastructure currently a limitation most such providers have?

I don't know about "most", but certainly some.   See e.g. the attached 
message posted here 2018/06/25.

Ray

Subject: Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex
From: Colm MacCárthaigh <[email-masked]>
To: Tony Finch <[email-masked]>
Cc: IETF DNSOP WG <[email-masked]>, Ray Bellis <[email-masked]>
Date: Mon, 25 Jun 2018 07:25:07 -0700
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>

On Mon, Jun 25, 2018 at 7:02 AM, Tony Finch <[email-masked]> wrote:

> > Even that though requires that the authoritative server be capable of
> > waiting for an asynchronously retrieved value before it can respond.
> >
> > For some authoritative servers that might require a substantial redesign.
>
> That isn't required if the ANAME target records are fetched/updated by an
> out-of-band provisioning process. A server will want to do it this way if
> its query rate is bigger than the number of ANAME targetss divided by
> their TTLs.
>

A challenge with that is that many people now use geographic or latency
based DNS routing based on the resolver IP address or EDNS-client-subnet.
That's one of the reasons why Route53's ALIAS works only for targets that
Route53 is authoritative for.

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

---

From: Ondřej Surý <[email-masked]>
Date: Sun, 12 May 2019 13:59:06 +0700

Also, I would argue that the ability to run ANAME at your own infrastructure
might drive less people to the “managed DNS” land or allow them to migrate
away without a significant loss of functionality.

One way or another, ANAME-like behaviour became defacto industry standard
and we need to have a solution on a protocol level.

Ondrej
--
Ondřej Surý
[email-masked]

> On 11 May 2019, at 16:34, Ray Bellis <[email-masked]> wrote:
> 
> 
> 
> I don't know about "most", but certainly some.   See e.g. the attached message posted here 2018/06/25.
> 
> Ray
> 
> <[DNSOP] abandoning ANAME and standardizing CNAME at apex.eml>_______________________________________________
> DNSOP mailing list
> [email-masked]

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 14 May 2019 15:31:35 +0800

configure several CNAME records to use multi-CDN service is also  widely used in industry, though this is not allowed by DNS standards.
shall we support this on protocal level? like defining new CNAMEx  record which contains "weight" attribute. 

[email-masked]
 
From: Ondřej Surý
Date: 2019-05-12 14:59
To: Brian Dickson; dnsop
Subject: Re: [DNSOP] ANAME high-level benefit question
Also, I would argue that the ability to run ANAME at your own infrastructure
might drive less people to the “managed DNS” land or allow them to migrate
away without a significant loss of functionality.

Ondrej
--
Ondřej Surý
[email-masked]

---

From: Olli Vanhoja <[email-masked]>
Date: Wed, 15 May 2019 11:03:33 +0300

> shall we support this on protocal level? like defining new CNAMEx  record which contains "weight" attribute.

I believe this is typically done at higher level. This higher level
often supports serving different responses based on geographical
location, latency etc.This information is derived from the IP prefix
using EDNS and by using anycast IP addresses etc.

I don't think any of this should be at the rr level. I do agree that
the higher level configuration language would be neat to standardize
but it's out of scope of this draft.

---

From: Richard Gibson <[email-masked]>
Date: Thu, 16 May 2019 13:43:14 -0400

> hacks, committed publicly to neutral ANAME operations, presuming ANAME 

Oracle are happy to see progress on ANAME and intend to support it. I 
personally have been active on the GitHub repository for the draft, with 
an eye to meaningful compatibility and ensuring that Oracle's support 
goes beyond trivial addition of ANAME records in response to A/AAAA 
queries in order to satisfy and deprecate existing proprietary "ALIAS" use.