Discussion: Follow redirects in DNS?

[Biserkov]

Currently the proposal says:

If the server responds with anything other than a 200 OK status, return a failed lookup.

A lookup for dat://www.biserkov.com will hit https://www.biserkov.com/.well-known/dat and everything will work.

But a lookup for dat://biserkov.com will hit https://biserkov.com/.well-known/dat which returns HTTP/1.0 301 Moved Permanently so the lookup will fail.

I believe this situation is quite common, with the current wisdom against apex domains and stuff.

[pfrazee]

That's a good question. I suppose the argument is, you might have foo.com redirecting automatically to www.foo.com, and you want dat://foo.com to do the same, yeah?

[Biserkov]

Precisely!

[bnewbold]

A couple notes:

• does the "don't use apex domains" wisdom hold for .well-known static files, or is it oriented towards high-traffic services redirecting to a third party?
• what do other folks do? Eg, does ACME (let's encrypt) verification work following an HTTP redirect?
• for the common case of "domain.tld to www.domain.tld", at some point I think it was common for browsers to auto-redirect; maybe discovery should do that also? this probably has security implications, particularly if a domain was configured with wildcard subdomains pointing somewhere.
• do we allow arbitrary recursive depth of redirects? which redirect codes (of the 3 or more that exist) are considered valid? presumably all hops have the same HTTPS requirements, right?

I find the simplicity of the "no redirects allowed" status quo appealing, but I guess I can't back that up with any reason to break the HTTP(S) "default" of following redirects.

[emilbayes]

For lets encrypt you need to have .well-known accessible on both "www.domain.tld" and "domain.tld" without redirect, which is why you often special case this folder in redirect rules (however you manage those)

[Biserkov]

does the "don't use apex domains" wisdom hold for .well-known static files, or is it oriented towards high-traffic services redirecting to a third party?

There are several reasons/justifications, I find the one about cookies the most convincing.
https://www.yes-www.org/why-use-www/

do we allow arbitrary recursive depth of redirects?

No, all browsers seems to have a maximum number. 2012, so a bit dated https://stackoverflow.com/questions/10895406/what-is-the-maximum-number-of-http-redirections-allowed-by-all-major-browsers

For lets encrypt you need to have .well-known accessible on both "www.domain.tld" and "domain.tld" without redirect

I don't know how netlify handles this, but it supports Let's Encrypt and redirects .well-known.

[pfrazee]

I can't think of any reasons against this yet, but I do share @bnewbold's vibe that I'm unsure about adding complexity. Perhaps if we can't think of a good reason not to after a couple weeks, we move forward?

[pfrazee]

We discussed this in the WG and ultimately decided to give this a "soft no." Our concerns are:

1. The .well-known DNS method may not be a long term solution, and adding this behavior would make it difficult to migrate away from it (because the equivalent isn't possible in DNS).
2. The change would add complexity such as the need to detect redirect loops.
3. We're unsure whether there could be security concerns.

We've decided to leave the issue open so that more people can comment, but we're not going to move forward with the change for now.

Sorry @Biserkov. I appreciate why you'd want this, but we're just concerned about using the DNS layer to do it. Is it possible there's another point in the stack this could be done?

[Biserkov]

I like this "soft no" approach. I've managed to solve my use case via the DNS route.