配置好DNS服務器，添加了相應的記錄之後，只要IP地址保持不變，一般情況下我們就不再需要去維護DNS的數據文件了。不過在確認域名解釋正常之前我們最好是測試一下所有的配置是否正常。許多人會簡單地使用ping命令檢查一下就算了。不過Ping指令只是一個檢查網絡聯通情況的命令，雖然在輸入的參數是域名的情況下會通過DNS進行查詢，但是它只能查詢A類型和CNAME類型的記錄，而且只會告訴你域名是否存在，其他的信息一概欠奉。所以如果你需要對DNS的故障進行排錯就必須熟練另一個更強大的工具nslookup。這個命令可以指定查詢的類型，可以查到DNS記錄的生存時間還可以指定使用那個DNS服務器進行解釋。 查詢IP地址 nslookup最簡單的用法就是查詢域名對應的IP地址，包括A記錄和CNAME記錄，如果查到的是CNAME記錄還會返回別名記錄的設置情況。其用法是： nslookup域名 以下是A記錄的返回情況。
nslookup命令會採用先反向解釋獲得使用的DNS服務器的名稱，由於我這裡使用的是一個內部的DNS服務器所以沒有正確的反向記錄，導致結果的前面幾行出錯。大家可以不必理會。重點看的是最後的兩行這裡看到的是www.oray.net的IP地址是61.145.112.212。注意即使www.oray.net的主機沒有在線同樣能夠返回結果。 如果目標域名是一個別名記錄(CNAME)，nslookup就開始顯示出和ping命令不同的地方了，請看查詢CNAME記錄的結果。由於CNAME和A記錄最後都是活的IP地址，所以一般情況下兩者是等同看待的，命令的格式相同。
注意這次nslookup返回了三行信息，前兩行顯示這是一個CNAME記錄，對應的域名和IP地址。最後顯示的就是目標域名， 並註明Alias（別名）。 如果域名不存在會怎樣呢？ 看得懂最後以行的 英文嗎，不懂沒關係記住形狀就可以了。如果一個指定類型的域名不存在對應的記錄同樣也是這種結果。 查詢其他類型的域名 前面兩個命令我們沒有加任何參數，所以默認情況下nslookup查詢的是A類型的記錄。如果我們配置了其他類型的記錄希望看到解釋是否正常。這時候ping就無能為力了。比如我們配置了MX記錄，但是郵件服務器只能發信不能收信，到底是域名解釋問題還是其他的問題Ping命令的檢查只能讓你誤入歧途。nslookup這時候可以模擬你的其他遇見服務器進行域名解釋的情況。我們需要在nslookup上加上適當的參數。指定查詢記錄類型的指令格式如下： nslookup –qt=類型目標域名 註意qt必須小寫。 類型可以是一下字符，不區分大小寫： A地址記錄(Ipv4) AAAA地址記錄（Ipv6） AFSDB Andrew文件系統數據庫服務器記錄（不懂） ATMA ATM地址記錄（不是自動提款機） CNAME別名記錄 HINFO硬件配置記錄，包括CPU、操作系統信息 ISDN域名對應的ISDN號碼 MB存放指定郵箱的服務器 MG郵件組記錄 MINFO郵件組和郵箱的信息記錄 MR改名的郵箱記錄 MX郵件服務器記錄 NS名字服務器記錄 PTR反向記錄（從IP地址解釋域名） RP負責人記錄 RT路由穿透記錄（不懂） SRV TCP服務器信息記錄（將有大用處） TXT域名對應的文本信息 X25域名對應的X.25地址記錄看看oray. net的郵件服務器記錄吧。
看看，nslookup把服務器的名稱和地址都給出來了，注意preference就是前面所說的優先級，該數值越小則優先級越高。 我再看看名字服務器記錄是怎麼樣的。
看起來和MX記錄的格式差不多，一般情況下服務器會同時返回對應的地址。不過也有不返回的情況。 在這裡我希望大家注意一行顯示“Non-suthoritativeanswer:”，這一行在前面的例子中都沒有顯示過。它的出現代表這個結果是從服務器的緩存中得到的。所以提醒你這不是一個授權的答案。前面我們進行的幾次查詢過程中192.168.1.104這台機器就採用了我們第一篇文章中描述的過程查詢了oray.net的域名。在這個過程中不但緩存了www.oray.net、test.oray.net以及oray.net的MX記錄等最終結果。也包括獲取的名字服務器等中間結果。隱含的查詢了oray.net的NS記錄。後面我們還會介紹這個過程。 指定使用的名字服務器 在默認情況下nslookup使用的是我們在本機TCP/IP配置中的DNS服務器進行查詢，但有時候我們需要指定一個特定的服務器進行查詢試驗。這時候我們不需要更改本機的TCP/IP配置，只要在命令後面加上指定的服務器IP或者域名就可以了。這個參數在我們對一台指定服務器排錯是非常必要的，另外我們可以通過指定服務器直接查詢授權服務器的結果避免其他服務器緩存的結果。命令格式如下： nslookup [-qt=類型]目標域名指定的DNS服務器IP或域名 我們可看看以下的命令結果：
這個命令直接從頂級域名服務器查詢oray.net的NS記錄。所有的二級域名的NS記錄都存放在頂級域名服務器中，這是最權威的解釋。注意這次沒有非授權結果的提示。對於二級域名的NS記錄查詢來說這肯定是授權結果。頂級域名服務器的名稱是a到j.gtld-servers.net共十台服務器。(gtld是Global Top Level Domain的縮寫)。當我們修改域名的NS記錄的時候可以通過上述查詢知道修改的結果是不是已經在頂級域名服務器上生效。不過即使已經生效也可能不能正常解釋，注意我在上一篇文章中提到的緩存時間的問題。 那麼到底緩存多久呢？ 檢查域名的緩存時間 檢查域名的緩存時間需要我們使用一個新的參數：-d 格式如下： nslookup –d [其他的參數]目標域名[指定的服務器地址] 請看範例
我們忽略其他的看看Got answer後面幾行，包括了一個ttl數值。這個數值就是域名記錄的生存時間。 這種查詢將整個DNS數據包的所有部分都揭示出來，大家可以看到DNS實際上並不是想像中那麼簡單的東西。具體的各部分解釋大家可以去看看相關的標准文檔。需要提醒大家的是一定要找到ANSWER:的內容，其他的東西都不是描述最終的結果。上面就不止一個地方又TTL數值。
域名解釋過程的模擬 我們現在來模擬一下一台DNS服務器接到一個不是自己管理的域的域名解釋過程。回憶一下第一篇文章的過程： 首先我們會詢問根服務器，然後根服務器會讓我們去找對應的頂級服務器。如果查詢的是oray.net，就會要求我們去找net的服務器。 看看下面的範例： 這裡我們讓21cn.com的服務器解釋www.oicp.net的域名，很顯然這台服務器不用有這個域，需要詢問根服務器。一般情況下DNS服務器會幫我們完成全部的過程。這種解釋方式我們稱之為遞歸解析，為了讓大家看到這個過程我家了一個參數讓21cn.com的服務器不要這樣做。這個參數是-norecurse。這樣理論上21cn.com會讓我們去問根服務器，不過由於它已經緩存了頂級服務器的記錄，所以直接返回了管理net的頂級服務器記錄。實際上大部分的查詢都不需要從根服務器開始。大家看到了所有的頂級域名服務器的地址都被返回。 我們隨便選擇一個在進行查詢。
這次頂級服務器就返回了oicp.net的服務器地址記錄的。然後我們就向這些記錄之一進行查詢，一定能夠得到答案。可能是一個地址、一個CNAME記錄或者告訴你不存在。 nslookup的命令就介紹到這裡，其實nslookup還有許多其他參數。不過常用的就這麼幾個，另外如果大家不喜歡命令行方式的話。還有幾個圖形界面的nslookup功能的工具。不過大家還是需要了解域名解釋都有些什麼才能夠正確使用這些工具。
| 
發表於 2015-8-3 10:16:04
微信
收藏