New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discussion: Follow redirects in DNS? #40

Open
Biserkov opened this Issue Sep 7, 2018 · 8 comments

Comments

Projects
None yet
4 participants
@Biserkov
Copy link

Biserkov commented Sep 7, 2018

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

This comment has been minimized.

Copy link
Member

pfrazee commented Sep 7, 2018

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

This comment has been minimized.

Copy link

Biserkov commented Sep 7, 2018

Precisely!

@bnewbold

This comment has been minimized.

Copy link
Contributor

bnewbold commented Sep 10, 2018

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

This comment has been minimized.

Copy link

emilbayes commented Sep 10, 2018

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

This comment has been minimized.

Copy link

Biserkov commented Sep 10, 2018

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

This comment has been minimized.

Copy link
Member

pfrazee commented Sep 10, 2018

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?

@bnewbold bnewbold referenced this issue Sep 26, 2018

Closed

Upcoming Meeting Agenda - 26 September 2018 #31

6 of 6 tasks complete

@pfrazee pfrazee referenced this issue Sep 26, 2018

Closed

Action Items - Meeting #16 (26 September) #33

2 of 12 tasks complete
@pfrazee

This comment has been minimized.

Copy link
Member

pfrazee commented Sep 26, 2018

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

This comment has been minimized.

Copy link

Biserkov commented Sep 28, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment