On Wed, May 12, 2021 at 4:44 PM Brian Dickson <brian.peter.dick...@gmail.com>
wrote:
>
> Having multiple AliasMode records within an RRset (with either the same or
> different Priority) would provide an avenue for dealing with resolution
> failure - which is one of the main reasons for any CDN customer to use
> multiple CDNs, i.e. to avoid single points of failure (which includes the
> DNS component of the CDN).
>
> I think it would be reasonable to restrict the handling of SVCB processing
> to allow multiple AliasMode records in a single RRset in the resolution of
> SVCB, i.e. once a branch has been reached, follow the preferred branch
> using the existing logic, and either abandon the other branch after the
> first successful step in the resolution of the preferred branch, or
> alternatively holding the entry point to the second branch (as a backup)
> until the first branch's resolution has succeeded to the point of returning
> ServiceMode records (and if resolution failure occurs before that point,
> switching to the next branch).
> This would be the equivalent to keeping a simple list, rather than needed
> to handle full recursion tree-walking logic.
>
> This is a suggestion only, but I think it has merit.
> The current examples of "juggling CNAMEs" isn't really practical,
> especially given TTLs on CNAMEs.
> Having multiple RRs in an RRSET with various Priority values achieves the
> equivalent function without requiring the domain owner to engage in active
> management of DNS records. The latter approach is at best naive, at worst
> harmful to deployment and use of SVCB in the real world.
>
A question would be whether this adds more to client complexity than even
advanced clients would
be willing to implement. Multiple Alias records pointing to independent
CDNs is only useful if clients
pop all the way back to that point to try another tree in the case where
connecting to the services
at the end of the first Alias record path fails.
This also only covers a small number of the "juggling CNAMEs" multi-CDN
setups today.
Many/most seem to take factors of cost, geographic location, and
performance into account,
so multiple Alias records wouldn't solve this but would just add another
place for more complexity.
Erik
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
