Route 53 Resolver DNS Firewall 的 chain 處理

在「Stop the CNAME chain struggle: Simplified management with Route 53 Resolver DNS Firewall」這邊看到的新功能。

說實話... 我早就忘記 Route 53 Resolver DNS Firewall 這個產品了,我查資料才發現我在 2021 年的時候寫過:「AWS 推出 Amazon Route 53 Resolver DNS Firewall」。

這個產品的用途是避免透過 DNS 將敏感資訊打出去,不過先前的產品的條件很死,遇到 CNAME 或是 DNAME 的情況,你必須事先把可能後續的 record 也放進白名單才行,所以如果遇到類似於 X (Twitter) 用的 pbs.twimg.com 的情況就很麻煩了:

;; ANSWER SECTION:
pbs.twimg.com.          300     IN      CNAME   cs196.wac.edgecastcdn.net.
cs196.wac.edgecastcdn.net. 3409 IN      CNAME   cs2-wac.apr-8315.edgecastdns.net.
cs2-wac.apr-8315.edgecastdns.net. 110 IN CNAME  cs2-wac-us.8315.ecdns.net.
cs2-wac-us.8315.ecdns.net. 110  IN      CNAME   cs45.wac.edgecastcdn.net.
cs45.wac.edgecastcdn.net. 725   IN      A       117.18.237.70

理想上是你放行 pbs.twimg.com 就好,但因為 CNAME 的關係,你可能會需要多放行 *.edgecastcdn.net 以及 *.ecdns.net

可是這是第三方的服務,你無法控制對方怎麼切換 (沒有 API contract 的概念),像是有時候他會跳到 Fastly

;; ANSWER SECTION:
pbs.twimg.com.          290     IN      CNAME   dualstack.twimg.twitter.map.fastly.net.
dualstack.twimg.twitter.map.fastly.net. 290 IN A 151.101.40.159

如果之後又跑出 Akamai 或是 CloudFront 的話就沒完沒了。

另外一種常見的情況是第三方的 API endpoint,對方有可能有多個不同的點做 DR 切換,有可能 CNAME 到 AWSELB 或是 GCPCloud Load balancing 上。

所以為了「保險」,這個方式通常都是開整個 CDN 的服務,但這麼一來攻擊者可以透過租用這些服務 (像是 *.cloudfront.net),搭配一些其他比較鬆的 rule 鑽出來。

這次的這個功能有點 stateful firewall 的概念,第一個啟動的 record 是被放行的,那 CNAME 或是 DNAME 延伸出來的 record 也跟著放行,這樣算是補強了這個問題...

Common Media Client Data (CMCD)

Amazon CloudFront 的公告看到的東西:「Amazon CloudFront now supports Common Media Client Data (CMCD) fields in real-time logs」。

CMCD (Common Media Client Data) 是一個私有的 log format,可以讓 client 透過 HTTP(S) header 回報狀態,所以 AWS 這邊有提到你可以設定讓 CloudFront 記錄下來,然後透過其他軟體分析:

Previously, CloudFront logged CMCD parameters as part of the full query string log field, or the HTTP headers log field. Now, you can simply select to include specific CMCD parameters in your real-time logs and save on compute needed to search and extract the CMCD key-value pairs, and reduce the data set for your log analysis.

現在 CloudFront 則是支援判讀做一些處理:

Starting today, you can enable Common Media Client Data (CMCD) fields in your CloudFront real-time logs. You can select key client-side performance parameters and CloudFront delivery performance parameters in the same log record. This can help you correlate variations in Quality of Experience (QoE) for your viewers to CloudFront performance at the granularity of single viewer sessions, simplifying the troubleshooting of QoE issues that impact your viewers engagement.

看了一下就是定義一些欄位,用 JSON 包起來後讓 client 打回伺服器端,可以利用這些資訊動態從伺服器端調整策略,而不像以前主要的調整策略都放在 client 端。

CloudFront 端出 Embedded Points of Presence

看到 CloudFront 的產品新聞稿:「Amazon CloudFront announces availability of Embedded Points of Presence」,AWS 在 CloudFront 上端出了 Embedded Points of Presence 服務,看名字就是更彈性的 CDN PoP,不過想知道更細節的東西得去看 FAQs 的部分...

從這段可以看到應該是 AWS 的 appliance,然後放到實體機房裡面提供服務:

These embedded POPs are owned and operated by Amazon and deployed in the last mile of the ISP/MNO networks to avoid capacity bottlenecks in congested networks that connect end viewers to content sources, improving performance.

比較特別的消息是,這個不會額外收費:

Q. Is there a separate charge for using embedded POPs?
No, there is no additional charge for using CloudFront embedded POPs.

另外這個服務會是 opt-in 選擇加入,但不需要額外設定 distribution,而且 CloudFront 會針對有 opt-in 的 distribution 自動混搭:

Embedded POPs are an opt-in capability intended for the delivery of large scale cacheable traffic. Please contact your AWS sales representative to evaluate if embedded POPs are suitable for your workloads.

No, you do not need to create a new distribution specifically for embedded POPs. If your workload is eligible, CloudFront will enable embedded POPs for your existing distribution upon request.

You don't have to choose between CloudFront embedded POPs or CloudFront POPs for content delivery. Once your CloudFront distribution is enabled for embedded POPs, CloudFront's routing system dynamically utilizes both CloudFront POPs and embedded POPs to deliver content, ensuring optimal performance for end users.

下一章「Compliance」的部分有提到 embedded POPs 是不包括在 PCI DSSHIPAA 以及 SOC 這些 compliance 的,所以也可以回頭看到在提到推薦掛上來的內容,有避開掉敏感服務,主要是以大家都會看到一樣的內容的東西為主:

Embedded POPs are custom built to deliver large scale live-streaming events, video-on-demand (VOD), and game downloads.

看起來有點像是 NetflixOpen Connect 或是 GoogleGGC,讓 ISP 或是 MNO 可以放 cache service 降低對外消耗的流量。

這應該會回到老問題,ISP/MNO 當然是希望 CloudFront 花錢放機器進來,不會是 ISP/MNO 自己申請放,這不是技術問題而是商業問題...

雲端的流量費用

在「Cloud Egress Costs (getdeploying.com)」這邊看到的文章,原文在「Cloud Egress Costs」這邊,主要是整理了表格出來可以快速了解不同雲端的流量費用差異,裡面不是單純 VPS 比較,而是各類的服務都拿出來比,像是 storage 類的以及 CDN 類的都有放進來...

Backblaze 的頻寬費用算法頗有趣,每個月給資料量的三倍大小當作免費頻寬,沒記錯的話因為 Cloudflare 是 Backblaze 的 partner,兩邊的傳輸費用不計費,如果資料是可以公開的,可以透過這個方式接出來;如果真的得走一般的流量輸出,收費是 US$0.01/GB (所以換算後是 US$10/TB)。

三家常被擺在一起的 VPS (LinodeDigitalOceanVultr) 的頻寬也都是 US$10/TB。

以前沒注意到的是 OVH CloudScaleway 的頻寬費用居然是免費的?另外 Hetzner 雖然要收費但也很低?有機會好像該玩看看,看一下品質如何?

Vultr 推出了自己的 CDN

Vultr 推出了自己的 CDN:「Vultr CDN: Revolutionizing Content Delivery with Global Reach and Unbeatable Price-to-Performance」。

畢竟手上也有很多機房了,這算是弄個加值服務賣... 不過對於量小的人就不太划算了,有基本開銷 US$10/mo (看起來不可抵使用的量),然後再加上頻寬費:

亞洲區的點主要還是比較傳統的點... 其中日本的東京與大阪以及新加坡都是 US$0.03/GB,韓國的首爾則是 US$0.05/GB;歐美看起來是 US$0.01/GB。

目前還在 beta,可以觀望看看...

CloudFront 支援 4096-bit RSA 的 SSL/TLS certificate 了

CloudFront 總算支援 4096-bit 的 RSA SSL/TLS certificate 了:「Amazon CloudFront now supports 4096-bit RSA TLS certificates」。

翻了一下 AWS ACM,看起來是 2020 年以前就支援 4096-bit RSA SSL/TLS certificate 了,CloudFront 晚蠻多的...

另外查了一下目前的強度,NSA 給出 2048-bit RSA 對到 112-bit strength,而 3072-bit RSA 對到 128-bit strength;至於 4096-bit RSA,目前是估算大約在 140-bit strength,有點微妙的數字。

看起來主要應該是給 compliance 需求使用的,有些舊的 library 未必支援 ECC 類的演算法,還是得透過拉高 RSA key size 來增加安全性。

arXiv 上了 Fastly CDN

看到 arXiv 宣佈上了 FastlyCDN:「Faster arXiv with Fastly」。

翻了一下 arxiv.org 的 DNS record,可以看到現在是這樣:

;; ANSWER SECTION:
arxiv.org.              10      IN      A       151.101.131.42
arxiv.org.              10      IN      A       151.101.3.42
arxiv.org.              10      IN      A       151.101.67.42
arxiv.org.              10      IN      A       151.101.195.42

mtr 測試,看起來 HiNet 過去的 routing 還是進到新加坡。

不過 static.arxiv.org 是在 CloudFront 上:

;; ANSWER SECTION:
static.arxiv.org.       3600    IN      CNAME   daa2ks08y5ls.cloudfront.net.
daa2ks08y5ls.cloudfront.net. 60 IN      A       13.35.35.100
daa2ks08y5ls.cloudfront.net. 60 IN      A       13.35.35.29
daa2ks08y5ls.cloudfront.net. 60 IN      A       13.35.35.88
daa2ks08y5ls.cloudfront.net. 60 IN      A       13.35.35.127

依照官方的說明看起來還在換,只是不知道已經在 CloudFront 上的 (像是上面提到的 static.arxiv.org) 會不會換過去:

That includes our home page, listings, abstracts, and papers — both PDF and HTML (more on that soon).

Cloudflare 前幾天 API 與 Dashboard 出事的 Post Mortem 記錄

前幾天 Cloudflare 的 API 與 dashboard 掛了一天多,少見的讓 Matthew Prince (CEO) 自己出來發 post mortem 記錄了:「Post Mortem on Cloudflare Control Plane and Analytics Outage」,在 Hacker News 上面也有蠻多討論的:「Post Mortem on Cloudflare Control Plane and Analytics Outage (cloudflare.com)」,這邊是整理我自己讀完後的感想。

從「Matthew Prince - The Cloudflare Blog」這邊可以看出來 Matthew Prince 上次是 2023/09/27 的公關文「Cloudflare’s 2023 Annual Founders’ Letter」,還有對應的多國翻譯,像是繁體中文的「Cloudflare 2023 年度創始人來信」,再往前的 2022/12/11 也是公關文「Welcome to Cloudflare’s Impact Week」(以及對應的繁體中文版本:「歡迎來到 Cloudflare 的 Impact Week」)。

這次的事情算是 Cloudflare 在 post-IPO 後很少見的長時間出事,就難得看到 Matthew Prince 自己出來坦了。為了重新建立信任,加上因為層級的關係,可以看到透漏出很多架構細節,算是這次可以窺視 Cloudflare 架構的一些資訊。

先大概提一下官方文章的著墨點:他們花了非常多的篇幅在機房服務商 Flexential 在處理 PDX-04 (這是 Cloudflare 訂的名稱) 機房電力問題的失職 (要注意這邊是 Cloudflare 的觀點,認為 Flexential 的失職,目前沒有從 Flexential 這邊的消息出來解釋),淡化掉了 Cloudflare 自己的設計問題,這邊在 Hacker News 上有蠻多人都有指出來的。

這次事件一切的起因是 Flexential 的 PDX-04 機房整個電力系統斷線 offline 導致的,屬於標準的 data center failure 的情況,像是 2013 年二月時是方機房的火災 (可以參考 iThome 的整理),或是 2021 年 OVH 的機房火災 (「去年 OVH 機房大火的部份情形最近被揭露」),是個在設計架構時一定會規劃進去的項目。

所以 Matthew Prince 先是解釋 Cloudflare 的 HA 作法,是直接在 Hillsboro, Oregon 租三個機房建立起 low-latency network:

Cloudflare's control plane and analytics systems run primarily on servers in three data centers around Hillsboro, Oregon. The three data centers are independent of one another, each have multiple utility power feeds, and each have multiple redundant and independent network connections.

但大家看到這計馬上就會去查,這個城市也才 66.9km2 的土地,大約是 1/4 個台北市 (約 291.8km2) 再小一些,拉了一下城市內的直線最遠距離,大約是 12km?

呃,這不是一個地震 (就在聖安地列斯斷層區域?) 或是一個核攻擊就把 Cloudflare 最核心的部分給擺平了嗎?

其中 analytics systems 就算了:整個 Hillsboro 掛了進入 gracefully degrading,我可以理解這個設計的考量,但 control plane 看起來不太妙?

雞蛋放在同一個籃子的問題裡先放著,雖然這個問題真的很...。

後續提到了有些重要的產品對沒有 HA 能力的服務上有相依性:

Unfortunately, we discovered that a subset of services that were supposed to be on the high availability cluster had dependencies on services exclusively running in PDX-04.

這邊沒有講是哪些服務的相依性,但文章其他地方有提到有些基礎服務是沒有跨機房 HA 架構的,只有在 PDX-04 有跑,包括了 KafkaClickHouse

In particular, two critical services that process logs and power our analytics — Kafka and ClickHouse — were only available in PDX-04 but had services that depended on them that were running in the high availability cluster.

這點讓人頗意外的,Kafka 因為自己架設 & 維護過,知道他的架構本身就很容易設計到跨機房的 case,而且這算是很基礎建設的東西,居然沒有跨機房 HA?

而 ClickHouse 只有研究過,沒有實際把 production 量丟上去跑,但從文件看到的東西,應該至少能做到 shared-everything 的架構,也居然沒有跨機房 HA?

這接基礎建設的問題,導致了雖然只是單一機房 PDX-04 掛掉,但在有重要基礎建設消失的情況下 (應該就是上面提到的 Kafka 與 ClickHouse),加上 Flexential 沒有給出恢復的時間,決定直接跑災難重建的 SOP (也就是 Hillsboro 的三個機房都回不來的情境)。

而這也可以看到恢復時間比較久,從決定切到歐洲的 DR site 到整個切過去花了四個多小時:

Because more services were offline than we expected, and because Flexential could not give us a time for restoration of our services, we made the call at 13:40 UTC to fail over to Cloudflare's disaster recovery sites located in Europe.

By 17:57 UTC, the services that had been successfully moved to the disaster recovery site were stable and most customers were no longer directly impacted.

因為 Kafka 與 ClickHouse 在 Hillsboro 只有單一機房有服務,那就不確定歐洲 DR site 平常有沒有建起來,也許這邊的四個多小時有不少是在歐洲 DR site 把 Kafka 與 ClickHouse 建起來?(這個就只能猜測了)

回到 Flexential 這邊,在恢復供電的過程發現 Cloudflare 這邊迴路用的 breaker 掛了,直到十個小時後才供電,但也因為大家都忙了一整天,Matthew Prince 決定讓大家先回去休息,隔天早上再從歐洲的 DR site 切回 Hillsboro,也因此拉長了恢復的時間:

At 12:48 UTC, Flexential was able to get the generators restarted. [...] When Flexential attempted to power back up Cloudflare's circuits, the circuit breakers were discovered to be faulty.

Flexential replaced our failed circuit breakers, restored both utility feeds, and confirmed clean power at 22:48 UTC. Our team was all-hands-on-deck and had worked all day on the emergency, so I made the call that most of us should get some rest and start the move back to PDX-04 in the morning. That decision delayed our full recovery, but I believe made it less likely that we’d compound this situation with additional mistakes.

要注意報告慣例是用 UTC 時間 (這又是另外一個主題了,先前 HN 上也有其他文章討論過...),而 Hillsboro 在美西,要減八個小時,所以 22:48 UTC 是下午兩點多左右,美東與歐洲的團隊時間則會更晚。

目前看起來 Cloudflare 的設計與流程有很大的改善空間?之後看看有沒有其他的八卦消息出來?

Cloudflare 正式推出 ECH (Encrypted Client Hello)

Cloudflare 宣佈所有的 Plan 都支援 ECH 了:「Encrypted Client Hello - the last puzzle piece to privacy」。

要講 ECH 之前,會先提到 Domain fronting 這個避開網路審查 (censorship) 的技巧,這是利用 CDN 服務裡對 SNI 的處理與對 HTTP header 的處理分開的特性,算是一種 side effect 的搞法,不保證會動,但蠻多 CDN 的服務都會動。

實際上的作法就是在 SNI 層的 hostname 填寫一個沒有被審查的 Hostname (像是 www.akamai.com),然後連到 www.akamai.com:443 上,也都使用 www.akamai.com 的 SSL certificate 交換。

但在 HTTP header 上面則是送出不一樣的 hostname (但也必須是在這家 CDN 的機器上有提供服務的網域),通常是被管制的網域名稱,像是 Host: www.cnbc.com 這樣的 HTTP header;而因為這部份被 TLS 保護,無法從外部看到內容而可以穿過網路審查。

理論上 CDN 服務是可以 reject 這樣的連線的,但大多數的 CDN 廠商並沒有阻擋這麼嚴格,於是算是一種堪用的方式。而這次 ECH 算是把這個行為標準化了,就不需要再用 side effect 的方式了。

Cloudflare 本身就很大,可以來看看後續的效應...