On Wed, Aug 24, 2022 at 07:11:16PM -0400, Eric Orth wrote:

> > Regarless, once AliasMode records are found, these MUST be used and
> > partial lookup failure along a non-empty (so far) alias chain needs
> > to be fatal.
> 
> This would be a big non-editorial change from the current draft, and I
> don't see any need for such a rule rising to the "exceptional
> circumstances" bar at this stage.  Why would such behavior be necessary
> beyond a vague desire to be more consistent with the behavior of CNAMEs?

Because otherwise, even SVCB-aware client behaviour is subject to random
rolls of the dice.  Sometimes they follow the alias, and sometimes
randomly, when a DNS query times out, they go some place unexpected.

Your zone serving the AliasMode record is working, but the target zone
has a glitch, should your legacy service now see a spike in unexpected
traffic from AliasMode aware clients to the wrong destination?  Is it a
good idea to require it to also serve all the clients that SHOULD
normally use the SVCB location.

> As a client implementor, I think the draft already has the correct behavior
> here, and I do not support making changes at this time.  I don't like when
> implementing new specs makes my client more susceptible to errors in cases
> where a non-implememnting client would have kept working fine (except for
> cases of obvious domain misconfiguration or where breaking is important for
> security).

Well, except that resolving the SVCB chain to its conclusion (actual
ServiceMode RRset, NODATA or NXDOMAIN) is NOT an error.  That's the
configured service location.  Yes some legacy clients might for now make
do with a legacy location, but I rather think that SVCB-aware clients
SHOULD NOT be rolling the dice except when SVCB queries are completely
unavailable (the initial SVCB query runs into "lookup failure").

> If a client receives non-aliased A and AAAA records that a
> non-HTTPS-implementing client would have been able to use
> successfully, why should an HTTPS-aware client be forced to ignore
> them and refuse to load a website? This is not at all the same
> situation as a CNAME records where it isn't generally possible to also
> receive non-aliased A and AAAA records.

Because predictable behaviour is I think the better option, and once the
initial SVCB lookup succeeds, there is good reason to expect the rest to
work.

Yes, a shrinking minority of clients will use the legacy location, but
we should I believe not optimise for these.

As it stands, AliasMode is a non-deterministic redirect even for
SVCB-aware clients, that makes me uneasy.  I could of course find that
Brian and I are the only ones that share this view, but I hope that's
not the case.

-- 
    Viktor.

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to