通解DNS（下）
??? 當我為繼續寫《通解DNS（下）》的時候，我才發現，我遇到了一些難題，在解決這些問題的時候，我才理解到了DNS與之關聯的技術還是比較復雜的 ?-丁胖胖
六、DNS中特殊的@與FQDN
在DNS設置中，@符號是一個比較特殊的符號，它用來代表ZONE，所以在如z00w00.local這樣的ZONE文件中，所以在SOA中有一個“responsible mail addr”配置的地方，你不會找到@符號，但那確實是一個E-MAIL地址（圖6.1）
（圖6.1）
FQDN-Fully Qualified Domain Name 中文譯名為“完全合格域名”（微軟官方是如此稱呼）但也有的會翻譯為“完全限定域名”（賽門鐵克的官方） 我這里不是閑的蛋疼來咬文嚼字說中文譯名的，而是要說，DOMAIN中的FQDN中是這樣的
以www.51CTO.com.?為例（圖6.2）
（圖6.2）
注意com后面的“.”才是我要闡述的關鍵，windows dns中是這樣的（我比較懶，于是就COPY來岳雷老師的一副圖了（圖6.3）
（圖6.3）
對于普通用戶來說，那個“."似乎無關緊要，但是對于技術人員來說，那就必須要搞明白了。如果沒有那個“."就不是真正的FQDN
很多詐騙的網站其實就是利用這點制造了二級域名，如:www.51cto.com?我變成了www.51cto.com.z00w00.
真是的詐騙網站類似這樣的：www.qq.q1q.com.
七、A記錄和PTR記錄
? ?我并不想闡述A記錄-正向主機解析記錄，因為A記錄相對用的較多，就是一個域名轉換成IP，其實很多用戶都知道在DNS的客戶端中設置HOSTS文件設置而無須DNS解析（圖7.1）
（圖7.1）
上圖中的內容之所以變得如此怪異，是因為我使用了文本編輯器設置了格式（....代表空格，CR,LF代表結束和換行符）
為了照顧新手朋友，我重新換了一副記事本打開的HOSTS文件，圖7.2
（圖7.2）
我也不想闡述PTR記錄-因為反向IP解析記錄，因為PTR的用途確實較少，除了電子郵件用來反向解析一個收發郵件服務器的域名外， 一個容易理解PTR的實踐是當你使用NSLOOKUP交換機查詢時，會首先進行反向解析LDNS的FQDN，如下7.3
（圖7.3）
如果是內部的DNS（關于內部DNS請見前文描述）因為沒有創建反向解析區域-PTR記錄，NSLOOKUP的時候就會出現(UN KNOW-未知狀態)
我個人認為，在這里反向解析LDNS會首先檢查其可用狀態，如果出現UN KNOW，（特別是不是內部DNS）你就要小心了，DNS很可能設置錯了，如果有問題了，下面是我自己構造的一個錯誤的DNS服務器地址，圖7.4
（圖7.4）
?
在確保像上圖中DNS服務器地址沒錯的情況下（我故意輸出為8.8.8.9），很可能就是DNS服務器掛了。
注：我發現很多人都喜歡用PING工具來測試DNS服務器，我強烈不建議用這種方式，理由有如下：
1、PING在連接的時候首先會像WEB的客戶端程序如瀏覽器先檢查HOSTS文件然后檢查DNS客戶端的緩存
（WINDOWS下利用 ipconfig /displaydns查詢）如果你已經瀏覽器了www.51cto.com?并且再次ping?www.51cto.com?只要WEB服務器沒掛，肯定會正常返回包，但這并不意味著DNS可用，如果你第一次訪問如www.360dns.com這樣網站的時候很可能就無法訪問。
2、并不是所有的DNS都允許ICMP回傳，就如同很多企業網站為是禁PING的，禁PING的理由無法是為了安全。如
北京聯通的202.106 DNS服務器
八、CNAME-別名記錄
? ? ?我想著單獨談一下CNAME別名記錄，原因是這個別名記錄也把我搞暈了一下。
首先我們先做一個有趣的實驗，當你ping?www.baidu.com的時候，不知道結果是不是會和我出現一樣的結果呢，見圖8.1
（圖8.1）
亮點我已經用紅框標出來了，怎么ping?www.baidu.com的時候變成了www.a.shifen.com?了呢？
為了做對比，我將ping?www.51cto.com?做了對比，如下圖8.2
（圖8.2）
很明顯，雖然PING 出現超時，但是返回結果并沒有變化
不知道有沒有人會認為是域名劫持呢？說實話，這個念頭我也閃過一下，但是還是通過強大的搜索找了原因
為了不影響篇幅，簡單說一下：原來shifen.com 這個域名最早就是百度起家的時候用的，就是baidu的競價排名系統，名字就叫十分系統 ,據說因為最早的時候每一下的點擊率可以賺取10分錢。有興趣的可以繼續挖掘一下。
其實我并關心這個，我所關心的是：www.baidu.com和www.a.shifen.com?肯定有一個是A記錄，有一個是CNAME記錄了。那么到底誰是誰的別名呢？我查了一下網上說的，網上有一個問答系統和一篇博文都說www.baidu.com是A記錄，www.a.shifen.com?是CNAME別名記錄 但是我用NSLOOKUP看了一下，確得到完全不同的答案 圖8.3
（圖8.3）
即使你不懂計算機，如果稍微知道點英文就應該明白Aliases的意思吧？那我們在nslookup一下www.a.shifen.com?吧，結果如下圖8.4
（圖8.4）
看到沒，并沒有出現ALIASES的字樣，看來網上和那篇文章的解釋是錯誤的。為了進一步佐證我們的判斷，使用DIG工具再看一下，圖8.5
（圖8.5）
?
根據RR記錄格式CNAME記錄格式如下：
主機別名（WWW.BAIDU.COM) ?IN CNAME 實際代表這個主機別名的主機名字(WWW.A.SHIFEN.COM）
由此我們得出前者是后者的別名
由此我們得出結論：
1、當解析一個主機地址的時候，如WWW.BAIDU.COM?會查詢是否A記錄，如果是A記錄，那么解析出其IP地址
2、如果記錄WWW.BAIDU.COM是一個CNAME記錄，那么先找到其A記錄，然后根據A記錄解析出其IP地址。
?
有人可能會說：“胖胖，你搞了半天就是要搞明白WWW.BAIDU.COM究竟是A記錄還是CNAME記錄呀，這個意義大嗎？”
這里我要解釋說：其一，首先要搞清楚CNAME記錄是如果被解析的；其二，CNAME記錄還有其他的大作用，先在這里賣一個關子，我們后面會說到。
九、DNS輪詢
? ? 之前我們說過，DNS作為網絡的基礎架構，主要是為了解析域名為IP地址，很多應用程序都需要這個過程，拿用途最多的WEB進行繼續闡述。大家知道，為了保障WEB的高可用性和業務連續性，WEB服務器不止一臺，當有多個WEB服務器時，DNS如何解析呢？見下圖9.1
?
（圖9.1）
當用戶訪問www.z00w00.com的時候，dns服務器ns.z00w00.com會去解析其A記錄，結果發現有3條A記錄，這個時候按照默認不做任何策略的時候，會按照順序提供A主機對應的IP地址，當第二個用戶訪問的時候就會返回第二臺主機的IP地址，如下9.2
（圖9.2）
這就是DNS輪詢，不過需要注意一點的是，如果用戶1與用戶2同時設置了同一臺LDNS（本地的DNS）因為緩存的關系，可能會得到同一個IP地址。DNS雖然支撐輪詢訪問WEB，但是也有一些缺點，最大的缺點之一就是當其中一臺WEB宕機或其它原因無法訪問的時候，DNS并不能判斷是否宕機，依然會解析IP地址給用戶，當然用戶就無法正常訪問了。后來人們想了一個辦法，就是在WEB前端放一個負載均衡設備，可以判斷WEB集群的健康狀態，如下圖9.3
（圖9.3）
?
負載均衡并不是我們講述的重點，所以只是簡單提一句。
十、 主/輔DNS模式
單點風險，是很多IT公司最不愿意承受的，所以絕大部分的IT公司并不會僅僅允許1臺DNS進行權威解析，如果一臺DNS因為故障而無法解析，那么你所有需要訪問的用戶都無法正常訪問，不要告訴你的用戶用IP訪問呦。所以DNS是允許多臺進行解析的，不過DNS服務器僅允許一臺DNS進行寫操作，而其它DNS只允許讀操作。這樣方式有點像MYSQL數據庫的主/從模式，可寫操作的被稱為主要區域DNS,剩下可讀操作的被稱為輔助區域DNS。如下圖10.1
?
（圖10.1）
ns1.z00w00.com 為主區域，ns2.z00w00.com為輔助區域 由于輔助區域服務器不能寫操作，所以ns2.z00w00.com的區域記錄（基于z00w00.com的正向或反向）通過區域文件復制得到，什么時候復制，依據什么復制，是通過SOA記錄完成的，下面我們以51cto.com為例，看一下SOA記錄，如下圖10.2
（圖10.2）
?
primary name server 代表主區域服務器是誰
responsible mail addr 代表管理員E-MAIL
serial 序號代表數據庫文件新舊，如果輔助區域發現其值比當前值小，就會進行區域復制
refresh 是更新頻率 3600秒輔助區域向主區域進行更新
retry 失敗重新嘗試時間 如果輔助區域無法連接主區域，那么連接的時間就是這個值
expire 失效時間
dafault TTL 緩存時間
十一、CDN與DNS
當很多企業正在為TCP連接數、并發過高、DDOS***、用戶抱怨訪問較慢發愁而思考如何更改架構、增加帶寬、買防DDOS設備的時候，一些ICP已經提供了一些解決方案，那就是CDN。CDN技術還是很復雜的，并且我不打算在這里闡述CDN。只是說一下CDN與DNS的關系。
CDN是內容分發系統，可以通過CDN技術將你自己的源站內容推送的CDN服務器上，而CDN分步在全國各電信、聯通、移動等機房；用戶可以就近訪問自己需要的內容，從而也隱藏了真實的WEB服務器，一舉多得。還記得我們之前說到的CNAME記錄嗎？CNAME記錄就是和CDN有密切關系的。如圖11.1
（圖11.1）
z00w00.com的權威解析服務器ns1.z00w00.com 將www.z00w00.com改該cdn.www.z00w00.com的CNAME記錄
??? 當用戶要求解析其IP地址時，首先訪問到權威服務器，但是權威服務器發現這是一個別名，然后將別名記錄提交到設置為A記錄的CDN的DNS服務器，CDN的DNS服務器會根據用戶本地DNS的IP地址判斷選擇里用戶最近的一個CDN節點服務器并提供IP地址，然后用戶訪問這個CDN節點服務器。
當然這只是最簡單的過程，CDN比這要復雜的多，實際上還有CDN節點服務器如果沒有獲取到用戶所需的資源，還要回源處理（從原始WEB服務器模擬用戶提供申請，取得數據）另外CDN如何判斷用戶所在區域，并根據其節點調度提供IP地址。因為我們不是在解釋CDN，此復雜細節略過。
?? 其實，我還想寫的更多，如DNSSEC，DNS劫持等；但在《通解DNS（上）》發布后并沒有得到大家的更多關注，所以暫時放棄了這些內容。寫原創技術文章，確實很辛苦。除了需要構思內容，有些東西知識點還需要認真思考，盡量不要出錯，畢竟我本人不是大神。當然我也可以寫一篇DNS部署的文章，若干行命令，按照部署的流程走一遍，甚至負不負責的不反復推敲排除特殊環境變量。但這不是我的風格，我希望有網友能通過這上下兩篇文章，得到一些啟示，這就夠了。當然，如果在描述的有不準確，或者在知識點上就有錯誤，也希望大神給予指出。
總結
- 上一篇： IEnumerator,IEnumera
- 下一篇： jps