udleinati / redirect.center

Redirect domains using DNS only
http://redirect.center
MIT License
261 stars 49 forks source link

Fix uppercase query support #40

Closed mike1808 closed 3 years ago

mike1808 commented 4 years ago

PR #37 added support for query params, however, as DNS spec doesn't care about upper and lower case the case wasn't preserved. This PR tries to solve that issue by encoding query string to some encoding which is supported by DNS. I chose base32 RFC 4648 which uses Latin alphanumeric symbols. This solution has one limitation - the resulted string can be long and don't feed to some providers DNS zone settings.

tmackay-cenet commented 4 years ago

Is case really a problem? Size very much is (253 byte hard limit) as I quickly discovered using even modest path/query redirects. I suppose it would depend on the DNS server but the important interaction is between the DNS server and the DNS client used by redirect.center, both of which are in our control and not subject to end user client variations. While the lookup is case insensitive, I observe the case is preserved in returned CNAMEs. I had a similar idea using deflate+base64 encoding which results in URLs just slightly longer than the original (but very much be case sensitive). I also propose maintaining backwards compatibility with the old scheme by adding a new mechanism rather than a replacement. We could do this by checking first if the URL matches our encoding scheme and if not revert to the old way. Additionally DNS label names are further limited to 63 bytes so we could encode the path+query+fragment (or just the entire redirect URL) then split it into 63 byte chunks. If the incoming CNAME matches a single label under our fqdn or one followed by 1 or more 63 byte chunks and it is valid base64+deflate encoded then process this way, otherwise use the .opts-slash. method. We could also check multiple encoding methods by checking base32 first for example. There is also the possibility of optionally including a TXT record which is case sensitive and capable of storing longer strings. Again, I wouldn't want to break backwards compatibility with existing CNAME redirects deployed in the wild. Edit: I'm just looking at rfc4343 and from what I can tell, case is preserved but comparisons are case insensitive, am I mistaken or are there just some funky DNS servers out there that try to "help"?

mike1808 commented 3 years ago

Hey @tmackay-cenet sorry for the late response. The case was a problem for Google DNS servers. In my company, we have been using this version of redirect.center for 3 months and we have complaints. It works well but as you said required a breaking change.

tmackay-cenet commented 3 years ago

It probably could be made backwards compatible by first checking if it looks like a valid base32 string and if not reverting to the plaintext encoding