Add a REDIRECT record, deprecate URL/URL301/FRAME records

[j-f1]

Several providers support configuring a domain name to be redirected to another URL:

• Namecheap has URL for temporary redirects and URL301 for permanent ones, plus FRAME for rendering the site inside of an iframe or similar.
• Cloudflare has CF_REDIRECT and CF_TEMP_REDIRECT (docs)
• DNSimple seems to support URL
• Exoscale seems to support URL
• NS1 has URLFWD.
• ClouDNS has CLOUDNS_WR which supports 301/302/masked

As discussed by @tlimoncelli in https://github.com/StackExchange/dnscontrol/issues/1539#issuecomment-1160733399 and https://github.com/StackExchange/dnscontrol/pull/1827#issuecomment-1331417650, this is problematic. Based on my research:

• DNSimple treats URL records as 301 (permanent redirects), but Namecheap treats them as temporary.
• Exoscale doesn’t clearly specify which type of redirect they use.

Proposed API:

REDIRECT("foo", "https://example.com") // invalid
REDIRECT("foo", "https://example.com", TEMPORARY_REDIRECT) // valid for Namecheap/CF/NS1/ClouDNS
REDIRECT("foo", "https://example.com", PERMANENT_REDIRECT) // valid for Namecheap/CF/DNSimple/NS1/ClouDNS
REDIRECT("foo", "https://example.com", MASKED_REDIRECT) // valid for Namecheap/NS1/ClouDNS

• Namecheap: URL, URL301, and FRAME would be deprecated.
• Cloudflare: CF_REDIRECT, CF_TEMP_REDIRECT would remain available with wildcard support. REDIRECT would work by specifying the source as source + "/*" and asserting that destination does not include $1
  • alternatively, this could be a CF_WILDCARD or similar record option that disables the assert and adding /* to the source, and the custom record types could be deprecated
• NS1: NS1_URLFWD would remain available with wildcard support. REDIRECT would have similar behavior to Cloudflare, and would use “capture” mode.
  • (I think this record may be treated incorrectly at present, or at least needs more documentation. According to NS1 you need to give it a path on the domain name that it should be handling. I don’t have an account so I can’t verify how this works though)
  • alternatively this could take a similar route where you could pass NS1_WILDCARD or NS1_URLFWD as an option
• CLOUDNS_WR would be deprecated, and a new CLOUDNS_SAVE_PATH/CLOUDNS_NO_SAVE_PATH could be provided. Additionally, something like CLOUDNS_REDIRECT() would enable the record variables (i.e. REDIRECT("www", CLOUDNS_REDIRECT("http://{*domain*}/?ref={*host*}"), TEMPORARY_REDIRECT))

Some options for how path redirects could be handled:

REDIRECT("foo", "https://example.com",
    TEMPORARY_REDIRECT,
    CF_REDIRECT_PATH("/foo/bar/*"))
REDIRECT("foo", "https://example.com",
    TEMPORARY_REDIRECT,
    CF_REDIRECT({ path: "/foo/bar/*" }))
REDIRECT("foo", "https://example.com",
    TEMPORARY_REDIRECT,
    CF_REDIRECT({ from: "/foo/bar/*" }))

[tlimoncelli]

This is definitely in the right direction.

What do we do if (for example) a DNS provider doesn't support "masked" domains? Should that silently fail or should the provider return an error if it sees any flags/options it doesn't recognize?

I think the answer is that it should error if it sees a flag it doesn't recognize. That way we can even add flags for provider-specific things like CF_REDIRECT().

(Implementation detail: This is easy to implement. We can use the auditrecord.go system, or require the providers to return an error if they don't recognize an option. Option names would be in the form redirect_* to make it easy to implement.)