聊聊DNS，HTTPDNS

DNS域名解析就是将我们熟知的域名转换为ip的服务。如将 www.baidu.com 转换为 61.135.169.125 这样的ip地址。
想要记住域名比较容易，但是想要记住ip就不容易了，由此可见dns服务是多么的重要。

解析流程

DNS.jpg

如上图所示就是一个最简单的查询流程，根服务器是不会给任何人提供递归查询服务的，它只提供 迭代查询，根只是知名一个方向，让你去找相关的顶级域服务器。
但是站在客户端的角度，这就是一次 递归查询 过程。本地DNS就是做这个的，本地dns服务器一般是通过DHCP服务器配置，本地DNS由你所在的网络服务商ISP，如电信，移动等自动分配配置的，它通常就是在你的网络服务商的某个机房中。

负载均衡

dns不仅仅可以对域名解析出ip。它还能根据客户端的所在地理位置解析出对客户端最优质的ip。这个怎么理解呢，比如我在深圳访问 baidu.com ，那么dns服务器会将解析成就近的机房的ip地址，而不会让我去访问位于北京的机房。
这就是 全局负载均衡（GSLB，Global Server Load Balance）。因为，为了保证服务应用的高可用性，往往会部署多个机房，每个地方都会有自己的IP地址。当用户访问某个域名的时候，这些IP地址可以轮询这些机房。另外尽可能希望，北京的用户访问北京的机房，上海的用户访问上海的机房。这样客户体验就会非常好，访问速度也会非常快。

DNS (GSLB).jpg

有什么问题木有呢？

看似十分完美的 GSLB 和 SLB。实则有很多的问题。

问题一 本地缓存
不是每一个请求都是去访问的权威DNS服务器，而是访问过一次，就把结果缓存到本地，当其他人来访问的时候，直接就返回了这个结果。
一些运营商会把一些静态页面，缓存到本地运营商的服务器中，这样用户请求的时候，就不用跨运营商进行访问了，这样既加快了速度，也减少了运营商之间的流量计算的成本。
再就是本地缓存，往往使得全局负载均衡失败。因为上次进行缓存的时候，缓存的地址不一定是这次访问离客户最近的地方，如果把缓存的数据返回给客户，那就绕远了。
问题二 域名转发问题
有一些本地DNS服务器比较黑心，收到解析请求之后，直接转发给了其他运营商去做解析，自己只是外包出去了。比如你是移动用户，你发起对baidu.com 的解析请求，而移动的本地DNS服务器将解析转给联通的DNS服务器，最终GSLB误认为你是联通的，返回一个相对于联通用户的更优解。结果每次客户端访问其实都是跨运营商的，速度就会慢很多。
问题三 出口NAT
在 IPV4 地址不够用的大环境下，其实有十分多的NAT，也就是网络地址转换。使得从这个网关出去的包都换成了一个新的IP地址。一旦做了地址转换，可能GSLB就不知道你的运营商，源IP了。
问题四 域名更新
受TTL限制，解析变更在全网的生效时间较长。我们这里一个机房挂了，将这个机房的A记录摘掉。但是往往过了一天还能发现有流量过来（这就和TTL没关系了，还是本地DNS层层缓存惹的祸）
问题五 解析延迟问题
一个解析需要递归本地DNS 可能多次，再去迭代。比较慢。

既然传统 DNS 问题这么多，那怎么解决呢？
有，那就是HTTPDNS

HTTPDNS 的工作模式

HTTPDNS不走传统的DNS解析，而是自己搭建基于HTTP协议的DNS服务器集群，分布多个地点和多地运营商，当客户端需要DNS解析的时候，就通过HTTP协议进行请求这个服务器集群。到就近的地址。
而使用HTTPDNS的往往是手机应用，需要在手机端嵌入支持HTTPDNS的客户端SDK。
在客户端的SDK里动态请求服务端，获取HTTPDNS的服务器列表。缓存到本地，随着不断域名解析，SDK也会在本地缓存DNS域名解析的结果。
当应用要访问一个地址时，先看下是否有缓存（这个缓存时手机应用自己做的，不走运营商的缓存，所以如何更新，合适更新全在自己的掌控之中）如果本地没有缓存，那就请求 HTTPDNS的服务器吧。而手机客户端当然知道收集在哪个运营商，在哪个地址，由于是直接的HTTP通信，HTTPDNS也能更好的返回结果信息，更好的做到全局负载均衡。

curl 'https://dns.google.com/resolve?name=www.qq.com&type=A&dnssec=true&ecs=112.12.1.1' -s |jq
{
  "Status": 0,
  "TC": false,
  "RD": true,
  "RA": true,
  "AD": false,
  "CD": false,
  "Question": [
    {
      "name": "www.qq.com.",
      "type": 1
    }
  ],
  "Answer": [
    {
      "name": "www.qq.com.",
      "type": 5,
      "TTL": 203,
      "data": "news.qq.com.edgekey.net."
    },
    {
      "name": "news.qq.com.edgekey.net.",
      "type": 5,
      "TTL": 21109,
      "data": "e6156.dscf.akamaiedge.net."
    },
    {
      "name": "e6156.dscf.akamaiedge.net.",
      "type": 1,
      "TTL": 17,
      "data": "23.198.121.20"
    }
  ]
}

HTTPDNS的调度设计

在客户端，可以知道确切的地理位置信息，运营商。HTTPDNS可以根据这些信息返回最佳的服务节点。
如果有多个节点，还会考虑错误率，请求时间，服务器压力，网络状况等，进行综合选择。而非仅仅考虑地理位置。当有一个节点宕机或者性能下降时，尽快切换。
在服务端，服务端可以配置不同的服务质量的权重，优先级，对客户端上报的错误率，请求时间，请求质量等数据，统计，分析，聚合，以此查看不同的IP的服务质量。
为了不让调度失真，客户端可以根据，不同的移动网络运营商的WIFI的SSID分维度缓存，不同的运营商或者WIFI解析出来的结果会不同。

GOOGLE HTTPDNS

2016.4.1日，Google正式启用了 DNS-Over-HTTPS 域名安全查询服务
该服务支持以下参数：

name
唯一的一个必选string参数，就是你要查询的域名地址。长度在1-255，字符在[0-9a-zA-Z-.]，不支持非ASCII字符。
type
可选string，默认是1。RR type可以用[1, 65535]之间的数字表示，或者canonical string表示(A, AAAA等）。目前支持：A， AAAA，CNAME， MX，ANY，PTR
cd
布尔型，默认是false。CD(Checking Disabled)字段，设置为true时禁用DNSSEC validation。可用格式：cd, cd=0, cd=1, cd=false, cd=true
edns_client_subnet
可选string，默认为空。这个是edns0-client-subnet选项。格式是：IP/Mask。比如：1.2.3.4/24，2001:700:300::/48。

edns_client_subnet 这里有个坑，比如你有海外需求，需要将域名cname到海外著名的cdn厂商，比如fastly，akamai等，你需要确定cdn厂商认不认edns扩展，比如 akamai 的权威是不认阿里httpdns ，腾讯httpdns 的edns 扩展的，也就是你用 ali，tencent 的httpdns 解析akamai 的是会调度错误的。

怎么测试权威是否支持我们的edns 扩展呢？
以 www.qq.com 为例
找到域名的权威。

$ dig www.qq.com +trace @114.114.114.114
...
www.qq.com.     86400   IN  NS  ns-cmn1.qq.com.
www.qq.com.     86400   IN  NS  ns-tel1.qq.com.
www.qq.com.     86400   IN  NS  ns-cnc1.qq.com.
www.qq.com.     86400   IN  NS  ns-os1.qq.com.

www.qq.com.     300 IN  CNAME   public-v6.sparta.mig.tencent-cloud.net.
...

对权威发起 subnet 查询, www.qq.com 被 cname 到腾讯云上去了，看来权威在腾讯云上

dig public-v6.sparta.mig.tencent-cloud.net. @ns1.qq.com. +subnet=12.13.1.12

看看是否有解析结果。

参考 1. 刘超老师的极客时间
2.https://blog.csdn.net/windyf2013/article/details/79727348