DNS域名解析系统

为什么需要DNS

人们习惯使用主机名，比如www.yahoo.com、www.facebook.com等，但路由器喜欢数字格式的IP地址。
需要DNS把主机名翻译为IP地址。

DNS工作原理

①同一台用户主机上运行着DNS的客户端。
Windows用户可以打开任务管理器，在服务那一栏可以看到名为DNS Client的运行着的后台服务。
②浏览器从接收到的url中抽取出主机名，比如：www.baidu.com，并将这个主机名传给DNS应用的客户端
③DNS客户端向DNS服务器发送一份查询报文，报文中包含着要访问的主机名。
中间包含一系列的DNS缓存查询和分布式DNS服务器查询。
④该DNS客户端最终会收到一份响应报文，其中包含有该主机名对应的IP地址。
⑤一旦该浏览器收到来自DNS客户端的该IP地址，它能够向位于该 IP 地址 80 端口的
HTTP 服务器进程发起一个 TCP 连接。

所有的 DNS 请求和回答报文使用 UDP 数据报经端口 53 发送。 经过若干毫秒到若干秒的时延后，用户主机上的 DNS 接收到一个提供所希望映射的 DNS 回答报文。这个映射结果则被传递到调用 DNS 的应用程序。 因此，从用户主机上调用应用程序的角度看， DNS 是一个提供简单、直接的转换服务的黑盒子。 但事实上，实现这个服务的黑盒子非常复杂，它由分布于全球的大量 DNS 服务器以及定义了 DNS 服务器与查询主机通信方式的应用层协议组成。

大致说来，有 3 种类型的 DNS 服务器: 根 DNS 服务器、顶级域 (Top-Level Domain , TLD) DNS 服务器和权威 DNS 服务器 。这些服务器以图 2-17 中所示的层次结构组织起来。

根 DNS 服务器。有 400 多个根名字服务器遍及全世界。这些根名字服务器由 13 个不同的组织管理。根名字服务器的全部清单连同管理它们的组织及其 IP 地址可以在 [ Root Servers 2016 ]中找到。 根名字服务器提供 TLD 服务器的 IP 地址。
全球的所有根域名服务器的IP地址：https://root-servers.org/
管理全球的所有根域名服务器的13个组织机构：http://www.iana.org/domains/root/servers
顶级域 (DNS) 服务器。 对于每个顶级域(如 com、 org、 net、 edu 和 gov) 和所有国家的顶级域(如 uk、fr、 ca 和 jp) ，都有 TLD 服务器(或服务器集群) 。 Verisign Global Registry Services 公司维护 corn 顶级域的 TLD 服务器， Educause 公司维护 edu 顶级域的 TLD 服务器。支持 TLD 的网络基础设施可能是大而复杂的， [ Osterweil 2012]对 Verisign 网络进行了很好的概述。 所有顶级域的列表参见 [TLD list 2016 ] 。 TLD 服务器提供了权威 DNS 服务器的IP地址。
权威 DNS 服务器。 在因特网上具有公共可访问主机(如 Web 服务器和邮件服务器)的每个组织机构必须提供公共可访问的 DNS 记录，这些记录将这些主机的名字映射为 IP 地址。一个组织机构的权威 DNS 服务器收藏了这些 DNS 记录。 一个组织机构能够选择实现它自己的权威 DNS 服务器以保存这些记录；另一种方法是，该组织能够支付费用，让这些记录存储在某个服务提供商的一个权威 DNS 服务器中。 多数大学和大公司实现和维护它们自己基本和辅助(备份)的权威 DNS 服务器。

根、 TLD和权威 DNS 服务器都处在该 DNS 服务器的层次结构中，如图 2~17 所示。

还有另一类重要的 DNS 服务器，称为本地 DNS 服务器 (local DNS server)。

域名结构

在了解DNS服务器之前，需要先了解因特网上的域名空间结构，具体如下图所示：

DNS 是一种分层结构，在整个互联网中组成一个树状系统，顶层是系统的根域名，下层为 TLD 以及二级域名，叶子就构成了所谓的 FQDN（Fully Qualified Domain Names），

根域名通常使用 “.” 来表示，其实际上也是由域名组成，全世界目前有 13 组域名根节点，由少数几个国家进行管理，而国内仅有几台根节点镜像。

如查询 www.im.qq.com，简略描述 DNS 的过程就是，先查询 com 这个域名的name server有哪些，然后选一个继续查询qq这个子域名的name servers有哪些，再选一个继续查询im这个子域名的name servers有哪些，www不是域名(www是主机名)，查询结束。

关于域名与主机名：
举几个域名的例子：google.com，baidu.com，163.com
可以明确的告诉你，加上www，就不再是域名了！
注意：www.google.com中，www是主机名，www是World Wide Web的简称，表示这是一台web服务器，即网页服务器。相对应的，mail.google.com中，mail是主机名，mail表示邮件，表示这是一台邮箱服务器。

以http://mail.163.com/index.html为例进行说明：
1)http://：这个是协议，也就是HTTP超文本传输协议，也就是网页在网上传输的协议。
2)mail：这个是服务器名(主机名)，代表着是一个邮箱服务器，所以是mail。（www代表一个Web（万维网）服务器）
3)163.com:这个是域名，是用来定位网站的独一无二的名字。
4)mail.163.com：这个是网站名，由服务器名+域名组成。
5)/：这个是根目录，也就是说，通过网站名找到服务器，然后在服务器存放网页的根目录
6)index.html：这个是根目录下的默认网页（当然，163的默认网页是不是这个我不知道，只是大部分的默认网页，都是index.html）
7)http://mail.163.com/index.html：这个叫做URL，统一资源定位符，全球性地址，用于定位网上的资源。

如何获取Root Servers

怎么样获取 Root servers 的地址呢，注意这里没有动态域名（DNS）可用，获取的地址其实就是要获取IP，假如我们来实现 DNS 服务器，这一步你会怎么做呢？
其实这种做法很显然易见，写程序直觉就是如此：

• 写一份配置文件放程序里，记录了全部Root servers的 IP 地址列表，定时从网上（这个就可以用域名了）更新这份配置文件；
• 又或者程序启动的时候，直接从网上获取这些信息，存下来，也是定时更新；

DNS的做法也不外乎如是，而上面说到的这份"配置文件"，就在 https://www.internic.net/domain/named.root，里面就是所有Root Servers的信息。

Initializing a DNS Resolver with Priming Queries 就是Internet Engineering Task Force (IETF) 写的一份关于 priming query 的 BCP(Best Current Practice )文档。下面是这份文档的摘要：

Abstract

   This document describes the queries that a DNS resolver should emit
   to initialize its cache.  The result is that the resolver gets both a
   current NS RRSet for the root zone and the necessary address
   information for reaching the root servers.

关于 Priming Query 的额外知识可以看下面的补充(来自：https://www.ietf.org/rfc/bcp/bcp209.html )：

A priming query is a normal DNS query. Thus, a root name server cannot distinguish a priming query from any other query for the root NS RRset. Thus, the root server's response will also be a normal DNS response.

Resolver software SHOULD treat the response to the priming query as a normal DNS response, just as it would use any other data fed to its cache. Resolver software SHOULD NOT expect exactly 13 NS RRs because historically some root servers have returned fewer.

根DNS服务器只能有13台吗？

根据上面的知识就可以知道“根DNS服务器只能有13台”的说法是错误的。
全球的所有根域名服务器有几百台，所有这些根域名服务器的IP地址可以在 https://root-servers.org/ 查看。
所有这些根域名服务器由 13 个不同的组织管理，这13个组织机构可以在 http://www.iana.org/domains/root/servers 查看。

本地域名服务器（Local DNS）

本地域名服务器在整个互联网访问环节中是一个看起来不起眼，但是极其重要的角色。

本地域名服务器的隐患

大部分人认为域名是由配置在主机里的本地域名服务器来解析的(通过ipconfig/all可以查看配置的本地域名服务器)，其实这种观点是不对的，本地域名服务器本身不具备权威域名服务器解析域名的功能，它的作用有两个：第一，代替用户设备参与域名查询的迭代过程，帮助获取域名查询结果返回给用户设备；第二，缓存域名查询记录，当其他用户发起相同的域名查询请求时可以直接返回查询结果，可以加快域名查询速度，同时也降低了权威域名服务器，尤其是根域名服务器的工作压力。

本地域名服务器给我们访问互联网带来很大便利，但也埋下了隐患。从域名查询的流程中可以看出，所有要访问互联网的设备都必须配置本地域名服务器才可以正常访问网站域名。试想一下如果黑客控制了某个运营商的Local DNS服务器，修改某个A记录到黑客伪造的站点，那么用户的访问该网站的信息就会被劫持，实际上用户输入的域名以为是访问到目标网站，其实真网站的域名解析被劫持解析为假网站的IP地址，这样用户在无知觉的情况下就会访问到这个假网站（也称钓鱼网站），并泄露个人信息，这种攻击方式叫做域名劫持（如图2）。当然，域名劫持不一定是劫持到钓鱼网站，也可能是一些广告页面（骗取流量），只要打开的网站不是想访问的目标网站，那域名劫持的可能性就很大了。域名劫持可以发生在域名查询流程的各个环节，很明显本地域名服务器是最薄弱的一个环节，大部分个人电脑的本地域名服务器配置的是家用路由器（通常是自动获取，包括手机连公开的wifi，获取的本地域名服务器也是wifi的地址），而家用路由器可能连出厂密码都没改过，要获得控制权限毫无难度。

其次，公共的本地域名服务器本身的稳定性也遭到诟病，由于公共域名服务器的公开免费的特性，在访问量大或者互联网线路不稳定的时候，加上各运营商之间互联互通的问题，经常会出现解析异常的情况，比如通过电信线路访问联通的本地域名服务器可能出现解析超时的情况。对于多线路冗余的企业用户来说，配置哪个运营商的本地域名服务器是一个令人困扰的问题。

另外，域名缓存时间虽然通常跟随权威服务器TTL设置，但是本地域名服务器是有权限覆盖这个设置的，若本地域名服务器配置不正规，将缓存时间设置的极长，那么域名绑定IP地址的更新就会成为一个问题，不管权威服务器如何更新IP，本地域名服务器上的域名由于还在缓存时间内就不会主动到权威域名服务器更新IP地址，使用这台域名服务器的用户很长时间内只能访问到旧网站，唯一的办法是建议用户换个本地域名服务器，或者通知本地域名服务器管理员刷新缓存。

自建本地域名服务器

对于互联网用户来说，面对本地域名服务器的问题可以尝试更换可信的第三方的本地域名服务器。企业用户考虑到可用性、稳定性、安全性的需求，建议自建本地域名服务器。

自建本地域名服务器将直接对域名进行迭代查询，可以规避互联网本地域名服务器被劫持的问题，同时通过负载均衡设备建立本地域名服务器池，可以极大的提高本地域名服务的可用性和稳定性。另外，本地域名服务器的解析日志数据具有极高的分析价值，我们知道中毒或者被控的服务器会主动向外发起访问，此时通常会解析一个异常的黑域名，通过对本地域名服务器的解析日志的监控可以快速发现识别被控的服务器，提升互联网安全防护能力。

自建本地域名服务器虽然可以保证本身的可用性和安全性，但依然无法实现互联网域名解析成功率100%。从域名整体解析流程可以看到，域名解析是一个全球互联网域名服务器迭代查询访问的过程，其中任何一个环节出问题都会导致域名解析缓慢、解析失败等情况的出现，这在复杂的互联网环境下比较常见，与互联网质量、各层级的权威服务器状态都有关系，作为终端用户很难跟踪到问题的根本原因，建议应用系统建设时考虑容错能力，在解析失败后进行多次尝试，必要时考虑应急方案，直接通过IP访问目标网站。

DNS相关命令

ipconfig/all：查看电脑的ip地址、DNS服务器信息，DHCP服务器信息等
ipconfig/displaydns：显示本机DNS缓存
ipconfig/flushdns：清除本机DNS缓存(执行本命令后再去执行ipconfig/displaydns，会发现没有一大堆结果输出了，因为缓存的dns解析结果已经被清除了。)
nslookup：解析域名的ip

参考：
计算机网络自顶向下方法 第7版
https://tools.ietf.org/html/draft-ietf-dnsop-resolver-priming-11
https://www.ietf.org/rfc/bcp/bcp209.html

副参考：
HTTP头部
为什么域名根服务器只能有 13 台呢？
为什么域名根服务器只能有13台呢？

求教 dns 劫持的原理与实现
DNS劫持原理与实现
域名劫持原理及实现