Within worker DNS resolution is failing

Hello, I am pretty confident that my worker when it is reached through its custom domain. Y.Z.com is unable to resolve X.Z.com.

Zone is not entirely managed by Cloudflare (partial CNAME setup)
Y.Z.com is reachable and worker is running correctly. (just DNS resolution is broken)
X.Z.com is managed on AWS
when reached via it's worker.dev route, DNS resolution is working.

I have logs and proofs of all that.

Any help? I can't be the only one with that error? Either I do something weird or it's a bug somewhere. Thanks

This doc says it should work: https://developers.cloudflare.com/workers/configuration/routing/custom-domains/#:~:text=On%20the%20same%20zone%2C%20if,succeed%20without%20a%20service%20binding

Custom Domains · Cloudflare Workers docs

Custom Domains allow you to connect your Worker to a domain or subdomain, without having to make changes to your DNS settings or perform any …

SSébastien Morel Hello, I am pretty confident that my worker when it is reached through its custo...

Chaika•12/27/23, 12:59 AM

If your issue is fetching a worker from another worker on the same zone, even though the docs say it'll work if you're using a Custom Domain, it's still broken. There's a workaround here: https://github.com/cloudflare/workerd/issues/787#issuecomment-1597396873
Service Bindings are better if you can use them though

GitHub

🐛 BUG: Worker <-> Worker request over `custom_domain` returns insta...

Which Cloudflare product(s) does this pertain to? Workers/Other What version of Wrangler are you using? 2.9.0 What operating system are you using? Mac Describe the Bug Same zone worker <-> wo...

Sébastien MorelOP•12/27/23, 12:59 AM

it's not a worker from a worker, it's a another endpoint (with the same X.com zone) but it's an entirely other api that I want to call from my worker

Chaika•12/27/23, 1:02 AM

ahh ok, the part of the docs you linked is for Workers to Workers

Sébastien MorelOP•12/27/23, 1:02 AM

it also mentions that worker to anything should work

Sébastien MorelOP•12/27/23, 1:04 AM

just read the github issue and I have the same exact behavir as jgontrumjgontrum

I think a bug related to this are quests from worker to an api that's using the same subdomain.

My scenario was:
Worker with custom domain on api.myapp.com makes a request to my db running on my own server db.myapp.com. This resulted in basically empty requests in my server logs which threw off my reverse proxy running there.

Adding the compatibility_flags did not change anything, the only solution for now is to use .workers.dev subdomain instead of a custom domain.

I think a bug related to this are quests from worker to an api that's using the same subdomain.

My scenario was:
Worker with custom domain on api.myapp.com makes a request to my db running on my own server db.myapp.com. This resulted in basically empty requests in my server logs which threw off my reverse proxy running there.

Adding the compatibility_flags did not change anything, the only solution for now is to use .workers.dev subdomain instead of a custom domain.

Sébastien MorelOP•12/27/23, 1:04 AM

thing is for me I would like to expose the worker to the public and can't really use the .dev.dev

SSébastien Morel it also mentions that worker to anything should work

Chaika•12/27/23, 1:06 AM

There is a ton of limitations on fetch. For example to different zones you're forced to http/80 https/443, can't use other ports. You also can't fetch IPs, only domains, etc. Not quite worker to anything.

There is other reasons the workers.dev may work, for example it doesn't have cache and isn't same zone so it can fetch workers.

But none of that sounds quite like your case. You're saying a worker running on your one cloudflare zone is unable to fetch a url on a non-cloudflare zone, right?
Would need more logs/information then just it not working

Sébastien MorelOP•12/27/23, 1:11 AM

let me rephrase it but it's a very common situation I believe.
I have an API. api.z.comapi.z.com on the zone z.comz.com which is not managed by Cloudflare.
we are now thinking about using more Cloudflare so, I have CNAME for a specific new API that I want to run on cloudflare: new-api.z.comnew-api.z.com
new-api.z.comnew-api.z.com is reachable and run the code from my worker.
when I reach the worker from its custom domain new-api.z.comnew-api.z.com the DNS resolution of api.z.comapi.z.com is non-sense. the worker does not reach the correct servers behind api.z.comapi.z.com
When reached through its workder.devworkder.dev route, the worker has no issue to resolve api.z.comapi.z.com

Is that clearer? I'd love to figure this out!

SSébastien Morel let me rephrase it but it's a very common situation I believe. I have an API. `a...

Chaika•12/27/23, 1:20 AM

I think I get what you're saying, and It looks like the root of your issue is just the partial zone, it seems to try to resolve internally because it thinks it's entirely using CF DNS. I'm guessing a workaround is adding the api subdomain in Cloudflare even if you're never going to CNAME it to Cloudflare, just so that it knows where to send traffic. Was trying to look up more info on this, but using partial zones is an edge case/rare since it's Biz or higher

Sébastien MorelOP•12/27/23, 1:22 AM

ha, and yes what you say would make sense, so you say I could trick the zone in Cloudflare for api.z.comapi.z.com so internally it would use it rather than the real one? I like it, it's weird but it makes sense.

Sébastien MorelOP•12/27/23, 1:24 AM

I actually I have never really checked that but it has records and says "proxied" which has to be wrong as only 1 record is managed by Cloudflare. I will give some try

Sébastien MorelOP•12/27/23, 1:25 AM

maybe 1 more question but technically I could remove all of them right, Cloudflare does not mange the DNS at all in my usecase

Sébastien MorelOP•12/27/23, 1:25 AM

all but the new-api.z.comnew-api.z.com

Chaika•12/27/23, 1:26 AM

I'm guessing it imported a bunch of records before you converted it. Most should be fine to remove yea, you just need to keep records for whatever subdomains/hostnames the partial zone is responsible for/so it knows where to send traffic

Sébastien MorelOP•12/27/23, 1:26 AM

one thing that does not make sense so much yet to me is why when reached via it's .workers.dev.workers.dev everything works fine

Sébastien MorelOP•12/27/23, 1:27 AM

it's like depending on how the worker is reached, it changes something in the dns resolution

SSébastien Morel ha, and yes what you say would make sense, so you say I could trick the zone in ...

Chaika•12/27/23, 1:28 AM

Yea it's a hack/workaround but basically the worker executing on the partial zone will use whatever you specify in that DNS over Public DNS. For example I have a zone, partialzone.compartialzone.com and a worker executing on test.partialzone.com, which is CNAME'd to that zone. Then I have a record for testktestk which only exists in Cloudflare DNS and is not cname'd to Cloudflare, however a worker executing on test.partialzone.com can fetch testk.partialzone.comtestk.partialzone.com and send traffic to it

SSébastien Morel it's like depending on how the worker is reached, it changes something in the dn...

Chaika•12/27/23, 1:29 AM

yea it does, the zone its executing on changes the behavior of the fetch. Outbound fetches go through a lot of the normal zone-specific cdn logic

Sébastien MorelOP•12/27/23, 1:29 AM

hum ok

Sébastien MorelOP•12/27/23, 1:30 AM

ok I will then play around and try removing the records first and see, and then I will add some and test.
but it does sound like a very interesting lead. thanks @Chaika I will definitely come back here and tell my findings

SSébastien Morel ok I will then play around and try removing the records first and see, and then ...

Chaika•12/27/23, 1:33 AM

Sure, to summarize what I was saying may be a workaround is just manually creating the A/AAAA records in cloudflare for api.z.comapi.z.com which you fetch in your worker on new-api.z.comnew-api.z.com. You don't have to point api.z.com to Cloudflare in Public DNS, but the worker will still use those dns records in the fetch.
Basically it doesn't use Public DNS/it only uses internal DNS for same-zone fetch even for partial zones.
I remember there was a post about this which explained it fully I read somewhere in the past, I can't find it now.
If you have a partial zone though it means you have ticket support/live chat, you could ask support about it as well, perhaps there's some better workaround or something.

Sébastien MorelOP•12/27/23, 1:34 AM

I asked the chat they told me to post in community

Sébastien MorelOP•12/27/23, 1:34 AM

and that's clear I will CNAME the load balancer and test

Sébastien MorelOP•12/27/23, 1:35 AM

which I did in the forum and another thread here last week, gave it another chance today and you saved me, I believe, cause I really think it makes sense

Sébastien MorelOP•12/27/23, 1:40 AM

instant fix @Chaika

Sébastien MorelOP•12/27/23, 1:40 AM

working now!

Within worker DNS resolution is failing

Similar Threads

Similar Threads

Similar Threads