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
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
