Need help with redirecting a subdomain to another domain.

[brittle robin]

I want to redirect *.domain.app to domain.cc/app/*
The fact that there's two different TLD's is a bit tricky, but they're both listed under cloudflare and use it's DNS.

I've attached a picture of a DNS record that I tried adding, but I get an Origin DNS error when trying to visit the .app site.

My goal is to REDIRECT, and not FORWARD.

[brittle robin]

gonna try out some page rules stuff

[dreamy trout]

Yea CNAMEs don't work like that, can't specify path or anything, nor do they redirect. They're a DNS level concept of "look over here to resolve A/AAAA/etc records" Page Rules, Dynamic Redirect Rules, or Bulk Redirects are your best option

[brittle robin]

Ah okay, I cant seem to get page rules to work though. Here's my setup:

when i try to visit tsar.app, i get this:

[dreamy trout]

you don't have a dns record created for tsar.app, and wildcards only cover subdomains

you can create
AAAA @ 100:: Proxied
and AAAA * 100:: Proxied

100:: being IPv6 Discard, basically saying "if nothing in CF handles this, there's nowhere to go"

[brittle robin]

That worked perfectly, thanks. One more question:
When I try to make a rule to redirect auth.tsar.cc/* to tsar.cc/auth/*, I get the same exact issue. Do I just need to add the AAAA entries in the tsar.cc DNS as well?

I already have DNS records for tsar.cc though

Rules:

My CNAME entry redirecting tsar.cc to tsarcc.pages.dev

[brittle robin]

Cause I do have them for tsar.cc, yet i still get the DNS_PROBE_FINISHED_NXDOMAIN error when visiting auth.tsar.cc

[dreamy trout]

you have the wildcard on tsar.cc?

[brittle robin]

Yeah, this time my goal is to redirect auth.tsar.cc/* to tsar.cc/auth/*

The .app one works fine now, so it's irrelevant

[dreamy trout]

You should just do AAAA auth 100:: Proxied in that case

don't do wildcard unless you want to redirect all

[brittle robin]

I need to include the rest of the request though. Typically you'd visit auth.tsar.cc/f82d4a57-389f-4682-bb94-dda46f28e0a7/something

and I need the two parameters to stay

[dreamy trout]

cname entries don't ever redirect

probably a key thing worth pointing out

unless you have a seperate redirect on there

a CNAME is just saying "DNS, resolve this by going over here"

[brittle robin]

oh yeah I meant resolving

thats a default entry made by pages

I tried adding this

but it still wont work

[dreamy trout]

for me
curl https://auth.tsar.cc/f82d4a57-389f-4682-bb94-dda46f28e0a7/something -vvv -o /dev/null | grep 'location'
goes to
location: https://tsarcc.pages.dev/auth/f82d4a57-389f-4682-bb94-dda46f28e0a7/something

[dreamy trout]

that's just dns cache

can take up to an hour or longer, depends on your DNS Resolver

[brittle robin]

oh, could it be the page rules making it work or the dns entry?

which should I keep

[dreamy trout]

You visited it when it didn't exist, so you have negative cache saying the record doesn't exist

[brittle robin]

makes sense

[dreamy trout]

You need both the DNS Entry and the Page rule for a redirect to work.
The DNS Entry lets CF know it should publish a/aaaa proxy IPs and make it connectable. The Page Rule handles the incoming traffic

[brittle robin]

Ah, makes perfect sense. Thanks for the explanation.

[dreamy trout]

for me that redirect looks good now

curl https://auth.tsar.cc/f82d4a57-389f-4682-bb94-dda46f28e0a7/something -vvv -o /dev/null | grep 'location'
location: https://tsar.cc/auth/f82d4a57-389f-4682-bb94-dda46f28e0a7/something

[brittle robin]

How do I get the curl command to work? Did I paste it wrong?

[dreamy trout]

no, just dns cache

[brittle robin]

damn okay

try www.tsar.cc

[dreamy trout]

I always test everything on a test box which uses 1.1.1.1 directly

no cache or anything

[brittle robin]

I get a server error for www.tsar.cc, heres my entry

[dreamy trout]

that 522's. What are you looking for? If it's a Pages Custom Domain, you need to add it under the Pages Project Custom Domains tab

[brittle robin]

I should set one up as well, i just use googles dns rn

[brittle robin]

just treat it like the root domain

I need www to either redirect or act as the root

[dreamy trout]

you need to add it under the Pages Project Custom Domain tab if you want it to work, just like you did for the root

or redirect: https://developers.cloudflare.com/pages/how-to/www-redirect/

[brittle robin]

oh wow, interesting. Needing to add www. to the pages project but not needing the same for auth. is confusing

but im assuming thats the case cause auth redirects

while www resolves

[dreamy trout]

because auth is just redirecting

[brittle robin]

makes sense

thanks for the help, everything should be working fine now

[dreamy trout]

It may be worth pointing out further, the difference between CNAMEs and redirects.

A redirect is a simple response that makes the browser go to that url, and resolve it/send a request to it.

When you use a CNAME, proxied or unproxied, the CNAME is resolved down to an IP address (v4 or v6, a/aaaa respectively), and a request is send to it. The request contains the hostname and serverName of the original request. Like for www, it'd be www.tsarc.cc.

Cloudflare Pages uses CF for SaaS under the hood, which has a sort of allowlist for host headers/serverNames. It sees www.tsarc.cc and says "that's not on the list, only tsarcc.cc is"

This would also happen if you CNAMEd from www to root, as it'd still flatten down to IPs and the host header/serverName would be www

[brittle robin]

Ah okay

[dreamy trout]

Proxied CNAMEs only show Proxy IPs which makes following the trail externally harder, but for example with wikipedia when using a public resolver, you can see it just followed the CNAME to get the IP to connect to
;; QUESTION SECTION:
;en.wikipedia.org. IN A

;; ANSWER SECTION:
en.wikipedia.org. 6757 IN CNAME dyna.wikimedia.org.
dyna.wikimedia.org. 300 IN A 103.102.166.224

For Web Browsers, it's essentially/kind of the same if it returned the A record directly

[brittle robin]

Oh alright, so proxied doubles as both DDoS protection, etc as well as hides your origin server IP

[dreamy trout]

It'd only work as DDoS Protection if it hides your origin ip

otherwise even if you properly firewall'd your origin to only allow requests from CF, they could still down it by volumetric attacks/brute force

Proxied has requests flow through the entire CDN, benefiting from Edge Caching, WAF/Security/DDoS Protection, Redirects, HTTP/3, etc

[brittle robin]

Yeah, that's how I assumed it worked.

[brittle robin]

Alright, I'll keep that in mind