DNS简单来说，就是用来将一个网站的域名转换为对应的IP
当我们发现可以上QQ但不能浏览网页时，我们会想到可能是域名解析的问题
理论
1、 DNS起源
最初，要访问网站时候，必须要知道它的IP地址，没有规律，难记住。且如果网站的IP更改后后，还必须通知所有的人。
人们想出了一个替代的方法，即为其起一个名字，然后建立名字到IP地址的一个映射关系。我们访问名字，剩下的名字到地址的转换过程则由计算机自动完成。（每个人电脑中被保存hosts文件，里面记录所有映射关系，然后定期从一个维护此文件的站点更新里面的记录。当我们访问某个名字时，先在hosts文件找到对应的IP，然后就可以建立连接。）
产生的问题：hosts文件变得非常大；主机名字会冲突；集中的维护站点会不堪重负
之后出现了域名系统（DNS, Domain Name System)，这是一种层次的、基于域的命名方案，并且用一个分布式数据库系统加以实现。
当我们需要访问一个域名时，应用程序会向DNS服务器发起一个DNS请求，DNS服务器返回该域名对应的IP地址。
这样访问一个域名的过程可以简化为下图：
2、 DNS协议
如何管理一个超大型并且不断变化的域名到IP的映射集合？
如何应付成千上万的DNS查询请求？
如何防止域名出现重复？
关于域名的规则和我们生活中的快递系统类似，使用层次的地址结构。如：邮寄地址：中国、广东省、广州市、番禺区、中山西路12号 XXX。对应域名看起来是这样的www.google.com（为什么不是com.google.groups？可能和老外写地址的习惯有关）。
对于Internet来说，域名层次结构的顶级（相当于国际快递地址中的国家部分）由ICANN（互联网名称与数字地址分配机构）负责管理。每个顶级域名可以进一步划为一些子域（二级域名），这些子域可被再次划分（三级域名），依此类推。
域名空间树
域名资源记录，它是一个五元组: Domain_name Time_to_live Class Type Value
Domain_name：记录适用于哪个域名；
Time_to_live：记录的生存周期，也就是最多可以缓存该记录多长时间
Class：一般总是IN；
Value：记录的值(如果是A记录，则value是一个IPv4地址)。
Type：记录的类型；
如何合理地将所有的域名资源记录存储到不同的域名服务器上?
可以进一步将其划分为不重叠的区域（DNS zone）
然后将每个区域与多个域名服务器（其中一个是master，其他slave服务器则用来提供数据备份、加快解析速度、保证服务可用性）关联起来，称这些域名服务器为该区域的权威域名服务器(Authoritative Name Servers )，它保存两类域名资源记录：
1：该区域内所有域名的域名资源记录。
2：父区域和子区域的域名服务器对应的域名资源记录（主要是NS记录）。
这样，所有的域名资源记录都保存在多个域名服务器中，并且所有的域名服务器也组成了一个层次的索引结构，便于我们后面进行域名解析。
下面以一个简化的域名空间为例子，说明域名资源记录是如何保存在域名服务器中的.
图中域名空间划分为A-G七个DNS区域，每个DNS区域都有多个权威域名服务器，这些域名服务器里面保存了许多域名解析记录。
发现区域A、B并没有父区域，他们之间并没有一条路径连在一起。这将导致一个很麻烦的问题，那就是区域A的权威域名服务器可能根本不知道区域B的存在。
引入根域名服务器，它保存了所有顶级区域的权威域名服务器记录。现在通过根域名服务器，我们可以找到所有的顶级区域的权威域名服务器，然后就可以往下一级一级找下去了。下图为全球根域名服务器的分布图，可以在这里找到。
权威域名服务器和根域名服务器其实组成了一个树，树根为根域名服务器，下面每个节点都是一个区域的权威域名服务器,
3、 域名解析
当连接上网络之后，计算机会自动获得一个默认的DNS服务器（当然你也可以用自己信任的DNS服务器），我们把这个域名服务器也叫作本地域名服务器。
当我们需要知道一个域名对应的资源记录时，会向本地域名服务器发起请求，如果该域名恰好在本地域名服务器所辖属的域名区域（DNS zone）内，那么可以直接返回记录。
如果在本地域名服务器没有发现该域名的资源记录，就需要在整个域名空间搜索该域名。而整个域名空间的资源记录存储在一个分层的、树状联系的一系列域名服务器上，所以本地域名服务器首先要从根域名服务器开始往下搜索。
这里有一个问题就是本地域名服务器如何找到根域名服务器在哪里呢？
其实域名服务器启动的时候，就会加载一个配置文件，里面保存了根域名服务器的NS记录（根域名服务器地址一般非常稳定，不会轻易改变，并且数量很少，所以这个配置文件会很小）。找到根域名服务器之后，就可以一级一级地往下查找了。
访问math.sysu.edu.cn流程如下：
用户：喂，本地域名服务器，告诉我math.sysu.edu.cn的地址；
本地域名服务器：哎呀，我不知道啊，不在我的辖区，容我去问问老大哥吧。root老大，能告诉我math.sysu.edu.cn的地址吗；
根域名服务器：忙着呢，你去问B（.cn）；
本地域名服务器：喂，B，告诉我math.sysu.edu.cn的地址；
B：你去问D（.edu.cn）；
本地域名服务器：喂，D，告诉我math.sysu.edu.cn的地址；
D：你去问F（sysu.edu.cn）；
本地域名服务器：喂，F，告诉我math.sysu.edu.cn的地址；
F：容老衲看看，哎呀，找到了，是X.X.X.X；
本地域名服务器：踏破铁鞋终于找到啦，喂用户，出来啊，我找到了，是X.X.X.X
上面的是本地域名服务器的迭代解析过程，其实也可以递归查询。
4、 缓存机制
回顾一下平时浏览网站的情况，我们会发现两个比较有意思的结论：
1：80%的时间我们都在看那些20%的网站，这就是大名鼎鼎的80/20 Rule；
2：我们会在一个网站的不同网页之间跳转，也就是不断地访问同一个域名，类似程序访问的局部性原理。
如果我们将已经访问过的那些域名的解析结果缓存在自己的计算机上，那么下次访问的时候可以直接读取结果，不用再次重复DNS查询过程，给自己和域名服务器都节省了麻烦。
当然，这样做的一个前提是要缓存的解析结果不会频繁更改，也就是说我十分钟后解析一个域名的结果和现在解析的结果是一样的。
我们之所以在域名资源记录里面添加一个Time_ti_live字段，表明这条记录最多可以缓存多久。对于那些“稳如泰山”的域名，给一个比较大的值，而那些“朝三暮四”的域名，则可以给定一个小的值。
我们既然可以在本机利用缓存，那么可不可以在域名服务器上也利用缓存机制呢，答案当然是可以的。所以，域名服务器可以将那些访问过的域名资源记录缓存，用户再次发起请求时，可以直接返回缓存结果，不用去迭代或者递归解析。