dig命令

• nslookup:query Internet name servers interactively;
  dig:Domain Information Groper
• 【我想用google-DNS來查baidu.com的A記錄】dig @8.8.8.8 www.baidu.com A
  可以看出 dig的基本的命令格式是：
  dig @dnsserver name querytype
  如果你設置的dnsserver是一個域名，那么dig會首先通過默認的上連DNS服務器去查詢對應的IP地址，
  然后再以設置的dnsserver為上連DNS服務器。
  如果你沒有設置@dnsserver，那么dig就會依次使用/etc/resolv.conf里的地址作為上連DNS服務器。
  querytype可以設置A/AAAA/PTR/MX/ANY等值，默認是查詢A記錄。
• 常用選項

1. -c選項，可以設置協議類型（class），包括IN(默認)、CH和HS。
2. -f選項，dig支持從一個文件里讀取內容進行批量查詢，這個非常體貼和方便。文件的內容要求一行為一個查詢請求。
3. -4和-6兩個選項，用于設置僅適用哪一種作為查詢包傳輸協議，分別對應著IPv4和IPv6。
4. -t選項，用來設置查詢類型，默認情況下是A，也可以設置MX等類型
5. -q選項，其實它本身是一個多余的選項，但是它在復雜的dig命令中又是那么的有用。
6. -q選項可以顯式設置你要查詢的域名，這樣可以避免和其他眾多的參數、選項相混淆，提高了命令的可讀性
7. -x選項，是逆向查詢選項。可以查詢IP地址到域名的映射關系。

• 【dig特有的查詢選項（query option）】
  和剛才的選項不同，dig還有一批所謂的“查詢選項”，這批選項的使用與否，
  會影響到dig的查詢方式或輸出的結果信息，因此對于這批選項，
  dig要求顯式的在其前面統一的加上一個“+”（加號），這樣dig識別起來會更方便，
  同時命令的可讀性也會更強。

1. 【TCP代替UDP】
   眾所周知，DNS查詢過程中的交互是采用UDP的。如果你希望采用TCP方式
2. 【跟蹤dig全過程】
   dig非常著名的一個查詢選項就是+trace，當使用這個查詢選項后，
   dig會從根域查詢一直跟蹤直到查詢到最終結果，并將整個過程信息輸出出來。

Q：請教大神 Linux（Unix）的設計思想 ： 程序應該小而專一，程序應該盡量的小，
且只專注于一件事上，不要開發那些看起來有用但是90%的情況都用不到的特性，
所以dig也是一個程序吧；如果以最小化安裝很多命令都不知道這條命令屬于哪個
程序只能用google搜索么？？？
A：不用的，舉例redhat , centos , fedora 下用yum provides 命令名，
就可以查找該命令屬于哪個軟件包了。非常方便。
Q：dig +trace 這句執行的結果中，看到
roclinux.cn. 21600 IN NS ns11.edong.com.
roclinux.cn. 21600 IN NS ns12.edong.com.

roclinux.cn. 3600 IN NS ns12.edong.com.
roclinux.cn. 3600 IN NS ns11.edong.com.

這里DNS的緩存時間，一個是21600，一個是3600，到底以那個為準呢

上述摘自：《dig挖出DNS的秘密》-linux命令五分鐘系列之三十四

關于百度DNS的解析過程

[root@zichen star]# nslookup www.baidu.com
Server: 211.140.13.188
Address: 211.140.13.188#53

Non-authoritative answer:
www.baidu.com canonical name = www.a.shifen.com.
Name: www.a.shifen.com
Address: 220.181.112.76
Name: www.a.shifen.com
Address: 220.181.111.111
百度有個cname=www.a.shifen.com.的別名，這所怎么一個過程呢？用dig工具跟蹤一下。
[root@zichen star]# dig +trace www.baidu.com

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.2.rc1.fc16 <<>> +trace www.baidu.com
;; global options: +cmd
. 167778 IN NS b.root-servers.net.
. 167778 IN NS d.root-servers.net.
. 167778 IN NS f.root-servers.net.
. 167778 IN NS m.root-servers.net.
. 167778 IN NS e.root-servers.net.
. 167778 IN NS h.root-servers.net.
. 167778 IN NS l.root-servers.net.
. 167778 IN NS g.root-servers.net.
. 167778 IN NS i.root-servers.net.
. 167778 IN NS k.root-servers.net.
. 167778 IN NS c.root-servers.net.
. 167778 IN NS a.root-servers.net.
. 167778 IN NS j.root-servers.net.
;; Received 228 bytes from 211.140.13.188#53(211.140.13.188) in 1841 ms--------（1）

com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
;; Received 503 bytes from 198.41.0.4#53(198.41.0.4) in 1884 ms-------------------------（2）

baidu.com. 172800 IN NS dns.baidu.com.
baidu.com. 172800 IN NS ns2.baidu.com.
baidu.com. 172800 IN NS ns3.baidu.com.
baidu.com. 172800 IN NS ns4.baidu.com.
;; Received 167 bytes from 192.31.80.30#53(192.31.80.30) in 305 ms-------------------（3）

www.baidu.com. 1200 IN CNAME www.a.shifen.com.
a.shifen.com. 86444 IN NS ns4.a.shifen.com.
a.shifen.com. 86444 IN NS ns7.a.shifen.com.
a.shifen.com. 86444 IN NS ns9.a.shifen.com.
a.shifen.com. 86444 IN NS ns5.a.shifen.com.
;; Received 194 bytes from 202.108.22.220#53(202.108.22.220) in 68 ms-------------（4）
DIG工具會在本地計算機做迭代，然后記錄查詢的過程。
第一步是我這臺PC的ISPDNS獲取到13個根服務器的13個IP和主機名【b-j】.root-servers.net。
第二步是向其中的一臺根域服務器198.41.0.4發送www.baidu.com的請求，他返回來com.頂級域的服務器的IP（未顯示）和名稱。
第三步是向com.域的一臺服務器192.31.80.30請求www.baidu.com，他返回來baidu.com域發服務器IP（未顯示）和名稱.
第四步，向百度的頂級域名服務器dns.baidu.com.請求www.baidu.com，他發現這個www有別名叫www.a.shifen.com。
按照一般邏輯，當dns請求到別名時，查詢都會終止，而所重新發起查詢別名的請求，所以此處應該返回的是www.a.shifen.com.但是為什么返回的是a.shifen.com這個NS呢？
此處我們可以用：
[root@zichen star]# dig +trace shifen.com
shifen.com. 172800 IN NS dns.baidu.com.
shifen.com. 172800 IN NS ns2.baidu.com.
shifen.com. 172800 IN NS ns3.baidu.com.
shifen.com. 172800 IN NS ns4.baidu.com.
;; Received 170 bytes from 192.26.92.30#53(192.26.92.30) in 325 ms
發現shifen.com的頂級域名服務器和baidu.com的域名服務器是同一臺！
當 我拿到www.baidu.com的別名www.a.shifen.com的時候，本來要重新到com域查找shifen.com的NS，又因為，兩個域 在同一臺NS上，所以直接向本機發起了shifen.com域發現請求的www.a.shifen.com是屬于a.shifen.com這個域的，于是 就把a.shifen.com的這個NS和IP返回，讓我到a.shifen.com這個域的域名服務器上查詢www.a.shifen.com。
于是
shifen.com. 7200 IN A 202.108.250.218
shifen.com. 86400 IN NS ns3.baidu.com.
shifen.com. 86400 IN NS ns1.baidu.com.
shifen.com. 86400 IN NS ns2.baidu.com.
shifen.com. 86400 IN NS ns4.baidu.com.
;; Received 186 bytes from 220.181.37.10#53(220.181.37.10) in 61 ms
拿到一條A記錄，最終也就是www.baidu.com的IP地址了。

域名解析中A記錄、CNAME、MX記錄、NS記錄的區別和聯系

1.A記錄
又稱IP指向，用戶可以在此設置子域名并指向到自己的目標主機地址上，
從而實現通過域名找到服務器。
說明：·指向的目標主機地址類型只能使用IP地址；

2. CNAME
   通常稱別名指向。可以為一個主機設置別名。比如設置test.mydomain.com，
   用來指向一個主機www.rddns.com那么以后就可以用test.mydomain.com來
   代替訪問www.rddns.com了。
   說明：CNAME的目標主機地址只能使用主機名，不能使用IP地址；
   ·主機名前不能有任何其他前綴，如：http://等是不被允許的；·A記錄優先于CNAME記錄。即如果一個主機地址同時存在A記錄和CNAME記錄，則CNAME記錄不生效。
   3.MX記錄
   郵件交換記錄。用于將以該域名為結尾的電子郵件指向對應的郵件服務器以進行處理。如：用戶所用的郵件是以域名mydomain.com為結尾的，則需要在管理界面中添加該域名的MX記錄來處理所有以@mydomain.com結尾的郵件。
   說明：MX記錄可以使用主機名或IP地址；·MX記錄可以通過設置優先級實現主輔服務器設置，“優先級”中的數字越小表示級別越高。也可以使用相同優先級達到負載均衡的目的；·如果在“主機名”中填入子域名則此MX記錄只對該子域名生效。
   4.NS記錄
   解析服務器記錄。用來表明由哪臺服務器對該域名進行解析。這里的NS記錄只對子域名生效。
   例如用戶希望由12.34.56.78這臺服務器解析news.mydomain.com，則需要設置news.mydomain.com的NS記錄。
   說明：·“優先級”中的數字越小表示級別越高；·“IP地址/主機名”中既可以填寫IP地址，也可以填寫像ns.mydomain.com這樣的主機地址，但必須保證該主機地址有效。
   如，將news.mydomain.com的NS記錄指向到ns.mydomain.com，在設置NS記錄的同時還需要設置ns.mydomain.com的指向，
   否則NS記錄將無法正常解析；·NS記錄優先于A記錄。即，如果一個主機地址同時存在NS記錄和A記錄，則A記錄不生效。這里的NS記錄只對子域名生效。

1、什么是負載均衡服務器？
負載均衡(Server Load Balancing，SLB)是指在一系列資源上面智能地分布網絡負載。負載均衡可以減少網絡擁塞，提高整體網絡性能，提高自愈性，并確保企業關鍵性應用的可用性。當相同子域有多個目標地址，或域名的MX記錄有多個目標地址且優先級相同時，表示輪循，可以達到負載均衡的目的，但需要虛擬主機和郵箱服務商支持。:
2、什么是TTL？
TTL值TTL值全稱是“生存時間（Time To Live)”，簡單的說它表示DNS記錄在DNS服務器上緩存時間。這個緩存時間太長和太短都不好，如果緩存時間太長，一旦域名被解析到的IP有變化，會導致被客戶端緩存的域名無法解析到變化后的IP地址，以致該域名不能正常解析，這段時間內有可能會有一部分用戶無法訪問網站。如果緩存時間太短，會導致用戶每次訪問網站都要重新解析一次域名。
另外可以參考：
CNAME
一個域名有了A 記錄解析就不能cname了?