On Wed, May 12, 2021 at 4:44 PM Brian Dickson <brian.peter.dick...@gmail.com> wrote:
> > > 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. > Is the primary concern here resolution failures or connection failures? I suppose this could help recover from resolution failures, but I would be surprised if that is the concern in mind when people are configuring multiple redundant CDNs. For connection failures, such decisions can only be made on the client making the connection attempts, so it's not clear to me what behavior we should suggest for recursives. I'm already concerned enough with persuading recursives to do the support here that we want, so unless a recursive operator/implementor speaks up here to explain why it wouldn't be an issue, I'm guessing we wouldn't see a lot of full support if we say they must/should fully follow all branches. A client could use RFC 8305 (or similar logic) to attempt connections via one alias branch and move to others (separately queried) only on connection failures. But my client doesn't currently support RFC 8305, so we're unable to reasonably and performantly use separate branches conditionally on connection failures. Assuming many other clients would be in a similar position, I worry that even if we make multiple aliases possible, this would create a defacto standard that only a single alias is allowed if you want your domain to be compatible with all the clients. > > 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
