anycast

AS112 計畫

在「Cloudflare is joining the AS112 project to help the Internet deal with misdirected DNS queries」這邊看到的東西：「AS112 Project」，在維基百科上面也有條目：「Blackhole server」。

Cloudflare 宣佈 2022/12/15 參與 AS112 Project：

We are going to announce the AS112 prefixes starting December 15, 2022.

針對 private network 的反解 (像是 192.168.x.x 這些網段)，目前的 NS RR 會丟到 IANA 的 blackhole server 上：

;; AUTHORITY SECTION:
10.in-addr.arpa.        86400   IN      NS      blackhole-1.iana.org.
10.in-addr.arpa.        86400   IN      NS      blackhole-2.iana.org.

這兩的 domain name 分別是 192.175.48.6 與 192.175.48.42。

而 IANA 的 blackhole server 的負荷愈來愈重，所以就有了透過 anycast 打散負荷的想法，也因為在發 anycast 時的 ASN 是 112，後來也就變成了 AS112 計畫，在 RFC 7534 裡面解釋了要怎麼做：「AS112 Nameserver Operations」。

另外在 AS112 Project 的網站上也有提到 anycast 的範圍：

The address blocks are 192.175.48.0/24 and 2620:4f:8000::/48 and its origin AS is 112.

昨天 HiNet 線路連到 AS112 的 192.175.48.x 網段會丟到日本的 WIDE，剛剛看發現已經是 Cloudflare 在台灣的點了：

;; ANSWER SECTION:
hostname.as112.arpa.    604800  IN      TXT     "Cloudflare DNS, TPE"
hostname.as112.arpa.    604800  IN      TXT     "See http://www.as112.net/ for more information."

但如果是用 Google Public DNS 查詢的話則是會到 STUIX，先前也有在其他地方看到這個有趣的組織：

;; ANSWER SECTION:
hostname.as112.arpa.    300     IN      TXT     "Taiwan Digital Streaming Co. with STUIX"
hostname.as112.arpa.    300     IN      TXT     "Taipei, TW"
hostname.as112.arpa.    300     IN      TXT     "Unicast IP: 103.147.22.82"
hostname.as112.arpa.    300     IN      TXT     "See http://as112.net/ for more information."

回過頭來看這次 Cloudflare 的加入，他們手上的機房與點都很多，這次跳進去看起來會分擔掉不少其他節點的 loading。

但另外隱憂 privacy 的考量，他們手上等於是可以看到一堆 invalid DNS query log...

AWS Global Accelerator 支援 IPv6

AWS 的 Anycast 服務 AWS Global Accelerator 宣佈支援 IPv6：「New for AWS Global Accelerator – Internet Protocol Version 6 (IPv6) Support」。

算是補功能，不過這個功能只對於「純 IPv6 環境」的使用者端有用 (沒有 DNS64 + NAT64 的轉換)，目前商轉給一般使用者用的 IPv6 環境應該都還是有掛 DNS64 + NAT64 才對...

另外使用這個功能會需要 VPC 有 IPv6 能力：

To test this new feature, I need a dual-stack application with an ALB entry point. The application must be deployed in Amazon Virtual Private Cloud (Amazon VPC) and support IPv6 traffic.

然後 IPv4 會進到 IPv4 的服務裡，IPv6 則會進到 IPv6 的服務裡：

Protocol translation is not supported, neither IPv4 to IPv6 nor IPv6 to IPv4. For example, Global Accelerator will not allow me to configure a dual-stack accelerator with an IPv4-only ALB endpoint. Also, for IPv6 ALB endpoints, client IP preservation must be enabled.

短時間還用不太到，但之後應該有機會...

Cloudflare 推出了 BYOIP 的服務

Cloudflare 推出了 BYOIP 的服務，用客戶的 IP address 放 routing 出去：「Bringing Your Own IPs to Cloudflare (BYOIP)」。

照敘述上看起來應該是 anycast，不過這邊沒明講：

When you BYOIP with Cloudflare, this means we announce your IP space in over 200 cities around the world and tie your IP prefix to the service (or services!) of your choosing.

裡面沒有提到 IPv4 或是 IPv6，在 https://developers.cloudflare.com/byoip/ 這邊看起來也沒提到，以 Cloudflare 的技術架構，應該是都支援？

用自己的 IP 的好處，一個明顯的方向就是 firewall 會好設不少，另外如果需要服務中國或是其他管制地區，比較不會因為 IP space 混用誤殺受到影響？

Google Hangouts 將會使用固定 IP 位置

Google 宣佈 Hangouts 將會使用固定 IP 位置，讓系統管理員更方便管理：「Dedicated Hangouts Meet IP addresses」。

We’re adding a range of official, fixed IP addresses to be used exclusively for classic Hangouts and Hangouts Meet in G Suite domains.

目前看到的資訊是：

IPv4: 74.125.250.0/24
IPv6: 2001:4860:4864:5::0/64

然後文章裡的說明是二月 14 日會變更：

Hangouts Meet and classic Hangouts will stop using the old IP address on February 14, 2019.

管理者可以調整關於這段 IP 的流量，通常是調高優先權？不過要調低也是可以...

AWS 推出 Global Accelerator，用 AWS 的網路加速

AWS 推出了 Global Accelerator，利用 AWS 的網路加速：「New – AWS Global Accelerator for Availability and Performance」。

這個產品有點像是 GCP 的 Premium Network 的概念，從名稱叫做 Data Transfer-Premium (DT-Premium) 也可以看出來這點。另外 Cloudflare 也有類似的產品，叫做 Spectrum。

使用者的連線會先進入最接近使用者的 AWS Edge，然後走 AWS 自己的網路到真正服務所在的 AWS 區域：

AWS 自家的 CloudFront 可以做類似的事情，但是 CloudFront 是 DNS-based service，而且只吃 HTTP 類的連線；這次推出的 Global Accelerator 則是 Anycast-based service，同時支援 TCP 與 UDP。

目前的 edge 只有北美、歐洲與亞洲：

AWS Global Accelerator is available in US East (N. Virginia), US East (Ohio), US West (Oregon), US West (N. California), Europe (Ireland), Europe (Frankfurt), Asia Pacific (Tokyo) and Asia Pacific (Singapore).

這類服務通常也都可以擋下一些 DDoS 攻擊，畢竟是拿大水管在擋...

Cloudflare 推出 1.1.1.1 的 DNS Resolver 服務

Cloudflare 推出了 1.1.1.1 上的 DNS Resolver 服務：「Announcing 1.1.1.1: the fastest, privacy-first consumer DNS service」，主打項目是隱私以及效能。

然後因為這個 IP 的特殊性，上面有不少奇怪的流量... 而 Cloudflare 跟 APNIC 交換條件後取得這個 IP address 的使用權 (然後 anycast 發出去)：

APNIC's research group held the IP addresses 1.1.1.1 and 1.0.0.1. While the addresses were valid, so many people had entered them into various random systems that they were continuously overwhelmed by a flood of garbage traffic. APNIC wanted to study this garbage traffic but any time they'd tried to announce the IPs, the flood would overwhelm any conventional network.

We talked to the APNIC team about how we wanted to create a privacy-first, extremely fast DNS system. They thought it was a laudable goal. We offered Cloudflare's network to receive and study the garbage traffic in exchange for being able to offer a DNS resolver on the memorable IPs. And, with that, 1.1.1.1 was born.

Cloudflare 做了效能比較表 (與 Google Public DNS 及 OpenDNS 比較)，可以看到平均速度快不少：

在台灣的話，HiNet 非固定制 (也就是 PPPoE 連線的使用者) 連到 8.8.8.8 有奇怪的 latency：

可以比較同一台機器對 168.95.1.1 的反應速度：

不過如果你是 HiNet 固定制 (固 2 或是固 6 IP 那種，不透過 PPPoE，直接設定 IP address 使用 bridge mode 連線的使用者)，兩者的 latency 就差不多，不知道是 Google 還是 HiNet 的架構造成的。

~~另外比較奇怪的一點是在文章最後面提到的 https://1.1.1.1/，理論上不會發 IP-based 的 SSL certificate 才對？不知道 CEO 老大是有什麼誤解... XD~~

Visit https://1.1.1.1/ from any device to get started with the Internet's fastest, privacy-first DNS service.

Update：查了資料發現是可以發的，只是大多數的 CA 沒有提供而已...

中華的 DNS 架構

在 Twitter 上看到「HiNet DNS系統設備維護作業」這則維護公告，裡面提到了會對 HiNet DNS 系統維護，但範圍是雲林以南：

起訖日期：2017-10-19
時間： 14:00 ~ 16:00
範圍：雲林(含)以南
說明：親愛的HiNet客戶您好﹕ 為提昇網路服務品質，HiNet DNS系統將於106/10/19(星期四)下午2:00到4:00進行設備維護，期間DNS查詢服務將可能發生瞬斷情形，若影響上網服務造成您的不便，敬請見諒，並感謝您對HiNet的支持與愛護。祝您身體健康萬事如意中華電信數據通信分公司敬上客服專線：0800-080-412

這樣聽起來中華有在自己內部網路跑 anycast service 了？而且這樣應該表示有機會在 DNS 層拆出不同區域的用戶？

Google CDN 進入 Beta

最近 CDN 產業裡有不少蕭期，其中一個新聞是 Google CDN 進入 beta，Google 藉由在全球佈署的機房來服務。

不過雖然進入了 Beta，但仍然有很嚴重的技術限制，只能透過 GCE 當 origin server，這使得實用性低很多：

Origins
Delivers HTTP/HTTPS content originating from Compute Engine VM instances. External origin servers are not supported.

有些特點是跟一般 CDN 不同的，一個是 Google 對 HTTPS 的口號，所以 HTTP 與 HTTPS 的價錢相同。其實你就當做他把 HTTP 的費用收的跟 HTTPS 一樣就好：

SSL Shouldn't Cost Extra
The web is moving to HTTPS, and your cacheable content should, too. With Cloud CDN, you can secure your content using SSL/TLS for no additional charge.

另外一個特點是從技術上就宣稱完全使用 Anycast，而不是見到的 DNS + Anycast：

Anycast
Serve all your content from a single IP address with low latency worldwide.

另外，計價的方式與其他的 CDN 有不少地方不一樣，另外也有針對中國地區另外處理。

首先是他把 Cache Egress (從 CDN 給使用者) 與 Cache Fill (從 CDN 到 Origin 取得資源) 分開收，一的般 CDN 都只收 Cache Egress 這塊。

再來是中國大陸地區的價錢另外標示，有特地標明不是從中國大陸地區直接提供服務：

Traffic destined for mainland China is served from Google locations outside of mainland China. Performance and reliability may be lower than for traffic served from in-country locations.

言下之意就是另外買 optimized 的頻寬來服務，但還是不會像在中國大陸地區有機房的效果這麼好，不過好處是不需要 ICP 之類的證照。

不過不得不說價錢其實還蠻便宜的，無論是歐美還是亞洲區。

Google 的 Load balancer：Seesaw

前幾天因為流感而睡太多，來消化一些文章。

上個星期 Google 放出一套用 Go 寫的 Load balancer，叫 Seesaw：「Seesaw: scalable and robust load balancing」。

比較有趣的是 BGP 與 anycast VIP 的能力：

Seesaw v2 provides full support for anycast VIPs - that is, it will advertise an anycast VIP when it becomes available and will withdraw the anycast VIP if it becomes unavailable.

Google 這個規模玩的是不同 scale 的花樣...

LinkedIn 的工程師分析 TCP Anycast 技術的穩定性與效能

LinkedIn 的工程師測試了 TCP Anycast 技術的穩定性以及效能：「TCP over IP Anycast - Pipe dream or Reality?」。

由於 stateless 再加上一個封包就傳的完的情況下，Anycast 技術被用在 DNS 上已經很長一段時間了，目前大多數 CDN 業者也都有用 Anycast 技術加快 CDN 的回應速度。

但 TCP 因為 stateful，如果 router 上採用的方式有問題，那麼就會導致封包可能會送到不同節點，這會是個嚴重的問題。不過很早之前，幾乎所有的骨幹 router 都已經支援 flow-based load balancing policy：

Most routers now do a per-flow load balancing, meaning packets on a TCP connection are always sent over the same path, but even a small percentage of routers with per-packet load balancing can cause the website to be unreachable for users behind that router.

所以 LinkedIn 的人試著測試 TCP Anycast 技術的穩定性：

So, to validate the assumption that TCP over anycast in the modern internet is no longer a problem, we ran a few synthetic tests.

測試的方式是設定 web server，讓下載速度不快，然後設了好幾個點並且放出對應的 routing，用 Catchpoint 服務監控，如果不穩定的話，應該就會收到 RST 中斷連線：

We configured our U.S. PoPs to announce an anycast IP address and then configured multiple agents in Catchpoint, a synthetic monitoring service, to download an object from that IP address. Our web servers were configured to deliberately send the response back slowly, taking over a minute for the complete data transfer. If the internet was unstable for TCP over anycast, we would observe continuous or intermittent failures when downloading the object. We would also observe TCP RSTs at the PoPs.

而好消息是，測試起來相當穩定：

But even after running these tests for a week, we did not notice any substantial instability problems! This gave us confidence to proceed further.

所以也因此可以看到 CacheFly 與 CloudFlare 兩家採用 TCP Anycast 技術：

[S]ome popular CDNs have also started using anycast for HTTP traffic.

由於穩定性的部份沒問題，所以接下來就是討論效率。

Anycast 是基於 routing 而決定要怎麼走，目標是希望可以透過 routing 取得 latency 最低的點。但實務上會把成本考慮進去，有可能會走到比較遠的點。在測試中可以發現北美的部份 Anycast 表現的比 GeoIP 好，但離開北美就掉很多：

所以 LinkedIn 決定用「Regional Anycast」，先用 GeoIP 決定要丟到哪個洲，而每個洲共用一個 Anycast 位置，這個方法讓效能提昇不少，全球在分配時 sub-optimal 的比率從 31% 降到 10% (i.e. 沒有分配到最好的點的比率)：

上面主要是讀 LinkedIn 文章的心得，後面就是感想了。

TCP Anycast 用 CDN 上其實是相當吃虧的技術，由於 routing 的掌控權不再自己手上，有很多重要的手段是沒辦法做到的。

首先是當對外流量已經滿載時，不能切換到其他機房的機器，這邊講的「對外流量」不是 CDN 本身而已，而是中途任何的線路滿載都算，像是 HiNet 對 CloudFlare 香港機房的情況就很明顯。

另外在被 DDoS 時，由於沒辦法導流，在被攻擊時幾乎只剩下 clean pipe 類的解法，而同時間其他用戶會因為流量大量流入機房而一起被波及到。GeoIP 的方式彈性就大很多。

當然，還是有可以列出來的好處。主要是對於需要有固定 IP 應用來說 (像是 firewall 設定需求)，TCP Anycast 滿足了這點。

只能說不同市場有不同的產品線在供應啦，不同的情境下有不同的需求...