Consider limiting chain lengths to 1

[bemasc]

It's not clear that we have a use case for SVCB chains containing more than one AliasForm record. The purpose of AliasForm is mostly for aliasing the apex; everything else can pretty much be handled with CNAME (e.g. AliasForm -> CNAME -> CNAME -> SvcForm)

At a minimum, limiting the chain length to 1 would seem to reduce the likelihood of a performance footgun.

[enygren]

I think I'd agree, at least as a SHOULD? The counter-argument would be that clients will do SVCB lookups on the SvcDomainName of the AliasForm record and if they get back another AliasForm record we could enter ambiguous territory. (I believe CNAME originally prohibited chaining but it ended up being a common pattern that got used anyways.)

[davidben]

It's only ambiguous if we choose to make it ambiguous. I think, in that case, the client ought to reject the record. That way administrators know their config didn't work and get back on the well-lit path.

I'm not familiar with the history of CNAMEs, but my guess is it was prohibited but clients accepted it anyway? In that case, yeah, the natural result is the prohibition gets dropped. Invariants are only invariants if enforced.

[bemasc]

AliasForm only exists to provide apex aliasing, so I think the question is: can we imagine any need for a chain of aliases where more than one is the apex of its zone. For example:

foo.example -> www.foo.example -> cdn.example -> cdn2.example.com -> us-east.cdn2.example.com
AliasForm      CNAME              AliasForm      ServiceForm         AAAA

In this example, "cdn.example" is a vanity alias for "cdn2.example.com", but because it's a zone apex, it can't use CNAME. If the CDN were willing to add a label to the vanity alias, it could use a CNAME instead. Alternatively, the CDN could place the ServiceForm record there, although that might be inconvenient if "cdn.example" is a simple static domain, because the ServiceForm record is highly "dynamic" (frequently updated and geo-targeted).

Given that CDN apex vanity aliases are currently impossible, I don't think this is a motivating use case, but I would still like to ask the working group before ruling it out.

EDIT: A more compelling use case might be for zone structure flexibility. If AliasForm can appear more than once, that makes it easier for CNAME users to add zone cuts that would put the CNAME at an apex, since they can replace the CNAME with an AliasForm without worrying that there might already be an AliasForm earlier in the chain.

[bemasc]

At IETF 106, the consensus of DNSOP seemed to oppose this kind of limit. Recursive resolver developers explained that applying different limits to SVCB and CNAME would be difficult to implement, and some also declared that domain owners are to be blamed if they choose an inefficient layout of their own zone. Some declared that, regardless of the spec, they would not enforce any low limit on the number of alias steps in their implementations.

I think we could still specify that domain owners MUST NOT include more than one alias in a chain, and recursive/client implementors MAY impose limits as low as 1.

[bemasc]

After some further discussion, a new idea:

• domain owners MUST NOT include more than one alias in a chain
• recursive implementors MAY stop following aliases after the first
• client implementors SHOULD stop following aliases after the first
• client implementors SHOULD reject responses from recursive resolvers that contain chains with multiple aliases

This gets us reliable, consistent behavior without imposing any extra constraints on the recursive implementor.

TODO: Figure out what happens when the chain length is exceeded in each case. Does resolution fail or fall back? Does HSTS still apply?

[davidben]

That seems reasonable to me. On the HSTS side, you don't actually need to follow anything when resolving an HTTP URL, right? Once you see an HTTPSSVC record of any flavor, you know you're going to abandon this URL and try a different URL. (Of course, that retry is likely going to make the same DNS query---though not necessarily depending on HTTP cache or Alt-Svc---so it's not a waste to follow it anyway.)

[bemasc]

We should remove the "(8?)" guidance and instead propose that AliasForm can't point to AliasForm (without imposing any restrictions on CNAMEs before, during, and after). We'll need to review this with the commenters from the WG.

[bemasc]

I brought this proposal to the group in December, but there did not appear to be consensus for a tight limit like this: https://mailarchive.ietf.org/arch/msg/dnsop/Fim9mbPIfSBwBQg-3uU6wwSfmhg/

[bemasc]

Please review #151, which relaxes the requirement here in a way that I hope reflects the WG consensus (or lack thereof).

[ericorth]

I wonder if the MUST rules around following at least one link should be changed to a SHOULD since, while it's necessary in the general case to support apex delegation, it seems like you could come up with special-case situations where it would be fine to skip chain following eg looking up specific records where the stub has specific knowledge that there shouldn't be a chain at all.

But either way, I think this new language works well for Chrome.