一次有关 DNS 解析导致 APP 慢的问题探究

一、业务背景

HTTTPDNS

AWS Router53

APP 使用 HTTPDNS，为解决 DNS 解析生效慢， DNS 劫持等问题。

我们 IOS 和安卓都是使用了 HTTPDNS。

域名托管在 AWS Router53。

域名有多个解析(基于延迟)，为了解决就近接入。

示例配置

ai.baidu.com	CNAME	延迟	亚太地区(香港)	alias-ai-hk.baidu.com
ai.baidu.com	CNAME	延迟	默认值 	123455.baidu.com
ai.baidu.com	CNAME	延迟	中国	alias-ai-zh.baidu.com
alias-ai-zh.baidu.com  A - - 18.18.18.18(国内ip接入)

二、问题

很直观的体现就是, APP 打开很慢。反馈主要是国内的用户。APP 用户面向的群体是全球，所以我们有多个接入。背后通过专线打通。

三、问题排查

不管是从前往后查，还是从后往前查。每个阶段都需要查下。

用户访问到接入层的网络
接入层到网关的网络。
各个服务的耗时。看下链路追踪。

这里也就直接说下我们重点关注的问题的地方： DNS 解析。

3.1、问题一：基于DNS 延迟的解析

因为我们发现由于是基于DNS 延迟的策略，我发现在深圳通过 HTTPDNS 接口获取对应域名的解析，有很大概率会解析到香港的节点。我们发现这个并不准确。

然后我们调整为基于地理位置的路由策略。

ai.baidu.com	CNAME	地理位置	香港	 alias-ai-hk.baidu.com
ai.baidu.com	CNAME	地理位置	默认值 	123455.awsglobalaccelerator.com
ai.baidu.com	CNAME	地理位置	中国	alias-ai-zh.baidu.com
alias-ai-zh.baidu.com  A - - 18.18.18.18(国内ip接入)

我们经过测试，发现这个对应的大陆请求都是解析到大陆的节点。经过这次调整，我们几个APP 好像打开都快了点(不知道是不是心里作用)。我们继续往下看。

3.2、问题二：HTTPDNS侧

HTTPDNS基础理论

HTTPDNS 的原理：

原本用户进行 DNS 解析是向运营商的 DNS 服务器发起 UDP 报文进行查询，而在 HTTPDNS 下，修改为用户带上待查询的域名和本机 IP 地址直接向 HTTPDNS 服务器发起 HTTP 请求，这个 HTTPDNS 服务将返回域名解析后的IP地址。那么这个 HTTPDNS 服务器会做什么？第一 HTTPDNS 获取到请求后，如果当前节点(HTTPDNS 有很多节点) 没有缓存，那么 HTTPDNS 当前节点会向 DNS权威服务器发起请求获取对应的解析记录。

那么一个域名的 DNS 权威服务器是什么？我们可以找到我们的域名再对应的 DNS 管理可以看到。我们的 DNS 服务器信息。

[root@185 ~]# dig xiaoaxiao.cn; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.13 <<>> xiaoaxiao.cn
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16195
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;xiaoaxiao.cn.			IN	A;; AUTHORITY SECTION:
xiaoaxiao.cn.		600	IN	SOA	dns27.hichina.com. hostmaster.hichina.com. 2022052002 3600 1200 86400 600;; Query time: 261 msec
;; SERVER: ……
;; WHEN: Tue May 30 22:37:28 CST 2023
;; MSG SIZE  rcvd: 105

其中 dns27.hichina.com 和 dns28.hichina.com 就是我们这个域名的对应的权威服务器。

每个域名的权威DNS服务器是指该域名的DNS服务器，它负责管理该域名下的所有DNS记录，包括IP地址、邮件服务器、别名等。权威DNS服务器的作用是回答其他DNS服务器关于该域名的所有DNS查询请求。当用户访问该域名时，他们的计算机会向该域名的权威DNS服务器发送查询请求，以获取与该域名相关的IP地址和其他DNS记录。

四、优化方向

4.1、域名解析配置

尽量只配置一层解析。或者使用 CNAME 加速。

假设 a.com，b.com，c.com 都是在解析的域名：

域名记录类型记录值
www.a.com CNAME www.b.com
www.b.com CNAME www.c.com
www.c.com A 1.2.3.4
只配置一层解析也就是 www.a.com 直接 A 记录到具体的 IP，

如果我们设置的是 www.a.com cname 到 www.b.com, www.b.com cname 到 www.c.com， www.c.com A 记录到具体的 IP,

一般情况下，递归需要到授权服务器请求三次才能得到 www.a.com 的 IP 地址，如下图所示：

启用 CNAME 加速功能，授权服务器会把 CNAME 记录和最终的 A 记录一次返回给递归，递归服务器由请求三次授权服务器，减小到请求一次，如下图所示：

这样就极大地减少了请求和应答中网络通信消耗的时间，让解析变得更快，特别是在设置多条 CNAME 解析记录的情况下，加速效果更明显。

域名	记录类型	记录值
www.a.com	CNAME	www.b.com
www.b.com	CNAME	www.c.com
www.c.com	A	1.2.3.4

4.2、靠近 HTTPDNS 服务端层

缩减 HTTPDNS 到权威服务器之间的耗时。把域名切到 DNSPOD 、万网等国内域名商。 AWS(非AWS 中国) Router53 不支持国内 DNS 节点。
调整 TTL 值，也就是增大 TTL 值，让它在 HTTPDNS 服务端缓存失效的时间变长，时间变长，在相同时间范围内，需要去请求权威服务器的次数也会变少。
增加请求量，像 HTTPDNS 某个运营商在国内有近 100多个节点。如果我们的请求量达不到一个层级的话。那么请求到每个节点的请求去命中缓存的概率也会降低。这样可以通过拨测实现，但是注意，不是直接拨测对应的域名，拨测的应该特定的接口(HTTPDNS 的接口)。如果直接拨测域名的话，只是改变的公网解析的场景，而改变不了HTTPDNS 的场景。

4.3、靠近用户层

也就是APP 层

减少请求HTTPDNS

尽量使用缓存的DNS ，不要频繁请求 HTTPDNS。
预解析和乐观DNS

预解析：绝大多数的 APP 在应用初始化阶段都有一个启动期，我们可以在这个启动期做一些preflight工作，即在初始化阶段我们可以针对业务的热点域名在后台发起异步的 HTTPDNS 解析请求。这部分预解析结果在后续的业务请求中可以直接使用，进而消除首次业务请求的 DNS 解析开销，提升 APP 首页的加载速度。

乐观DNS：乐观 DNS（Optimistic DNS）是一种基于缓存的 DNS 解析方法，它认为大多数 DNS 查询都会命中缓存，因此不需要每次都向上游 DNS 服务器发送查询请求，而是直接使用本地缓存中的结果。只有在缓存中没有找到对应的解析结果时，才会向上游 DNS 服务器发送请求。

五、扩展

5.1、如何测试本地到权威DNS服务器获取域名的时间

[root@185 ~]# time dig @ns4.dnsv4.com  www.a.com  
……real	0m0.074s
user	0m0.006s
sys	    0m0.008s

5.2、同地区不同网络，访问HTTPDNS 会不会命中缓存。

比如同一个手机，不同的网络，切换联通到电信在TTL 时间范围内，访问 HTTPDNS(腾讯云) 会不会命中缓存？
比如后面的 DNS 配置只配置了，基于地理位置的逻辑的配置。比如国内到 A ，国外到 B. 在这个场景下会不会命中缓存？可以想一想？

经过确认，腾讯云的HTTPDNS 是同一个地域(省或者直辖市)+同一个运营商，会命中同一个缓存。但是注意，同一个地域的 HTTPDNS 后端节点有多个，可能请求会到不同的节点，也可能命中不了缓存。