On Fri, Feb 21, 2020 at 11:05 AM Ben Schwartz <bemasc= 40google....@dmarc.ietf.org> wrote:
> I agree with Erik's characterization of the problem. Personally, I favor > an _optional_, authoritative-only specification for ANAME, so that ANAME > can be present in zone files if the server supports it, and it is processed > 100% locally at the authoritative. This would essentially standardize the > existing industry practice, improving portability. > One of the key problems with ANAME (the concept, generally, and in particular the requirement for the fallback A/AAAA records) is the locality problem: Outside of the existing, proprietary CNAME flattening environments (where the recursive and authoritative operator are the same), there is an "impedance mismatch" problem with the ANAME left-hand-side and right-hand-side DNS server locations. The LHS (where the ANAME record would live) is on one DNS provider's infrastructure. The RHS (where the ANAME target would live) is on another DNS provider's infrastructure, most typically a CDN operator. The resolver is in a third location, and the ultimate client (stub, and web browser typically) are in a fourth location. The correct result can only be obtained from the CDN, if the resolver location is closely aligned with the LHS, or if the LHS is closely aligned with the RHS, in terms of whatever mechanism the CDN uses for selecting its subset of responses (e.g. A/AAAA records). Put simply: unless one of those two things (resolver/LHS or LHS/RHS) are about 1:1, the CDN *cannot* give the right answer reliably. It isn't that ANAME couldn't give an answer, it is that it isn't guaranteed to give the *right* answer. HTTPSSVC/SVCB fixes this problem, by having either the stub or the resolver be the one to get the A/AAAA from the CDN (RHS) directly, and thus get the *right* answer. Or, in other words, the ANAME standardization is standardization in name only, with the result being that good answers still only could be obtained if the LHS was also the CDN operator. It literally has no operational or functional benefit to DNS providers or recursive operators or end users. It's fundamental to the need for ANAME authorities to be the ones doing the "fetch" of the A/AAAA records to populate the fallback components. In the absence of the fallback records, it devolves to being exactly what the HTTPSSVC/SVCB drafts provide, with the caveat that it applies only the web rather than handling all types of traffic. (And, IMHO, this is a feature, not a bug.) Brian > > Zone files containing ANAME would be portable only among > authoritative servers that enable ANAME, but I think this is an unavoidable > consideration due to long update cycles even if ANAME support were > "mandatory", and is an easy criterion to understand for zone owners who > choose to use ANAME. > > I believe this approach is nicely complementary to SVCB, for the reasons > Erik mentioned. > > On Fri, Feb 21, 2020 at 12:30 PM Erik Nygren <erik+i...@nygren.org> wrote: > >> On Fri, Feb 21, 2020 at 9:53 AM Vladimír Čunát < >> vladimir.cunat+i...@nic.cz> wrote: >> >>> In this case however, I personally believe it's much better design *not* >>> to put the link-following work on authoritative servers (or their >>> provisioning) but further down the chain (resolvers and/or clients). >>> Well, I suppose I don't really want to open a long thread around this >>> topic again :-) >>> >> >> This is my perspective as well. Some of the "proprietary CNAME >> flattening" >> approaches done by CDNs are proprietary not because it wouldn't better >> to standardize but because the design and implementation constraints >> get insanely complex and not what we wanting to put into >> authoritatives+recursives. >> See this mail for some more context: >> https://www.mail-archive.com/dnsop@ietf..org/msg20734.html >> <https://www.mail-archive.com/dnsop@ietf.org/msg20734.html> >> >> The HTTPSSVC record will help for new clients and it's hopeful that >> major clients will have good incentives to implement it. >> Some of the caveats (to not over-sell this approach and to set >> expectations appropriately): >> >> 1) As mentioned, this only helps new clients. (There is nothing >> preventing >> API clients from also implementing this, and they may have benefits as >> well.) >> But this means the A/AAAA fallback records may still be needed for some >> significant time for legacy clients. Perhaps if traffic levels from >> those >> get small enough that a complementary less-performant ANAME >> solution might be easier. >> >> 2) Some major web clients have indicated that they may only >> support and query HTTPSSVC when received via >> a secured transport such as DoH, at least initially. >> >> 3) The HTTPSSVC record also indicates that the site is only >> available over HTTPS, so won't be applicable for insecure >> HTTP-only sites. Hopefully not a problem with HTTPS >> becoming the new default for most sites. >> It also will help performance for the common zone apex cases, >> especially where a user enters "example.com" into a browser. >> Right now browsers default to http (port 80) and (most now?) servers >> then redirect to https port 443. So a HTTPS redirect is often in the >> loop >> for some zone apex flows, and this removes that by signalling the use >> of HTTPS. >> >> One option might be to shelve ANAME for the time-being and then return >> back >> to it in a few years if it still seems needed at that point? >> >> Erik >> >> _______________________________________________ >> 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 >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
