On 7/23/19 2:33 PM, Ben Schwartz wrote: > > > On Tue, Jul 23, 2019 at 4:39 AM Matthijs Mekking <matth...@pletterpet.nl > <mailto:matth...@pletterpet.nl>> 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 > <matth...@pletterpet.nl <mailto:matth...@pletterpet.nl> > > <mailto: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> <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 > > > DNSOP@ietf.org <mailto:DNSOP@ietf.org> > <mailto:DNSOP@ietf.org <mailto:DNSOP@ietf.org>> > > > https://www.ietf.org/mailman/listinfo/dnsop > > > > > > > _______________________________________________ > > DNSOP mailing list > > DNSOP@ietf.org <mailto:DNSOP@ietf.org> <mailto: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 <mailto:DNSOP@ietf.org> > https://www.ietf.org/mailman/listinfo/dnsop > _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
