On Wed, May 12, 2021 at 12:28 PM Eric Orth <ericorth= 40google....@dmarc.ietf.org> wrote:
> > I also oppose allowing multiple aliases within an RRSet. This would allow > aliasing trees, unreasonably exploding the complexity/performance scope of > query followup logic in stubs and recursives. In practice, I don't think > this would actually make multiple aliases useful because I would then > expect many stub/recursive implementations (including mine) to only make > followup queries down a single branch of the alias tree. > The current version of the document only addresses DNS issues which result from actual attacks. There do not appear to be any logic branches on timeouts (or other similar failures) other than to abandon the SVCB handling. 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. I am a big fan of SVCB, and want it to succeed, so my comments should be viewed in that light, please. This is about improving the proposal only. Brian
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
