Hmmm, I'm not seeing the value proposition here. Or, I'm unclear why I'd use this service.
Here's how I understand redirect.name working:
===
1. An A/ALIAS/ANAME record for "example.com" points to a redirect.name service (self-hosted or otherwise).
2. The service sees the "example.com" HTTP request via the host header.
3. Service does a DNS lookup for a matching TXT record redirect rule.
4. When found, the service issues a 301/302 HTTP redirect, according to the matching rule.
===
Is this correct?
If so, compare to:
===
1. Create an A record for "example.com" that points to my Apache server.
2. Apache detects "example.com" via the host header.
3. Virtual host config for matching domain issues a 301/302 HTTP redirect.
===
Aside from shuffling the redirect config from Apache to DNS, what's the advantage of using redirect.name?
Additionally, every domain name registrar I've used includes a feature called "URL forwarding" that can redirect all HTTP requests for a domain to another. Again, what benefit does redirect.name provide that URL forwarding doesn't?
My company is currently offering "web forwarding" to our customers for free, but this service outsourced to the same third-party that provides our DNS hosting. While the DNS service is rock solid, the redirection service has had many shortcomings including delays in updating redirects, caching issues, etc.
This was one of a few ideas we had for bringing this in-house. I've seen other DNS-configured redirection services, but nothing with the flexibility we'd need to offer our customers to match what they're currently getting. I thought I'd do a quick mock-up of the idea and put it out there to get some feedback.
You can't always have URL redirect for your host records (see for instance DigitalOcean's DNS service). Also, as you unintentionally pointed out, you need a server to do the redirection, which can be a waste of resources for some use cases (see below).
You'd use this service if you were using things like Heroku, which are relying on CNAME records to avoid distributing all the traffic on one IP address that could have the machine it points to shut down at any moment - that's the principle of the cloud.
Comments
Hmmm, I'm not seeing the value proposition here. Or, I'm unclear why I'd use this service.
Here's how I understand redirect.name working:
===
1. An A/ALIAS/ANAME record for "example.com" points to a redirect.name service (self-hosted or otherwise).
2. The service sees the "example.com" HTTP request via the host header.
3. Service does a DNS lookup for a matching TXT record redirect rule.
4. When found, the service issues a 301/302 HTTP redirect, according to the matching rule.
===
Is this correct?
If so, compare to:
===
1. Create an A record for "example.com" that points to my Apache server.
2. Apache detects "example.com" via the host header.
3. Virtual host config for matching domain issues a 301/302 HTTP redirect.
===
Aside from shuffling the redirect config from Apache to DNS, what's the advantage of using redirect.name?
Additionally, every domain name registrar I've used includes a feature called "URL forwarding" that can redirect all HTTP requests for a domain to another. Again, what benefit does redirect.name provide that URL forwarding doesn't?
I'd love to hear the use cases.
My company is currently offering "web forwarding" to our customers for free, but this service outsourced to the same third-party that provides our DNS hosting. While the DNS service is rock solid, the redirection service has had many shortcomings including delays in updating redirects, caching issues, etc.
This was one of a few ideas we had for bringing this in-house. I've seen other DNS-configured redirection services, but nothing with the flexibility we'd need to offer our customers to match what they're currently getting. I thought I'd do a quick mock-up of the idea and put it out there to get some feedback.
You can't always have URL redirect for your host records (see for instance DigitalOcean's DNS service). Also, as you unintentionally pointed out, you need a server to do the redirection, which can be a waste of resources for some use cases (see below).
You'd use this service if you were using things like Heroku, which are relying on CNAME records to avoid distributing all the traffic on one IP address that could have the machine it points to shut down at any moment - that's the principle of the cloud.