高中生 Nate Sales 在 2020 年 8 月利用隔离期，凭借已有 AS34553 与 /24、/48 前缀，从零构建可生产使用的 Anycast CDN，先实现 DNS 服务再扩展 HTTP 缓存。
初始 Anycast DNS 集群搭建
在三台位于不同物理位置的 Debian 虚拟机上分别运行 BIRD 处理 BGP 与 BIND 提供 DNS，使用同一 /24 与 /48 前缀进行 Anycast 宣告。几百行 Ansible 剧本完成部署，手动撤销某节点路由可观测路由器收敛与故障切换速度。
控制平面与自动化部署
随后引入 Flask API、MongoDB 与 BeanstalkD 消息队列，API 写入区域数据后通过队列触发 Python 进程，经 SCP 与 SSH 将新区域文件推送至各 Anycast 节点。原本节点自带 RPC 接口后改为 JSON 经 SSH 传输，简化控制器与节点交互，并加入用户认证向朋友开放个人域名托管。
引入 HTTP 缓存与 TLS 挑战
为突破仅提供 DNS 的限制，增加 HTTP 缓存服务。最大难点在于为 Anycast 节点统一管理 TLS 证书，需在多地节点同步证书颁发与续期，原文未给出具体解决方案细节。
该实验展示了从路由层到应用层的完整 Anycast CDN 构建路径，工程师可借鉴其最小化依赖、基于 SSH 的控制面设计，在自有 ASN 与地址块上快速验证 Anycast 可行性。
原文: APNIC Blog（2021-04-07）｜编译自 APNIC Blog，事实以原文为准。
来源：APNIC Blog