My point was that it will be used by spammers to hide their domains. So redirect.name will quickly get added to email blacklists, so people wont be able to send legitimate emails containing redirect.name URLs as they'll be rejected/blocked/filtered.
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?
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.
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.
I have done something similar myself. First I tried to put the TXT record at the same domain which I did want to redirect. To tackle the CNAME problem did I come up with a complicated solution which I also did write up (https://github.com/tellnes/dhr2). But when I actually tried to use it was it too complicated.
What I'm actually using now and have been using for some time is just a simple TXT record at a subdomain (eg _redirect.example.com). I also have a script which looks for these TXT records in my zones and adds A/AAAA records when needed.
17 comments
[ 3.1 ms ] story [ 45.7 ms ] thread[edit] Also, this service will be abused by spammers and it will then become impossible to use a "redirect.name" URL in email.
I hadn't thought about putting the TXT records on another hostname. That would actually be advantageous for using a CNAME instead of a A record, too.
Can you elaborate on "impossible to use redirect.name URL in email"?
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.
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.
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.
See: http://support.dnsimple.com/articles/differences-between-a-c... http://www.dnsmadeeasy.com/services/aname-records/
What I'm actually using now and have been using for some time is just a simple TXT record at a subdomain (eg _redirect.example.com). I also have a script which looks for these TXT records in my zones and adds A/AAAA records when needed.
You can check it out as follows:
The plan is at some point to put the scripts I actually use on GitHub, but I have never come so far.