Accessing origin context in Worker

Hello everyone,

I would like to have a worker do dynamic routing based on the CNAME settings relevant to the incoming request.

How do I access the designated CNAME value if the request URL matches one?

Thanks,
Vicary

If I’m understanding you correctly, use a CNAME record (Orange-Clouded) for each subdomain to be accessed via (a) worker(s) routing logic. Use a page rule set to Always Use HTTPS for each CNAME record / subdomain. Then use conditional logic in your workers’ routes such as, to give the most basic route-type (a strict subdomain only) as an example, sub.example.com assigned to a worker at 2nd-lvl-sub.sub.workers.dev. Here’s a real world, overly simplified example I just set up in the last 5 minutes -

banned.intr0.com is CNAMEd to country-ip-ban.why.workers.dev. Now either site shows the same code, which I use for my custom IP/Country Block page, so that each ::TOKEN:: translates to the corresponding values when triggered.

Thanks for replying.

My use case is in fact quite simple, I would like to do location based routing, targeting a variant of the original CNAME value. Such that for a record *.foo.com CNAME example.com, I would like to rewrite the target to something like us.example.com, uk.example.com, au.example.com… etc. based on the source IP.

I have added a worker route of *.foo.com/* to my worker, but in the JavaScript context I cannot find a way to access the CNAME value.

There are multiple possible targets, so hard-coding values in javascript may not be an option.

Okay. Looking here:

Despite this not being your use case, it does detail a CNAME policy such that:


You can add this new subdomain as a CNAME DNS record to act as an alias for the host name expected by your object storage service. For example, you can configure the new DNS record with values similar to:

Type: CNAME
Name: assets
Value: myassets.s3.amazonaws.com
Now the pages served from your standard origin web server could refer to your object storage asset as:

https://assets.mydomain.com/image1.jpg

This URL pattern — along with the underlying DNS record for the subdomain — ensures that the request is treated as a Cloudflare-proxied resource that is cacheable. Make sure that the Cloudflare orange cloud is active for the new subdomain or workers.dev domain.

On the other hand, I only have ever used my DNS records within the Dash for purposes of routing to workers so I cannot help regarding setting up CNAMEs strictly within the context of a worker’s JS. I wish I could help further, though it’s quite likely someone else can easily do so.

Thanks for the info, in fact that’s quite close to where I stopped Googling.

This is also where it raised so many questions between worker routes and the CNAME record.

I mean, if the worker is doing everything, why do they even need the CNAME record in the first place? If it is required, why couldn’t a worker have access to it?

Weird, isn’t it?

Yes, although if one has a workers.dev subdomain, one necessarily has a registered origin so that one may use its DNS records. Then again, I am sure there is a way (there usually always is, it’s just that no one has yet created it) to accomplish what you want.