Route 53 名称的由来与 DNS 冷知识 - 为什么是 53，为什么用 UDP
从 Route 53 的名称源自端口号 53 和美国国道 Route 66 的典故出发，解析 DNS 为何使用 UDP 端口 53，以及 DNS 解析背后究竟发生了什么。
Route 53 名称中隐藏的双重含义
Amazon Route 53 中的「53」源自 DNS 使用的 TCP/UDP 端口号 53。DNS 的请求和响应默认使用 UDP 端口 53。「Route」部分既表示 DNS 将域名「路由」到 IP 地址的功能，同时也是对美国著名国道「Route 66」的致敬。Route 66 是连接芝加哥和洛杉矶的历史性干线公路，被称为「美国的大动脉」。Route 53 同样寓意着将互联网流量引导到正确目的地的「互联网大动脉」。AWS 的服务名称中有不少这样兼具技术含义和文化含义的双重结构。顺便一提，真实存在的 US Route 53 是威斯康星州的一条短途州道，知名度远不及 Route 66。
DNS 为什么使用 UDP 端口 53
DNS 使用 UDP 的原因要追溯到 1983 年 DNS 设计之初的网络环境。当时的互联网带宽极为有限，TCP 三次握手 (SYN → SYN-ACK → ACK) 建立连接的开销是不可忽视的成本。DNS 的查询和响应通常在 512 字节以下，一次往返即可完成。TCP 建立连接需要 3 个数据包、数据收发需要 2 个数据包、断开连接需要 4 个数据包，共计 9 个数据包；而 UDP 只需 2 个数据包 (查询 + 响应) 即可完成。端口号 53 的分配经过与 IANA (Internet Assigned Numbers Authority) 的端口号分配历史有关。1983 年 DNS 通过 RFC 882 和 RFC 883 标准化时，当时尚未使用的端口号 53 被分配给了 DNS。端口号 1~1023 被称为「知名端口」，保留给主要协议使用。正如 HTTP 使用 80、HTTPS 使用 443、SSH 使用 22 一样，DNS 使用 53。不过，当 DNS 响应超过 512 字节时 (如 DNSSEC 的响应)，会回退到 TCP。
从在浏览器输入 URL 到页面显示之间发生了什么
从在浏览器中输入 example.com 到页面显示的过程中，DNS 解析经历了多个阶段。首先，浏览器检查自身的 DNS 缓存。如果缓存中没有，则检查操作系统的 DNS 缓存 (macOS 为 mDNSResponder，Linux 为 systemd-resolved)。如果操作系统缓存中也没有，则向配置的 DNS 解析器 (通常是 ISP 的 DNS 服务器或 8.8.8.8 等公共 DNS) 发送查询。DNS 解析器检查自身缓存，如果没有则开始递归名称解析。首先向根 DNS 服务器 (全球 13 个集群) 查询「.com 的权威 DNS 服务器在哪里」。然后向 .com 的权威 DNS 服务器查询「example.com 的权威 DNS 服务器在哪里」。最后向 example.com 的权威 DNS 服务器 (Route 53 的情况下为 ns-xxx.awsdns-xx.com) 查询「example.com 的 IP 地址是什么」。这三个阶段的查询就是缓存为空时 DNS 解析的全貌。每个阶段的响应都设置了 TTL (Time to Live)，在 TTL 期间内缓存有效。
Route 53 的别名记录 - AWS 独创的发明
Route 53 的别名记录 (Alias Record) 是 DNS 标准规范中不存在的 AWS 独有功能。在标准 DNS 中，不能在域名顶点 (Zone Apex，例如 example.com) 设置 CNAME 记录。这是因为 RFC 1034 规定 Zone Apex 不得让 CNAME 与其他记录类型共存。然而，CloudFront 分配和 ELB 的端点以动态 DNS 名称 (如 d1234.cloudfront.net) 提供，要从 Zone Apex 指向这些服务就需要 CNAME。Route 53 的别名记录正是为解决这个问题而发明的。别名记录在 Route 53 内部解析 DNS 查询，最终以 A 记录的形式返回 IP 地址。从客户端角度看，与普通 A 记录无法区分。别名记录的另一个优势是，从 Route 53 到 AWS 资源 (CloudFront、ELB、S3 网站托管等) 的别名查询是免费的。普通 DNS 查询每 100 万次收费 0.40 USD，而别名查询不收费。Azure DNS 和 Google Cloud DNS 没有与别名记录等效的功能，各家以不同方式处理 Zone Apex 的 CNAME 问题。
DNS 故障为何会波及整个互联网
DNS 是互联网最基础的基础设施，DNS 停止运行时几乎所有互联网服务都将无法使用。2016 年针对 Dyn DNS 的大规模 DDoS 攻击导致 Twitter、Netflix、GitHub、Spotify 等众多服务数小时无法访问。这些服务本身运行正常，但由于 DNS 无法响应，用户无法解析服务的 IP 地址。Route 53 针对此类故障采取了多项对策。第一，Route 53 的权威 DNS 服务器运行在全球分布式 Anycast 网络上，针对特定节点的攻击不易波及整体。第二，Route 53 是少数提供 100% 可用性 SLA 的 AWS 服务之一。该 SLA 保证对 DNS 查询返回正确响应。第三，通过 Route 53 的健康检查功能，当后端服务器发生故障时，可自动将流量切换到正常服务器，实现 DNS 故障转移。要系统学习 DNS 机制和网络设计，可参考相关专业书籍 (Amazon)。