DNS是DomainNameSystem的缩写，也就是域名解析系统，它的作用非常简单，就是根据域名查出对应的IP地址。
NS服务器：说白了，就是一台翻译名字到IP的软件。
IP:IP就是IP,不解释。
下面，我们来看一下逻辑关系：假设某设备（充当DNS客户端）需要解析域名a.b.c.d,于是就可以向DNS服务器发起请求，然后然后DNS服务器将解析的IP结果w.x.y.z返回给客户端。
由于后面我会讲到DNS的解析过程，因此需要你对域名的层级有一些了解
域名是分层结构，域名服务器也是对应的层级结构。有了域名结构，还需要有一个东西去解析域名，域名需要由遍及全世界的域名服务器去解析，域名服务器实际上就是装有域名系统的主机。
由高向低进行层次划分，可分为以下几大类：
注：一个域名服务器所负责的范围，或者说有管理权限的范围，就称为区域（Zone）关于分层，需要注意的是:
域名的层级有关要点，说明如下：
（1）“www.baidu.com”的一个最完整的形式应该是“www.baidu.com.”。
即在每个域名后面会有一个“.”，“.”来表示根，我们统称这种域名叫绝对域名“FullyQualifiedDomainName”(FQDN)，相当于Linux系统中的文件绝对路径。可以通过在计算机中输入“www.baidu.com.”或“www.dianrong.com.”来确认是否可以打开网站。
不需要输入，不代表不存在。
“.”来表示根,通常我们不需要输入这个根，因为计算机和浏览器默认已帮我们输入了这个“.”根。
（2）域名体系，使用逆向树所示，树中的每一个分支，都称为域，一个域名可以属于多个域，如域名www.baidu.com属于baidu.com域的一部分，同时也是com域的一部分。
（3）“.”是最树状结构中最顶层的域名，统称为“根”，即每个域名都是由根开始索引的，所有域名都属于根。
（4）域名体系是通过倒着来叙述一个域名，如www.baidu.com是先写最下面的www，在写中间的baidu，接着写上面的com，最后写“.”，只是根可以省略
（5）顶级域名下面的分支是二级域名，即我们平时通过阿里云、腾讯云购买的域名，如baidu.com、fastcp.cn、dianrong.com等。
（6）二级域名下面的分支为三级域名，有时也可称为服务器名称，如baidu下面的www代表了百度的网站服务名称，music代表了百度的音乐网站服务器名称。
（7）由根分支出的域名叫顶域域名（一般简称为TLD），一般分为国家地区顶级域名和通用顶级域名。
当然三级域名下还可以在分支四级域名出来，DNS类似于Unix文件系统的结构，由根节点在上的反转树表示。最多分分支127层，每一层可以由最多63个字符组成，每层中间都以“.”进行分隔，类似Unix文件中以“/”分隔每一个目录。域名的总长度不可超过255个字符，仅可使用字符、数字和连字符，不区分大小写。
下面是一条A类型的资源记录（简称为A记录）：域名www.zdns.cn的数据为202.173.11.10
记录一条域名信息映射关系，称之为资源记录（RR）。当我们查询域名www.zdns.cn的时候，查询结果得到的资源记录结构体中有如下数据：
常见的资源记录类型如表所示。
都是区域（Zone）数据库文件都是由资源记录。
用户可以在此设置子域名并指向到自己的目标主机地址上，从而实现通过域名找到服务器。
说明：指向的目标主机地址类型只能使用IP地址；附加说明：
当相同子域名有多个目标地址时，表示轮循，可以达到负载均衡的目的，但需要虚拟主机服务商支持。
您可以为一个主机设置别名。比如设置test.mydomain.com，用来指向一个主机www.rddns.com,那么以后就可以用test.mydomain.com来代替访问www.rddns.com了。
说明：·
用于将以该域名为结尾的电子邮件指向对应的邮件服务器以进行处理。如：用户所用的邮件是以域名mydomain.com为结尾的，则需要在管理界面中添加该域名的MX记录来处理所有以@mydomain.com结尾的邮件。
说明：
附加说明：
服务器解析记录,用来表明由哪台服务器对该域名进行解析。这里的NS记录只对子域名生效。
例如用户希望由12.34.56.78这台服务器解析news.mydomain.com，则需要设置news.mydomain.com的NS记录。
如，将news.mydomain.com的NS记录指向到ns.mydomain.com，在设置NS记录的同时还需要设置ns.mydomain.com的指向，否则NS记录将无法正常解析；
即，如果一个主机地址同时存在NS记录和A记录，则A记录不生效。这里的NS记录只对子域名生效。
Nslookup一般是用来确认DNS服务器动作的.
nslookup有多个选择功能用命令行键入nslookup<主机名>执行,即可显示出目标服务器的主机名和对应的IP地址,称之为正向解析.
如果不能使用dig、nslookup，如下：
[root@cdh1~]#nslookupwww.baidu.com-bash:nslookup:commandnotfound报错，命令找不到，是因为新安装的centos7，没有安装bind-utils,安装后就可以运行nslookup了
安装相应软件包
yuminstall-ybind-utils
命令的基本格式
nslookupdomain[dns-server]1使用命令nslookup域名查询IP[root@cdh1~]#nslookupwww.baidu.comServer:10.0.2.3Address:10.0.2.3#53Non-authoritativeanswer:www.baidu.comcanonicalname=www.a.shifen.com.Name:www.a.shifen.comAddress:36.152.44.95Name:www.a.shifen.comAddress:36.152.44.96Name:www.a.shifen.comAddress:::1结果说明如下：
Server:10.0.2.3--->指定的dns服务器Address:10.0.2.3#53------>指定的dns服务器的IP和端口Non-authoritativeanswer:----->未验证的回答baidu.comcanonicalname=www.a.shifen.com.------->目标域名的规范名称（正名/别名）记录Name:www.a.shifen.com------->目标域名Address:36.152.44.95------->目标返回的IpName:www.a.shifen.com------->目标域名Address:36.152.44.96------->目标返回的IpName:www.a.shifen.comAddress:::1没有指定DNS服务器，使用默认的本地DNS服务器，保存在/etc/resolv.conf配置文件中。
[root@cdh1~]#cat/etc/resolv.conf#GeneratedbyNetworkManagernameserver10.0.2.32使用命令nslookup域名dns-server查询IP[root@cdh1~]#nslookupwww.baidu.com114.114.114.114Server:114.114.114.114Address:114.114.114.114#53Non-authoritativeanswer:www.baidu.comcanonicalname=www.a.shifen.com.Name:www.a.shifen.comAddress:36.152.44.95Name:www.a.shifen.comAddress:36.152.44.96以上的命令，通过电信DNS114.114.114.114查询www.baidu.com的IP地址。
Non-authoritativeanswer表示解析结果来自非权威服务器，也就是说这个结果来自缓存，并没有完全经历全部的解析过程，从某个缓存中读取的结果，这个结果存在一定的隐患，比如域名对应的IP地址已经更变。
直接查询返回的是A记录，我们可以指定参数，查询其他记录，比如AAAA、MX等。
nslookup-qt=typedomain[dns-server]其中，type可以是以下这些类型：
例如：
1、缓存查找IP
2、本机的hosts文件查找IP
3、DNS服务器查找IP
第一步：检查浏览器缓存中是否缓存过该域名对应的IP地址
用户通过浏览器浏览过某网站之后，浏览器就会自动缓存该网站域名对应的IP地址，当用户再次访问的时候，浏览器就会从缓存中查找该域名对应的IP地址.
当浏览器从缓存中找到了该网站域名对应的IP地址，将进行下一步骤。
第二步：如果在浏览器缓存中没有找到IP，那么找本机的hosts文件中是否存在IP配置
如果第一个步骤没有完成对域名的解析过程，那么浏览器会去系统hosts文件中，查找系统是否配置过这个域名对应的IP地址，可以理解为系统也具备域名配置的基本能力。
对于开发者来说，通过hosts绑定域名和IP，可以轻松切换环境，可以从测试环境切换到开发环境，方便开发和测试。
第三步：向本地域名解析服务系统发起域名解析的请求
如果在本地无法完成域名的解析，那么系统只能请求域名解析服务系统进行解析，本地域名系统LDNS一般都是本地区的域名服务器。localdns(localnameserver)是客户端网络设置的一部分，要么是手工配置，要么从DHCP得到。一般localdns在从网络上靠近客户端。
对于本地DNS服务器地址，Windows系统使用命令ipconfig就可以查看，在Linux和Mac系统下，直接使用命令cat/etc/resolv.conf来查看LDNS服务地址。
从客户端出发，完整的DNS查找过程中，会出现三种类型的查询。
通过组合使用这些查询，优化的DNS解析过程可缩短传输距离。
本机向本地域名服务器发出一次查询请求，就静待最终的结果。如果本地域名服务器无法解析，自己会以DNS客户机的身份向其它域名服务器查询，直到得到最终的IP地址告诉本机。
在理想情况下，可以使用缓存的记录数据，从而使DNS域名服务器能够直接使用非递归查询。
本地域名服务器向根域名服务器查询，根域名服务器告诉它下一步到哪里去查询，然后它再去查，每次它都是以客户机的身份去各个服务器查询。
迭代查询一般发生在DNSServer之间，当Client发出域名解析的请求后，DNSServer需要给予最佳答案，这个最佳答案可能是"距离最近"的顶级域名服务器，也能是权威域名服务器。无论如何，Client需要对返回结果再次发起请求，知道获得最终结果
可以理解为缓存查找或者一次搞定的查找。
非递归查询发生在Client和DNSServer之间，指的是，请求的DNSServer已经知道答案，直接返回。这里可能有两种情况，一种是DNSServer本机缓存了对应的IP，或者是缓存了对应的域名的权威服务器。第二种情况只需要再发一次请求，即可拿到结果返回
当DNS解析器客户端查询DNS服务器以获取其有权访问的记录时通常会进行此查询，因为其对该记录具有权威性，或者该记录存在于其缓存内。
DNS服务器通常会缓存DNS记录，查询到来后能够直接返回缓存结果，以防止更多带宽消耗和上游服务器上的负载。
从递归和迭代查询可以看出：
客户端-本地dns服务端：
这部分属于递归查询。递归查询时，返回的结果只有两种:查询成功或查询失败.
本地dns服务端---外网：
这部分属于迭代查询。迭代查询，又称作重指引,返回的是最佳的查询点或者主机地址.
但是这种操作系统级别的域名解析规程也被很多黑客利用，通过修改你的hosts文件里的内容把特定的域名解析到他指定的ip地址上，造成所谓的域名劫持。所以在windows7中将hosts文件设置成了readonly，防止被恶意篡改。
dig（域信息搜索器）命令是一个用于询问DNS域名服务器的灵活的工具。它执行DNS搜索，显示从受请求的域名服务器返回的答复。多数DNS管理员利用dig作为DNS问题的故障诊断，因为它灵活性好、易用、输出清晰。虽然通常情况下dig使用命令行参数，但它也可以按批处理模式从文件读取搜索请求。不同于早期版本，dig的BIND9实现允许从命令行发出多个查询。除非被告知请求特定域名服务器，dig将尝试/etc/resolv.conf中列举的所有服务器。当未指定任何命令行参数或选项时，dig将对“.”（根）执行NS查询。
dig[@server][-baddress][-cclass][-ffilename][-kfilename][-n][-pport#][-ttype][-xaddr][-yname:key][name][type][class][queryopt...]
dig最基本的使用方式就是
dig
即查询域名的A记录，查询的dns服务器将采用系统配置的服务器，即/etc/resovle.conf中的。
如果要查询其他类型的记录，比如MX，CNAME，NS，PTR等，只需将类型加在命令后面即可
digmxdigns
另外一个重要的功能是+trace参数，使用这个参数之后将显示从根域逐级查询的过程
diga+trace
如果需要浏览全部的解析过程，那么可以使用dig命令来查看解析过程。以www.baidu.com为例。
一般情况下，DNS解析到别名就停止了，返回了具体的IP地址
后面我将使用wireshark抓取DNS的数据包，但是在开始之前，得先了解一下DNS的报文结构
整个DNS格式主要分为3部分内容，即基础结构部分、问题部分、资源记录部分。
事务ID、标志、问题计数、回答资源记录数、权威名称服务器计数、附加资源记录数这6个字段是DNS的报文首部，共12个字节。
请求和应答的事务ID应当是一个：0xd0d7
标志字段里的内容比较多，每个字段的含义如下
回答资源记录数，在应答包里为2，说明返回了两条查询结果，你可以在Answer字段里看到。
权威名称服务器计数
附加资源记录数
应答的主要内容，这里返回两条结果，每条结果里的字段有
DNS报文的基础结构部分指的是报文首部，如图所示。
该部分中每个字段含义如下。
基础结构部分中的标志字段又分为若干个字段，如图所示。
标志字段中每个字段的含义如下：
为了能够更好地了解DNS数据包的基础结构部分，下面通过捕获的DNS数据包查看基础结构部分。
图中的数据包为DNS请求包，DomainNameSystem(query)部分方框标注中的信息为DNS报文中的基础结构部分。
DomainNameSystem(query)TransactionID:0x9ad0#事务IDFlags:0x0000Standardquery#报文中的标志字段0...............=Response:Messageisaquery#QR字段,值为0,因为是一个请求包.0000...........=Opcode:Standardquery(0)#Opcode字段,值为0,因为是标准查询......0.........=Truncated:Messageisnottruncated#TC字段.......0........=Recursiondesired:Don'tdoqueryrecursively#RD字段.........0......=Z:reserved(0)#保留字段,值为0...........0....=Non-authenticateddata:Unacceptable#保留字段,值为0Questions:1#问题计数,这里有1个问题AnswerRRs:0#回答资源记录数AuthorityRRs:0#权威名称服务器计数AdditionalRRs:0#附加资源记录数以上输出信息显示了DNS请求报文中基础结构部分中包含的字段以及对应的值。这里需要注意的是，在请求中Questions的值不可能为0；AnswerRRs，AuthorityRRs，AdditionalRRs的值都为0，因为在请求中还没有响应的查询结果信息。这些信息在响应包中会有相应的值。
图中方框标注部分为响应包中基础结构部分，每个字段如下：
DomainNameSystem(response)TransactionID:0x9ad0#事务IDFlags:0x8180Standardqueryresponse,Noerror#报文中的标志字段1...............=Response:Messageisaresponse#QR字段,值为1,因为是一个响应包.0000...........=Opcode:Standardquery(0)#Opcode字段.....0..........=Authoritative:Serverisnotanauthorityfordomain#AA字段......0.........=Truncated:Messageisnottruncated#TC字段.......1........=Recursiondesired:Doqueryrecursively#RD字段........1.......=Recursionavailable:Servercandorecursivequeries#RA字段.........0......=Z:reserved(0)..........0.....=Answerauthenticated:Answer/authorityportionwasnotauthenticatedbytheserver...........0....=Non-authenticateddata:Unacceptable............0000=Replycode:Noerror(0)#返回码字段Questions:1AnswerRRs:2AuthorityRRs:5AdditionalRRs:5以上输出信息中加粗部分为DNS响应包比请求包中多出来的字段信息，这些字段信息只能出现在响应包中。在输出信息最后可以看到AnswerRRs，AuthorityRRs，AdditionalRRs都有了相应的值（不一定全为0）。
问题部分指的是报文格式中查询问题区域（Queries）部分。
该部分是用来显示DNS查询请求的问题，通常只有一个问题。该部分包含正在进行的查询信息，包含查询名（被查询主机名字）、查询类型、查询类。
该部分中每个字段含义如下：
在下图中，Queries部分的信息为问题部分信息，每个字段说明如下：其中，可以看到DNS请求类型为A，那么得到的响应信息也应该为A类型。
从图中Queries部分中可以看到，响应包中的查询类型也是A，与请求包的查询类型是一致的。
资源记录部分是指DNS报文格式中的最后三个字段，包括：
这三个字段均采用一种称为资源记录的格式，格式如图所示。
资源记录格式中每个字段含义如下：
资源记录部分只有在DNS响应包中才会出现。下面通过DNS响应包来进一步了解资源记录部分的字段信息。
其中，方框中标注的信息为DNS响应报文的资源记录部分信息。
该部分信息主要分为三部分信息，即回答问题区域、权威名称服务器区域、附加信息区域，下面依次分析这三部分信息。
回答问题区域
这里获取到了2个IP地址，分别为220.181.57.216和123.125.115.110。
权威名称服务器区域
这里总共获取到5个，如ns7.baidu.com。
附加信息区域
与一个不分片的UDP报文的大小有关系。
最初的DNS域名查询默认使用UDP协议，而使用UDP传输的DNS查询响应（QueryResponse）报文，不希望任何形式的分片,包括DNS应用层的分片、以及IP层的分片。。换句话说，要求使用唯一的UDP报文传输DNS响应。
绝大多数的网络接口类型支持IP报文≥576字节无需分片自由通行，考虑到以上诸因素，IETF决定将DNS报文体限制在512字节。每一个根域名服务器占用32字节，其中包括根域名的名称、IP地址、TTL(TimeToLive)等参数。
所以：早期的DNS查询结果是一个512字节的UDP数据包。
一个512字节的UDP数据包，一个根域名服务器占用32个字节(因为，IP地址由32位二进制数组成)，13根域名服务器一共占用416字节。
剩余的96字节用于包装DNS报文头以及其它协议参数。
所以，从空间上来说，一个512字节的dns数据包，最多可以容纳13个服务器的地址，没有多余的空间容纳第14个根域名服务器的32字节。
因此就规定全世界有13个根域名服务器，编号从a.root-servers.net一直到m.root-servers.net。
这13台根域名服务器由12个组织独立运营。其中，Verisign公司管理两台根域名服务器：A和J。每家公司为了保证根域名服务器的可用性，会部署多个节点，比如单单Verisign一家公司就部署了104台根域名服务器（2016年1月数据）。所以，根域名服务器其实不止13台。
容易被大众误解的是，这13个根域名服务器并不等于13台物理服务器，而是代表着13个全球IP地址，由12个机构来管理，其中美国最大电信运营商Verizon管理两个根域名全球IP地址。
截至到今天为止，全球一共有996台服务器实例（Instances），遍布5大洲4大洋。
既然根域名服务器只有13个全球IP，而物理服务器却有996台，到底怎么分配的？
答案是：使用BGP泛播技术（Anycast）
以Verizon管理的“198.41.0.4”为例，在全球一共分布在28个站点，每个站点的服务器，都使用同一个IP——“198.41.0.4”，反过来说，“198.41.0.4”是一个全球IP，在全球被28服务器使用。
问题是：IP地址在互联网上重复使用，会不会有什么问题？
咱们学习网络知识的时候，特别在局域网配置的时候，着重强调IP地址要唯一，不允许有重复使用IP地址的情况发生。但是，在互联网上不同站点可以使用相同的IP地址，只要使用方是IP地址的合法使用者。
“198.41.0.4”就会在28个站点，通过BGP路由协议，28次扩散到Internet路由表。
全球的主机究竟挑选哪个“198.41.0.4”来使用呢？当然是距离自己最近的，用BGP的专业术语表达就是最优路径。
根域名服务器特别重要，曾经有黑客集中攻击它，差一点就成功了，因为13个服务器中某些依然没有被打趴下，源于服务器的全球式分布。
一朝被蛇咬，十年怕草绳。互联网管理机构发现对付DDoS攻击最有效的方法，就是分布式部署根域名服务器。于是，使用了泛播技术，全球有了996台实例。
如果有一天996台不够用，可以添加任意多台服务器，因为全球IP可以重复使用。
先回顾一下DNS劫持的概念？
DNS劫持即通过某种技术手段，篡改正确域名和IP地址的映射关系，使得域名映射到了错误的IP地址，因此可以认为DNS劫持是一种DNS重定向攻击。DNS劫持通常可被用作域名欺诈，如在用户访问网页时显示额外的信息来赚取收入等；也可被用作网络钓鱼，如显示用户访问的虚假网站版本并非法窃取用户的个人信息。
那么DNS劫持是如何产生的呢？
下面大概说几种DNS劫持方法：
1.本机DNS劫持
攻击者通过某些手段使用户的计算机感染上木马病毒，或者恶意软件之后，恶意修改本地DNS配置，比如修改本地hosts文件，缓存等
2.路由DNS劫持
很多用户默认路由器的默认密码，攻击者可以侵入到路由管理员账号中，修改路由器的默认配置
3.攻击DNS服务器
直接攻击DNS服务器，例如对DNS服务器进行DDOS攻击，可以是DNS服务器宕机，出现异常请求，还可以利用某些手段感染dns服务器的缓存，使给用户返回来的是恶意的ip地址
BGP泄漏后：
事件危害：黑客诱导原本想访问正常银行网站的受害者访问到钓鱼网站，并恶意窃取受害者的银行账目密码信息。事件还原：事件发生在2018年。黑客利用D-Link路由器的漏洞，入侵了至少500个家用路由器。黑客入侵后更改受害者路由器上的DNS配置，将受害者的DNS请求重定向到黑客自己搭建的恶意DNS服务器上。黑客入侵后更改受害者路由器上的DNS配置，将受害者的DNS请求重定向到黑客自己搭建的恶意DNS服务器上，最终诱导原本想访问正常银行网站的受害者访问到钓鱼网站，并恶意窃取受害者的银行账目密码信息。
上面两个案例都是触目惊心啊。接下来我们来介绍一下黑客们是怎么做到DNS劫持的？
我们按照客户端侧--递归DNS服务器--权威DNS服务器的路径，将DNS劫持做如下分类：
客户端侧发生的DNS劫持统称为本地DNS劫持。本地DNS劫持可能是：
DNS解析过程中发生在客户端和DNS服务器网络通信时的DNS劫持统一归类为DNS解析路径劫持。通过对DNS解析报文在查询阶段的劫持路径进行划分，又可以将DNS解析路径劫持划分为如下三类：
通过技术手段(中间盒子，软件等)将DNS流量重定向到其他DNS服务器。案例：
利用分光等设备将DNS查询复制到网络设备，并先于正常应答返回DNS劫持的结果。案例：一个DNS查询抓包返回两个不同的应答。
网络设备或者软件直接代替DNS服务器对DNS查询进行应答。案例：一些DNS服务器实现了SERVFAIL重写和NXDOMAIN重写的功能。
篡改DNS权威记录我们这里指的黑客非法入侵DNS权威记录管理账号，直接修改DNS记录的行为。案例：黑客黑入域名的管理账户，篡改DNS权威记录指向自己的恶意服务器以实现DNS劫持。
DNS劫持在互联网中似乎已经变成了家常便饭，那么该如何应对各种层出不穷的DNS劫持呢？如果怀疑自己遇到了DNS劫持，首先要做的事情就是要确认问题。
安装杀毒软件，防御木马病毒和恶意软件；定期修改路由器管理账号密码和更新固件。选择安全技术实力过硬的域名注册商，并且给自己的域名权威数据上锁，防止域名权威数据被篡改。选择支持DNSSEC的域名解析服务商，并且给自己的域名实施DNSSEC。DNSSEC能够保证递归DNS服务器和权威DNS服务器之间的通信不被篡改。阿里云DNS作为一家专业的DNS解析服务厂商，一直在不断完善打磨产品功能，DNSSEC功能已经在开发中，不日就会上线发布。在客户端和递归DNS服务器通信的最后一英里使用DNS加密技术，如DNS-over-TLS，DNS-over-HTTPS等。在此《DNS攻击防范科普系列》已经完结，欢迎大家给我们留意反馈自己对DNS攻击防范对看法。
通过上面的讲解，我们都知道了，DNS完成了一次域名到IP的映射查询，当你在访问www.baidu.com时，能正确返回给你百度首页的ip。
但如果此时DNS解析出现了一些问题，当你想要访问www.baidu.com时，却返回给你www.google.com的ip，这就是我们常说的DNS劫持。
与之容易混淆的有HTTP劫持。
那什么是HTTP劫持呢？
传统DNS存在哪些问题？
如下是我们的域名在用户机器上被篡改的实例，通过修改hosts文件，可以看到下面的域名被篡改成了127.0.0.1。
2014年1月21日下午3点，国内顶级域的根服务器出现异常，许多知名网站的域名均被劫持到一个错误的IP地址上，至少有2/3的国内网站受到影响，用户无法正常访问。
根服务器恢复后，由于DNS缓存问题，部分地区用户“断网”现象仍持续了几个小时。
DNS的解析机制为了提升效率，在很多地方会有缓存，例如本机的缓存，DNS服务器上的缓存。缓存带来了效率上的提升，但同时却给故障处理带来了不小的麻烦，即：当我们将故障的机器下线或者将DNS指向的主机地址修改以后，用户并不能立刻感知新的主机地址，在缓存有效期内还是会继续访问旧的主机。
定义：不走传统的DNS解析，而是自己搭建基于HTTP协议的DNS服务器集群，分布在多个地点和多个运营商，当客户端需要DNS解析的时候，直接通过HTTP协议进行请求这个服务器集群，获得就近的地址。
例如dns缓存在内存中，也可以持久化到存储上，app重启后，就可以尽快的从存储中加载上次积累的解析结果。
解析可以是同步或异步的。
同步更新的优点是实时性好，缺点是如果有多个请求都发现过期的时候，会同时请求HTTPDNS，浪费资源。对应到应用架构中缓存的Cache-Aside机制，先读缓存，不命中读数据库，同时写入到缓存。
异步的优点是多个请求都过期的情况可以合并为一个，同时可以在即将过期的时候，创建一个任务进行预加载，防止过期之后再刷新成为预加载。缺点是当请求拿到过期数据，如果可以请求就没问题，如果不能请求，则失败，等下次缓存更新后，再请求方能成功。
对应于应用架构中缓存的Refresh-Ahead机制，即业务仅仅访问缓存，当过期就定期刷新。
HTTPDNS使用HTTP协议进行域名解析，代替现有基于UDP的DNS协议，域名解析请求直接发送到阿里云的HTTPDNS服务器，从而绕过运营商的LocalDNS，能够避免LocalDNS造成的域名劫持问题和调度不精准问题。
防劫持
HTTPDNS代替了传统的LocalDNS完成递归解析的功能，基于HTTP协议的设计可以适用于几乎所有的网络环境，同时保留了鉴权、HTTPS等更高安全性的扩展能力，避免恶意攻击劫持行为。
精准调度
DNS解析0延迟：
服务端提供API接口,app端直接通过ip地址访问,ip地址可以有多个
请求方式：HTTPGET
URL参数说明：
请求示例：
考虑到服务IP防攻击之类的安全风险，为保障服务可用性，HTTPDNS同时提供多个服务IP，当某个服务IP在异常情况下不可用时，可以使用其它服务IP进行重试。
请求成功时，HTTP响应的状态码为200，响应结果用JSON格式表示，示例如下：
{"host":"www.suning.com","ips":["112.84.104.48"],"ttl":57,"origin_ttl":120}请求失败的响应示例：
{"code":"MissingArgument"}错误码列表如下：
错误处理
异常下的出错兼容逻辑,主要包括异步请求,重试,降级
异步请求
访问HTTPDNS服务解析域名时，如果请求HTTPDNS服务端失败，即HTTP请求没有返回，可以进行重试。大部分情况下，这种访问失败是由于网络原因引起的，重试可以解决。降级
不管是因为什么原因，当通过HTTPDNS服务无法获得域名对应的IP时，都必须降级：使用标准的DNS解析，通过LocalDNS去解析域名。Android端:OkHttp默认使用系统DNS服务InetAddress进行域名解析，但同时也暴露了自定义DNS服务的接口，通过该接口我们可以优雅地使用HttpDns。
OkHttp暴露了一个Dns接口，通过实现该接口，我们可以自定义Dns服务：
实现简单，只需通过实现Dns接口即可接入HttpDns服务通用性强，该方案在HTTPS,SNI以及设置Cookie等场景均适用。规避了证书校验，域名检查等环节IOS端:基于NSURLProtocol可拦截iOS系统上基于上层网络库NSURLConnection/NSURLSession发出的网络请求；
通过以下接口注册自定义NSURLProtocol，用于拦截上层网络请求，并创建新的网络请求接管数据发送、接收、重定向等处理逻辑，将结果反馈给原始请求。
[NSURLProtocolregisterClass:[CustomProtocolclass]];自定义NSURLProtocol处理过程概述：
ServerLoadBalancing，中文:服务端负载均衡
DNS（DomainNameSystem）是因特网的一项服务，它作为域名和IP地址相互映射的一个分布式数据库，能够使人更方便的访问互联网。人们在通过浏览器访问网站时只需要记住网站的域名即可，而不需要记住那些不太容易理解的IP地址。
DNS除了能解析域名之外还具有负载均衡的功能，下面是利用DNS工作原理处理负载均衡的工作原理图：
由上图可以看出，在DNS服务器中应该配置了多个A记录，如：
www.apusapp.comINA114.100.20.201;
www.apusapp.comINA114.100.20.202;
www.apusapp.comINA114.100.20.203;
因此，每次域名解析请求都会根据对应的负载均衡算法计算出一个不同的IP地址并返回，这样A记录中配置多个服务器就可以构成一个集群，并可以实现负载均衡。上图中，用户请求www.apusapp.com，DNS根据A记录和负载均衡算法计算得到一个IP地址114.100.20.203，并返回给浏览器，浏览器根据该IP地址，访问真实的物理服务器114.100.20.203。所有这些操作对用户来说都是透明的，用户可能只知道www.apusapp.com这个域名。
DNS域名解析负载均衡有如下优点：
同时，DNS域名解析也存在如下缺点：
事实上，大型网站总是部分使用DNS域名解析，利用域名解析作为第一级负载均衡手段，即域名解析得到的一组服务器并不是实际提供服务的物理服务器，而是同样提供负载均衡服务器的内部服务器，这组内部负载均衡服务器再进行负载均衡，请请求发到真实的服务器上，最终完成请求。
GSLB,GlobalServerLoadBalancing，中文:全局负载均衡
由于现实中存在各种不稳定因素，比如某个服务器集群所在的数据中心断电，洪水或者地震造成数据中心瘫痪等等。在一个数据中心内，无论采用怎样的技术，总可能存在一些不可抗因素，导致其瘫痪。所以通常会把服务器分散部署到多个数据中心，以最大程度减小灾害对服务质量产生影响的概率和程度。
采用全局负载均衡（GSLB）的前提是在不同地区设立了多个数据中心，并不是所有的互联网服务都能做GSLB，前提是业务已经做了分布式部署的规划，无论用户从哪个IDC访问都能得到相同的结果;或者，用户基本不会出现跨区域流动访问的情况，只会访问就近IDC，或者有一套入口调度机制，能将用户调度到所属的节点。
SLB(Serverloadbalancing)是对集群内物理主机的负载均衡，而GSLB是对物理集群的负载均衡。这里的负载均衡可能不只是简单的流量均匀分配,而是会根据策略的不同实现不同场景的应用交付。
GSLB是依赖于用户和实际部署环境的互联网资源分发技术，不同的目的对应着一系列不同的技术实现。
常见的GSLB实现方式有三种：
这三种实现方式都是在用户通过域名来访问目标服务器时，由GSLB设备进行智能决策，将用户引导到一个最佳的服务IP。
用户访问某个网站时，需要首先通过域名解析服务（DNS）获得网站的IP。域名解析通常不是一次性完成的，常常需要查询若干不同的域名服务器才能找到对应的IP。
普通DNS解析流程与全局负载均衡流程GSLB解析流程的对比，大致如下：
(a)普通访问流程
用户首先在本地配置一个本地DNS服务器地址，本地DNS服务器收到DNS请求后若不能解析，会进行递归查询，将请求转发给更高一级的DNS服务器直到找到域名对应的IP或确定域名不存在。
(b)加入GSLB的情况
基于DNS的GSLB域名解析过程,大致如下：
对于加入了GSLB的情况，一个GSLB设备（可能是一个4层交换机）会最终代替DNS服务器完成域名解析。
下例的是一个全局负载均衡解决方案。
本示例基于DNS轮询的GSLB方案：
全局负载均衡解决方案中，DNS解析的步骤如下：
假设全国有多个数据中心，托管在多个运营商，每个数据中心三个可用区。对象存储通过跨可用区部署，实现高可用性。在每个数据中心中，都至少部署两个内部负载均衡器，内部负载均衡器后面对接多个对象存储的前置服务器。
对于不需要做全局负载均衡的简单应用来讲，权威DNS服务器可以直接将object.yourcompany.com域名解析为一个或多个ip地址，服务端可以通过多个ip地址，进行简单的轮询，实现简单的负载均衡。
这种方案的优点是：实现简单、实施容易、成本低。
其缺点是：当GSLB设备采用“用户就近访问”的原则作为选择最优服务器的策略时，会存在判断不准的现象。原因是在这种策略下，GSLB设备是根据用户IP地址和内容服务器IP地址比较来判断其就近性的，请注意GSLB设备收到的DNS请求的源地址，不是用户的地址，而是用户所配置的本地DNS服务器地址，而GSLB的就近性探测是根据这个地址来判断的，若用户指定的DNS服务器IP不能正确代表用户的实际位置，就会出现判断不准的现象。
在我国大多数ADSL拨号上网用户,都能就近分配正确的数据中心
但是当用户用户通过4G移动网络上网的情况下，客户会一直使用归属地的DNS服务器，
或者，存在手动设定本地DNS而设置的DNS距离用户较远的情况，GSLB不能分配最佳的地址。
这种手动设定本地DNS的情况，在国内很常见，国内有很多人使用google的公有dns或者opendns。
为了解决基于DNS实现方式判断不准的问题，又出现了基于HTTP重定向的GSLB。这种方案中GSLB使用HTTP重定向技术，将用户访问重定向到最合适的服务器上。
DNS的这几个问题虽然我们都很清楚，但是也无能为力，因为我们不能控制DNS的设备，也不能修改DNS的实现机制。要想解决这个问题，只能另想办法，我们的解决方案就是HTTP-DNS。
基于HTTP重定向的GSLB工作流程，大致如下图：
使用基于HTTP重定向方案，首先在DNS中将GSLB设备的IP地址登记为域名的A记录（既域名对应的IP）。如上图所示，用户首先通过DNS得到GSLB设备的IP地址，此时用户以为这就是站点服务器的IP，并向其发送HTTP请求。
GSLB设备收到HTTP请求后使用一定策略选择一个最合适的服务器，然后GSLB设备向用户发送一个HTTP重定向指令（HTTP302），并附上选出的服务器的IP地址。最后，用户根据重定向IP访问站点的服务器。
这一方案的优点是：由于直接向用户发送HTTP重定向指令，可以得到用户的真实IP，从而解决了判断不准确的问题。
其缺点是只能为HTTP访问重定向。
故名思议，HTTP-DNS就是通过HTTP的方式来自己实现一套DNS的功能，简单来说就是客户端通过HTTP接口来获取指定域名对应的主机地址，而不再通过传统的DNS设备来获取主机地址。其基本架构示意图如下：
相比传统DNS，HTTP-DNS具备如下优势：
1.自己实现，控制力度强，可以根据业务特点灵活实现
可以根据业务进行细粒度的调度，例如发现A业务某个集群请求量较多，可以动态的将请求分配到其它集群。
2.更新快，故障处理及时
当更新域名对应的主机信息后，客户端能够立刻拿到最新的信息。例如下线一台机器后，客户端再来获取主机地址就不会获取已经下线的机器地址，能够实现秒级的故障处理速度。
当然，HTTP-DNS的这些优势是在特定场景下才能体现的，并不能完全取代传统的DNS。因为如果每次访问都先通过HTTP-DNS拿取主机地址的话，效率和性能都太低，对于手机类智能设备还会导致耗电和流量增加。因此我们需要结合传统DNS和HTTP-DNS的优势，既要保证大部分情况下的性能和效率，也要保证异常情况下的故障快速处理。
具体的做法为：正常情况下我们通过传统DNS完成业务请求，异常重试的时候通过HTTP-DNS完成请求。如图3所示简要的说明了整体流程。
HTTP重定向方案解决了判断不准确的问题，但只能针对HTTP协议应用使用。
对于HTTP协议以外的访问，就需要使用基于IP欺骗（又称三角传输）的GSLB。基于IP欺骗（三角传输）的GSLB工作流程，大致如下图：
基于IP欺骗的方案同样需要首先将GSLB设备的IP地址在DNS中登记为域名的A记录，这样用户对该域名的请求包都会先发送到GSLB设备。如上图所示，GSLB设备首次收到服务请求包后，会选择一个最合适的服务器，并将服务请求包发送到该服务器。服务器在向用户发送响应包时，将其源IP地址字段改为GSLB设备的IP，发送给用户。
基于IP欺骗的GSLB更改IP首部实现使用跳转.并利用IPtunneling技术实现只对请求负载均衡(响应直接返回).
这样，整个过程对用户来说，感觉到的只是GSLB设备在为其提供服务，并不知道其中经历这样一个三角传输的过程。而且这种方案可以对所有类型的访问如HTTP、FTP等进行重定向，但其速度和效率相对比前两种方案要差一点，因为用户所有的访问请求都通过三个点才能响应，经历了更多的路径和处理，所以其主要作为HTTP重定向方案的补充方案在同一GSLB设备中实现。
特点
上文中介绍的三种方案，解决了如何将用户引导到指定服务器群的问题，而在此之前,GSLB内部首先需要使用某种方式选出最适合用户的服务器群，也就是GSLB在选择服务器群时所采用的策略。
接下来介绍一些常用的GSLB策略。
a)ActiveRTT测量：
当GSLBController收到来自LDNS的DNS请求时，GSLBController会通知所有站点负载均衡设备对该LDNS进行RTT测量。根据采集到的RTT值，GSLBController会选择RTT值最小的站点的VIP返回给LDNS。
由于ActiveRTT采用DNSQuery或ICMP进行RTT测量，在有些网络中可能会被安全策略所过滤而无法工作。
ActiveRTT测量会产生额外的DNSQuery或ICMP流量，在有些网络中用户不希望有太多类似的非用户流量。
b)PassiveRTT测量：
PassiveRTT测量不会主动去进行测量，也不会产生额外的数据流量，而是在用户向返回的VIP建立连接时进行采集。
PassiveRTT的测量值真正反映了用户的上网感受，在运营商网络中也不会产生额外流量。也不会受到其他运营商或网络的安全策略的影响。
例如域名www.dns-example.com，有三台服务器，分别是联通IP，移动IP，电信IP，DNS解析配置如下：
可实现的解析效果：
可实现的解析效果
LocalDNS会迭代请求至云解析DNS，云解析DNS根据访问者LocalDNS出口IP来判断访问者的地址位置，实现智能解析。
用户发起DNS请求，递归到LocalDNS，则LocalDNS将本次请求发送到二级节点，通过二级节点向云解析DNS发起请求，此时云解析DNS会根据LocalDNS二级节点的地域位置返回具体的细分线路解析结果。
2.在域名解析页面，全部域名页签下，单击域名，进入解析设置页面。
3.在解析设置页面，单击添加记录按钮
示例：
如果您拥有3台服务器，分别位于电信、联通、移动，添加记录时，在解析线路选择时，按如下配置：
实现效果则是：
2.在解析设置页面，单击添加记录按钮
如果您拥有3台阿里云服务器，分别位于华东1-杭州、华东2-上海、华北2-北京，添加记录时，在解析线路选择时，按如下配置：