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 <matth...@pletterpet.nl > <mailto:matth...@pletterpet.nl>> 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 > > DNSOP@ietf.org <mailto:DNSOP@ietf.org> > > https://www.ietf.org/mailman/listinfo/dnsop > > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org <mailto:DNSOP@ietf.org> > https://www.ietf.org/mailman/listinfo/dnsop > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
