redirect.name

Configure domain redirects and URL forwarding with a simple DNS record

View project onGitHub

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

  1. 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 ALIAS or ANAME record type if your DNS provider supports it. Otherwise, use a plain A record, keeping in mind that the IP address may change (or more may be added).
    • CNAME and ALIAS/ANAME records should point to alias.redirect.name
    • A records should point to 45.55.72.95
  2. Configure your redirect by adding a TXT record on the same hostname as the record above, prepended with _redirect.
    • For example, on the hostname github, your TXT record should be added to the _redirect.github hostname.
    • Your TXT record value should have a human-readable format format like one of the following:
      • Redirects to [target], where target is the target URL
      • Redirects from [path] to [target], where path is a path to match on the hostname
      • Redirects permanently to [target], where permanently redirects with a 301 status code (defaults to 302 otherwise)
    • As long as the TXT record starts with Redirect or Redirects and has a target, it does not matter the order of from [path], to [target], or the permanently flag.

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.