从理论到实践，全方位认识DNS（实践篇）

时间 2019-11-10

原文原文链接

在理论篇咱们基本了解了DNS的整个协议原理，可是可能还会有着下面的疑问：html

为何我想申请的域名都没了？
DNS 域名还要备案，这是为何啊？
如何将刚申请的域名绑定到本身的网站呢？
怎么才能看到那些在背后默默给我解析的域名服务器呢？
他们说用一个什么文件就能够访问好多好多不存在的网站，是真的吗？
可信任的域名服务器是怎么一回事，难道有些域名服务器会作坏事？
怎么知道我如今用的域名服务器有没有使坏呢？
……

我不许备一个一个地去回答这些问题，不过相信我，读完本文，对于上面问题的答案你会有一个清晰的认识，而且能够解决其余各类各样关于 DNS 方面的问题。git

域名注册、绑定

首先明确一点，每一个人均可以去注册域名。大多数时候咱们但愿去注册一个顶级域名（好比selfboot.cn, google.com等），那些二级域名毕竟不够好记（好比github托管博客的域名：username.github.io）。有的顶级域名（好比.tk域名）提供免费的一年域名试用，不过绝大多时候仍是要为本身的域名付费的（通常是按年付费，也不是很贵）。要想去注册域名，首先得找到域名注册商，国内的比较著名的有DNSpod等，国外的有godaddy等。相信注册过域名的人都知道绝大多数咱们能想到的本身喜欢的域名都已名花有主了，只剩那些不是那么惹人关注的域名供咱们选择。因此，注册域名时，发现本身每想到一个域名都显示被人注册后，那太正常不过了，说明你的品味比较正常。程序员

这里一点我的建议，选中一个域名后不要轻易去改了，由于换域名成本挺高的（我猜如今就算给淘宝一千万，它也不会换另成一个域名吧）。因此，最好不要去用免费的域名，由于指不定啥时候就不让你用了。你应该相信这么一个观点：天下没有免费的午饭。拓展一下就是，掏钱买服务，内心踏实。github

接下来你可能会但愿将本身的站点或者博客挂在本身选中的域名下，这其实很简单，只须要找到一个提供域名解析的服务商，而后填写相应的域名解析记录。大多时候，你注册域名的服务商都会免费提供域名解析服务。缓存

现实中，大部分人可能会拥有我的博客，之前咱们都是依赖一个博客平台（如CSDN），或者是买一台VPS托管本身的博客。不过自从Github推出了Blog服务，好多程序员都转而将博客托管在上面。Github Blog支持绑定我的域名，并提供了详细的绑定文档：Adding a CNAME file to your repository。假设你的博客已经能够经过 username.github.io 访问，接下来只须要用 CNAME 告诉Github你的博客绑定了哪一个域名（好比说是 selfboot.cn），而后在域名解析商那里添加解析记录便可，下图是我我的博客在DNSpod的解析记录：服务器

如今当咱们访问 selfboot.cn 时，DNSpod就会将请求解析到 Github 提供的 IP 地址上。以后 Github 上面的博客托管服务器在全部用户的 CNAME 记录中，找到本次请求的域名对应的博客项目地址，好比说是 xuelangZF.github.io，而后返回博客内容。网络

域名解析

咱们都知道一个域名的解析过程当中，可能会有多台域名服务器给咱们帮助，那么咱们怎么能看到这些背后的功臣呢？先介绍两个经常使用的关于DNS的命令。app

dig, nslookup

dig(Domain Information Groper), 是 UNIX/BSD 系统自带的 DNS 诊断工具，使用十分灵活、方便。dom

查询 selfboot.cn 的A记录，并返回简短的结果：工具

$ dig selfboot.cn -t A +short
192.30.252.153
192.30.252.154

用 dig 还能够查询某一 ip 对应的域名，以下：

$ dig -x 192.30.252.153 +short
pages.github.com.

这里返回的是pages.github.com，由于当你访问博客地址 selfboot.cn 时，实际上是Github的pages 服务器（域名是：pages.github.com）在后台返回该博客内容的（根据 CNAME 肯定返回哪一个博客）。

nslookup 也是一个 DNS 诊断工具，几乎全部平台都自带该工具，使用也很简答，能够用 man 查询手册。

解析路径查询

接下来用 dig 命令查看从根域名到指定域名中间可能通过的全部域名服务器，使用 +trace 选项便可。

dig selfboot.cn +trace @8.8.8.8

; <<>> DiG 9.8.3-P1 <<>> selfboot.cn +trace @8.8.8.8
;; global options: +cmd
.            474418    IN    NS    j.root-servers.net.
.            474418    IN    NS    g.root-servers.net.
......
.            474418    IN    NS    l.root-servers.net.
.            474418    IN    NS    m.root-servers.net.
;; Received 496 bytes from 8.8.8.8#53(8.8.8.8) in 12 ms

cn.            172800    IN    NS    a.dns.cn.
......
cn.            172800    IN    NS    e.dns.cn.
cn.            172800    IN    NS    ns.cernet.net.
;; Received 292 bytes from 2001:500:1::803f:235#53(2001:500:1::803f:235) in 382 ms

selfboot.cn.        86400    IN    NS    f1g1ns2.dnspod.net.
selfboot.cn.        86400    IN    NS    f1g1ns1.dnspod.net.
;; Received 83 bytes from 203.119.25.1#53(203.119.25.1) in 816 ms

selfboot.cn.        14400    IN    A    192.30.252.153
selfboot.cn.        14400    IN    A    192.30.252.154
selfboot.cn.        600    IN    NS    f1g1ns1.dnspod.net.
selfboot.cn.        600    IN    NS    f1g1ns2.dnspod.net.
;; Received 125 bytes from 115.236.137.40#53(115.236.137.40) in 31 ms

能够看到最开始是13台顶级域名服务器的NS记录（中间省去一些记录减小行数，方便观察更清楚），接下来是顶级域名 cn. 的权威域名服务器（省略一些输出），而后是 selfboot.cn 的 NS 记录，即 DNSpod 的两条 NS 记录，最后从 f1g1ns2.dnspod.net 找到 selfboot.cn 的 A 记录。

seveas 提供了一个可视化的路径查询工具：dnsgraph，能够在线绘制跟域名到指定域名的全部可能路径。

固然，实际查询过程当中，大多时候咱们在本地缓存或者本地域名服务器缓存就能直接找到须要的域名记录，不须要每次都向根域名服务器发起请求，而后重复迭代或者递归查询过程。

DNS 缺陷

域名系统设计的很理想很美好，然而仍有一些小的瑕疵，可能会给咱们带来些许困扰。

域名抢注

首先，有些域名对注册人没有限制，而另一些域名则对谁能够获得一个域名空间中的名字有限制。好比pro域名是分配给合适的专业人员，但问题是谁才是专业的呢？显然医生、工程师是专业人员，但理发师、管道工呢？

此外，域名也能够被倒卖。黄牛们会批量注册大量域名（听说com域名下几乎每个普通词都被人尝试注册了域名），而后转身就以高价转卖给那些对该域名感兴趣的人，这就是所谓的域名抢注。因此，如今你想注册一个符合本身网站特色的域名是很难的。

这个问题其实还不算严重，更要命的是下面两个问题。

DNS 劫持

咱们知道一个域名服务器对其区域内的用户解析请求负责，可是并无一个机制去监督它有没有真地负责。也就是说域名服务器的权力并无被关在笼子里，因此它既能够认真地“为人民服务”，也能够“混淆是非”。因而有些流氓的域名服务器故意更改一些域名的解析结果，将用户引向一个错误的目标地址。这就叫做 DNS 劫持，主要用来阻止用户访问某些特定的网站，或者是将用户引导到广告页面。

下面验证下我所用的域名服务器有没有干这种坏事，只须要一条简单的命令便可：

➜  ~  nslookup google.com
Server:        10.8.4.4
Address:    10.8.4.4#53

Non-authoritative answer:
Name:    google.com
Address: 120.196.0.5

个人DNS服务器地址为10.8.4.4，他告诉我google.com的地址是120.196.0.5，我才不信呢。因而用whois 120.196.0.5一看，果然不是Google的地址。针对DNS劫持，咱们能够简单地更换域名服务器，比较靠谱的一个是Google提供的8.8.8.8。下面用 8.8.8.8 来解析一下 www.google.com 就能看到正确的地址了。

$ nslookup www.google.com 8.8.8.8
Server:        8.8.8.8
Address:    8.8.8.8#53

Non-authoritative answer:
Name:    www.google.com
Address: 216.58.221.68

DNS 欺骗

DNS 劫持经过简单的切换域名服务器就能够绕过，不过一旦你赶上了 DNS 欺骗，就没法简单地绕过了。下面咱们用不一样的域名服务器来查看 fb 的 IP 地址，结果都返回了同一个地址，看起来好像是真的同样，不过也仅仅是看起来而已。

$ nslookup facebook.com
Server:        10.8.4.4
Address:    10.8.4.4#53

Non-authoritative answer:
Name:    facebook.com
Address: 159.106.121.75

$ nslookup facebook.com 8.8.8.8
Server:        8.8.8.8
Address:    8.8.8.8#53

Non-authoritative answer:
Name:    facebook.com
Address: 159.106.121.75

这个地址并非 fb 的服务器地址（能够在 ViewDNS 查询全部域名真实的域名资源记录，ViewDNS是个很好玩的网站，里面有许多有意思的工具）。其实我Google了一下这个地址，居然发现了一篇不错的译文，看来这个地址早在 2011 年就有了特殊的含义（英文原文是相关阅读第一个）。

DNS 欺骗简单来讲就是用一个假的 DNS 应答来欺骗用户计算机，让其相信这个假的地址，而且抛弃真正的 DNS 应答。在一台主机发出 DNS 请求后，它就开始等待应答，若是此时有一个看起来正确（拥有和DNS请求同样的序列号）的应答包，它就会信觉得真，而且丢弃稍晚一点到达的应答。

实施 DNS 欺骗的关键在于伪造一个有特定序列号的应答包，而且让其抢先一步到达发起请求的主机。这对于我的来讲还有点难度，可是对于拥有骨干网节点的组织来讲，实在是易如反掌，因此这么多网站都已沦陷。不过使用网上流传的那些 hosts文件，就能够在本机缓存许多网站的ip地址，进而能够和部分网站通讯。可是经过hosts文件并不能彻底 Cross the Great FireWall，由于人家还有不少其余手段。