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"
- 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
ANAMErecord type if your DNS provider supports it. Otherwise, use a plain
Arecord, keeping in mind that the IP address may change (or more may be added).
ANAMErecords should point to
Arecords should point to
- Configure your redirect by adding a
TXTrecord on the same hostname as the record above, prepended with
- For example, on the hostname
TXTrecord should be added to the
TXTrecord value should have a human-readable format format like one of the following:
Redirects to [target], where
targetis the target URL
Redirects from [path] to [target], where
pathis a path to match on the hostname
Redirects permanently to [target], where
permanentlyredirects with a
301status code (defaults to
- As long as the
TXTrecord starts with
Redirectsand has a target, it does not matter the order of
to [target], or the
- 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
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.
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.