> On 13 Jul 2019, at 3:52 am, Erik Nygren <e...@nygren.org> 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. > > 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: > > • 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 > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
