從理論到實踐，全方位認識DNS（實踐篇）

 

在理論篇咱們基本瞭解了DNS的整個協議原理，可是可能還會有着下面的疑問：

1. 爲何我想申請的域名都沒了？
2. DNS 域名還要備案，這是爲何啊？
3. 如何將剛申請的域名綁定到本身的網站呢？
4. 怎麼才能看到那些在背後默默給我解析的域名服務器呢？
5. 他們說用一個什麼文件就能夠訪問好多好多不存在的網站，是真的嗎？
6. 可信任的域名服務器是怎麼一回事，難道有些域名服務器會作壞事？
7. 怎麼知道我如今用的域名服務器有沒有使壞呢？
8. ……

我不許備一個一個地去回答這些問題，不過相信我，讀完本文，對於上面問題的答案你會有一個清晰的認識，而且能夠解決其餘各類各樣關於 DNS 方面的問題。

 

域名註冊、綁定

首先明確一點，每一個人均可以去註冊域名。大多數時候咱們但願去註冊一個頂級域名（好比selfboot.cn, google.com等），那些二級域名畢竟不夠好記（好比github託管博客的域名：username.github.io）。有的頂級域名（好比.tk域名）提供免費的一年域名試用，不過絕大多時候仍是要爲本身的域名付費的（通常是按年付費，也不是很貴）。要想去註冊域名，首先得找到域名註冊商，國內的比較著名的有DNSpod等，國外的有godaddy等。相信註冊過域名的人都知道絕大多數咱們能想到的本身喜歡的域名都已名花有主了，只剩那些不是那麼惹人關注的域名供咱們選擇。因此，註冊域名時，發現本身每想到一個域名都顯示被人註冊後，那太正常不過了，說明你的品味比較正常。

這裏一點我的建議，選中一個域名後不要輕易去改了，由於換域名成本挺高的（我猜如今就算給淘寶一千萬，它也不會換另成一個域名吧）。因此，最好不要去用免費的域名，由於指不定啥時候就不讓你用了。你應該相信這麼一個觀點：天下沒有免費的午飯。拓展一下就是，掏錢買服務，內心踏實。

接下來你可能會但願將本身的站點或者博客掛在本身選中的域名下，這其實很簡單，只須要找到一個提供域名解析的服務商，而後填寫相應的域名解析記錄。大多時候，你註冊域名的服務商都會免費提供域名解析服務。

現實中，大部分人可能會擁有我的博客，之前咱們都是依賴一個博客平臺（如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的命令。

dig, nslookup

dig(Domain Information Groper), 是 UNIX/BSD 系統自帶的 DNS 診斷工具，使用十分靈活、方便。

查詢 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，由於人家還有不少其餘手段。

相關閱讀

DNS cache poisoning
DNS Spoofing vs DNS Cache Poisoning
Reset the DNS cache in OS X
人爲網絡故障
DNS欺騙原理及工做工程分析
DNS污染與劫持之我的小見