Cloudflare Developers•13mo ago

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 …

14 Replies

Chaika•13mo ago

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•13mo ago

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•13mo ago

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

Sébastien MorelOP•13mo ago

it also mentions that worker to anything should work just read the github issue and I have the same exact behavir as jgontrum

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.

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

Chaika•13mo ago

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•13mo ago

let me rephrase it but it's a very common situation I believe. I have an API. api.z.com on the zone z.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.com new-api.z.com is reachable and run the code from my worker. when I reach the worker from its custom domain new-api.z.com the DNS resolution of api.z.com is non-sense. the worker does not reach the correct servers behind api.z.com When reached through its workder.dev route, the worker has no issue to resolve api.z.com Is that clearer? I'd love to figure this out! 😉

Chaika•13mo ago

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•13mo ago

ha, and yes what you say would make sense, so you say I could trick the zone in Cloudflare for api.z.com so internally it would use it rather than the real one? I like it, it's weird but it makes sense. 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 maybe 1 more question but technically I could remove all of them right, Cloudflare does not mange the DNS at all in my usecase all but the new-api.z.com

Chaika•13mo ago

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•13mo ago

one thing that does not make sense so much yet to me is why when reached via it's .workers.dev everything works fine it's like depending on how the worker is reached, it changes something in the dns resolution

Chaika•13mo ago

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.com and a worker executing on test.partialzone.com, which is CNAME'd to that zone. Then I have a record for testk 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.com and send traffic to it 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•13mo ago

hum ok 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

Chaika•13mo ago

Sure, to summarize what I was saying may be a workaround is just manually creating the A/AAAA records in cloudflare for api.z.com which you fetch in your worker on new-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•13mo ago

I asked the chat they told me to post in community 🙂 and that's clear I will CNAME the load balancer and test 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 instant fix @Chaika 🙂 working now!

Gaming

Programming

Within worker DNS resolution is failing