On Sat, May 15, 2021 at 8:00 AM Erik Nygren <erik+i...@nygren.org> wrote:
> 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.
>
Currently, the singular AliasMode (chain, but non-forking chain) still
requires potentially multiple ServiceMode records to be handled, including
queries for A and AAAA records for the TargetNames (or inclusion of those
by the Authority server etc.)
Resolving each AliasMode chain (if a single single sit "fork" occurs) to
the ServiceMode records of all the forks, would result in a set of
ServiceMode records. All of the handling of ServiceMode records from each
of the forks could be done effectively the way they are today, with the
results of each ServiceMode's evaluation being kept in the sorted order (as
is already the case).
It goes from the current method of:
AliasMode -> .... -> sorted list of ServiceMode records (possibly sorted in
random order if two or more of the same SvcPriority exist)
to:
Priority-sorted AliasMode set -> ... multiple sets of ServiceMode records
[each set corresponding to the AliasMode], respectively sorted within those
groupings according to the SvcPriority of the ServiceMode records within
each set.
The words are more complex than the implementation; the end result can be
treated as a single sorted list (and handled by whatever existing code for
handling connections and failures from the singular AliasMode case).
>
> 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.
>
There are almost no multi-CDN setups today, BECAUSE of the lack of
SVCB/HTTPS records.
If a CDN customer is making use of any sort of non-standard apex "cname",
they CANNOT use multiple CDNs.
Reading more into the "why" of almost no multiple-CDN setups than that, is
{insert appropriate logical fallacy name here}.
There are additional reasons for needing multiple CDNs, on at least a
temporary basis, such as migrating between CDN providers.
And finally, the use of same-priority multiple CDNs allows the client to
pick the best choice of destination based on local network effects
(latency, loss). This may not be the case at initial connection time, but
might be relevant over the longer term.
What is optimal for behavior on a cold cache, may not continue to be
optimal on a warm cache, or during global or local network issues.
Brian
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
