No sign-up required. Just add a DNS record.
This simple redirection service has no database backend, so there's no need to sign up for anything. Everything is configured by DNS. Just point your domain to the service, add a DNS record to configure your redirect(s), and you're good to go.
Here's a live example redirecting github.redirect.name to this project's GitHub repo:
github IN CNAME alias.redirect.name
_redirect.github IN TXT "Redirects to https://github.com/holic/redirect.name"
Instructions
- Point your domain or subdomain to the redirection service. For subdomains, this is done by setting up a CNAME record. For apex/naked domains, it is recommended that you use an
ALIASorANAMErecord type if your DNS provider supports it. Otherwise, use a plainArecord, keeping in mind that the IP address may change (or more may be added).-
CNAMEandALIAS/ANAMErecords should point toalias.redirect.name -
Arecords should point to45.55.72.95
-
- Configure your redirect by adding a
TXTrecord on the same hostname as the record above, prepended with_redirect.- For example, on the hostname
github, yourTXTrecord should be added to the_redirect.githubhostname. - Your
TXTrecord value should have a human-readable format format like one of the following:Redirects to [target], wheretargetis the target URLRedirects from [path] to [target], wherepathis a path to match on the hostnameRedirects permanently to [target], wherepermanentlyredirects with a301status code (defaults to302otherwise)
- As long as the
TXTrecord starts withRedirectorRedirectsand has a target, it does not matter the order offrom [path],to [target], or thepermanentlyflag.
- For example, on the hostname
You can add more than one TXT record per hostname. The first path matched will be used for the redirect. Multiple TXT records for the same matched path result in a round-robin effect.
Wildcard matches (*) are also supported.
Any unmatched paths will redirect to this documentation page, so it's recommended that you add a wildcard catch-all path when redirecting specific paths.
TXT record processing order
The DNS TXT records are processed in two stages; specific matches first and then catch-alls. This allows for complex matching against specific path values followed by a catch-all based fall through for
any non-matched requests. This ensures that more specific rules will match a request before a catch-all.
Since DNS lookups are not returned in any predetermined order there is an inherent round-robin effect when multiple TXT records are created which would match a given request. This is true for both specific
path matches and catch-alls.
Examples
Redirects to https://github.com/holic redirects all paths on the hostname to https://github.com/holic with a 302 status code.
Redirects permanently to https://github.com/holic redirects exactly as above, except with a 301 status code.
Redirects from /github to https://github.com/holic redirects only the /github path on the hostname to the target URL.
Redirects from /* to https://github.com/holic/* is a wildcard match that will redirect to the target URL, replacing the wildcards with the matched value.
The following combines all of the above using wildcards, regular matches, and a catch-all.
Redirects from /match1/* to https://github.com/holic/*
Redirects to https://github.com/holic
Redirects from /match2/ to https://github.com/holic/match2
The important thing to note is that with multiple redirects they are processed according to the TXT record processing order described above. So, even though the catch-all is in the middle of the other two rules it will only ever match last.