Re: [DNSOP] a CDN perspective on ANAME challenges

[Matthijs Mekking <[e-mail]>]

On 7/23/19 2:33 PM, Ben Schwartz wrote:
> 
> 
> On Tue, Jul 23, 2019 at 4:39 AM Matthijs Mekking <[e-mail]
> <mailto:[e-mail]>> wrote:
> 
>     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?
> 
> 
> 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.

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


>  
> 
> 
>     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]>
>     > <mailto:[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> <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>
>     <http://example.com>  300 IN
>     >     CNAME
>     >     > a123qk.example-cdn.net <http://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>
>     >     <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>
>     >     <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>
>     >     <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>
>     >     <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
>     >
>     >     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>
>     >     <http://www.example.com>” names.  However
>     >     > 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
>     >     > [e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>
>     >     > https://www.ietf.org/mailman/listinfo/dnsop
>     >     >
>     >
>     >     _______________________________________________
>     >     DNSOP mailing list
>     >     [e-mail] <mailto:[e-mail]> <mailto:[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] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/dnsop
>