深入分析Java Web技术内幕读书笔记（二）浅析DNS域名解析过程

上一篇文章《浅析Web请求过程》讲述的是如何发起HTTP请求，对于请求发起过程中很重要的一个步骤——DNS解析过程的描述是一带而过，本篇文章将跟着DNS解析过程来分析域名是如何解析的。

一、DNS域名解析步骤

下图是DNS域名解析的一个示例图，它涵盖了基本解析步骤和原理。

下面DNS解析步骤进行讲解，后面将采用命令行的形式来跟踪DNS解析过程。当用户在地址栏键入www.baidu.com并敲下回车键之后，域名解析就开始了。

第一步：检查浏览器缓存中是否缓存过该域名对应的IP地址

用户通过浏览器浏览过某网站之后，浏览器就会自动缓存该网站域名对应的IP地址，当用户再次访问的时候，浏览器就会从缓存中查找该域名对应的IP地址，因为缓存不仅是有大小限制，而且还有时间限制（域名被缓存的时间通过TTL属性来设置），所以存在域名对应的IP找不到的情况。当浏览器从缓存中找到了该网站域名对应的IP地址，那么整个DNS解析过程结束，如果没有找到，将进行下一步骤。对于IP的缓存时间问题，不宜设置太长的缓存时间，时间太长，如果域名对应的IP发生变化，那么用户将在一段时间内无法正常访问到网站，如果太短，那么又造成频繁解析域名。

第二步：如果在浏览器缓存中没有找到IP，那么将继续查找本机系统是否缓存过IP

如果第一个步骤没有完成对域名的解析过程，那么浏览器会去系统缓存中查找系统是否缓存过这个域名对应的IP地址，也可以理解为系统自己也具备域名解析的基本能力。在Windows系统中，可以通过设置hosts文件来将域名手动绑定到某IP上，hosts文件位置在C:\Windows\System32\drivers\etc\hosts。对于普通用户，并不推荐自己手动绑定域名和IP，对于开发者来说，通过绑定域名和IP，可以轻松切换环境，可以从测试环境切换到开发环境，方便开发和测试。在XP系统中，黑客常常修改他的电脑的hosts文件，将用户常常访问的域名绑定到他指定的IP上，从而实现了本地DNS解析，导致这些域名被劫持。在Linux或者Mac系统中，hosts文件在/etc/hosts，修改该文件也可以实现同样的目的。

前两步都是在本机上完成的，所以没有在上面示例图上展示出来，从第三步开始，才正在地向远程DNS服务器发起解析域名的请求。

第三步：向本地域名解析服务系统发起域名解析的请求

如果在本机上无法完成域名的解析，那么系统只能请求本地域名解析服务系统进行解析，本地域名系统LDNS一般都是本地区的域名服务器，比如你连接的校园网，那么域名解析系统就在你的校园机房里，如果你连接的是电信、移动或者联通的网络，那么本地域名解析服务器就在本地区，由各自的运营商来提供服务。对于本地DNS服务器地址，Windows系统使用命令ipconfig就可以查看，在Linux和Mac系统下，直接使用命令cat /etc/resolv.conf来查看LDNS服务地址。LDNS一般都缓存了大部分的域名解析的结果，当然缓存时间也受域名失效时间控制，大部分的解析工作到这里就差不多已经结束了，LDNS负责了大部分的解析工作。

第四步：向根域名解析服务器发起域名解析请求

本地DNS域名解析器还没有完成解析的话，那么本地域名解析服务器将向根域名服务器发起解析请求。

第五步：根域名服务器返回gTLD域名解析服务器地址

本地DNS域名解析向根域名服务器发起解析请求，根域名服务器返回的是所查域的通用顶级域（Generic top-level domain，gTLD）地址，常见的通用顶级域有.com、.cn、.org、.edu等。

第六步：向gTLD服务器发起解析请求

本地域名解析服务器向gTLD服务器发起请求。

第七步：gTLD服务器接收请求并返回Name Server服务器

gTLD服务器接收本地域名服务器发起的请求，并根据需要解析的域名，找到该域名对应的Name Server域名服务器，通常情况下，这个Name Server服务器就是你注册的域名服务器，那么你注册的域名的服务商的服务器将承担起域名解析的任务。

第八步：Name Server服务器返回IP地址给本地服务器

Name Server服务器查找域名对应的IP地址，将IP地址连同TTL值返回给本地域名服务器。

第九步：本地域名服务器缓存解析结果

本地域名服务器缓存解析后的结果，缓存时间由TTL时间来控制。

第十步：返回解析结果给用户

解析结果将直接返回给用户，用户系统将缓存该IP地址，缓存时间由TTL来控制，至此，解析过程结束。

这里对DNS解析的步骤进行了一个简单的介绍分析，后面将通过命令行的形式来解析一个域名的具体解析过程。

二、DNS域名解析过程分析

在正式开始分析解析过程之前，先来介绍几个基本的域名解析方式的概念。域名解析记录主要分为A记录、MX记录、CNAME记录、NS记录以及TXT记录。

A记录：A代表的是Address，用来指定域名对应的IP地址，比如将map.baidu.com指定到180.97.34.157，将zhidao.baidu.com指定到180.149.131.245，A记录允许将多个域名解析到一个IP地址，但不允许将一个域名解析到多个IP地址上。
MX记录：MX代表的是Mail Exchage，就是可以将某个域名下的邮件服务器指向自己的Mail Server，如baidu.com域名的A记录IP地址是180.97.34.157，如果将MX记录设置为180.97.34.154，即xxx@baidu.com的邮件路由，那么DNS会将邮件发送到180.97.34.154所在的服务器，而正常web请求仍然会解析到A记录的IP地址180.97.34.157。
CNAME记录：CNAME指的就是Canonical Name，也就是别名解析，可以将指定的域名解析到其他域名上，而其他域名就是指定域名的别名，整个解析过程称为别名解析。比如将baidu.com解析到itlemon.cn，将csdn.net解析到itlemon.cn，那么itlemon.cn就是baidu.com和CSDN.net的别名。
NS记录：就是为某个域名指定了特定的DNS服务器去解析。
TXT记录：为某个主机名或者域名设置特定的说明，比如为itlemon.cn设置的的TXT记录为“Lemon的技术笔记”，这个TXT记录为itlemon.cn的说明。

上面概念中的IP地址都是假定的，帮助理解。下面将通过解析域名baidu.com为例，进一步说明域名解析流程。

直接查看域名结果，可以通过命令nslookup加上域名来查看：

上图中Non-authoritative answer表示解析结果来自非权威服务器，也就是说这个结果来自缓存，并没有完全经历全部的解析过程，从某个缓存中读取的结果，这个结果存在一定的隐患，比如域名对应的IP地址已经更变。
这只是一个快捷的解析结果，如果需要浏览全部的解析过程，那么可以使用dig命令来查看解析过程。

分析上图DNS解析过程，我们可以看出：
第一步：从本地DNS域名解析服务器获取到13个根DNS域名服务器(.)对应的主机名。

第二步：从13个根域名服务器中的其中一个（这里是h.root-servers.net）获取到顶级com.的服务器IP（未显示）和名称。

第三步：向com.域的一台服务器192.43.172.30(i.gtld-servers.net)请求解析，它返回了baidu.com域的服务器IP（未显示）和名称，百度有四台顶级域的服务器。

第四步：向百度的顶级域服务器220.181.37.10(ns3.baidu.com)请求www.baidu.com，它发现这个www有个别名，而不是一台主机，别名是www.a.shifen.com。

一般情况下，DNS解析到别名就停止了，返回了具体的IP地址，如果想看到具体的IP地址，可以进一步对别名进行解析，解析结果如下：

这时候看到最后的解析结果是180.97.33.107和180.97.33.108。在解析别名的过程中，可以发现shifen.com和baidu.com都是指定了相同的域名解析服务器。以上是一个域名的解析过程，最后的解析结果和一开始的使用nslookup的结果一致。

深入分析Java Web技术内幕系列读书笔记文章列表：

深入分析Java Web技术内幕读书笔记（一）浅析Web请求过程
深入分析Java Web技术内幕读书笔记（二）浅析DNS域名解析过程

更多干货分享，欢迎关注我的微信公众号：爪哇论剑（微信号：itlemon）