Cloudflare 通配符 DNS 条目 - 如果目标是 CloudFlare Worker,仍然受保护?

发布于 2025-01-10 04:23:42 字数 962 浏览 0 评论 0原文

我在 CloudFlare 的 DNS 常见问题解答 他们对通配符 DNS 条目是这么说的:

非企业客户可以创建但不能代理通配符记录。

如果您创建通配符记录,这些通配符子域将直接提供服务,无需任何 Cloudflare 性能、安全性或应用程序。因此,通配符域在 Cloudflare DNS 应用程序中没有云(橙色或灰色)。如果您要添加 * CNAME 或 A 记录,请确保记录呈灰色云状,以便创建记录。

我想知道的是,如果通配符 CNAME 记录的目标是 Cloudflare,人们是否仍然可以获得 CloudFlares 基础设施的好处Worker,比如 my-app.my-zone.workers.dev?我想,由于这是 Cloudflare 控制的资源,因此它仍然会受到 DDoS 等攻击的保护。或者,即使目标是 Cloudflare 工作人员,在初始 DNS 阶段发生的大部分 Cloudflare 安全性和性能也会丢失?

还发布到 CloudFlare 支持:https://community.cloudflare.com/t/wildcard-dns-entry-protection-if-target-is-cloudflare-worker/359763

I see that in CloudFlare’s DNS FAQs they say this about wildcard DNS entries:

Non-enterprise customers can create but not proxy wildcard records.

If you create wildcard records, these wildcard subdomains are served directly without any Cloudflare performance, security, or apps. As a result, Wildcard domains get no cloud (orange or grey) in the Cloudflare DNS app. If you are adding a * CNAME or A Record, make sure the record is grey clouded in order for the record to be created.

What I’m wondering is if one would still get the benefits of CloudFlares infrastructure of the target of the wildcard CNAME record IS a Cloudflare Worker, like my-app.my-zone.workers.dev? I imagine that since this is a Cloudflare controlled resource, it would still be protected for DDoS for example. Or is it that much of the Cloudflare security and performance happening at this initial DNS stage that will be lost even if the target is a Cloudflare worker?

Also posted to CloudFlare support: https://community.cloudflare.com/t/wildcard-dns-entry-protection-if-target-is-cloudflare-worker/359763

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

樱花落人离去 2025-01-17 04:23:42

我相信您是正确的,工作人员面前将会有一些基本级别的 Cloudflare 服务,但我认为如果直接访问工作人员(例如指向的灰云 CNAME 记录),您根本无法配置它们在它)。然而,这里的文档在 Cloudflare 方面有点模糊。

他们确实在不久前添加了功能以显示其服务的操作顺序,并且 Workers 似乎即将结束(意味着所有内容都位于前面)。但是,我认为这只适用于将其绑定到启用 Cloudflare 的 DNS 条目所覆盖的路由的情况。

https://blog.cloudflare.com/traffic-sequence-which -product-runs-first/

好消息是您应该能够相当轻松地测试它。例如,您可以:

  1. 设置具有测试路由的工作人员
  2. 仅指向 DNS(灰云)
    记录
  3. 确认您可以向工作人员发出请求
  4. 添加防火墙规则以阻止其余路由
  5. 查看您是否仍然可以向工作人员发出请求

这至少会给您一个答案,即您的区域设置在访问工作人员时是否适用(甚至通过灰云/通配符 DNS 条目)。虽然它不会回答worker面前有什么样的内置/不可配置的服务。

I believe you are correct that there will be some basic level of Cloudflare services in front of workers, but I don't think you'll be able to configure them at all if accessing the worker directly (e.g. a grey-cloud CNAME record pointed at it). Documentation here is a little fuzzy on the Cloudflare side of things however.

They did add functionality a little while back to show the order of operations of their services, and Workers seem to be towards the end (meaning everything sits in front). However, I would think this only applies if you bind it to a route that is covered under a Cloudflare-enabled DNS entry.

https://blog.cloudflare.com/traffic-sequence-which-product-runs-first/

The good news is you should be able to test this fairly easily. For example, you can:

  1. Setup a worker with a test route
  2. Point a DNS-only (grey cloud)
    record at it
  3. Confirm you can make a request to worker
  4. Add a firewall rule to block the rest route
  5. See if you can still make the request to worker

This will at least give you an answer on whether your zone settings apply when accessing a worker (even through a grey cloud / wildcard DNS entry). Although it will not answer what kind of built-in / non-configurable services there are in front of workers.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文