Re: [DNSOP] a CDN perspective on ANAME challenges

[Matthijs Mekking <[e-mail]>]

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

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


>> >     Authoritative resolvers do a mixture of the following, which is
>> 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
> 
> 
> 
> 
> On Mon, Jul 15, 2019 at 4:56 AM Matthijs Mekking <[e-mail]
> <mailto:[e-mail]>> wrote:
> 
>     Hi Erik,
> 
>     Thanks for sharing this perspective.
> 
>     On 7/12/19 7:52 PM, Erik Nygren 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 <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.
> 
>     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)
> 
>     > 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 <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>" into their browser; and
>     >
>     > 2.  users will only see "example.com <http://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
>     <http://example-cdn.net>" *
>     > a123qk.example-cdn.net <http://a123qk.example-cdn.net>
>     <http://a123qk..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> 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 “*MailScanner heeft een e-mail met mogelijk een
>     > poging tot fraude gevonden van "www.example.com
>     <http://www.example.com>" * www..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>’ 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
> 
>     Do you mean authoritative name servers here?
> 
>     >     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 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>
>     <http://www.example.com>” names.  However
>     > HTTPSSVC leaves an option for “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
>     > [e-mail] <mailto:[e-mail]>
>     > https://www.ietf.org/mailman/listinfo/dnsop
>     >
> 
>     _______________________________________________
>     DNSOP mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/dnsop
> 
> 
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>