check_reverse_dns: don't force mw-lb.miraheze.org #3281
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
There is no technical reason that a custom domain couldn't point to some other miraheze.org subdomain. All possible subdomains will always exist and resolve to our servers. This uses regex to ensure that the CNAME is of the format <subdomain>.miraheze.org . The alert really comes into play if somebody has changed their DNS after the domain was setup for their wiki. And if they just changed what subdomain the record points to, I don't think it's worth chasing the user up about it. As for new domains, I always check the records beforehand (and anybody else handling SSL requests should too), and thus this check should not be relied on when adding SSL certs. We should be checking records before adding SSL, and only contacting users after if they changed it after, and for some reason the new configuration won't work. (non-miraheze.org CNAME, or improper A records, or somthing similar, or not pointed at all)
|
updated to disallow cp* and non-mediawiki subdomains (most) and non-mw subdomains not included, and other server names would already fail the RDNS check. (the left out non-mw subdomains are the ones not going though varnish) |
|
It would be nice to see tests |
paladox
reviewed
Aug 13, 2023
Universal-Omega
requested changes
Feb 1, 2024
With the change a bit simpler now, I don’t think additional tests are needed. |
Tests are always good. This is one of the early targets for Python functions so I'll write them. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There is no technical reason that a custom domain couldn't point to some other miraheze.org subdomain. All possible subdomains will always exist and resolve to our servers. This uses regex to ensure that the CNAME is of the format .miraheze.org . The alert really comes into play if somebody has changed their DNS after the domain was setup for their wiki. And if they just changed what subdomain the record points to, I don't think it's worth chasing the user up about it. As for new domains, I always check the records beforehand (and anybody else handling SSL requests should too), and thus this check should not be relied on when adding SSL certs. We should be checking records before adding SSL, and only contacting users after if they changed it after, and for some reason the new configuration won't work. (non-miraheze.org CNAME, or improper A records, or somthing similar, or not pointed at all)