Subject: [DNSOP] a CDN perspective on ANAME challenges

From: Erik Nygren <[email-masked]>
Date: Fri, 12 Jul 2019 13:52:02 -0400

One of the intended goals of ANAME is to improve interoperability of
onboarding onto CDNs for URLs at a zone apex, such as “http(s)://example.com
”.

The TL;DR is that ANAME is unlikely to allow interoperability here unless
authorities are willing to effectively and scalablely do recursion-with-ECS
for all requests (caching keyed by ECS prefix and obeying short, sub-minute
TTLs).  Simply resolving “sibling address records” on a zone master (per
draft-ietf-dnsop-aname-04) is likely to be declared incompatible and
unsupported (or at least severely restricted) by at least some (if not
many) CDNs.

For some background, Dan York highlights some sample use-cases here:

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

For example, web publishers want to do the equivalent of:

     example.com  300 IN CNAME a123qk.example-cdn.net.

Two use-cases (quoted from draft-york above):

1.  users will be able to simply enter "example.com" into their browser; and

2.  users will only see "example.com" in their address bar (if URLs are
even displayed).

Note that for some CDNs, the “a123qk.example-cdn.net” target name
dynamically selects which IP addresses to return based on a wide variety of
factors (recursive nameserver IP, end-user IP prefix passed via ECS,
dynamic load and liveness conditions, product, customer security
requirements, TLS certificate needed for non-SNI-only configurations, etc)
and often have short TTLs (often in the range of 20s to 60s, although
sometimes up to 300s).

Some CDNs have had vertically-integrated solutions for onboarding zone apex
names for years, allowing example.com to hand back CDN IPs as long as the
zone is delegated to the CDN authorities.  The need for these to be
vertically integrated comes from the level of complexity involved in
calculating these answers.

Even these vertically integrated solutions may have limitations.  For
example, one early vertically-integrated solution had very similar
functionality to some of the ANAME proposals.  It only covered case #1
above, handing out a subset of CDN IPs (with limited performance). Along
with this was a correlated site HTTP configuration that would issue a
30[127] redirect to “www.example.com” which would in-turn use a normal set
of CDN IPs.  This doesn’t help for the “users will only see ‘example.com’
in their address bar” case due to the need to redirect to a hostname that
can fully CNAME.

More advanced vertically-integrated solutions that can also handle case #2
may involve high-volume feeds of proprietary dynamic state and
configuration being fed to the authoritative nameservers, allowing them to
construct answers on-the-fly.

It is unclear if third-party authoritative servers will be able to do
enough here to be compatible with CDNs, at least until we get to a point
where most/all recursive servers support ANAME sibling address substitution
(and there are huge numbers of these around the world run by a huge variety
of operators!).

For third-party authoritative servers wishing to collapse A/AAAA names into
a zone as signalled by an ANAME, some of the options include:

   1.

   Primary zone master does sibling address substitution:  Some CDNs will
   declare this to be strictly incompatible.  (ie, all traffic would be
   directed to a small set of IPs associated with where the Primary Master is
   located).  This would defeat the purpose of using a non-purely-anycast
   CDN.
   2.

   Zone secondaries do frequent sibling address substitution:  Some CDNs
   may still declare this to be incompatible. Traffic is still directed to a
   small subset of IPs associated with where the zone secondaries are
   located.  If the zone secondaries are widely deployed, some CDNs might be
   able to support this using anycast configurations, although that might
   limit to a subset of products or limit to a subset of CDN server locations
   and might have CDN SLA limitations.
   3.

   Authoritative resolvers do a mixture of the following, which is likely
   what would be needed to be compatible with CDNs that do DNS-based traffic
   direction:

   -

      Online / on-demand lookups using ECS, with response caching.
      (Possibly requiring collaboration with the CDN to be on an ECS ACL or
      allowlist.)
      -

      Online DNSSEC signing.
      -

      Honoring short (eg, 20s-60s) response TTLs.
      -

      Having the scale/capacity and attack resilience to be able to support
      this possibly-low-cache-hit-rate request workload.

It is only the third of these that might actually work well enough, but may
add a huge amount of complexity to authorities, requiring the authority to
also have many recursive functionality.  It is possible that some
authoritative operators are willing and able to do this to enable
interoperability. However, if this set of functionality is what is required
to make ANAME work well enough to achieve its goals, then we should be
clear on that. It would be a mistake to go through all of the effort of
rolling out ANAME only to find that CDNs declare it to be incompatible.

I’ll add the caveat that the HTTPSSVC proposal doesn’t fully or magically
solve this problem either.  It is likely that A/AAAA records will need to
live at the zone apex for a long time to come. If those are static
addresses, they’ll likely still need to do 30[127]-style redirects to “
www.example.com” names.  However HTTPSSVC leaves an option for “example.com”
requests (eg, those containing an Alt-Used request header) to not need to
return a redirect, allowing a somewhat more graceful transition as client
adoption picks up.

    Erik

---

From: Mark Andrews <[email-masked]>
Date: Mon, 15 Jul 2019 09:08:17 +1000

> On 13 Jul 2019, at 3:52 am, Erik Nygren <[email-masked]> wrote:
> 
> One of the intended goals of ANAME is to improve interoperability of onboarding onto CDNs for URLs at a zone apex, such as “http(s)://example.com”.  
> 
> The TL;DR is that ANAME is unlikely to allow interoperability here unless authorities are willing to effectively and scalablely do recursion-with-ECS for all requests (caching keyed by ECS prefix and obeying short, sub-minute TTLs).  Simply resolving “sibling address records” on a zone master (per draft-ietf-dnsop-aname-04) is likely to be declared incompatible and unsupported (or at least severely restricted) by at least some (if not many) CDNs.
> 
> 2.  users will only see "example.com" in their address bar (if URLs are even displayed).
> 
> Note that for some CDNs, the “a123qk.example-cdn.net” target name dynamically selects which IP addresses to return based on a wide variety of factors (recursive nameserver IP, end-user IP prefix passed via ECS, dynamic load and liveness conditions, product, customer security requirements, TLS certificate needed for non-SNI-only configurations, etc) and often have short TTLs (often in the range of 20s to 60s, although sometimes up to 300s).
> 
> Some CDNs have had vertically-integrated solutions for onboarding zone apex names for years, allowing example.com to hand back CDN IPs as long as the zone is delegated to the CDN authorities.  The need for these to be vertically integrated comes from the level of complexity involved in calculating these answers.
> 
> Even these vertically integrated solutions may have limitations.  For example, one early vertically-integrated solution had very similar functionality to some of the ANAME proposals.  It only covered case #1 above, handing out a subset of CDN IPs (with limited performance).  Along with this was a correlated site HTTP configuration that would issue a 30[127] redirect to “www..example.com” which would in-turn use a normal set of CDN IPs.  This doesn’t help for the “users will only see ‘example.com’ in their address bar” case due to the need to redirect to a hostname that can fully CNAME.  
> 
> More advanced vertically-integrated solutions that can also handle case #2 may involve high-volume feeds of proprietary dynamic state and configuration being fed to the authoritative nameservers, allowing them to construct answers on-the-fly.
> 
> It is unclear if third-party authoritative servers will be able to do enough here to be compatible with CDNs, at least until we get to a point where most/all recursive servers support ANAME sibling address substitution (and there are huge numbers of these around the world run by a huge variety of operators!).  
> 
> For third-party authoritative servers wishing to collapse A/AAAA names into a zone as signalled by an ANAME, some of the options include:
> 
> 	• Primary zone master does sibling address substitution:  Some CDNs will declare this to be strictly incompatible.  (ie, all traffic would be directed to a small set of IPs associated with where the Primary Master is located).  This would defeat the purpose of using a non-purely-anycast CDN.   
> 	• Zone secondaries do frequent sibling address substitution:  Some CDNs may still declare this to be incompatible.  Traffic is still directed to a small subset of IPs associated with where the zone secondaries are located.  If the zone secondaries are widely deployed, some CDNs might be able to support this using anycast configurations, although that might limit to a subset of products or limit to a subset of CDN server locations and might have CDN SLA limitations.
> 	• Authoritative resolvers do a mixture of the following, which is likely what would be needed to be compatible with CDNs that do DNS-based traffic direction:
> 		• Online / on-demand lookups using ECS, with response caching.  (Possibly requiring collaboration with the CDN to be on an ECS ACL or allowlist.)
> 		• Online DNSSEC signing.
> 		• Honoring short (eg, 20s-60s) response TTLs.
> 		• Having the scale/capacity and attack resilience to be able to support this possibly-low-cache-hit-rate request workload.
> 
> It is only the third of these that might actually work well enough, but may add a huge amount of complexity to authorities, requiring the authority to also have many recursive functionality.  It is possible that some authoritative operators are willing and able to do this to enable interoperability. However, if this set of functionality is what is required to make ANAME work well enough to achieve its goals, then we should be clear on that. It would be a mistake to go through all of the effort of rolling out ANAME only to find that CDNs declare it to be incompatible.  
> 
> I’ll add the caveat that the HTTPSSVC proposal doesn’t fully or magically solve this problem either.  It is likely that A/AAAA records will need to live at the zone apex for a long time to come.  If those are static addresses, they’ll likely still need to do 30[127]-style redirects to “www.example.com” names.  However HTTPSSVC leaves an option for “example.com” requests (eg, those containing an Alt-Used request header) to not need to return a redirect, allowing a somewhat more graceful transition as client adoption picks up.

No one ever thought that it would.  With the transition from address to MX lookups for SMTP it took many years before you could just publish a MX record and have it work reliably enough.  The transition from A/AAAA to whatever was always going to take sometime (years) before you could reliably just publish the alternative.

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

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Matthijs Mekking <[email-masked]>
Date: Mon, 15 Jul 2019 10:56:13 +0200

Hi Erik,

Thanks for sharing this perspective.

On 7/12/19 7:52 PM, Erik Nygren wrote:
> onboarding onto CDNs for URLs at a zone apex, such as
> “http(s)://example.com <http://example.com>”.  
> 
> 
> The TL;DR is that ANAME is unlikely to allow interoperability here
> unless authorities are willing to effectively and scalablely do
> recursion-with-ECS for all requests (caching keyed by ECS prefix and
> obeying short, sub-minute TTLs).  Simply resolving “sibling address
> records” on a zone master (per draft-ietf-dnsop-aname-04) is likely to
> be declared incompatible and unsupported (or at least severely
> restricted) by at least some (if not many) CDNs.

The document is written in such a way that it is inter-operable, and can
work with offline DNSSEC signing, but authorities can still implement
their own "on-the-fly" ANAME processing that takes into account ECS and
perform online DNSSEC signing.  I suspect that authoritities with CDN
customers will do so, similar how they provide CNAME-at-the-apex
functionality now.

The benefit of ANAME over those vendor specific solutions is that
customers can have provider diversity and transfer their zone from one
to another.

(some more comments below)

>      example.com <http://example.com>  300 IN CNAME
> a123qk.example-cdn.net <http://a123qk.example-cdn.net>.
> 
> 
> 1.  users will be able to simply enter "example.com
> <http://example.com>" into their browser; and
> 
> 2.  users will only see "example.com <http://example.com>" in their
> address bar (if URLs are even displayed).
> 
> 
> Note that for some CDNs, the “*MailScanner heeft een e-mail met mogelijk
> een poging tot fraude gevonden van "a123qk..example-cdn.net" *
> a123qk.example-cdn.net <http://a123qk..example-cdn.net>” target name
> dynamically selects which IP addresses to return based on a wide variety
> of factors (recursive nameserver IP, end-user IP prefix passed via ECS,
> requirements, TLS certificate needed for non-SNI-only configurations,
> etc) and often have short TTLs (often in the range of 20s to 60s,
> although sometimes up to 300s).
> 
> 
> Some CDNs have had vertically-integrated solutions for onboarding zone
> apex names for years, allowing example.com <http://example.com> to hand
> back CDN IPs as long as the zone is delegated to the CDN authorities. 
> The need for these to be vertically integrated comes from the level of
> complexity involved in calculating these answers.
> 
> 
> 30[127] redirect to “*MailScanner heeft een e-mail met mogelijk een
> poging tot fraude gevonden van "www.example.com" * www..example.com
> <http://www.example.com>” which would in-turn use a normal set of CDN
> IPs.  This doesn’t help for the “users will only see ‘example.com
> <http://example.com>’ in their address bar” case due to the need to
> redirect to a hostname that can fully CNAME.  
> 
> 
> More advanced vertically-integrated solutions that can also handle case
> #2 may involve high-volume feeds of proprietary dynamic state and
> configuration being fed to the authoritative nameservers, allowing them
> to construct answers on-the-fly.
> 
> 
> where most/all recursive servers support ANAME sibling address
> substitution (and there are huge numbers of these around the world run
> by a huge variety of operators!).  
> 
> 
> For third-party authoritative servers wishing to collapse A/AAAA names
> into a zone as signalled by an ANAME, some of the options include:
> 
> 
>  1.
> 
>     Primary zone master does sibling address substitution:  Some CDNs
>     will declare this to be strictly incompatible.  (ie, all traffic
>     would be directed to a small set of IPs associated with where the
>     Primary Master is located).  This would defeat the purpose of using
>     a non-purely-anycast CDN.   
> 
>  2.
> 
>     Zone secondaries do frequent sibling address substitution:  Some
>     CDNs may still declare this to be incompatible. Traffic is still
>     directed to a small subset of IPs associated with where the zone
>     secondaries are located.  If the zone secondaries are widely
>     deployed, some CDNs might be able to support this using anycast
>     configurations, although that might limit to a subset of products or
>     limit to a subset of CDN server locations and might have CDN SLA
>     limitations.
> 
>  3.
> 
>     Authoritative resolvers do a mixture of the following, which is

Do you mean authoritative name servers here?

>     likely what would be needed to be compatible with CDNs that do
>     DNS-based traffic direction:
> 
>       o
> 
>         (Possibly requiring collaboration with the CDN to be on an ECS
>         ACL or allowlist.)
> 
>       o
> 
>         Online DNSSEC signing.
> 
>       o
> 
>       o
>         Having the scale/capacity and attack resilience to be able to
>         support this possibly-low-cache-hit-rate request workload.
> 
> 
> It is only the third of these that might actually work well enough, but
> may add a huge amount of complexity to authorities, requiring the
> authority to also have many recursive functionality.  It is possible
> that some authoritative operators are willing and able to do this to
> enable interoperability. However, if this set of functionality is what
> is required to make ANAME work well enough to achieve its goals, then we
> should be clear on that. It would be a mistake to go through all of the
> effort of rolling out ANAME only to find that CDNs declare it to be
> incompatible.

I agree that ANAME should fit the CDN use case, but there are other use
cases for ANAME that does not require ECS, online DNSSEC signing.  I
think the ANAME draft provides enough flexibility such that
authoritative servers can combine ANAME with the above features to fit
the CDN use case, but can also be a very simple setup for the "I just
want an address redirection from my apex domain name to 'www'".

If you feel like something specific is missing for the CDN case, please
let me know.

Thanks,

Matthijs

> I’ll add the caveat that the HTTPSSVC proposal doesn’t fully or
> magically solve this problem either.  It is likely that A/AAAA records
> will need to live at the zone apex for a long time to come. If those are
> static addresses, they’ll likely still need to do 30[127]-style
> redirects to “www.example.com <http://www.example.com>” names.  However
> HTTPSSVC leaves an option for “example.com <http://example.com>”
> requests (eg, those containing an Alt-Used request header) to not need
> to return a redirect, allowing a somewhat more graceful transition as
> client adoption picks up.
> 
> 
>     Erik
> 
>

---

From: Erik Nygren <[email-masked]>
Date: Mon, 22 Jul 2019 15:31:38 -0400

Reading the draft again, I think a challenge with the structure relative to
the CDN
use-case is that requirements on how and where sibling record resolution
is done are derived from the target of the ANAME, not from the
authoritative nameserver.

It may make sense to be much more clear on this, as what it means to
support ANAME
on an Authority  in an interoperable fashion depends on the DNS
architecture
of the expected targets of ANAMEs.  If the common use-case of ANAME is
to provide interoperability between authoritative DNS infrastructure for
zone apex ANAMEs that point to CDNs not operated by the DNS infrastructure,
then the common case for ANAME may need to be for authorities
to  "recurse with ECS to get the A/AAAA sibling record".

Otherwise the interoperability goal won't be achieved.
>From the perspective I've seen from my $dayjob at Akamai
(a large provider of CDN services), I suspect that CDNs
may say "we only support being the target of an ANAME
for third-party authorities that do X, Y, and Z" then it may
be confusing to mutual customers if that set of things
is only listed as being an optional variation in an appendix.
This seems like it has lots of risk of confusion around interoperability
and what it means for an authoritative DNS provider to
have "implemented ANAME".

> Do you mean authoritative name servers here?

Yes, authoritative nameservers, but also ones that effectively have
to be resolvers in-order to do inline sibling record resolution (and
caching)
and sending ECS.

       Erik

---

From: Matthijs Mekking <[email-masked]>
Date: Tue, 23 Jul 2019 10:39:08 +0200

Hi Erik,

On 7/22/19 9:31 PM, Erik Nygren wrote:
> Reading the draft again, I think a challenge with the structure relative
> to the CDN

It almost feels like this is a separate document: "Interoperable ANAME
services for DNS providers". Describe how to implement ANAME for this
specific (but large) use case.

Also, how does HTTPSSRVC deal with this?

Best regards,

Matthijs

> On Mon, Jul 15, 2019 at 4:56 AM Matthijs Mekking <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Hi Erik,
> 
>     > “http(s)://example.com <http://example.com> <http://example.com>”.  
>     >
>     >
>     >      example.com <http://example.com> <http://example.com>  300 IN
>     CNAME
>     > a123qk.example-cdn.net <http://a123qk.example-cdn.net>
>     <http://a123qk.example-cdn.net>.
>     >
>     >
>     <http://example.com>
>     > 2.  users will only see "example.com <http://example.com>
>     <http://example.com>" in their
>     > een poging tot fraude gevonden van "a123qk..example-cdn.net
>     <http://example-cdn.net>" *
>     > a123qk.example-cdn.net <http://a123qk.example-cdn.net>
>     <http://a123qk..example-cdn.net <http://example-cdn.net>>” target name
>     > apex names for years, allowing example.com <http://example.com>
>     <http://example.com> to hand
>     > poging tot fraude gevonden van "www.example.com
>     <http://www.example.com>" * www..example.com <http://example.com>
>     <http://example.com>
>     want an address redirection from my apex domain name to 'www'"..
> 
>     > redirects to “www.example.com <http://www.example.com>
>     <http://www.example.com>” names.  However
>     > HTTPSSVC leaves an option for “example.com <http://example.com>
>     <http://example.com>”
>     > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 23 Jul 2019 08:33:30 -0400

> Also, how does HTTPSSRVC deal with this?

HTTPSSVC gives responsibility for out-of-bailiwick lookups to the
recursive, or the stub if the recursive isn't HTTPSSVC-aware.  The
authoritative doesn't have to perform recursive-style lookups.

> >     > “http(s)://example.com <http://example.com> <http://example.com
> >”.
> >     >
> >     >

---

From: Matthijs Mekking <[email-masked]>
Date: Tue, 23 Jul 2019 16:32:51 +0200

On 7/23/19 2:33 PM, Ben Schwartz wrote:
> 
> 
> On Tue, Jul 23, 2019 at 4:39 AM Matthijs Mekking <[email-masked]

ANAME allows this too, but note that a solution that depends on the
resolver is going to be a deployment issue.

Target lookup for ANAME can be done at any point in time: At the
provisioning, at the authoritative, at the resolver, at the stub. So the
stub could already perform the out-of-bailiwick lookups by querying for
type ANAME and chase it to the target.

Best regards,

Matthijs

>     > On Mon, Jul 15, 2019 at 4:56 AM Matthijs Mekking
>     <[email-masked] <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>>
>     wrote:
>     >
>     >     Hi Erik,
>     >
>     >     > One of the intended goals of ANAME is to improve
>     interoperability of
>     >     > onboarding onto CDNs for URLs at a zone apex, such as
>     >     > “http(s)://example.com <http://example.com>
>     <http://example.com> <http://example.com>”.  
>     >     >
>     >     >
>     >     > The TL;DR is that ANAME is unlikely to allow
>     interoperability here
>     >     > unless authorities are willing to effectively and scalablely do
>     >     > recursion-with-ECS for all requests (caching keyed by ECS
>     prefix and
>     >     > obeying short, sub-minute TTLs).  Simply resolving “sibling
>     address
>     >     > records” on a zone master (per draft-ietf-dnsop-aname-04) is
>     likely to
>     >     > be declared incompatible and unsupported (or at least severely
>     >     > restricted) by at least some (if not many) CDNs.
>     >
>     >     > For some background, Dan York highlights some sample
>     use-cases here:
>     >     >
>     >     >
>     >   
>     >     >
>     >     > For example, web publishers want to do the equivalent of:
>     >     >
>     >     >      example.com <http://example.com> <http://example.com>
>     <http://example.com>  300 IN
>     >     CNAME
>     >     > a123qk.example-cdn.net <http://a123qk.example-cdn.net>
>     <http://a123qk.example-cdn.net>
>     >     >
>     >     >
>     >     > Two use-cases (quoted from draft-york above):
>     >     >
>     >     > 1.  users will be able to simply enter "example.com
>     <http://example.com>
>     >     <http://example.com>
>     >     > <http://example.com>" into their browser; and
>     >     >
>     >     > 2.  users will only see "example.com <http://example.com>
>     <http://example.com>
>     >     > address bar (if URLs are even displayed).
>     >     >
>     >     >
>     >     > Note that for some CDNs, the “*MailScanner heeft een e-mail met
>     >     mogelijk
>     >     > een poging tot fraude gevonden van "a123qk..example-cdn.net
>     <http://example-cdn.net>
>     >     > a123qk.example-cdn.net <http://a123qk.example-cdn.net>
>     <http://a123qk.example-cdn.net>
>     >     <http://a123qk..example-cdn.net <http://example-cdn.net>
>     <http://example-cdn.net>>” target name
>     >     > dynamically selects which IP addresses to return based on a wide
>     >     variety
>     >     > of factors (recursive nameserver IP, end-user IP prefix
>     passed via
>     >     ECS,
>     >     > dynamic load and liveness conditions, product, customer security
>     >     > requirements, TLS certificate needed for non-SNI-only
>     configurations,
>     >     > etc) and often have short TTLs (often in the range of 20s to
>     60s,
>     >     > although sometimes up to 300s).
>     >     >
>     >     >
>     >     > Some CDNs have had vertically-integrated solutions for
>     onboarding zone
>     >     > apex names for years, allowing example.com
>     <http://example.com> <http://example.com>
>     >     > back CDN IPs as long as the zone is delegated to the CDN
>     authorities. 
>     >     > The need for these to be vertically integrated comes from
>     the level of
>     >     > complexity involved in calculating these answers.
>     >     >
>     >     >
>     >     > Even these vertically integrated solutions may have
>     limitations.  For
>     >     > example, one early vertically-integrated solution had very
>     similar
>     >     > functionality to some of the ANAME proposals.  It only
>     covered case #1
>     >     > above, handing out a subset of CDN IPs (with limited
>     performance).
>     >     Along
>     >     > with this was a correlated site HTTP configuration that
>     would issue a
>     >     > 30[127] redirect to “*MailScanner heeft een e-mail met
>     mogelijk een
>     >     > poging tot fraude gevonden van "www.example.com
>     <http://www.example.com>
>     >     <http://www.example.com>" * www..example.com
>     <http://example.com> <http://example.com>
>     >     > <http://www.example.com>” which would in-turn use a normal
>     set of CDN
>     >     > IPs.  This doesn’t help for the “users will only see
>     ‘example.com <http://example.com>
>     >     <http://example.com>
>     >     > <http://example.com>’ in their address bar” case due to the
>     need to
>     >     > redirect to a hostname that can fully CNAME.  
>     >     >
>     >     >
>     >     > More advanced vertically-integrated solutions that can also
>     handle
>     >     case
>     >     > #2 may involve high-volume feeds of proprietary dynamic
>     state and
>     >     > configuration being fed to the authoritative nameservers,
>     allowing
>     >     them
>     >     > to construct answers on-the-fly.
>     >     >
>     >     >
>     >     > It is unclear if third-party authoritative servers will be
>     able to do
>     >     > enough here to be compatible with CDNs, at least until we
>     get to a
>     >     point
>     >     > where most/all recursive servers support ANAME sibling address
>     >     > substitution (and there are huge numbers of these around the
>     world run
>     >     > by a huge variety of operators!).  
>     >     >
>     >     >
>     >     > For third-party authoritative servers wishing to collapse
>     A/AAAA names
>     >     > into a zone as signalled by an ANAME, some of the options
>     include:
>     >     >
>     >     >
>     >     >  1.
>     >     >
>     >     >     Primary zone master does sibling address substitution: 
>     Some CDNs
>     >     >     will declare this to be strictly incompatible.  (ie, all
>     traffic
>     >     >     would be directed to a small set of IPs associated with
>     where the
>     >     >     Primary Master is located).  This would defeat the
>     purpose of
>     >     using
>     >     >     a non-purely-anycast CDN.   
>     >     >
>     >     >  2.
>     >     >
>     >     >     Zone secondaries do frequent sibling address
>     substitution:  Some
>     >     >     CDNs may still declare this to be incompatible. Traffic
>     is still
>     >     >     directed to a small subset of IPs associated with where
>     the zone
>     >     >     secondaries are located.  If the zone secondaries are widely
>     >     >     deployed, some CDNs might be able to support this using
>     anycast
>     >     >     configurations, although that might limit to a subset of
>     >     products or
>     >     >     limit to a subset of CDN server locations and might have
>     CDN SLA
>     >     >     limitations.
>     >     >
>     >     >  3.
>     >     >
>     >     >     Authoritative resolvers do a mixture of the following,
>     which is
>     >
>     >     >     likely what would be needed to be compatible with CDNs
>     that do
>     >     >     DNS-based traffic direction:
>     >     >
>     >     >       o
>     >     >
>     >     >         Online / on-demand lookups using ECS, with response
>     caching. 
>     >     >         (Possibly requiring collaboration with the CDN to be
>     on an ECS
>     >     >         ACL or allowlist.)
>     >     >
>     >     >       o
>     >     >
>     >     >         Online DNSSEC signing.
>     >     >
>     >     >       o
>     >     >
>     >     >         Honoring short (eg, 20s-60s) response TTLs.
>     >     >
>     >     >       o
>     >     >
>     >     >         Having the scale/capacity and attack resilience to
>     be able to
>     >     >         support this possibly-low-cache-hit-rate request
>     workload.
>     >     >
>     >     >
>     >     > It is only the third of these that might actually work well
>     >     enough, but
>     >     > may add a huge amount of complexity to authorities,
>     requiring the
>     >     > authority to also have many recursive functionality.  It is
>     possible
>     >     > that some authoritative operators are willing and able to do
>     this to
>     >     > enable interoperability. However, if this set of
>     functionality is what
>     >     > is required to make ANAME work well enough to achieve its goals,
>     >     then we
>     >     > should be clear on that. It would be a mistake to go through all
>     >     of the
>     >     > effort of rolling out ANAME only to find that CDNs declare
>     it to be
>     >     > incompatible.
>     >
>     >     > I’ll add the caveat that the HTTPSSVC proposal doesn’t fully or
>     >     > magically solve this problem either.  It is likely that
>     A/AAAA records
>     >     > will need to live at the zone apex for a long time to come. If
>     >     those are
>     >     > static addresses, they’ll likely still need to do 30[127]-style
>     >     > redirects to “www.example.com <http://www.example.com>
>     <http://www.example.com>
>     >     > HTTPSSVC leaves an option for “example.com
>     <http://example.com> <http://example.com>
>     >     <http://example.com>”
>     >     > requests (eg, those containing an Alt-Used request header)
>     to not need
>     >     > to return a redirect, allowing a somewhat more graceful
>     transition as
>     >     > client adoption picks up.
>     >     >
>     >     >
>     >     >     Erik
>     >     >
>     >     >
>     >     > _______________________________________________
>     >     > DNSOP mailing list
>     >     > [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     >     > https://www.ietf.org/mailman/listinfo/dnsop
>     >     >
>     >
>     >     [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>