Re: [DNSOP] status of the aname and svcb/httpsvc drafts

[Ben Schwartz <[e-mail]>]

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.

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 <[e-mail]> wrote:

> On Fri, Feb 21, 2020 at 9:53 AM Vladimír Čunát <[e-mail]>
> 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/[e-mail]/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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>