DNS 工作机制全面剖析与应用探究

谈到 DNS, 映入脑海的可能就是 IP 映射、负载均衡、域名劫持、就近接入这些概念，但是作为整个 Internet 使用最为广泛的基础设施之一，他的工作原理是怎样的、里面有哪些黑科技、就近接入如何实现，相信大多数人并不十分清楚，本文就来做一一介绍。此外，本文引用了很多 RFC, 官方或非官方文档，想要深入了解的同学可以细读文中的引用出处。

目录

DNS Basic

Hierarchy of DNS servers

DNS server 一共有 4 类：

• Root DNS servers. 根服务器，记录了顶级域名服务器(Top-level domain (TLD) servers)的 IP, 全球只有 13 个逻辑节点，也就是 13 个 IP（当然，实际物理接入点有几百个）。(Root name server - Wikipedia)
• Top-level domain (TLD) servers. 顶级域名服务器，如 .com, .net, .org, .edu, 记录了 Authoritative DNS servers 的 IP.
• Authoritative DNS servers. 权威域名服务器，由 ISP 提供或机构组织自己提供（如腾讯的 ns1.qq.com, ns2.qq.com, ns3.qq.com, ns4.qq.com），记录了目标域名的 IP(A record)或别名(CNAME record)或委托的其它 Authoritative DNS servers 的 IP(NS record)等。
• Recursive DNS servers. 与客户端直接打交道的 DNS server, 通常情况下，客户端的解析请求都由它响应，大多数情况下指 local DNS server, 除此以外，还有 public DNS server.

如下图（图1）：

Root DNS servers, Top-level domain (TLD) servers, Authoritative DNS servers 分别对应图中的第一、二、三层。
Recursive DNS servers 有点特殊，其作用有点类似于代理服务器，代理客户端去请求图中的 DNS server.

域名解析过程

主机 cis.poly.edu 需要解析主机 gaia.cs.umass.edu 的地址，主机 gaia.cs.umass.edu 的 authoritative DNS server 为 dns.umass.edu, 主机 cis.poly.edu 的 local DNS server 为 dns.poly.edu. 其中一种解析过程如下图（图2）所示：

1. 主机 cis.poly.edu 向 local DNS server dns.poly.edu 发送目的域名为 gaia.cs.umass.edu 请求
2. local DNS server dns.poly.edu 向 root DNS server 发送目的域名为 gaia.cs.umass.edu 请求
3. root DNS server 匹配到目的域名 gaia.cs.umass.edu 的后缀为 .edu, 于是返回 .edu 的 TLD DNS server 的 IP
4. local DNS server dns.poly.edu 向 .edu 的 TLD DNS server 发送目的域名为 gaia.cs.umass.edu 请求
5. .edu 的 TLD server 匹配到 gaia.cs.umass.edu 的后缀为 umass.edu, 查找数据库找到 umass.edu 对应的 authoritative DNS server 为 dns.umass.edu, 于是返回 dns.umass.edu 的 IP
6. local DNS server dns.poly.edu 向 dns.umass.edu 发送目的域名为 gaia.cs.umass.edu 请求
7. dns.umass.edu 从数据库找找到 gaia.cs.umass.edu 的 IP 将其返回
8. local DNS server dns.poly.edu 返回 gaia.cs.umass.edu 的 IP 给 cis.poly.edu

Note: 上述过程没有考虑 DNS cache 的情况。

迭代式查询与递归式查询

上例中 local DNS server 到其他 DNS server 的查询属于迭代式查询, 上例还有另外一种递归式查询方式，如下图（图3）所示：

在实际应用中，图 2 中的查询方式用的比较多，即客户端到 local DNS server 采用递归式查询，剩余部分采用迭代式查询。递归式查询容易使 DNS server 遭到攻击，大多数 DNS server(非 local DNS server 或 public DNS server) 会禁用递归式查询。(What risks are associated with recursive DNS queries?)

此外，DNS server 可以根据 local DNS server 的 IP 来查找 geo-location database, 从而返回地理位置最近的(geographically closest)的 IP (Geolocation Routing - Amazon Route 53), 由于递归式查询中与 authoritative DNS server 交互的是 TLD DNS server, 因此 authoritative DNS server 无法获取 local DNS server 的 IP(不支持 edns-client-subnet (ECS) 的情况下), 也就无法实现 geo-location DNS routing. 当然，如果每一级 DNS server 都支持 ECS, 递归式查询也可以实现 geo-location DNS routing, 但毕竟 ECS 只是 DNS 标准的一个扩展(Extension Mechanisms for DNS (EDNS0) option)，因此并不能保证整个链中每一个环节都支持。

DNS records

DNS 协议标准里定义了多种记录，这里只描述几个常用的，下面以 (Name, Value, Type) 举例：

• A record(address record). 记录了名字到 IP 地址的映射，如 (relay1.bar.foo.com, 145.37.93.126, A).
• CNAME record(canonical name record). 记录名字到别命的映射，如 (foo.com, relay1.bar.foo.com, CNAME).
• NS record(name server record). 记录了名字到委托的 DNS server 的 IP 地址，如 (foo.com, dns.foo.com, NS).

DNS caching

DNS server 保存的每一条记录中都包含了 TTL(Time To Live ) 字段，表示记录的缓存时间，在上例中，如果 local DNS server 保存了 gaia.cs.umass.edu 的记录，那 local DNS server 就可以直接返回 gaia.cs.umass.edu 的 IP 给 cis.poly.edu, 而不用再去查询其他 DNS server 了。对于 local DNS server 来说，它既可以缓存目标域名的记录，也可以缓存后端 TLD DNS server 及 authoritative DNS server 的记录，因此，即使 gaia.cs.umass.edu 的缓存过期，dns.poly.edu(local DNS server) 也可以不用访问 root DNS server 或 TLD DNS server, 这样可以减轻二者的压力。

TTL 值设置多少合适？

TTL 值在注册或修改域名时设置，那么设置多少合适呢？这个取决于项目需要，如果域名变动频繁（如扩容），那么可以设置短一点，如果不那么频繁，可以设置长一点，(Definitive Guide to DNS TTL Settings) 给出了一些典型的值：

What are typical TTL times for DNS records?

Time to Live values are always represented in seconds. Most DNS setup configuration services provide you a preset list of values to set your records to.

300 seconds = 5 minutes = “Very Short”
3600 seconds = 1 hour = “Short”
86400 seconds = 24 hours = “Long”
604800 seconds = 7 days = “Insanity”

需要注意的是，TTL 值也决定了下一次修改的等待时间，例如 TTL 设置为 86400, 则必须等待 24 小时之后修改才能生效。因此，通常可以先设置短一点（例如 300），验证没有问题之后再改为需要的值。(DNS basics - G Suite Administrator Help)

Advanced Topics

Anycast

13 个 root DNS server 如何服务全球？

由上文可以看出，在缓存失效的情况下，全球所有的 local DNS server 解析域名时都需要去请求 root DNS server, 仅有的 13 个 root DNS server 是如何承载这么大的请求量的。这是因为 root DNS server 用到了 Anycast 技术。每个 root DNS server 的 IP 并非只有一个物理接入点，通过 Andycast 技术，一个 IP 可以分布在多个地区。这不同于 LVS 等负载均衡技术中的 (VIP)Virtual IP, VIP 是一处接入，多出转发，而 Anycast 是多处接入。

Is it true that there are only 13 root servers?

No, not for a long time. The size of UDP data packets means that there’s only room to include the IP addresses of 13 root servers in a single packet. Originally that meant a limit of 13 root server machines, and it gives us the root server names A-M. But thanks to the anycasting technique, each root server address can be mirrored on multiple physical servers in multiple diverse locations. By early August 2014, there were 372 root servers spread across the globe.*You can check the up-to-date numbers and locations here: http://www.root-servers.org. - DNS root server FAQ

除 root DNS server 以外，Anycast 技术还用在 CDN(Content Delivery Network), public DNS 等领域。

Geolocation-aware DNS

DNS server 可以实现一套

如何获取来源 IP?

上问已经提到过，获取来源 IP 有两种途径，一种是迭代式查询中直接获取本次请求的来源 IP, 在上文的例子中 dns.umass.edu(authoritative DNS server) 通过步骤 6 的请求获取 dns.poly.edu(local DNS server) 的 IP. 这种方式的问题非常明显，如果 dns.poly.edu(local DNS server) 与实际客户端 cis.poly.edu 地理位置相距较远，那么该 IP 并不能反映实际客户端的真实地址。

因此就有了第二种机制 - edns-client-subnet (ECS).

ECS(EDNS Client Subnet)

这种机制的实现一言以蔽之就是：在每一级的请求中，都携带最初的来源 IP 信息。机制的缘起在 RFC7871 中描述如下：

Many Authoritative Nameservers today return different responses based on the perceived topological location of the user. These servers use the IP address of the incoming query to identify that location.

Since most queries come from Intermediate Recursive Resolvers, the source address is that of the Recursive Resolver rather than of the query originator.

Traditionally, and probably still in the majority of instances, Recursive Resolvers are reasonably close in the topological sense to the Stub Resolvers or Forwarding Resolvers that are the source of queries. For these resolvers, using their own IP address is sufficient for Authoritative Nameservers that tailor responses based upon location of the querier.

Increasingly, though, a class of Recursive Resolvers has arisen that handles query sources that are often not topologically close. The motivation for having such Centralized Resolvers varies but is usually because of some enhanced experience, such as greater cache security or applying policies regarding where users may connect. (Although political censorship usually comes to mind here, the same actions may be used by a parent when setting controls on where a minor may connect.) Similarly, many ISPs and other organizations use a Centralized Resolver infrastructure that can be distant from the clients the resolvers serve. These cases all lead to less than desirable responses from topology-sensitive Authoritative Nameservers.

This document defines an EDNS0 [RFC6891] option to convey network information that is relevant to the DNS message. It will carry sufficient network information about the originator for the Authoritative Nameserver to tailor responses. It will also provide for the Authoritative Nameserver to indicate the scope of network addresses for which the tailored answer is intended.

ECS Response Caching

在不支持 ECS 的情况下，recursive DNS server(e.g. local DNS server) 对每一条记录只需记录 (Name, Value, Type, TTL) 等固定信息。支持 ECS 之后，recursive DNS server 对同一 name 的不同客户端可能返回不同的地址，因此需要将客户端的子网信息也缓存下来。即：

• 根据请求源 IP 路由的方式：由于来源 IP 是 recursive DNS server(e.g. local DNS server) 的 IP, 因此，对于某一 recursive DNS server 来说，不管实际客户端 IP 来自哪里，recursive DNS server 对于某一 name 的缓存是固定的。（当然，不同的 local DNS server 或 public DNS server 对同一 name 的缓存可能不同，比如联通和电信的 local DNS server 对 www.qq.com 的缓存可能不同。）

• 根据客户端 subnet 路由的方式：由于不同的客户端可能来自不同的子网，如果 authoritative DNS server 对不同的客户端子网返回不同的 IP，那么，对于某一 recursive DNS server(e.g. local DNS server) 来说，只要请求它的客户端子网不同，对于某一 name 它也要返回不同的 IP. 因此，recursive DNS server 也要缓存客户端子网信息。关于匹配子网的规则可以参见 RFC7871.

Public DNS

出于商业目的，一些 ISP 提供的 local DNS server 会对用户的 DNS 解析请求进行劫持(DNS hijacking), 对不存在的记录直接返回自身服务器的地址来推送广告，更有甚者，对于存在的记录也进行无耻的劫持。因此，业界推出了 public DNS server 来代替 local DNS server.

需要注意的是，public DNS 并非进行域名托管的机构，它充当的角色是 recursive DNS server, 与 local DNS server 角色相同，而非 authoritative DNS server.

Google Public DNS

最典型的 public DNS 是 “Google Public DNS” - 8.8.8.8, 8.8.4.4, 具官方文档介绍 2014 年 Google Public DNS 的日解析量就已经有 4000 亿次了。

Google Public DNS operates recursive name servers for public use at the two following IP addresses: 8.8.8.8 and 8.8.4.4 for IPv4 service, as well as 2001:4860:4860::8888 and 2001:4860:4860::8844, for IPv6 access. The addresses are mapped to the nearest operational server by anycast routing. - Google Public DNS - Wikipedia

Anycast 与 ECS 在 Public DNS 上的应用

Public DNS 同 root DNS server 一样，也会面临一个问题：单个 IP 如何服务全球用户？答案是 Andcast.
用 public DNS 取代 local DNS server 之后，会面临另一个问题：如何实现 geo-location routing? 因为客户端与 public DNS 不在同一地区的可能性比 local DNS server 大的多。为了解决这一问题，大多数 public DNS 都会实现 ECS.

Google Public DNS 关于 Anycast 和 ECS 的描述如下：

Anycast routing directs your queries to the closest Google Public DNS server. For more information on anycast routing.

Google Public DNS uses Name Server (NS) records published in the DNS root zone and zones of top-level domains to find the names and addresses of the DNS servers that are authoritative for any domain. Some of those name servers also use anycast routing. - How does Google Public DNS know where to send my queries?

Google Public DNS servers are available worldwide. There are two answers to this question, one for clients and another for the DNS servers from which Google Public DNS gets the answers it returns to clients.

When clients send queries to Google Public DNS, they are routed to the nearest location advertising the anycast address used (8.8.8.8, 8.8.4.4, or one of the IPv6 addresses in 2001:4860:4860::). The specific locations advertising these anycast addresses change due to network conditions and traffic load, and include nearly all of the Core data centers and Edge Points of Presence (PoPs) in the Google Edge Network.

Google Public DNS sends queries to authoritative servers from Core data centers and Google Cloud region locations. Google publishes a list of the IP address ranges Google Public DNS may use to query authoritative DNS servers (not all the ranges in the list are used). You can use it for geo-location of DNS queries lacking EDNS Client Subnet (ECS) data, and to configure ACLs to allow higher query rates from Google Public DNS. - Where are your servers currently located?

DNS is often used by Content Distribution Networks (CDNs) such as Akamai to achieve location-based load balancing by constructing responses based on clients’ IP addresses. However, CDNs usually see the DNS resolvers’ IP address instead of the actual clients’ and are therefore forced to assume that the resolvers are close to the clients. Unfortunately, the assumption is not always true. Many resolvers, especially those open to the Internet at large, are not deployed at every single local network.

To solve this issue, a group of DNS and content providers, including Google, proposed an approach to allow resolvers to forward the client’s subnet to CDN nameservers in an extension field in the DNS request. The subnet is a portion of the client’s IP address, truncated to preserve privacy. - Google Public DNS and Location-Sensitive DNS Responses

Wildcard DNS Record(泛域名)

Wildcard DNS Record, 泛域名。即注册 .example.com 之后，满足规则 .example.com 的域名(e.g. a.example.com, b.example.com, a.b.example.com) 在不注册的情况下都能返回 *.example.com 对应的记录值。由于新注册的域名生效需要一段时间，而且时间不可把控，因此泛域名具有很强的灵活性。

应用实践 - IP or Domain

先来分析一下 DNS 的利弊。DNS 的弊端非常明显，笔者总结了一下几方面原因：

• DNS server 容易遭到攻击，如 DNS cache poisoning, DNS hijacking, DDoS attack
• ISP local DNS server 劫持
• 域名注册或变更生效时间不可控
• 从整个 DNS 解析流程上看，假设我们充分信任 root DNS server 及 TLD DNS server, 而 authoritative DNS server 由我们自己管理。用户的访问必须经过 local DNS server 之后才能到达我们的服务，而 local DNS server 位于用户侧，我们把控不了。而且使用域名使整个流程增加了一环，不可靠的风险随之增加。

尽管缺点很多，但是 DNS 的优势也是巨大的，笔者总结如下：

• failover. 很多时候通过域名来实现容灾，效果是非常好的，虽然一些场合 IP 层面的负载均衡技术可以取代域名，但并非所有环境都有这样的基础设施，比如 AWS 就没有。
• load balancing. 通过 DNS 轮询来实现负载均衡是常用手段，这里也就不多讲了。
• 业务区分。通过域名区分业务也是常用手段，因为域名的注册管理比 IP 要灵活的多，而且对人类更友好，比如 Amazon S3.
• 就近接入 - Geo-location routing. 这点 CDN 发挥这项功能可谓淋漓尽致。

通常来说，域名劫持或攻击毕竟是少数，如果对可靠性要求不是那么苛刻，使用域名不失为一个不错的选择。此外，如果条件允许，可以采用 domain + IP 方式来提高可靠性。

References

Computer Networking: A Top-Down Approach (6th Edition)
Root name server - Wikipedia
What risks are associated with recursive DNS queries?
Definitive Guide to DNS TTL Settings
DNS basics - G Suite Administrator Help
Geolocation Routing - Amazon Route 53
RFC 7871 - Client Subnet in DNS Queries
DNS root server FAQ
Anycast - Wikipedia
Google Public DNS - Wikipedia
Google Public DNS and Location-Sensitive DNS Responses
FAQ - Google Public DNS