-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
Custom domain: check CNAME when adding domains #11747
base: main
Are you sure you want to change the base?
Conversation
If the user owns the domain, they can delete the CNAME before adding the domain to their project. Ref readthedocs/meta#157
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It called my attention that we are asking users to delete the CNAME first. I think we didn't talk about that in our meeting, did we?
However, it seems this approach solves our concern at the expenses of having to follow the documented steps in order, which is not a big deal, I guess.
Pinging @ericholscher in case he has more thoughts on this.
We talked about detecting chained CNAMEs, but www usually points to the root domain, there is no CNAME in there (A record). We could try detecting that case as well, but just checking if there is a CNAME seemed easier. There is still the case when a root domain is left pointing to us, but that case is less usual I'd say (since your domain will serve nothing until you re-point it to something valid). |
Dismissing because Eric pointed out really good arguments against this approach.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This approach works. I don't love that we're discarding the additional CNAME answers, but that seems fine given the overall simplicity of what we're doing here.
We should document these limitations in the custom domains page, and then I think we're OK to merge.
- Has a CNAME pointing to another CNAME. | ||
This prevents the subdomain from being hijacked if the last subdomain is already on RTD, | ||
but the user didn't register the other subdomain. | ||
Example: doc.example.com -> docs.example.com -> readthedocs.io, | ||
We don't want to allow doc.example.com to be added. | ||
- Has a CNAME pointing to the APEX domain. | ||
This prevents a subdomain from being hijacked if the APEX domain is already on RTD. | ||
A common case is `www` pointing to the APEX domain, but users didn't register the | ||
`www` subdomain, only the APEX domain. | ||
Example: www.example.com -> example.com, | ||
we don't want to allow www.example.com to be added. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can mostly just copy this to the limitations in the docs.
If the user owns the domain, they can delete the CNAME before adding the domain to their project.
Hashed domains won't be needed anymore to prevent domain hijacking (but still be something we should do), since users trying to add a domain with an old CNAME will need to delete that CNAME first, and only domain owners can do that. It may be a little of a pain for some users that first add the CNAME before creating the domain on .org, but that's only on .org, since on .com the users doesn't know the CNAME before creating the domain.
Ref https://github.com/readthedocs/meta/discussions/157