2023 年 10 月 4 日 1.1.1.1 查询失败
在 2023 年 10 月 4 日，从 7:00 UTC 到 11:00 UTC 的这段时间里，Cloudflare 出现了 DNS 解析问题。1.1.1.1 或 Warp、Zero Trust 等产品或使用 1.1.1.1 的第三方 DNS 解析器的一些用户可能会收到对有效查询的 SERVFAIL DNS 响应。对于本次故障，我们深表歉意。本次故障是内部软件错误造成的，不是遭到攻击所致。在这篇博文中，我们将讨论出现了什么故障、发生原因以及我们采取了哪些措施来确保这种情况不再发生。
背景
在域名系统 (DNS) 中，每个域名都位于一个 DNS 区域中。区域是一起控制的域名和主机名的集合。例如，Cloudflare 负责域名 cloudflare.com，我们称其为在 "cloudflare.com" 区域中。.com 顶级域名 (TLD) 归第三方所有，位于 "com" 区域中。它提供如何访问 cloudflare.com 的指示。对于 TLD，最重要的是根区，它提供如何访问 TLD 的指示。这意味着根区对于解析所有其他域名非常重要。与 DNS 的其他重要部分一样，根区也使用 DNSSEC 进行签名，这意味着根区本身包含加密签名。
根区在根服务器上发布，但 DNS 运营商通常也会自动检索并保留根区的副本，使得万一根服务器无法访问时，根区中的信息仍然可用。Cloudflare 的递归 DNS 基础设施也采用了这种方法，因为它还可以加快解析过程。根区的新版本通常每天发布两次。1.1.1.1 有一个名为 static_zone 的 WebAssembly 应用程序，它在主 DNS 逻辑的基础上运行，在新版本可用时为它们提供服务。
究竟发生了什么
在 9 月 21 日，作为根区管理已知和计划变更的一部分，根区中首次加入了一种新的资源记录类型。新资源记录名为 ZONEMD，实际上是根区内容的校验和。
根区通过在 Cloudflare 核心网络中运行的软件检索。随后，它被重新分配到 Cloudflare 遍布全球的数据中心。更改后，包含 ZONEMD 记录的根区仍可正常检索和分配。但是，使用该数据的 1.1.1.1 解析器系统在解析 ZONEMD 记录时遇到了问题。由于区域必须完整加载并提供，如果系统无法解析 ZONEMD，则意味着 Cloudflare 解析器系统未使用新版本的根区。一些托管 Cloudflare 解析器基础架构的服务器在未收到新的根区时，无法逐个请求直接查询 DNS 根服务器。然而，继续依赖于根区的已知正常工作版本的其他用户在内存缓存中仍可使用该版本，即在变更前于 9 月 21 日提取的版本。
在 2023 年 10 月 4 日 07:00 UTC，9 月 21 日发布的根区版本中的 DNSSEC 签名已过期。由于 Cloudflare 解析器系统无法使用本来应该可以使用的较新版本，Cloudflare 的一些解析器系统无法验证 DNSSEC 签名，因此开始发送错误响应 (SERVFAIL)。Cloudflare 解析器生成 SERVFAIL 响应的比率增长了 12%。下图说明了故障的发展过程以及用户如何看到故障。
事件时间线和影响
9 月 21 日 6:30 UTC：最后一次成功提取根区
10 月 4 日 7:00 UTC：在 9 月 21 日获得的根区中的 DNSSEC 签名过期，导致对客户端查询的 SERVFAIL 响应增加。
7:57：开始收到第一份关于意外 SERVFAIL 的外部报告。
8:03：宣布内部 Cloudflare 事件。
8:50：首次尝试通过覆盖规则阻止 1.1.1.1 使用过期的根区文件提供响应。10:30：完全阻止 1.1.1.1 预装根区文件。
10:32：响应恢复正常。
11:02：事件关闭。
下图显示了受影响的时间以及返回 SERVFAIL 错误的 Continue reading
2023 年 10 月 4 日 1.1.1.1 查詢失敗
2023 年 10 月 4 日，Cloudflare 於世界標準時 7:00 開始至 11:00 結束期間遇到 DNS 解析問題。1.1.1.1 或 Warp 、 Zero Trust 等產品的一些使用者，或使用 1.1.1.1 的第三方 DNS 解析程式可能已經收到對有效查詢的 SERVFAIL DNS 回應。對於此次服務中斷，我們深感抱歉。此次服務中斷為內部軟體錯誤，而非攻擊造成的結果。在這篇部落格中，我們將討論失敗的內容、發生的原因，以及我們可以採取哪些措施來確保這種情況不再發生。
背景
在 Domain Name System (DNS) 中，每一個網域名稱存在於 DNS 區域內。區域是在一起接受控制的網域名稱和主機名稱的集合。例如，Cloudflare 負責網域 cloudflare.com，我們稱之為「cloudflare.com」區域。頂級網域 (TLD) .com 由第三方擁有，位於「com」區域。它提供如何連線 cloudflare.com 的指示。所有 TLD 之上為根區域，提供如何連線 TLD 的指示。這意味著根區域對於解析所有其他網域名稱很重要。與 DNS 的其他重要部分一樣，根區域使用 DNSSEC 進行簽署，這也意味著根區域本身包含加密簽章。
根區域發布於根伺服器上，但 DNS 營運商自動擷取並保留根區域副本的情況也很常見， 以便在無法連線根伺服器的情況下，根區域中的資訊仍然可供使用。Cloudflare 的遞迴 DNS 基礎架構會採用此方法，因為它還可加速解析程序。新版根區域通常一天發布兩次。1.1.1.1 具有稱為 static_zone 的 WebAssembly 應用程式，該應用程式執行於主 DNS 邏輯之上，當新版本可供使用時，即可提供這些新的版本。
狀況說明
9 月 21 日，作為根區域管理中的已知計畫內變更的一部分，新的資源記錄類型首次納入根區域。新資源記錄稱為 ZONEMD，實際上是根區域內容的總和檢查碼。
藉由執行於 Cloudflare 核心網路的軟體來擷取根區域。隨後，根區域被重新分散到 Cloudflare 在世界各地的資料中心。變更之後，可繼續正常擷取和分散包含 ZONEMD 記錄的根區域。然而，使用該資料的 1.1.1.1 解析程式系統在剖析 ZONEMD 記錄時遇到問題。由於區域必須完整載入和提供，因此系統無法剖析 ZONEMD，這意味著新版根區域未在 Cloudflare 的解析程式系統中使用。若託管 Cloudflare 解析程式基礎架構的某些伺服器未收到新的根區域，則會發生容錯移轉，直接逐個請求地查詢 DNS 根伺服器。不過，其他伺服器會繼續依賴其記憶體快取仍然可用的已知工作版根區域，這是在變更之前於 9 月 21 日提取的版本。
2023 年 10 月 4 日世界標準時 7:00，根區域版本中自 9 月 21 日開始的 DNSSEC 簽章到期。由於 Cloudflare 解析程式系統沒有能夠使用的更新版本，某些 Cloudflare 解析程式系統無法驗證 DNSSEC 簽章，並因此開始傳送錯誤回應 (SERVFAIL)。Cloudflare 解析程式產生 SERVFAIL 回應的速度提升了 12%。下圖說明了失敗的進度，以及如何顯示給使用者。
事件時間表和影響
9 月 21 日世界標準時 6:30：根區最後一次成功提取
10 月 4 日世界標準時 7:00：根區域中於 9 月 21 日取得的 DNSSEC 簽章到期，導致對用戶端查詢的 SERVFAIL 回應增加。
7:57︰第一個外部非預期 SERVFAIL 報告開始出現。
8:03︰正式宣佈發生內部 Cloudflare 事件。
8:50：初次嘗試阻止 1.1.1.1 使用具有覆寫規則的過時根區域檔案來提供回應。
10:30：完全阻止 1.1.1.1 預先載入根區域檔案。
10:32：回應恢復正常。
11:02︰事件結束。
下圖顯示了影響時間表，以及傳回 SERVFAIL 錯誤的 DNS 查詢百分比：
我們預計，在正常操作期間，常規流量的 SERVFAIL 錯誤數量會達到基準。該比例通常在 Continue reading
2023年10月4日の1.1.1.1ルックアップ障害
2023年10月4日、Cloudflareで07:00～11:00 (協定世界時) にかけてDNS解決に関する障害が発生しました。一部の1.1.1.1の利用者、または1.1.1.1を使用するWarp 、Zero Trust、サードパーティDNSリゾルバなどの製品の一部の利用者が、有効なクエリに対して「SERVFAIL DNS」応答を受信した可能性があります。この度は、ご迷惑をおかけして大変申し訳ございませんでした。この障害は内部的なソフトウェアのエラーであり、攻撃によるものではありません。このブログでは、障害の経緯、発生理由、そして再発防止に対する当社の取り組みについて説明します。
背景
ドメインネームシステム（DNS）の仕組みでは、すべてのドメイン名はDNSゾーン内に存在します。ゾーンには、ドメイン名とホスト名のセットの集合体が管理されています。たとえば、Cloudflareはcloudflare.comというドメイン名を管理しており、これは「cloudflare.com」ゾーンにあると言えます。トップレベルドメイン（TLD）「.com」はサードパーティが所有し、「com」ゾーンにあります。comによってcloudflare.comへのアクセス方法が示されます。すべてのTLDの上位には各TLDへのアクセス方法を示す、ルートゾーンがあります。そのため、ルートゾーンは他のすべてのドメイン名を解決できるようにするために重要な存在です。DNSの他の重要な部分と同様に、ルートゾーンもDNSSECで署名されており、ルートゾーン自体には暗号署名が含まれています。
ルートゾーンはルートサーバーによって公開されていますが、多くのDNS運用者は一般的にルートサーバーに到達できない場合でもルートゾーンの情報を利用できるようにルートゾーンのコピーを自動的に取得して保持するようにしています。 Cloudflareの再帰DNSインフラストラクチャも解決プロセスを高速化するため、このアプローチを採用しています。ルートゾーンの新バージョンは通常1日2回公開されます。1.1.1.1では、 static_zoneと呼ばれるWebAssemblyアプリがメインのDNSロジックの上で動作しており、新バージョンが公開された段階で新バージョンを提供できるようにしています。
障害発生の原因
9月21日、ルートゾーン管理における既知の計画済みの変更の内容に、ルートゾーンに初めて、チェックサムとして機能する新たなリソースレコードタイプ「ZONEMD」が追加されるというものがありました。
ルートゾーンの情報は、Cloudflareのコアネットワークで動作するソフトウェアによって取得されます。その後、世界中のCloudflareのデータセンターに再配布されます。変更後も、ZONEMDレコードを含むルートゾーンは通常通り取得および配布は継続して実行されていました。しかし、そのデータを利用する1.1.1.1のリゾルバシステムに問題があり、ZONEMDレコードを解析することができませんでした。ゾーンは全体をロードして提供する必要があるため、システムがZONEMDを解析できなかったことにより、ルートゾーンの新バージョンをCloudflareのリゾルバシステムで使用することができなくなりました。Cloudflareのリゾルバインフラストラクチャをホストしているサーバーの中には、新しいルートゾーンの情報を受信できなかった場合、リクエストの都度、DNSルートサーバーに直接問い合わせるようにフェイルオーバーするものもあります。しかし、他のサーバーは、メモリキャッシュに保存されたルートゾーンの既知の動作バージョン（変更前の9月21日に引き出されたバージョン）の利用を続けました。
2023年10月4日7時（協定世界時）、9月21日バージョンのルートゾーンのDNSSECの有効期限が切れました。Cloudflareのリゾルバシステムで利用可能な新しいバージョンが無くなり、Cloudflareの一部のリゾルバシステムがDNSSECシグネチャを検証できなくなり、その結果、エラーレスポンス（SERVFAIL）を送信するようになりました。CloudflareリゾルバのSERVFAILレスポンス生成割合が12%増加する事態となりました。以下の図は、障害の進行と、ユーザーへの影響が表面化した経緯を示しています。
インシデントのタイムラインと影響
9月21 日6:30（協定世界時）：ルートゾーンからの最後の情報引き出しの成功
10月4日7:00（協定世界時）：9月21日に取得したルートゾーンのDNSSEC署名が期限切れとなり、クライアントからの問い合わせに対するSERVFAIL応答が増加。
7:57：予期せぬSERVFAILに対する最初の外部報告が入り始める。
06:32：Cloudflare社内でインシデントが宣言される。
8:50：オーバーライドルールを使用して、1.1.1.1が古いルートゾーンファイルを使用した応答を提供するのを防ぐ最初の試みを実施。
10:30：1.1.1.1のルートゾーンファイルの事前読み込みを完全に停止。10:32：応答が正常に回復。
11:02：インシデントをクローズ。
この下のグラフは、影響とSERVFAILエラーで返されたDNS問い合わせのパーセンテージを時系列で表したものです：
私たちは、平常時のトラフィックにおけるSERVFAILエラーの基準量（通常値）を3%程度と想定しています。この場合のSERVFAILは、DNSSECチェーンにおける正当な問題、権威サーバーへの接続の失敗、権威サーバーの応答のタイムアウト、その他多くの要因によって引き起こされる可能性があります。インシデントの間、SERVFAILの量は総クエリの15%でピークに達しましたが、その影響は世界中に均等に分散されたわけではなく、アッシュバーン（バージニア州）、フランクフルト（ドイツ）、シンガポールのような大規模なデータセンターに主に集中しました。
インシデント発生の理由
ZONEMDレコードの解析に失敗した理由
DNSは、リソースレコードの格納にバイナリ形式を採用しています。このバイナリ形式では、リソースレコードのタイプ（TYPE）は16ビットの整数として格納されます。リソースレコードのタイプが、リソースデータ（RDATA）の解析方法を決定します。レコードタイプ「1」はAレコードであることを意味し、RDATAはIPv4アドレスとして解析されます。レコードタイプ「28」はAAAAレコードを意味し、RDATAはIPv6アドレスとして解析されます。解析が未知のリソースタイプに遭遇した場合、RDATAの解析方法を判断することができないが、RDLENGTHフィールドがRDATAフィールドの長さを示すため、解析はそれを不明なデータ要素として扱うことができます。
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ /
/ NAME /
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| CLASS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TTL |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RDLENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
/ RDATA /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
static_zoneが新しいZONEMDレコードをサポートしなかった理由は、これまで私たちがルートゾーンをバイナリ形式ではなく、プレゼンテーション形式で内部配布することを選んできたためです。リソースレコードのテキスト表現をいくつか見てみると、異なるレコードの表示形式には、さらに多くのバリエーションがあることがわかります。
. 86400 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2023100400 1800 900 604800 86400
. 86400 IN RRSIG SOA 8 0 86400 20231017050000 20231004040000 46780 . J5lVTygIkJHDBt6HHm1QLx7S0EItynbBijgNlcKs/W8FIkPBfCQmw5BsUTZAPVxKj7r2iNLRddwRcM/1sL49jV9Jtctn8OLLc9wtouBmg3LH94M0utW86dKSGEKtzGzWbi5hjVBlkroB8XVQxBphAUqGxNDxdE6AIAvh/eSSb3uSQrarxLnKWvHIHm5PORIOftkIRZ2kcA7Qtou9NqPCSE8fOM5EdXxussKChGthmN5AR5S2EruXIGGRd1vvEYBrRPv55BAWKKRERkaXhgAp7VikYzXesiRLdqVlTQd+fwy2tm/MTw+v3Un48wXPg1lRPlQXmQsuBwqg74Ts5r8w8w==
. 518400 IN NS a.root-servers.net.
. 86400 IN ZONEMD 2023100400 1 241 E375B158DAEE6141E1F784FDB66620CC4412EDE47C8892B975C90C6A102E97443678CCA4115E27195B468E33ABD9F78C
未知のリソースレコードに遭遇した際の処理方法の判断は必ずしも単純なものではありません。このため、私たちがエッジで使用するルートゾーン解析用のライブラリは、解析を行わずに代わりに解析エラーを返します。
ルートゾーンの古いバージョンが使用された理由
static_zoneアプリは、ルートゾーンをローカルに提供（FC 7706）する目的で、ルートゾーンの読み込みと解析を行い、最新バージョンをメモリに保存します。新バージョンが公開されると、static_zoneアプリがそれを解析し、解析に成功すると旧バージョンを削除します。しかし、static_zoneアプリは解析に失敗し、新しいバージョンに切り替えることができないため、古いバージョンを延々と使用し続けることになりました。1.1.1.1サービスが最初に起動されたとき、static_zoneアプリは既存のバージョンをメモリ内に持ち合わせていません。ルートゾーンを解析しようとすると失敗するものの、ルートゾーンの古いバージョンも持ち合わせていないため、ルートサーバーに直接リクエストを問い合わせることになります。
static_zoneを無効にする最初の試みがうまくいかなかった理由
当初、1.1.1.1の動作をプログラム的に変更可能な仕組みであるオーバーライドルールによってstatic_zoneアプリの無効化が試行されました。私たちが展開したルールは以下のとおりです：
phase = pre-cache set-tag rec_disable_static
このルールは、受信したリクエストに「rec_disable_static」タグを付加します。static_zoneアプリの内部でこのタグをチェックし、設定されている場合、キャッシュされた静的ルートゾーンから応答を返しません。ただし、現在のノードが自身のキャッシュから応答を見つけられない場合、キャッシュパフォーマンス向上のために、問い合わせが別のノードに転送されることがあります。残念ながら、他のノードに転送される問い合わせにはrec_disable_staticタグが含まれないため、最終的にアプリを完全に無効にするまで、static_zoneアプリは古い情報を返し続けることとなりました。
影響が部分的だった理由
Cloudflareでは、カーネルアップデートなどのシステムを完全に再起動することで有効になるタスクのため、当社のサービスをホストするサーバーを定期的に順次の再起動を実施しています。今回の障害発生時、ZONEMDの変更とDNSSECの無効化の間に再起動されたリゾルバサーバインスタンスは、影響に寄与していません。もしこの2週間の間に再起動されていた場合、起動時にルートゾーンのロードに失敗し、代わりにルートサーバーにDNSクエリを送信して解決を試みることになったでしょう。加えて、リゾルバはserve-stale（RFC 8767）と呼ばれる技法を用い、影響を抑制する目的で、アクセス数の多いレコードを、最新ではない可能性のあるキャッシュから提供し続けることになります。レコードが上流から取得されてからTTL秒数が経過すると、そのレコードは最新ではないとみなされます。これにより、完全な停止を防ぎました。影響は主に、その時間枠内に1.1.1.1サービスを再起動しなかった多数サーバーを抱える最大規模のデータセンターで発生しました。
改善とフォローアップ手順
今回のインシデントは広範囲に影響を及ぼしており、当社では当社のサービスの可用性について非常に重く受け止めております。当社はいくつかの領域における改善点の特定に至りましたが、今後も再発の原因となるその他のギャップの発見に努めてまいります。
当社が直後から取り組んでいる内容は以下のとおりです。
可視性：static_zoneが古いルートゾーンファイルを提供した場合に通知するアラートを追加しました。古いルートゾーンファイルが提供された場合に長期間気づかれないという事態は防がれるべき事象でした。もし私たちがこの件をもっときちんと監視し、キャッシングが存在していれば、影響はなかったでしょう。上流で行われた変更からお客様とそのユーザーをお守りすることが私たちの目標です。
耐障害性：内部的なルートゾーンの取得と配布方法を見直します。取得および配布のパイプラインは、新しいRRTYPEをシームレスに処理し、パイプラインの短時間の中断はエンドユーザーが気付かない程度に抑える必要があります。
テスト：新しいZONEMDレコードの解析における未公表の変更に関連するテストを含め、この問題に関するテストを実施しているにもかかわらず、ルートゾーンの解析に失敗した場合のテスト内容が不十分でした。そのため、カバレッジと関連するプロセスを改善していきます。
設計：特定の期限を過ぎたルートゾーンの古いコピーを使用すべきではありません。古いルートゾーンデータも限られた時間であれば使用し続けることは確かに可能ですが、ある時点を過ぎると、許容できない運用上のリスクが生じます。RFC 8806「Running a Root Server Local to a Resolver（ルートサーバーをリゾルバに対してローカルで実行する）」に記述されているように、キャッシュされたルートゾーンデータの有効期間をより適切に管理するための対策を講じます。
まとめ
このようなインシデントを起こしてしまったことを深くお詫び申し上げます。このインシデントから学ぶべき教訓は「変更はないだろう」と思い込まないことです。現代のシステムの多くは、最終的な実行ファイルに組み込まれる長いライブラリ群の連鎖で構築されており、そのひとつひとつにバグがあったり、変更があっても更新に遅延が発生してプログラムが正しく動作しないなどと言った事象が発生することがあります。私たちは、変更によるリグレッションを適切に検出する優れたテストや、変更に対して正常に失敗するシステムやコンポーネントを用意することがいかに重要であるかを理解しています。私たちは、インターネットの最も重要なシステム（DNSやBGP）における「形式」の変更が影響を及ぼすことを常に想定する必要があることを理解しています。
社内でフォローアップすべきことはたくさんあり、私たちは現在、このようなことを二度と起こさないよう24時間体制で取り組んでいます。
Fallos de la búsqueda de 1.1.1.1 del 4 de octubre de 2023
El 4 de octubre de 2023, Cloudflare sufrió problemas en la resolución de DNS entre las 07:00 y las 11:00 UTC. Algunos usuarios de 1.1.1.1 o de productos como WARP, Zero Trust o de solucionadores DNS externos que utilicen 1.1.1.1 pueden haber recibido respuestas SERVFAIL DNS a consultas válidas. Lamentamos mucho esta interrupción. Fue debido a un error interno del software y no fue consecuencia de ningún ataque. En esta publicación del blog, hablaremos acerca de en qué consistió el fallo, por qué se produjo y qué estamos haciendo para garantizar que no se repita.
Antecedentes
En el sistema de nombres de dominio (DNS), cada nombre de dominio existe en una zona DNS, que está formada por un conjunto de nombres de dominio y nombres de servidor que se controlan juntos. Por ejemplo, Cloudflare es responsable del nombre de dominio cloudflare.com, que decimos que está en la zona "cloudflare.com". El dominio de nivel superior (TLD) .com es propiedad de un tercero y está en la zona "com". Proporciona indicaciones acerca de cómo llegar a cloudflare.com. Por encima de todos los TLD se encuentra la zona raíz, que ofrece indicaciones Continue reading
1.1.1.1 Lookup-Fehler am 4. Oktober 2023
Am 4. Oktober 2023 traten bei Cloudflare Probleme bei der DNS-Auflösung auf, die um 07:00 UTC begannen und um 11:00 UTC endeten. Einige Nutzer von 1.1.1.1 oder Produkten wie WARP, Zero Trust oder DNS-Resolvern von Drittanbietern, die 1.1.1.1 verwenden, haben möglicherweise SERVFAIL DNS-Antworten auf gültige Anfragen erhalten. Wir möchten uns vielmals für diesen Ausfall entschuldigen. Dieser Ausfall war ein interner Softwarefehler und nicht das Ergebnis eines Angriffs. In diesem Blogartikel werden wir erläutern, was der Fehler war, warum er auftrat und was wir unternehmen, um sicherzustellen, dass sich so etwas nicht wiederholt.
Hintergrund
Im Domain Name System (DNS) existiert jeder Domain-Name innerhalb einer DNS-Zone. Die Zone ist eine Sammlung von Domain-Namen und Host-Namen, die gemeinsam kontrolliert werden. So ist Cloudflare beispielsweise für die Domain cloudflare.com verantwortlich, die sich in der Zone „cloudflare.com“ befindet. Die Top-Level-Domain (TLD) .com gehört einer dritten Partei und befindet sich in der Zone „com“. Sie gibt Auskunft darüber, wie cloudflare.com zu erreichen ist. Über allen TLDs befindet sich die Root-Zone, die Hinweise darauf gibt, wie die TLDs erreicht werden. Das bedeutet, dass die Root-Zone wichtig ist, um alle anderen Domain-Namen auflösen zu können. Wie andere wichtige Continue reading
Les échecs des recherches sur le résolveur 1.1.1.1 le 4 octobre 2023
Le 4 octobre 2023, Cloudflare a rencontré des problèmes de résolution DNS à partir de 7 h UTC, et ce jusqu'à 11 h UTC. Certains utilisateurs de 1.1.1.1 ou de produits tels que WARP, Zero Trust ou d'autres résolveurs DNS tiers utilisant 1.1.1.1 peuvent avoir reçu des réponses SERVFAIL DNS à leurs requêtes, pourtant valides. Nous sommes sincèrement désolés pour cette panne. Celle-ci était due à une erreur logicielle interne et n'était aucunement le résultat d'une attaque. Cet article de blog va nous permettre de discuter de la nature de cette défaillance, des raisons pour lesquelles elle s'est produite et des mesures que nous avons mises en œuvre pour nous assurer qu'une telle situation ne se reproduise jamais.
Contexte
Dans le Domain Name System (DNS, système de noms de domaine), chaque nom de domaine existe au sein d'une zone DNS. Cette zone constitue un ensemble de noms de domaine et de noms d'hôte, contrôlés conjointement. Pour prendre un exemple, Cloudflare est responsable du nom de domaine cloudflare.com, que nous disons se trouver dans la zone « cloudflare.com ». Le domaine de premier niveau (TLD, Top-Level Domain) « .com » est détenu par Continue reading
All Cloudflare Customers Protected from Atlassian Confluence CVE-2023-22515
On 2023-10-04 at 13:00 UTC, Atlassian released details of the zero-day vulnerability described as “Privilege Escalation Vulnerability in Confluence Data Center and Server” (CVE-2023-22515), a zero-day vulnerability impacting Confluence Server and Data Center products.
Cloudflare was warned about the vulnerability before the advisory was published and worked with Atlassian to proactively apply protective WAF rules for all customers. All Cloudflare customers, including Free, received the protection enabled by default. On 2023-10-03 14:00 UTC Cloudflare WAF team released the following managed rules to protect against the first variant of the vulnerability observed in real traffic.
When CVE-2023-22515 is exploited, an attacker could access public Confluence Data Center and Server instances to create unauthorized Confluence administrator accounts to access the instance. According to the advisory the vulnerability is assessed by Atlassian as critical. At the moment of writing a CVSS score is not yet known. More information can be found in the security advisory, including what versions of Confluence Server are affected.
Waiting Room adds multi-host and path coverage, unlocking broader protection and multilingual setups
Cloudflare Waiting Room protects sites from overwhelming traffic surges by placing excess visitors in a fully customizable virtual waiting room, admitting them dynamically as spots become available. Instead of throwing error pages or delivering poorly-performing site pages, Waiting Room empowers customers to take control of their end-user experience during unmanageable traffic surges.
A key decision customers make when setting up a waiting room is what pages it will protect. Before now, customers could select one hostname and path combination to determine what pages would be covered by a waiting room. Today, we are thrilled to announce that Waiting Room now supports coverage of multiple hostname and path combinations with a single waiting room, giving customers more flexibility and offering broader site coverage without interruptions to end-user flows. This new capability is available to all Enterprise customers with an Advanced Purchase of Waiting Room.
Waiting Room site placement
As part of the simple, no-coding-necessary process for deploying a waiting room, customers specify a hostname and path combination to indicate which pages are covered by a particular waiting room. When a site visitor makes a preliminary request to that hostname and path or any of its subpaths, they will be issued a Continue reading
Waiting Room ajoute la prise en charge d'hôtes et de chemins d'accès multiples, offrant une protection plus étendue et des configurations multilingues
Cloudflare Waiting Room protège les sites contre les surcharges liées aux pics de trafic en transférant l'excédent de visiteurs vers une salle d'attente virtuelle, entièrement personnalisable, dans laquelle les visiteurs sont admis dynamiquement, au fur et à mesure que des places se libèrent. Au lieu d'afficher des pages d'erreur ou de proposer une expérience insatisfaisante de l'affichage des pages du site, Waiting Room permet aux clients de prendre le contrôle de l'expérience de leurs utilisateurs finaux pendant les pics de trafic ingérables.
L'une des principales décisions que prennent les clients lors de la configuration d'une salle d'attente consiste à sélectionner les pages que protégera celle-ci. Jusqu'à présent, les clients pouvaient sélectionner un nom d'hôte et un chemin d'accès lors de la désignation des pages protégées par une instance de Waiting Room. Aujourd'hui, nous sommes ravis d'annoncer que Waiting Room propose désormais la prise en charge de combinaisons de noms d'hôtes et de chemins d'accès multiples pour une salle d'attente unique, offrant ainsi aux clients davantage de flexibilité et une prise en charge plus étendue des sites, sans interruption des flux des utilisateurs finaux.Cette nouvelle fonctionnalité est accessible à tous les clients Enterprise ayant préacheté Waiting Room.
Ajout d'un site Continue reading
Waiting Room añade la cobertura de múltiples hosts y rutas de acceso, y ofrece así una protección más amplia y configuraciones multilingües
Cloudflare Waiting Room protege los sitios contra las sobrecargas vinculadas a los picos de tráfico, colocando el exceso de visitantes en una sala de espera virtual, completamente personalizable, donde son admitidos dinámicamente a medida que se liberan plazas. En lugar de mostrar páginas de error o entregar páginas del sitio con un bajo rendimiento, Waiting Room permite a los clientes tomar el control de su experiencia de usuario final durante los picos de tráfico inmanejables.
Una decisión clave que toman los clientes al configurar una sala de espera es acerca de qué páginas protegerán. Hasta ahora, los clientes podían seleccionar una sola combinación de nombre de host y ruta de acceso para determinar las páginas cubiertas por una sala de espera. Hoy nos complace anunciar que Waiting Room ahora ofrece compatibilidad con varias combinaciones de nombres de host y rutas de acceso con una sola sala de espera, y ofrece así a los clientes más flexibilidad y una cobertura más amplia del sitio sin interrupciones de los flujos de los usuarios finales. Esta nueva funcionalidad está disponible para todos los clientes Enterprise con una versión Advanced de Waiting Room.
Colocación de un sitio en Waiting Room
Durante la implementación de Continue reading
Waiting Roomは、マルチホストとパスのカバレッジを拡充し、より広範な保護と多言語セットアップを実現できる製品です
Cloudflare Waiting Roomは、完全にカスタマイズ可能な仮想待機室に過剰なウェブ訪問者を配置し、空き枠ができると動的にこれを受け入れることにより、急激なトラフィック急増からサイトを保護します。Waiting Roomにより、管理しきれないトラフィック急増時にエラーページを表示したりパフォーマンスの低いサイトページを配信したりするのではなく、エンドユーザーエクスペリエンスをコントロールできるようにします。
待機室を設定する際、保護の対象となるページの決定が重要になります。これまでは、ホスト名とパスの組み合わせを1つ選び、待機室の対象となるページを決めることができました。今日、Waiting Roomsでは、単一の待機室で複数のホスト名とパスの組み合わせに対応できるようになりました。これにより、お客様にはより多くの柔軟性がもたらされ、エンドユーザーのフローを中断することなく、より広範なサイトカバレッジを提供できるようになりました。この新機能は、「Waiting Rooms」のアドバンスをご利用のすべてのEnterprise契約のお客様にご利用いただけます。
Waiting Roomsのサイトでの設置
シンプルかつコーディング不要の待機室のデプロイプロセスでは、ホスト名とパスの組み合わせを指定し、特定の待機室がカバーするページを指定します。Web訪問者がそのホスト名とパス、またはそのサブパスに予備リクエストを行うと、待機室クッキーが発行され、サイトへの入場が許可されるか、もしくはサイトの容量が足りない場合、待機室に導きます。
昨年、当社は Waiting Roomのバイパスルール機能を追加し、ホスト名とパスカバレッジの例外を設けるための多くの選択肢をお客様に提供しました。これにより、ユーザーエージェントバイパス、ジオターゲティング、URL除外、管理用IPバイパスなどの機能が活用できるようになりました。また、URL、パス、クエリ文字列を除外する機能を追加することで、顧客サイト上で待機室を適用するページの設定の柔軟性を高めることとなりました。このアップデートにより、Waiting Roomによってゲートされるべきトラフィックをより具体化できるようになった一方、カバレッジは狭いままで多くの顧客が単一の待機室でサイトの大部分を保護することはできませんでした。
顧客がよりカバレッジのWaiting Roomsを必要とした理由
幅広いカバレッジを持つ製品機能が顧客にとって重要であった理由について、簡単ではあるもののインパクトのある例をいくつか挙げてみます。example.comというオンラインストアがあるとします。単一の待機室で、ホームページから商品閲覧、チェックアウトまで、顧客の利用体験全体をカバーできるようにしたいと考えたとします。多くのサイトでは、フロー内のこれらのステップを次のようにパスを用いて指定します：「example.com/, example.com/shop/product1、 example.com/checkout」。Waiting Roomは設定されたパスの最後にワイルドカードを想定するため、これらのサイトではこのユースケースはすでに十分なものでした。したがって、example.com/に待機室を設置すれば、この顧客利用体験のあらゆる段階で関連することになるすべてのURLをカバーすることができました。このセットアップでは、一度待機室を通過したWeb訪問者は、Waiting Roomに対し同一のユーザーであることをURL間の遷移の際に明示する同一待機室のクッキーを使用しているため、ユーザーフローのどのステップでも再キューされなおすことはありません。
しかし、多くのサイトでは、パスの代わりもしくはパスと併せサブドメインを使い、この種のショッピングフローの各段階を区切っています。例えば、多くのサイトでは、チェックアウトページをcheckout.example.comのような別のサブドメインに置いています。以前は、このようなサイト構造を持つ顧客がサイト全体を単一の待機室で保護する場合、example.com/ に待機室をデプロイし、checkout.example.com/に別の待機室を配置する必要がありました。このやり方は、多くの顧客にとって理想的なものではありませんでした。あるサイトのWeb訪問者が、同じ顧客利用体験の2つの異なる部分でキューに入れられる可能性があったからです。これは、checkout.example.com/の待機室がexample.com/をカバーするのではなく、Web訪問者を別のユーザーとして同じカウントすることが理由です。
とはいえ、1つのサイトで待機室を分けた方が賢明な場合もあります。例えば、チケット販売Webサイトは、そのエイペックスドメイン（example.com）に待機室を置くことができます。 また、特定のイベント（example.com/popular_artist_tour）のページでは、プレキューを持つ個別の待機室を設定しています。example.com/に設定された待機室は、あるイベントのチケット販売が開始されたときに、サイトへの主要な入り口が圧倒されてクラッシュすることがないようにします。 特定のイベントページに置かれた待機室は、サイトの他の部分に行くトラフィックに影響を与えることなく、単一のイベントのためのトラフィックがイベントの前にキューを開始できることを保証します。
最終的には、顧客がサイトの保護に1つまたは複数の待機室を望むかどうかにかかわらず、当社は顧客がユースケースとサイト構造に最適な待機室をデプロイする柔軟性を提供したいと考えました。今回、Waiting Roomが単一の待機室で複数のホスト名とパスカバレッジに対応できるようになったことを発表できることを大変うれしく思います。
マルチホストとパスカバレッジの始め方
今回、同じゾーンに属する複数のホスト名とパスの組み合わせ（またはルート）に待機室を設定できるようになりました。Traffic > 待機室を開き、Create（作成）を選択します。ドメイン名は、すでに入力されています。待機室設定にさらにルートを追加するには、Add Hostname and Path（ホスト名とパスの追加）を選択します。次に、同じ待機室にカバーさせる別のホスト名とパスを入力してください。各パスの最後はワイルドカード扱いとなります。そのため、待機室にカバーさせたいURLごとに待機室を作成する必要はありません。すでに入力した他のホスト名とパスの組み合わせではカバーできないURLに対してのみ、追加ルートを作成してください。
複数のホスト名とパスの組み合わせをカバーする待機室をデプロイする場合、この待機室用にユニークなクッキー名を作成する必要があります（詳細は後述します）。その後、普段と同じワークフローで待機室をデプロイしてください。
多言語待機室のデプロイ
多言語サイトを1つの待機室でカバーできること、つまり言語ごとに異なるテキストを提供しながら、すべてのサイトトラフィックを同じ待機室の制限にカウントできることは、お客様からよく寄せられていた要望でした。異なる言語オプションを区別するためにサイトを構成する方法はいろいろある中、最も一般的なのはサブドメインかパスによる方法です。パス区切りが使われているサイトでは、example.com/enやexample.com/esのようになります。それぞれ英語とスペイン語に対応するものです。サブドメイン区分を使用するサイトでは、en.example.com/、およびes.example.com/のようになります。マルチホスト待機室がカバーする以前は、サブドメインのバリエーションは単一の待機室ではカバーできませんでした。
Waiting Roomの既存の設定オプションでは、すでにパスのバリエーションに対応していました。しかし、これは顧客がサイト全体をゲートしたい場合にのみ、example.com/に待機室を置くことで可能でした。多くのeコマースのお客様から、同じ商品を販売する需要の高い商品ページを異なる言語オプションでゲート表示できるようにしてほしいという要望がよせられていました。例えば、example.com/en/product_123、および example.com/es/product_123の両方のURLをカバーするために同じ待機室とトラフィック制限が望まれていました。これまでは、複雑なバイパスルールのロジックがなければそれは不可能でした。
今では、お客様は多言語サイトの構成のために、サブドメインまたはパスのアプローチのいずれかに対応する待機室をデプロイできるようになりました。残る唯一のステップは、ユーザーが待機室にキューイングされているときに異なる言語を提供するように待機室を設定することです。これは、URLを読み込んでロケールを決定し、テンプレート内で各ロケールに適切な翻訳を定義するテンプレートを構築することで実現できます。
以下は、URLパスからロケールを決定し、翻訳されたテキストを表示するテンプレートの例です：
<!DOCTYPE html>
<html>
<head>
<title>Waiting Room powered by Cloudflare</title>
</head>
<body>
<section>
<h1 id="inline-msg">
You are now in line.
</h1>
<h1 id="patience-msg">
Thank you for your patience.
</h1>
</section>
<h2 id="waitTime"></h2>
<script>
var locale = location.pathname.split("/")[1] || "en";
var translations = {
"en": {
"waittime_60_less": "Your estimated wait time is {{waitTime}} minute.",
"waittime_60_greater": "Your estimated wait time is {{waitTimeHours}} hours and {{waitTimeHourMinutes}} minutes.",
"inline-msg": "You are now in line.",
"patience-msg": "Thank you for your patience.",
},
"es": {
"waittime_60_less": "El tiempo de espera estimado es {{waitTime}} minuto.",
"waittime_60_greater": "El tiempo de espera estimado es {{waitTimeHours}} de horas y {{waitTimeHourMinutes}} minutos.",
"inline-msg": "Ahora se encuentra en la fila de espera previa.",
"patience-msg": "Gracias por su paciencia.",
}
};
Continue reading2023년 10월 4일 1.1.1.1 조회 실패
2023년 10월 4일, Cloudflare에서는 DNS 확인 문제를 겪었으며, 이 문제는 UTC 07:00에 시작하여 UTC 11:00에 끝났습니다. 1.1.1.1 또는 Warp, Zero Trust 등의 제품 또는 1.1.1.1을 사용하는 타사 DNS 확인자를 사용하는 사람 중 일부는 유효한 쿼리에 대해 SERVFAIL DNS 응답을 받았을 수도 있습니다. 이번에 서비스가 중단되어 정말 죄송합니다. 이번 서비스 중단은 공격이 아니라 내부 소프트웨어 오류로 발생했습니다. 이 블로그에서는 어떤 장애였는지, 장애가 왜 발생했는지, 이런 일이 다시 발생하지 않도록 우리가 무엇을 하고 있는지 설명하겠습니다.
배경
도메인 네임 시스템(DNS)에서 모든 도메인 네임은 DNS 영역 내에 존재합니다. 이 영역은 함께 제어되는 도메인 이름과 호스트 이름의 모음입니다. 예를 들어, Cloudflare에서는 도메인 이름 cloudflare.com을 관리하며, 우리는 이를 "cloudflare.com" 영역이라고 부릅니다. .com의 최상위 도메인(TLD)은 타사 소유이며 "com" 영역에 있습니다. TLD는 cloudflare.com에 접속하는 방법에 대한 지침을 제공합니다. 모든 TLD 위에는 루트 영역이 있으며, 이 영역은 TLD에 도달하는 방법에 대한 지침을 제공합니다 . 즉, 루트 영역은 다른 모든 도메인 이름을 확인할 수 있는 중요한 영역입니다. DNS의 다른 중요한 부분과 마찬가지로 루트 영역은 DNSSEC로 서명되며, 이는 루트 영역 자체에 암호화 서명이 포함되어 있음을 의미합니다.
루트 영역은 루트 서버에 게시되지만, 루트 서버에 연결할 수 없는 경우에도 루트 영역의 정보를 계속 사용할 수 있도록 DNS 운영자가 루트 영역의 Continue reading
Announcing General Availability for the Magic WAN Connector: the easiest way to jumpstart SASE transformation for your network
Today, we’re announcing the general availability of the Magic WAN Connector, a key component of our SASE platform, Cloudflare One. Magic WAN Connector is the glue between your existing network hardware and Cloudflare’s network — it provides a super simplified software solution that comes pre-installed on Cloudflare-certified hardware, and is entirely managed from the Cloudflare One dashboard.
It takes only a few minutes from unboxing to seeing your network traffic automatically routed to the closest Cloudflare location, where it flows through a full stack of Zero Trust security controls before taking an accelerated path to its destination, whether that’s another location on your private network, a SaaS app, or any application on the open Internet.
Since we announced our beta earlier this year, organizations around the world have deployed the Magic WAN Connector to connect and secure their network locations. We’re excited for the general availability of the Magic WAN Connector to accelerate SASE transformation at scale.
When customers tell us about their journey to embrace SASE, one of the most common stories we hear is:
We started with our remote workforce, deploying modern solutions to secure access to internal apps and Internet resources. But now, we’re looking at Continue reading
Birthday Week recap: everything we announced — plus an AI-powered opportunity for startups
This year, Cloudflare officially became a teenager, turning 13 years old. We celebrated this milestone with a series of announcements that benefit both our customers and the Internet community.
From developing applications in the age of AI to securing against the most advanced attacks that are yet to come, Cloudflare is proud to provide the tools that help our customers stay one step ahead.
We hope you’ve had a great time following along and for anyone looking for a recap of everything we launched this week, here it is:
Monday
창립기념일 주간 요약: Cloudflare에서 발표한 모든 내용 및 스타트업을 위한 AI를 기반으로 한 기회
올해 Cloudflare에서는 공식적으로 13주년을 맞습니다. 우리는 이 이정표를 고객과 인터넷 커뮤니티 모두에 이점을 선사하는 다양한 발표로 기념했습니다.
AI 시대에 애플리케이션을 개발하는 것부터 아직 등장하지도 않은 최신 위협으로부터 보호하는 것까지 Cloudflare에서는 고객이 한 발자국 앞서 있을 수 있도록 도구를 제공한다는 사실을 자랑스럽게 여깁니다.
이러한 발표를 지켜보며 즐거운 시간이 되셨기를 바랍니다. 이번 주에 출시한 제품의 요약은 다음과 같습니다.
월요일
バースデーウィークの総括：当社のすべての発表、そしておよびスタートアップ企業にとってのAI活用の機会
今年、Cloudflareは正式にティーンエイジャーとなり、13歳を迎えました。当社ではこの節目を、お客様とインターネットコミュニティの双方に有益な一連の発表で祝いました。
AI時代のアプリケーション開発から、これから起こる最先端の攻撃に対するセキュリティまで、Cloudflareはお客様が一歩先を行くためのツールを提供できることを誇りに思っています。
当社が今週発表したすべてのニュースをまとめてご紹介します：
月曜日
火曜日
水曜日
木曜日
金曜日
追加
Cloudflareが昨年12周年を迎えた折、Workers Launchpad Funding Programを発表しました。クラウドレアのデベロッパー・プラットフォーム上に構築する企業のためのスタートアップ加速プログラムのようなもので、企業の規模、ステージ、地域に制限はありません。
Launchpadの仕組みについての振り返り：四半期ごとに、私たちはスタートアップのグループを選出し、幅広い技術的アドバイス、指導、資金調達の機会を提供しています。これには、ファウンダーズ・ブートキャンプ、ソリューション・アーキテクトによるオープン・オフィス・アワー、デモ・デーなどが含まれます。また、資金調達の準備が整ったスタートアップは、40社以上のグローバルな大手ベンチャーキャピタルのコミュニティに参加することができます。
その代わり、率直な感想の提供を依頼しています。当社では、何がうまくいき、何がうまくいかず、何が必要なのかを知りたいのです。当社は、貴企業への出資者となることを求めることはなく、プログラムに参加するために費用を負担することも求めていません。
Targum (my startup) was one of the first AI companies (w/ @jamdotdev ) in the Cloudflare workers launchpad!
— Alex Volkov (@altryne) September 27, 2023
In return to tons of stuff we got from CF 🙏 they asked for feedback, and my main one was, let me do everything end to end on CF, I don't want to rent GPU servers… https://t.co/0j2ZymXpsL
ここまで、60か国近くからの応募を受けてきました。当社は、最初の2つのコホートに参加した50の見事な初期および成長段階の新興企業と緊密に協力する機会を得、当社のVCパートナー・コミュニティを40社以上に拡大し、Cloudflareを基盤とする新興企業への潜在的な投資額は20億ドルを超えました。
次は、コホート#3となります。 先日、第2コホートが終了し（デモ・デーをぜひご覧ください）、Launchpadの1歳の誕生日を祝い、そして先週行ったたくさんの発表の間に、皆様にすべてのニュースにキャッチアップしていただくために十分な時間をとることが必要だと考えました。そのため、第3コホートの締め切りを数週間延長し、2023年10月13日とします。また、先週水曜日に発表されたAIのいずれかをすでに利用している方のために、5名分の枠を確保しています。応募時には、現在お使いいただいているものを明記していただけるよう、お願いいたします。
お知らせをチェックし、コーヒーを飲んで休んだら、Workers Launchpadをチェックしてみてください。応募は簡単です。コーヒーが冷めないうちに、応募は完了するでしょう。
次回まで
2023年のバースデーウィークは、以上です。また次回のイノベーション・ウィークでお会いしましょう！
i hate @Cloudflare launch week
— Dax (@thdxr) September 29, 2023
most launch weeks are underwhelming
cloudflare always makes me rethink everything i’m doing
Récapitulatif de la Semaine anniversaire : tout ce que nous avons annoncé, ainsi qu'une opportunité fondée sur l'IA et dédiée aux start-ups
Cette année, Cloudflare est officiellement entrée dans l'adolescence, puisque l'entreprise a fêté ses 13 ans. Nous avons fêté cet événement avec une série d'annonces qui profitent à la fois à nos clients et à la communauté Internet.
Du développement d'applications à l'ère de l'IA à la sécurisation contre des attaques extrêmement avancées et encore inconnues, Cloudflare est fière de fournir des outils qui aident nos clients à garder une longueur d'avance.
Nous espérons que vous avez passé un excellent moment à suivre notre actualité, et pour tous ceux qui souhaiteraient pouvoir consulter un récapitulatif de toutes les innovations que nous avons inaugurées cette semaine, le voici :
Lundi
Resumen de la Semana aniversario – consulta todos nuestros anuncios y descubre una oportunidad para empresas emergentes de IA
Este año, Cloudflare ha alcanzado oficialmente la adolescencia ¡cumplimos 13 años! Celebramos este hito con una serie de anuncios que benefician tanto a nuestros clientes como a la comunidad de Internet.
Desde el desarrollo de aplicaciones en la era de la IA hasta la protección contra los ataques más avanzados que están por llegar, Cloudflare se enorgullece de facilitar herramientas que ayudan a nuestros clientes a mantener una posición de ventaja.
Esperamos que te lo hayas pasado muy bien en este viaje. Si te interesa conocer un resumen de todos nuestros anuncios en esta semana, sigue leyendo:
LUNES
Die Birthday Week im Rückblick: alle unsere Ankündigungen und eine KI-gestützte Chance für Start-ups
Dieses Jahr ist Cloudflare offiziell ins Teenager-Alter eingetreten, denn wir feiern unser 13-jähriges Firmenjubiläum. Anlässlich dieses Meilensteins haben wir eine Reihe von neuen Produkten vorgestellt, von denen sowohl unseren Kunden als auch die Internet-Community im Allgemeinen profitieren werden.
Von der Anwendungsentwicklung im Zeitalter der KI bis hin zum Schutz vor den ausgefeiltesten Angriffen, die noch erdacht werden müssen: Mit den Werkzeugen von Cloudflare sind unsere Kunden dem Geschehen immer einen Schritt voraus.
Wir hoffen, dass unsere Ankündigungen für Sie von Interesse waren. Sollten Sie befürchten, etwas verpasst zu haben, finden Sie hier noch einmal ein Überblick über alles, was wir während der Birthday Week eingeführt haben:
Montag
生日周回顾：我们宣布的所有内容，以及为初创企业提供的 AI 驱动机会
今年，Cloudflare 正式成为踏入青春阶段，迎来了 13 岁生日。为了庆祝这个里程碑，我们发布了一系列公告，我们的客户和互联网社区都会从中受益。
从在人工智能时代开发应用，到防御尚未出现的最先进攻击，Cloudflare 很高兴能提供帮助我们的客户保持领先一步的工具。
我们希望您跟随我们度过了一段美好的时光，如果想要回顾我们本周发布的所有内容，请查看下文：