| dns服務器為響應 SIP中的DNS |
| 1.SIP中的DNS過程 1.1.SIP消息涉及的DNS過程 SIP消息涉及到的DNS過程主要包括兩個方面：一方面是如何發(fā)送請求消息，發(fā)送方需要通過DNS過程得到傳輸層協(xié)議類型，下一跳的IP地址和端口等信息；另一方面是如何返回響應消息，需要決定上一跳的地址和端口，尤其是上一跳網(wǎng)元發(fā)生故障時，如何返回響應消息。 1.2.如何發(fā)送SIP請求消息 定義一個名為TARGET的變量，如果URI定義了maddr參數(shù)，TARGET取值于該參數(shù)，否則取值于URI的hostport部分。 第一步是決定使用哪種傳輸層協(xié)議發(fā)送請求消息，包括下列步驟： 1、如果URI定義了傳輸層協(xié)議，則使用該傳輸層協(xié)議，否則轉步驟2； 2、如果TARGET包含IP地址，那么對于SIP URI使用UDP協(xié)議，SIPS URI使用TCP協(xié)議，否則轉步驟3； 3、如果TARGET包含了端口，那么對于SIP URI使用UDP協(xié)議，SIPS URI使用TCP協(xié)議，否則轉步驟4； 4、使用TARGET中的域名進行NAPTR查詢，如果NAPTR返回的記錄為空轉步驟5，否則查看返回的記錄，記錄中的service域一般取值為”XXX+D2U”, X+D2T”, XX+D2S”, 其中XXX表示服務名稱，可以是”SIP”或”SIPS”，D2U表示使用UDP協(xié)議，D2T表示使用TCP協(xié)議，D2S表示使用SCTP協(xié)議； 5、根據(jù)RFC3261的傳輸準則判斷是否需要使用某種強制協(xié)議，如果需要使用強制協(xié)議，則使用該強制協(xié)議，否則對于SIP URI使用UDP協(xié)議，SIPS URI使用TCP協(xié)議； 第二步是決定目標的IP地址和端口，包括下列步驟： 1、如果TARGET包含了IP地址和端口，則使用該地址和端口，否則轉步驟2； 2、如果TARGET包含了IP地址，則使用對應傳輸協(xié)議的默認端口，否則轉步驟3； 3、如果TARGET不包含IP地址，但包含了端口，則使用A或AAAA查詢，獲得域名對應的IP地址，否則轉步驟4； 4、如果在第一大步的第四小步?jīng)]有進行NAPTR查詢，轉步驟5，則使用該查詢返回的記錄中的replacement域中域名進行SRV查詢，然后轉步驟6； 5、在TARGET包含的域名加上_XXX._YYY.前綴（其中XXX表示服務類型，可以取值sip或sips，YYY表示傳輸類型，可以取值udp, tcp或sctp等），然后使用加了前綴的域名進行SRV查詢，并轉步驟6； 6、如果SRV返回了記錄，記錄會包含端口和最新域名，然后對最新域名進行A或AAAA查詢得到IP地址，如果SRV沒有返回記錄轉步驟7； 7、直接對TARGET中的域名使用A或AAAA查詢得到IP地址，端口則根據(jù)傳輸協(xié)議使用默認端口； 一個發(fā)送請求消息例子，下一跳消息的SIP URI為：sip:example.com，如下是向該網(wǎng)元發(fā)送SIP請求消息的過程： 首先對域名example.com進行NAPTR查詢，查詢的結果為： order pref flags serviceregexp replacement IN NAPTR 50 50 "s" "SIPS+D2T""" _sips._tcp.example.com. IN NAPTR 90 50 "s" "SIP+D2T""" _sip._tcp.example.com IN NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.example.com. NAPTR返回了多條記錄，根據(jù)order和pref的取值選擇了第一條記錄，flag為s表示下一步進行SRV查詢，service為SIPS+D2T表示使用TCP作為傳輸層協(xié)議，同時使用sips方式傳輸消息，replacement表示使用_sips._tcp.example.com進行獲取目標網(wǎng)元的地址信息。 然后對域名_sips._tcp.example.com進行SRV查詢，查詢的結果為： Priority WeightPortTarget IN SRV 0 1 5060 server1.example.com IN SRV0 2 5060 server2.example.com SRV返回了兩條記錄，根據(jù)priority和weight選擇其中一條，假設選擇的是第一條，那么意味這目標端口為5060，Target包含了目標網(wǎng)元的域名server1.example.com。 最后對域名server1.example.com進行A或AAAA查詢，得到目標網(wǎng)元的IP地址： IN AAAA 5F05:2000:80AD:5800:0058:0800:2023:1D71 1.3.如何發(fā)送響應消息 一般情況下，對于可靠的傳輸層協(xié)議，響應消息在請求消息所在的連接上返回，對于非可靠的傳輸層協(xié)議，響應消息通過發(fā)送請求消息的源IP地址以及Via中的端口返回。但是如果UAC發(fā)送完請求消息后就發(fā)生了異常，UAS應當如何返回響應消息？具體包括如下過程： 1、如果Top Via包含了IP地址和端口，向該地址和端口返回響應消息； 2、如果Top Via包含了IP地址，沒有包含端口，使用傳輸層協(xié)議的默認端口返回響應消息； 3、如果Top Via包含了域名和端口，使用A或AAAA查詢，獲得IP地址列表，然后試圖向列表中的每一個IP地址發(fā)送響應消息，只到有一個發(fā)送成功為止； 4、如果Top Via包含了域名，沒有包含端口，使用SRV查詢，獲得端口和新域名，對新域名的處理和步驟3類似； 2.IMS中的DNS過程 IMS中的DNS過程也可以分為兩類：一類是IMS中的SIP實體基于SIP URI的DNS查詢，例如主叫側S-CSCF需要獲得被叫網(wǎng)絡中的I-CSCF，其過程采用SIP定義的DNS過程；另一類是基于TEL URI的DNS查詢。 2.1.基于SIP URI的DNS查詢 基于SIP URI的查詢采用SIP定義的DNS過程(RFC3261, RFC3263)，一般為NAPTR查詢，SRV查詢，最后是A或AAAA查詢。整個過程涉及多次DNS查詢，可能造成會話建立時間過長，為此有兩種方法可以解決這個問題。第一種方法，DNS服務器猜測用戶可能會進行的DNS查詢，然后返回所有這些可能的查詢，例如用戶進行了NAPTR查詢后，DNS服務器不僅返回NAPTR查詢的結果，還會返回相關的SRV以及AAAA的記錄。第二種方法是用戶將查詢結果緩存一段時間，在這段時間以內(nèi)，如果再次查詢該域名，可以直接使用相關記錄。 2.2.基于TEL URI的DNS查詢 IMS中的tel號碼有兩種情況：一種情況是tel號碼對應于IMS網(wǎng)絡中的一個用戶；另外一種情況是tel號碼對應于非IMS網(wǎng)絡中的用戶，如PSTN用戶、GSM用戶等。后一種情況比較簡單，只需要將對應的SIP消息轉發(fā)給BGCF來處理即可。而對于前一種情況則需要將TEL URI轉換成SIP URI，因為只有SIP URI才可以在IMS網(wǎng)絡中路由。 RFC2916講述了將TEL URI轉換為SIP URI的方法，即通過NAPTR查詢來獲得這種轉換，具體步驟為： 1、將TEL號碼按照E.164格式表達成全號碼（包括國家碼）； 2、去除首部”+”之外的所有其他非數(shù)字字符； 3、去除首部的”+”； 4、在數(shù)字字符之間加上”.”號； 5、將數(shù)字字符串順序反轉； 6、在字符串后面加上后綴”e164.arpa”； 7、將字符串作為域名，進行NAPTR查詢； 8、根據(jù)查詢返回的記錄得到對應SIP URI； 下面以一個例子來講述整個過程，假設號碼為+46-8-9761234，具體轉換過程為： 首先去除所有非數(shù)字字符，得到”4689761234”； 其次加上”.”號，得到”4.6.8.9.7.6.1.2.3.4”； 再次進行反轉，得到”4.3.2.1.6.7.9.8.6.4”； 再次加上后綴，得到” 4.3.2.1.6.7.9.8.6.4.e164.arpa”； 最后對域名” 4.3.2.1.6.7.9.8.6.4.e164.arpa”進行NAPTR查詢，得到如下記錄： order pref flags serviceregexp replacement IN NAPTR 100 10 "u" "sip+E2U""!^.*$!sip:info@tele2.se!". IN NAPTR 102 10 "u" "mailto+E2U" "!^.*$!mailto:info@tele2.se!" . NAPTR返回了兩條記錄，order和prefer表達記錄的使用偏好，flags為”u”，表示regexp域給出了替代規(guī)則，根據(jù)該規(guī)則和原來的域名可以得出一個滿足absoluteURI的URI(RFC2396)。Service給出記錄對應的協(xié)議和服務，”sip”表示轉換出的URI用于SIP協(xié)議，”mailto”表示轉換出的URI用于mail協(xié)議，”E2U”表示e.164 to URI服務。 本例是IMS中的TEL到SIP轉換，所有使用第一條記錄，得到最終的SIP URI，即sip:info@tele2.se。 3.DNS的基本概念 3.1.DNS的授權 網(wǎng)絡信息中心NIC負責分配頂極域和委派其他指定地區(qū)域的授權機構。一個獨立管理的DNS子樹稱為一個區(qū)域，許多二極域將他們的子域劃分為更小的區(qū)域。當一個系統(tǒng)加入到一個區(qū)域中時，該區(qū)域的DNS管理者為該新系統(tǒng)申請一個域名和一個IP地址，并將他們加入到名字服務器的數(shù)據(jù)庫中。一個名字服務器負責一個或多個區(qū)域，一個區(qū)域的管理者必須為該區(qū)域提供一個主名字服務器和至少一個輔助名字服務器。每個主名字服務器都必須知道根名字服務器的IP地址，根服務器必須知道所有二極域中每個授權名字服務器的名字和IP地址。常見的頂級域：com用于商業(yè)組織，edu用于教育機構，org用于非贏利組織，net用于計算機網(wǎng)絡組織，gov用于美國政府組織。 下面以一個例子講述DNS的查找過程，假設Web瀏覽器訪問“msdn.microsoft.com”站點，它會通過以下步驟來解析該域名的 IP 地址： 1、瀏覽器調(diào)用 DNS 客戶端（稱為解析器），并使用上次查詢緩存的信息在本地解析該查詢； 2、如果在本地無法解析查詢，客戶端就會向已知的 DNS 服務器詢問，如果該 DNS 服務器曾經(jīng)在特定的時間段內(nèi)處理過相同的域名（“msdn.microsoft.com“）請求，它就會在緩存中檢索相應的 IP 地址，并將它返回給客戶端； 3、如果該 DNS 服務器找不到相應的地址，客戶端就會向某個全局根 DNS 服務器詢問，后者返回頂級域權威 DNS 服務器的指針，在這種情況下，“com”域權威服務器的 IP 地址將返回給客戶端； 4、客戶端向“com”服務器詢問“microsoft.com”服務器的地址； 5、客戶端將原始查詢傳到“microsoft.com”服務器，因為“microsoft.com”服務器在本地維護“msdn.microsoft.com”域的權威記錄，所以它將最終結果返回給客戶端，并完成特定 IP 地址的查詢； 注意，可以將 DNS 資源記錄緩存到網(wǎng)絡上任意數(shù)量的 DNS 服務器中。第 2 步中提到的 DNS 服務器可能不包含“msdn.microsoft.com”緩存記錄。但是，它可能有“microsoft.com”的記錄，更可能有“com”域的記錄。這可省去客戶端獲得最終結果所需的一次或幾次查詢，從而加快了整個搜索過程。 3.2.DNS查詢報文中的問題部分 查詢報文由多個問題部分組成，每個問題代表一個查詢，其包括查詢名、查詢類型和查詢類。查詢名是指要查找的名字，它是一個或多個標識符的序列。每個標識符以首字節(jié)的計數(shù)值來說明隨后標識符的字節(jié)長度，每個名字以最后字節(jié)為0結束，長度為0的標識符是根標識符。計數(shù)字節(jié)的值必須為0－63，因為標識符的最大長度僅為63。該字段無需以整32為為邊界，即無需填充字節(jié)，例如gemini.tuc.noao.edu的存儲格式為6gemini3tuc4noao3edu0。查詢類型描述查詢哪個方面的問題，最常見的查詢類型是A類型（值為1），表示期望獲得查詢名的IP地址，PTR查詢（值為12）則請求獲得一個IP地址對應的域名。查詢類一般是1，指互聯(lián)網(wǎng)地址。 3.3.資源記錄RR 查詢結果通過資源記錄的方式返回，名字服務器返回的資源記錄可以是回答RR、授權RR和附加信息RR。RR記錄中的類型字段給出該記錄所包含的信息： 1、A，一個A記錄定義了一個IP地址； 2、PTR，指針記錄用于指針查詢，IP地址被看作是noao.edu域下的一個域名； 3、CNAME，表示規(guī)范名字，用來表示一個域名，而有規(guī)范名字的域名通常叫做別名，某些FTP服務器使用它向其他的系統(tǒng)提供一個易于記憶的別名； 4、HINFO，表示主機信息，包括說明主機CPU和操作系統(tǒng)的兩個字符串； 5、MX，郵件交換記錄，例如可以表達如果有郵件要發(fā)往use@foo.com，就將郵件發(fā)送到relay1.uu.net這樣的信息。 6、NS，名字服務器記錄，其說明一個域的授權名字服務器，它由域名表示。 3.4.使用UDP還是TCP DNS同時支持UDP和TCP，端口號都是53。當查詢請求的響應消息長度超過512個字節(jié)時，UDP僅返回前512個字節(jié)，這時名字解析器通常使用TCP重發(fā)原來的查詢請求。既然DNS主要使用UDP，因此好的重傳和超時機制就比較重要了。 4.DNS NAPTR資源記錄 DNS NAPTR資源記錄的功能是能夠將原來的域名映射成一個新的域名或者URI(Uniform Resource Identifier)，并通過flag域來指定這些新域名或URI在后繼操作中的使用方法。下面通過一個例子來講述NAPTR記錄各字段的含義： order pref flags serviceregexp replacement IN NAPTR 100 10 "u" "sip+E2U""!^.*$!sip:info@tele2.se!". lorder, 給出處理的順序，按照oder從小到大的順序對記錄搜索，搜索到匹配的記錄后，就停止搜索order值更大的記錄； lpreference, 給出在同一個order下各記錄的偏好（或權重），值越小偏好越高，pref和order的不同之處在于，order具有唯一性，用戶只可以處理某一個order值，而pref表達的是偏好，用戶可以對多個不同pref進行綜合考慮； lflags, 為[A-Z0-9]中的一個字符，表達映射關系及記錄本身的含義，目前有”U”,”S”,”A”和”P”四個標志，其中”U”,”S”和”A”是終結標志，即下一步不需要再進行NAPTR查詢，”A”表示下一步進行A，AAAA或者A6查詢，”U”表示下一步不需要DNS查詢，本次輸出的是滿足RFC2396要求的absoluteURI，”S”表示下一步進行SRV查詢，”P”表示由用戶根據(jù)service定義自己的規(guī)則，所以既可以是終結標志，也可以是非終結標志，如果flags為空(即什么字符也沒有)，表示用戶需要根據(jù)本次輸出，再進行一次NAPTR查詢； lservice, 給出新目標(即映射后的新域名或URI)上的服務，以及和該服務交互所使用的協(xié)議，其形式為[protocol]*(“+” service)，如果flags中的標志為終結標志時，protocol就必須填寫； lregexp, 給出根據(jù)原域名生成新域名或URI的規(guī)則； lreplacement, 包含一個域名，根據(jù)flags給出進行下一次NAPTR、SRV、A或者AAAA查詢所需要的域名，一般情況下，regexp和replacement兩者用其一； 5.DNS SRV 資源記錄 DNS SRV資源記錄用于給出在某域中實現(xiàn)某種服務和協(xié)議的服務器地址列表。假設我們需要得到example.com域中支持TCP協(xié)議的SIP服務器，這時就可以對_sip._tcp.example.com域進行DNS SRV查詢，假設DNS SRV返回如下記錄： Priority WeightPortTarget IN SRV 0 1 5060 icscf1.example.com IN SRV0 2 5060 icscf2.example.com 這樣就可以得到example.com域中支持TCP方式的兩個SIP服務器。下面對SRV記錄中的幾個域解釋一下： lpriority, 給出處理的順序，按照priority從小到大的順序對記錄搜索，搜索到匹配的記錄后，就停止搜索priority值更大的記錄，對于擁有相同priority的記錄將通過weight再次選擇； lweight, 對于擁有相同priority的多條記錄，weight給出了選擇某條記錄的幾率，值越大，被選中的概率就越大，合理的取值范圍為0-65535； lport, 目標機器提供對應服務的端口； ltarget, 目標機器的域名； 下面再用一個例子來介紹一下怎樣通過weight來選擇擁有相同priority的多條記錄，假設有四條記錄A，B，C，D，其weight分別為120，70，95，0，其過程如下： 1.將weight為0的記錄排在最前面，其他記錄順序任意，那么現(xiàn)在的順序可以是DABC； 2.每一個記錄取一個加權值，該值等于前面所有記錄(包括自己)的weight總和，那么D為0，A為120，B為190，C為285； 3.再計算出所有weight的總和，120+70+95+0=285，并隨機出一個在0到285之間(包括0和285)的隨機數(shù)； 4.將隨機值按照DABC的順序和各加權值比較，當出現(xiàn)隨機值小于等于加權值時停止比較，該加權值所對應的記錄就為本次選中的記錄； 通過上述方法可以選出一條可用的記錄，如果還需要再選出一條，可以將選出的記錄從列表中刪去，然后再按步驟2到步驟4進行一次即可。 6.相關RFC文檔 RFC3263, Session Initial Protocol: Locating SIP Servers, 講述SIP傳輸層的相關細節(jié)； RFC2916, E.164 number and DNS, 講述如何通過NAPTR將E.164轉換為URI的方法； RFC1034, DOMAIN NAMES – Concepts and Facilities, 講述DNS中的基本概念； RFC1035, DOMAIN NAMES – Implementation and Specification, 講述DNS實現(xiàn)的相關問題； RFC2915, The Naming Authority Pointer (NAPTR) DNS Resource Record，講述名稱權威指針的原理、細節(jié)及使用方法； RFC2782, A DNS RR for specifying the location of services, 講述SRV的原理、細節(jié)及使用方法； |
| dns服務器為響應 SIP中的DNS |
| 作者：互聯(lián)網(wǎng) 來源：互聯(lián)網(wǎng) 點擊數(shù)： 6 更新時間：2010年08月02日 |
| 1.SIP中的DNS過程 1.1.SIP消息涉及的DNS過程 SIP消息涉及到的DNS過程主要包括兩個方面：一方面是如何發(fā)送請求消息，發(fā)送方需要通過DNS過程得到傳輸層協(xié)議類型，下一跳的IP地址和端口等信息；另一方面是如何返回響應消息，需要決定上一跳的地址和端口，尤其是上一跳網(wǎng)元發(fā)生故障時，如何返回響應消息。 1.2.如何發(fā)送SIP請求消息 定義一個名為TARGET的變量，如果URI定義了maddr參數(shù)，TARGET取值于該參數(shù)，否則取值于URI的hostport部分。 第一步是決定使用哪種傳輸層協(xié)議發(fā)送請求消息，包括下列步驟： 1、如果URI定義了傳輸層協(xié)議，則使用該傳輸層協(xié)議，否則轉步驟2； 2、如果TARGET包含IP地址，那么對于SIP URI使用UDP協(xié)議，SIPS URI使用TCP協(xié)議，否則轉步驟3； 3、如果TARGET包含了端口，那么對于SIP URI使用UDP協(xié)議，SIPS URI使用TCP協(xié)議，否則轉步驟4； 4、使用TARGET中的域名進行NAPTR查詢，如果NAPTR返回的記錄為空轉步驟5，否則查看返回的記錄，記錄中的service域一般取值為”XXX+D2U”, X+D2T”, XX+D2S”, 其中XXX表示服務名稱，可以是”SIP”或”SIPS”，D2U表示使用UDP協(xié)議，D2T表示使用TCP協(xié)議，D2S表示使用SCTP協(xié)議； 5、根據(jù)RFC3261的傳輸準則判斷是否需要使用某種強制協(xié)議，如果需要使用強制協(xié)議，則使用該強制協(xié)議，否則對于SIP URI使用UDP協(xié)議，SIPS URI使用TCP協(xié)議； 第二步是決定目標的IP地址和端口，包括下列步驟： 1、如果TARGET包含了IP地址和端口，則使用該地址和端口，否則轉步驟2； 2、如果TARGET包含了IP地址，則使用對應傳輸協(xié)議的默認端口，否則轉步驟3； 3、如果TARGET不包含IP地址，但包含了端口，則使用A或AAAA查詢，獲得域名對應的IP地址，否則轉步驟4； 4、如果在第一大步的第四小步?jīng)]有進行NAPTR查詢，轉步驟5，則使用該查詢返回的記錄中的replacement域中域名進行SRV查詢，然后轉步驟6； 5、在TARGET包含的域名加上_XXX._YYY.前綴（其中XXX表示服務類型，可以取值sip或sips，YYY表示傳輸類型，可以取值udp, tcp或sctp等），然后使用加了前綴的域名進行SRV查詢，并轉步驟6； 6、如果SRV返回了記錄，記錄會包含端口和最新域名，然后對最新域名進行A或AAAA查詢得到IP地址，如果SRV沒有返回記錄轉步驟7； 7、直接對TARGET中的域名使用A或AAAA查詢得到IP地址，端口則根據(jù)傳輸協(xié)議使用默認端口； 一個發(fā)送請求消息例子，下一跳消息的SIP URI為：sip:example.com，如下是向該網(wǎng)元發(fā)送SIP請求消息的過程： 首先對域名example.com進行NAPTR查詢，查詢的結果為： order pref flags serviceregexp replacement IN NAPTR 50 50 "s" "SIPS+D2T""" _sips._tcp.example.com. IN NAPTR 90 50 "s" "SIP+D2T""" _sip._tcp.example.com IN NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.example.com. NAPTR返回了多條記錄，根據(jù)order和pref的取值選擇了第一條記錄，flag為s表示下一步進行SRV查詢，service為SIPS+D2T表示使用TCP作為傳輸層協(xié)議，同時使用sips方式傳輸消息，replacement表示使用_sips._tcp.example.com進行獲取目標網(wǎng)元的地址信息。 然后對域名_sips._tcp.example.com進行SRV查詢，查詢的結果為： Priority WeightPortTarget IN SRV 0 1 5060 server1.example.com IN SRV0 2 5060 server2.example.com SRV返回了兩條記錄，根據(jù)priority和weight選擇其中一條，假設選擇的是第一條，那么意味這目標端口為5060，Target包含了目標網(wǎng)元的域名server1.example.com。 最后對域名server1.example.com進行A或AAAA查詢，得到目標網(wǎng)元的IP地址： IN AAAA 5F05:2000:80AD:5800:0058:0800:2023:1D71 1.3.如何發(fā)送響應消息 一般情況下，對于可靠的傳輸層協(xié)議，響應消息在請求消息所在的連接上返回，對于非可靠的傳輸層協(xié)議，響應消息通過發(fā)送請求消息的源IP地址以及Via中的端口返回。但是如果UAC發(fā)送完請求消息后就發(fā)生了異常，UAS應當如何返回響應消息？具體包括如下過程： 1、如果Top Via包含了IP地址和端口，向該地址和端口返回響應消息； 2、如果Top Via包含了IP地址，沒有包含端口，使用傳輸層協(xié)議的默認端口返回響應消息； 3、如果Top Via包含了域名和端口，使用A或AAAA查詢，獲得IP地址列表，然后試圖向列表中的每一個IP地址發(fā)送響應消息，只到有一個發(fā)送成功為止； 4、如果Top Via包含了域名，沒有包含端口，使用SRV查詢，獲得端口和新域名，對新域名的處理和步驟3類似； 2.IMS中的DNS過程 IMS中的DNS過程也可以分為兩類：一類是IMS中的SIP實體基于SIP URI的DNS查詢，例如主叫側S-CSCF需要獲得被叫網(wǎng)絡中的I-CSCF，其過程采用SIP定義的DNS過程；另一類是基于TEL URI的DNS查詢。 2.1.基于SIP URI的DNS查詢 基于SIP URI的查詢采用SIP定義的DNS過程(RFC3261, RFC3263)，一般為NAPTR查詢，SRV查詢，最后是A或AAAA查詢。整個過程涉及多次DNS查詢，可能造成會話建立時間過長，為此有兩種方法可以解決這個問題。第一種方法，DNS服務器猜測用戶可能會進行的DNS查詢，然后返回所有這些可能的查詢，例如用戶進行了NAPTR查詢后，DNS服務器不僅返回NAPTR查詢的結果，還會返回相關的SRV以及AAAA的記錄。第二種方法是用戶將查詢結果緩存一段時間，在這段時間以內(nèi)，如果再次查詢該域名，可以直接使用相關記錄。 2.2.基于TEL URI的DNS查詢 IMS中的tel號碼有兩種情況：一種情況是tel號碼對應于IMS網(wǎng)絡中的一個用戶；另外一種情況是tel號碼對應于非IMS網(wǎng)絡中的用戶，如PSTN用戶、GSM用戶等。后一種情況比較簡單，只需要將對應的SIP消息轉發(fā)給BGCF來處理即可。而對于前一種情況則需要將TEL URI轉換成SIP URI，因為只有SIP URI才可以在IMS網(wǎng)絡中路由。 RFC2916講述了將TEL URI轉換為SIP URI的方法，即通過NAPTR查詢來獲得這種轉換，具體步驟為： 1、將TEL號碼按照E.164格式表達成全號碼（包括國家碼）； 2、去除首部”+”之外的所有其他非數(shù)字字符； 3、去除首部的”+”； 4、在數(shù)字字符之間加上”.”號； 5、將數(shù)字字符串順序反轉； 6、在字符串后面加上后綴”e164.arpa”； 7、將字符串作為域名，進行NAPTR查詢； 8、根據(jù)查詢返回的記錄得到對應SIP URI； 下面以一個例子來講述整個過程，假設號碼為+46-8-9761234，具體轉換過程為： 首先去除所有非數(shù)字字符，得到”4689761234”； 其次加上”.”號，得到”4.6.8.9.7.6.1.2.3.4”； 再次進行反轉，得到”4.3.2.1.6.7.9.8.6.4”； 再次加上后綴，得到” 4.3.2.1.6.7.9.8.6.4.e164.arpa”； 最后對域名” 4.3.2.1.6.7.9.8.6.4.e164.arpa”進行NAPTR查詢，得到如下記錄： order pref flags serviceregexp replacement IN NAPTR 100 10 "u" "sip+E2U""!^.*$!sip:info@tele2.se!". IN NAPTR 102 10 "u" "mailto+E2U" "!^.*$!mailto:info@tele2.se!" . NAPTR返回了兩條記錄，order和prefer表達記錄的使用偏好，flags為”u”，表示regexp域給出了替代規(guī)則，根據(jù)該規(guī)則和原來的域名可以得出一個滿足absoluteURI的URI(RFC2396)。Service給出記錄對應的協(xié)議和服務，”sip”表示轉換出的URI用于SIP協(xié)議，”mailto”表示轉換出的URI用于mail協(xié)議，”E2U”表示e.164 to URI服務。 本例是IMS中的TEL到SIP轉換，所有使用第一條記錄，得到最終的SIP URI，即sip:info@tele2.se。 3.DNS的基本概念 3.1.DNS的授權 網(wǎng)絡信息中心NIC負責分配頂極域和委派其他指定地區(qū)域的授權機構。一個獨立管理的DNS子樹稱為一個區(qū)域，許多二極域將他們的子域劃分為更小的區(qū)域。當一個系統(tǒng)加入到一個區(qū)域中時，該區(qū)域的DNS管理者為該新系統(tǒng)申請一個域名和一個IP地址，并將他們加入到名字服務器的數(shù)據(jù)庫中。一個名字服務器負責一個或多個區(qū)域，一個區(qū)域的管理者必須為該區(qū)域提供一個主名字服務器和至少一個輔助名字服務器。每個主名字服務器都必須知道根名字服務器的IP地址，根服務器必須知道所有二極域中每個授權名字服務器的名字和IP地址。常見的頂級域：com用于商業(yè)組織，edu用于教育機構，org用于非贏利組織，net用于計算機網(wǎng)絡組織，gov用于美國政府組織。 下面以一個例子講述DNS的查找過程，假設Web瀏覽器訪問“msdn.microsoft.com”站點，它會通過以下步驟來解析該域名的 IP 地址： 1、瀏覽器調(diào)用 DNS 客戶端（稱為解析器），并使用上次查詢緩存的信息在本地解析該查詢； 2、如果在本地無法解析查詢，客戶端就會向已知的 DNS 服務器詢問，如果該 DNS 服務器曾經(jīng)在特定的時間段內(nèi)處理過相同的域名（“msdn.microsoft.com“）請求，它就會在緩存中檢索相應的 IP 地址，并將它返回給客戶端； 3、如果該 DNS 服務器找不到相應的地址，客戶端就會向某個全局根 DNS 服務器詢問，后者返回頂級域權威 DNS 服務器的指針，在這種情況下，“com”域權威服務器的 IP 地址將返回給客戶端； 4、客戶端向“com”服務器詢問“microsoft.com”服務器的地址； 5、客戶端將原始查詢傳到“microsoft.com”服務器，因為“microsoft.com”服務器在本地維護“msdn.microsoft.com”域的權威記錄，所以它將最終結果返回給客戶端，并完成特定 IP 地址的查詢； 注意，可以將 DNS 資源記錄緩存到網(wǎng)絡上任意數(shù)量的 DNS 服務器中。第 2 步中提到的 DNS 服務器可能不包含“msdn.microsoft.com”緩存記錄。但是，它可能有“microsoft.com”的記錄，更可能有“com”域的記錄。這可省去客戶端獲得最終結果所需的一次或幾次查詢，從而加快了整個搜索過程。 3.2.DNS查詢報文中的問題部分 查詢報文由多個問題部分組成，每個問題代表一個查詢，其包括查詢名、查詢類型和查詢類。查詢名是指要查找的名字，它是一個或多個標識符的序列。每個標識符以首字節(jié)的計數(shù)值來說明隨后標識符的字節(jié)長度，每個名字以最后字節(jié)為0結束，長度為0的標識符是根標識符。計數(shù)字節(jié)的值必須為0－63，因為標識符的最大長度僅為63。該字段無需以整32為為邊界，即無需填充字節(jié)，例如gemini.tuc.noao.edu的存儲格式為6gemini3tuc4noao3edu0。查詢類型描述查詢哪個方面的問題，最常見的查詢類型是A類型（值為1），表示期望獲得查詢名的IP地址，PTR查詢（值為12）則請求獲得一個IP地址對應的域名。查詢類一般是1，指互聯(lián)網(wǎng)地址。 3.3.資源記錄RR 查詢結果通過資源記錄的方式返回，名字服務器返回的資源記錄可以是回答RR、授權RR和附加信息RR。RR記錄中的類型字段給出該記錄所包含的信息： 1、A，一個A記錄定義了一個IP地址； 2、PTR，指針記錄用于指針查詢，IP地址被看作是noao.edu域下的一個域名； 3、CNAME，表示規(guī)范名字，用來表示一個域名，而有規(guī)范名字的域名通常叫做別名，某些FTP服務器使用它向其他的系統(tǒng)提供一個易于記憶的別名； 4、HINFO，表示主機信息，包括說明主機CPU和操作系統(tǒng)的兩個字符串； 5、MX，郵件交換記錄，例如可以表達如果有郵件要發(fā)往use@foo.com，就將郵件發(fā)送到relay1.uu.net這樣的信息。 6、NS，名字服務器記錄，其說明一個域的授權名字服務器，它由域名表示。 3.4.使用UDP還是TCP DNS同時支持UDP和TCP，端口號都是53。當查詢請求的響應消息長度超過512個字節(jié)時，UDP僅返回前512個字節(jié)，這時名字解析器通常使用TCP重發(fā)原來的查詢請求。既然DNS主要使用UDP，因此好的重傳和超時機制就比較重要了。 4.DNS NAPTR資源記錄 DNS NAPTR資源記錄的功能是能夠將原來的域名映射成一個新的域名或者URI(Uniform Resource Identifier)，并通過flag域來指定這些新域名或URI在后繼操作中的使用方法。下面通過一個例子來講述NAPTR記錄各字段的含義： order pref flags serviceregexp replacement IN NAPTR 100 10 "u" "sip+E2U""!^.*$!sip:info@tele2.se!". lorder, 給出處理的順序，按照oder從小到大的順序對記錄搜索，搜索到匹配的記錄后，就停止搜索order值更大的記錄； lpreference, 給出在同一個order下各記錄的偏好（或權重），值越小偏好越高，pref和order的不同之處在于，order具有唯一性，用戶只可以處理某一個order值，而pref表達的是偏好，用戶可以對多個不同pref進行綜合考慮； lflags, 為[A-Z0-9]中的一個字符，表達映射關系及記錄本身的含義，目前有”U”,”S”,”A”和”P”四個標志，其中”U”,”S”和”A”是終結標志，即下一步不需要再進行NAPTR查詢，”A”表示下一步進行A，AAAA或者A6查詢，”U”表示下一步不需要DNS查詢，本次輸出的是滿足RFC2396要求的absoluteURI，”S”表示下一步進行SRV查詢，”P”表示由用戶根據(jù)service定義自己的規(guī)則，所以既可以是終結標志，也可以是非終結標志，如果flags為空(即什么字符也沒有)，表示用戶需要根據(jù)本次輸出，再進行一次NAPTR查詢； lservice, 給出新目標(即映射后的新域名或URI)上的服務，以及和該服務交互所使用的協(xié)議，其形式為[protocol]*(“+” service)，如果flags中的標志為終結標志時，protocol就必須填寫； lregexp, 給出根據(jù)原域名生成新域名或URI的規(guī)則； lreplacement, 包含一個域名，根據(jù)flags給出進行下一次NAPTR、SRV、A或者AAAA查詢所需要的域名，一般情況下，regexp和replacement兩者用其一； 5.DNS SRV 資源記錄 DNS SRV資源記錄用于給出在某域中實現(xiàn)某種服務和協(xié)議的服務器地址列表。假設我們需要得到example.com域中支持TCP協(xié)議的SIP服務器，這時就可以對_sip._tcp.example.com域進行DNS SRV查詢，假設DNS SRV返回如下記錄： Priority WeightPortTarget IN SRV 0 1 5060 icscf1.example.com IN SRV0 2 5060 icscf2.example.com 這樣就可以得到example.com域中支持TCP方式的兩個SIP服務器。下面對SRV記錄中的幾個域解釋一下： lpriority, 給出處理的順序，按照priority從小到大的順序對記錄搜索，搜索到匹配的記錄后，就停止搜索priority值更大的記錄，對于擁有相同priority的記錄將通過weight再次選擇； lweight, 對于擁有相同priority的多條記錄，weight給出了選擇某條記錄的幾率，值越大，被選中的概率就越大，合理的取值范圍為0-65535； lport, 目標機器提供對應服務的端口； ltarget, 目標機器的域名； 下面再用一個例子來介紹一下怎樣通過weight來選擇擁有相同priority的多條記錄，假設有四條記錄A，B，C，D，其weight分別為120，70，95，0，其過程如下： 1.將weight為0的記錄排在最前面，其他記錄順序任意，那么現(xiàn)在的順序可以是DABC； 2.每一個記錄取一個加權值，該值等于前面所有記錄(包括自己)的weight總和，那么D為0，A為120，B為190，C為285； 3.再計算出所有weight的總和，120+70+95+0=285，并隨機出一個在0到285之間(包括0和285)的隨機數(shù)； 4.將隨機值按照DABC的順序和各加權值比較，當出現(xiàn)隨機值小于等于加權值時停止比較，該加權值所對應的記錄就為本次選中的記錄； 通過上述方法可以選出一條可用的記錄，如果還需要再選出一條，可以將選出的記錄從列表中刪去，然后再按步驟2到步驟4進行一次即可。 6.相關RFC文檔 RFC3263, Session Initial Protocol: Locating SIP Servers, 講述SIP傳輸層的相關細節(jié)； RFC2916, E.164 number and DNS, 講述如何通過NAPTR將E.164轉換為URI的方法； RFC1034, DOMAIN NAMES – Concepts and Facilities, 講述DNS中的基本概念； RFC1035, DOMAIN NAMES – Implementation and Specification, 講述DNS實現(xiàn)的相關問題； RFC2915, The Naming Authority Pointer (NAPTR) DNS Resource Record，講述名稱權威指針的原理、細節(jié)及使用方法； RFC2782, A DNS RR for specifying the location of services, 講述SRV的原理、細節(jié)及使用方法； |
| dns服務器為響應 SIP中的DNS |
| 作者：互聯(lián)網(wǎng) 來源：互聯(lián)網(wǎng) 點擊數(shù)： 6 更新時間：2010年08月02日 |
| 1.SIP中的DNS過程 1.1.SIP消息涉及的DNS過程 SIP消息涉及到的DNS過程主要包括兩個方面：一方面是如何發(fā)送請求消息，發(fā)送方需要通過DNS過程得到傳輸層協(xié)議類型，下一跳的IP地址和端口等信息；另一方面是如何返回響應消息，需要決定上一跳的地址和端口，尤其是上一跳網(wǎng)元發(fā)生故障時，如何返回響應消息。 1.2.如何發(fā)送SIP請求消息 定義一個名為TARGET的變量，如果URI定義了maddr參數(shù)，TARGET取值于該參數(shù)，否則取值于URI的hostport部分。 第一步是決定使用哪種傳輸層協(xié)議發(fā)送請求消息，包括下列步驟： 1、如果URI定義了傳輸層協(xié)議，則使用該傳輸層協(xié)議，否則轉步驟2； 2、如果TARGET包含IP地址，那么對于SIP URI使用UDP協(xié)議，SIPS URI使用TCP協(xié)議，否則轉步驟3； 3、如果TARGET包含了端口，那么對于SIP URI使用UDP協(xié)議，SIPS URI使用TCP協(xié)議，否則轉步驟4； 4、使用TARGET中的域名進行NAPTR查詢，如果NAPTR返回的記錄為空轉步驟5，否則查看返回的記錄，記錄中的service域一般取值為”XXX+D2U”, X+D2T”, XX+D2S”, 其中XXX表示服務名稱，可以是”SIP”或”SIPS”，D2U表示使用UDP協(xié)議，D2T表示使用TCP協(xié)議，D2S表示使用SCTP協(xié)議； 5、根據(jù)RFC3261的傳輸準則判斷是否需要使用某種強制協(xié)議，如果需要使用強制協(xié)議，則使用該強制協(xié)議，否則對于SIP URI使用UDP協(xié)議，SIPS URI使用TCP協(xié)議； 第二步是決定目標的IP地址和端口，包括下列步驟： 1、如果TARGET包含了IP地址和端口，則使用該地址和端口，否則轉步驟2； 2、如果TARGET包含了IP地址，則使用對應傳輸協(xié)議的默認端口，否則轉步驟3； 3、如果TARGET不包含IP地址，但包含了端口，則使用A或AAAA查詢，獲得域名對應的IP地址，否則轉步驟4； 4、如果在第一大步的第四小步?jīng)]有進行NAPTR查詢，轉步驟5，則使用該查詢返回的記錄中的replacement域中域名進行SRV查詢，然后轉步驟6； 5、在TARGET包含的域名加上_XXX._YYY.前綴（其中XXX表示服務類型，可以取值sip或sips，YYY表示傳輸類型，可以取值udp, tcp或sctp等），然后使用加了前綴的域名進行SRV查詢，并轉步驟6； 6、如果SRV返回了記錄，記錄會包含端口和最新域名，然后對最新域名進行A或AAAA查詢得到IP地址，如果SRV沒有返回記錄轉步驟7； 7、直接對TARGET中的域名使用A或AAAA查詢得到IP地址，端口則根據(jù)傳輸協(xié)議使用默認端口； 一個發(fā)送請求消息例子，下一跳消息的SIP URI為：sip:example.com，如下是向該網(wǎng)元發(fā)送SIP請求消息的過程： 首先對域名example.com進行NAPTR查詢，查詢的結果為： order pref flags serviceregexp replacement IN NAPTR 50 50 "s" "SIPS+D2T""" _sips._tcp.example.com. IN NAPTR 90 50 "s" "SIP+D2T""" _sip._tcp.example.com IN NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.example.com. NAPTR返回了多條記錄，根據(jù)order和pref的取值選擇了第一條記錄，flag為s表示下一步進行SRV查詢，service為SIPS+D2T表示使用TCP作為傳輸層協(xié)議，同時使用sips方式傳輸消息，replacement表示使用_sips._tcp.example.com進行獲取目標網(wǎng)元的地址信息。 然后對域名_sips._tcp.example.com進行SRV查詢，查詢的結果為： Priority WeightPortTarget IN SRV 0 1 5060 server1.example.com IN SRV0 2 5060 server2.example.com SRV返回了兩條記錄，根據(jù)priority和weight選擇其中一條，假設選擇的是第一條，那么意味這目標端口為5060，Target包含了目標網(wǎng)元的域名server1.example.com。 最后對域名server1.example.com進行A或AAAA查詢，得到目標網(wǎng)元的IP地址： IN AAAA 5F05:2000:80AD:5800:0058:0800:2023:1D71 1.3.如何發(fā)送響應消息 一般情況下，對于可靠的傳輸層協(xié)議，響應消息在請求消息所在的連接上返回，對于非可靠的傳輸層協(xié)議，響應消息通過發(fā)送請求消息的源IP地址以及Via中的端口返回。但是如果UAC發(fā)送完請求消息后就發(fā)生了異常，UAS應當如何返回響應消息？具體包括如下過程： 1、如果Top Via包含了IP地址和端口，向該地址和端口返回響應消息； 2、如果Top Via包含了IP地址，沒有包含端口，使用傳輸層協(xié)議的默認端口返回響應消息； 3、如果Top Via包含了域名和端口，使用A或AAAA查詢，獲得IP地址列表，然后試圖向列表中的每一個IP地址發(fā)送響應消息，只到有一個發(fā)送成功為止； 4、如果Top Via包含了域名，沒有包含端口，使用SRV查詢，獲得端口和新域名，對新域名的處理和步驟3類似； 2.IMS中的DNS過程 IMS中的DNS過程也可以分為兩類：一類是IMS中的SIP實體基于SIP URI的DNS查詢，例如主叫側S-CSCF需要獲得被叫網(wǎng)絡中的I-CSCF，其過程采用SIP定義的DNS過程；另一類是基于TEL URI的DNS查詢。 2.1.基于SIP URI的DNS查詢 基于SIP URI的查詢采用SIP定義的DNS過程(RFC3261, RFC3263)，一般為NAPTR查詢，SRV查詢，最后是A或AAAA查詢。整個過程涉及多次DNS查詢，可能造成會話建立時間過長，為此有兩種方法可以解決這個問題。第一種方法，DNS服務器猜測用戶可能會進行的DNS查詢，然后返回所有這些可能的查詢，例如用戶進行了NAPTR查詢后，DNS服務器不僅返回NAPTR查詢的結果，還會返回相關的SRV以及AAAA的記錄。第二種方法是用戶將查詢結果緩存一段時間，在這段時間以內(nèi)，如果再次查詢該域名，可以直接使用相關記錄。 2.2.基于TEL URI的DNS查詢 IMS中的tel號碼有兩種情況：一種情況是tel號碼對應于IMS網(wǎng)絡中的一個用戶；另外一種情況是tel號碼對應于非IMS網(wǎng)絡中的用戶，如PSTN用戶、GSM用戶等。后一種情況比較簡單，只需要將對應的SIP消息轉發(fā)給BGCF來處理即可。而對于前一種情況則需要將TEL URI轉換成SIP URI，因為只有SIP URI才可以在IMS網(wǎng)絡中路由。 RFC2916講述了將TEL URI轉換為SIP URI的方法，即通過NAPTR查詢來獲得這種轉換，具體步驟為： 1、將TEL號碼按照E.164格式表達成全號碼（包括國家碼）； 2、去除首部”+”之外的所有其他非數(shù)字字符； 3、去除首部的”+”； 4、在數(shù)字字符之間加上”.”號； 5、將數(shù)字字符串順序反轉； 6、在字符串后面加上后綴”e164.arpa”； 7、將字符串作為域名，進行NAPTR查詢； 8、根據(jù)查詢返回的記錄得到對應SIP URI； 下面以一個例子來講述整個過程，假設號碼為+46-8-9761234，具體轉換過程為： 首先去除所有非數(shù)字字符，得到”4689761234”； 其次加上”.”號，得到”4.6.8.9.7.6.1.2.3.4”； 再次進行反轉，得到”4.3.2.1.6.7.9.8.6.4”； 再次加上后綴，得到” 4.3.2.1.6.7.9.8.6.4.e164.arpa”； 最后對域名” 4.3.2.1.6.7.9.8.6.4.e164.arpa”進行NAPTR查詢，得到如下記錄： order pref flags serviceregexp replacement IN NAPTR 100 10 "u" "sip+E2U""!^.*$!sip:info@tele2.se!". IN NAPTR 102 10 "u" "mailto+E2U" "!^.*$!mailto:info@tele2.se!" . NAPTR返回了兩條記錄，order和prefer表達記錄的使用偏好，flags為”u”，表示regexp域給出了替代規(guī)則，根據(jù)該規(guī)則和原來的域名可以得出一個滿足absoluteURI的URI(RFC2396)。Service給出記錄對應的協(xié)議和服務，”sip”表示轉換出的URI用于SIP協(xié)議，”mailto”表示轉換出的URI用于mail協(xié)議，”E2U”表示e.164 to URI服務。 本例是IMS中的TEL到SIP轉換，所有使用第一條記錄，得到最終的SIP URI，即sip:info@tele2.se。 3.DNS的基本概念 3.1.DNS的授權 網(wǎng)絡信息中心NIC負責分配頂極域和委派其他指定地區(qū)域的授權機構。一個獨立管理的DNS子樹稱為一個區(qū)域，許多二極域將他們的子域劃分為更小的區(qū)域。當一個系統(tǒng)加入到一個區(qū)域中時，該區(qū)域的DNS管理者為該新系統(tǒng)申請一個域名和一個IP地址，并將他們加入到名字服務器的數(shù)據(jù)庫中。一個名字服務器負責一個或多個區(qū)域，一個區(qū)域的管理者必須為該區(qū)域提供一個主名字服務器和至少一個輔助名字服務器。每個主名字服務器都必須知道根名字服務器的IP地址，根服務器必須知道所有二極域中每個授權名字服務器的名字和IP地址。常見的頂級域：com用于商業(yè)組織，edu用于教育機構，org用于非贏利組織，net用于計算機網(wǎng)絡組織，gov用于美國政府組織。 下面以一個例子講述DNS的查找過程，假設Web瀏覽器訪問“msdn.microsoft.com”站點，它會通過以下步驟來解析該域名的 IP 地址： 1、瀏覽器調(diào)用 DNS 客戶端（稱為解析器），并使用上次查詢緩存的信息在本地解析該查詢； 2、如果在本地無法解析查詢，客戶端就會向已知的 DNS 服務器詢問，如果該 DNS 服務器曾經(jīng)在特定的時間段內(nèi)處理過相同的域名（“msdn.microsoft.com“）請求，它就會在緩存中檢索相應的 IP 地址，并將它返回給客戶端； 3、如果該 DNS 服務器找不到相應的地址，客戶端就會向某個全局根 DNS 服務器詢問，后者返回頂級域權威 DNS 服務器的指針，在這種情況下，“com”域權威服務器的 IP 地址將返回給客戶端； 4、客戶端向“com”服務器詢問“microsoft.com”服務器的地址； 5、客戶端將原始查詢傳到“microsoft.com”服務器，因為“microsoft.com”服務器在本地維護“msdn.microsoft.com”域的權威記錄，所以它將最終結果返回給客戶端，并完成特定 IP 地址的查詢； 注意，可以將 DNS 資源記錄緩存到網(wǎng)絡上任意數(shù)量的 DNS 服務器中。第 2 步中提到的 DNS 服務器可能不包含“msdn.microsoft.com”緩存記錄。但是，它可能有“microsoft.com”的記錄，更可能有“com”域的記錄。這可省去客戶端獲得最終結果所需的一次或幾次查詢，從而加快了整個搜索過程。 3.2.DNS查詢報文中的問題部分 查詢報文由多個問題部分組成，每個問題代表一個查詢，其包括查詢名、查詢類型和查詢類。查詢名是指要查找的名字，它是一個或多個標識符的序列。每個標識符以首字節(jié)的計數(shù)值來說明隨后標識符的字節(jié)長度，每個名字以最后字節(jié)為0結束，長度為0的標識符是根標識符。計數(shù)字節(jié)的值必須為0－63，因為標識符的最大長度僅為63。該字段無需以整32為為邊界，即無需填充字節(jié)，例如gemini.tuc.noao.edu的存儲格式為6gemini3tuc4noao3edu0。查詢類型描述查詢哪個方面的問題，最常見的查詢類型是A類型（值為1），表示期望獲得查詢名的IP地址，PTR查詢（值為12）則請求獲得一個IP地址對應的域名。查詢類一般是1，指互聯(lián)網(wǎng)地址。 3.3.資源記錄RR 查詢結果通過資源記錄的方式返回，名字服務器返回的資源記錄可以是回答RR、授權RR和附加信息RR。RR記錄中的類型字段給出該記錄所包含的信息： 1、A，一個A記錄定義了一個IP地址； 2、PTR，指針記錄用于指針查詢，IP地址被看作是noao.edu域下的一個域名； 3、CNAME，表示規(guī)范名字，用來表示一個域名，而有規(guī)范名字的域名通常叫做別名，某些FTP服務器使用它向其他的系統(tǒng)提供一個易于記憶的別名； 4、HINFO，表示主機信息，包括說明主機CPU和操作系統(tǒng)的兩個字符串； 5、MX，郵件交換記錄，例如可以表達如果有郵件要發(fā)往use@foo.com，就將郵件發(fā)送到relay1.uu.net這樣的信息。 6、NS，名字服務器記錄，其說明一個域的授權名字服務器，它由域名表示。 3.4.使用UDP還是TCP DNS同時支持UDP和TCP，端口號都是53。當查詢請求的響應消息長度超過512個字節(jié)時，UDP僅返回前512個字節(jié)，這時名字解析器通常使用TCP重發(fā)原來的查詢請求。既然DNS主要使用UDP，因此好的重傳和超時機制就比較重要了。 4.DNS NAPTR資源記錄 DNS NAPTR資源記錄的功能是能夠將原來的域名映射成一個新的域名或者URI(Uniform Resource Identifier)，并通過flag域來指定這些新域名或URI在后繼操作中的使用方法。下面通過一個例子來講述NAPTR記錄各字段的含義： order pref flags serviceregexp replacement IN NAPTR 100 10 "u" "sip+E2U""!^.*$!sip:info@tele2.se!". lorder, 給出處理的順序，按照oder從小到大的順序對記錄搜索，搜索到匹配的記錄后，就停止搜索order值更大的記錄； lpreference, 給出在同一個order下各記錄的偏好（或權重），值越小偏好越高，pref和order的不同之處在于，order具有唯一性，用戶只可以處理某一個order值，而pref表達的是偏好，用戶可以對多個不同pref進行綜合考慮； lflags, 為[A-Z0-9]中的一個字符，表達映射關系及記錄本身的含義，目前有”U”,”S”,”A”和”P”四個標志，其中”U”,”S”和”A”是終結標志，即下一步不需要再進行NAPTR查詢，”A”表示下一步進行A，AAAA或者A6查詢，”U”表示下一步不需要DNS查詢，本次輸出的是滿足RFC2396要求的absoluteURI，”S”表示下一步進行SRV查詢，”P”表示由用戶根據(jù)service定義自己的規(guī)則，所以既可以是終結標志，也可以是非終結標志，如果flags為空(即什么字符也沒有)，表示用戶需要根據(jù)本次輸出，再進行一次NAPTR查詢； lservice, 給出新目標(即映射后的新域名或URI)上的服務，以及和該服務交互所使用的協(xié)議，其形式為[protocol]*(“+” service)，如果flags中的標志為終結標志時，protocol就必須填寫； lregexp, 給出根據(jù)原域名生成新域名或URI的規(guī)則； lreplacement, 包含一個域名，根據(jù)flags給出進行下一次NAPTR、SRV、A或者AAAA查詢所需要的域名，一般情況下，regexp和replacement兩者用其一； 5.DNS SRV 資源記錄 DNS SRV資源記錄用于給出在某域中實現(xiàn)某種服務和協(xié)議的服務器地址列表。假設我們需要得到example.com域中支持TCP協(xié)議的SIP服務器，這時就可以對_sip._tcp.example.com域進行DNS SRV查詢，假設DNS SRV返回如下記錄： Priority WeightPortTarget IN SRV 0 1 5060 icscf1.example.com IN SRV0 2 5060 icscf2.example.com 這樣就可以得到example.com域中支持TCP方式的兩個SIP服務器。下面對SRV記錄中的幾個域解釋一下： lpriority, 給出處理的順序，按照priority從小到大的順序對記錄搜索，搜索到匹配的記錄后，就停止搜索priority值更大的記錄，對于擁有相同priority的記錄將通過weight再次選擇； lweight, 對于擁有相同priority的多條記錄，weight給出了選擇某條記錄的幾率，值越大，被選中的概率就越大，合理的取值范圍為0-65535； lport, 目標機器提供對應服務的端口； ltarget, 目標機器的域名； 下面再用一個例子來介紹一下怎樣通過weight來選擇擁有相同priority的多條記錄，假設有四條記錄A，B，C，D，其weight分別為120，70，95，0，其過程如下： 1.將weight為0的記錄排在最前面，其他記錄順序任意，那么現(xiàn)在的順序可以是DABC； 2.每一個記錄取一個加權值，該值等于前面所有記錄(包括自己)的weight總和，那么D為0，A為120，B為190，C為285； 3.再計算出所有weight的總和，120+70+95+0=285，并隨機出一個在0到285之間(包括0和285)的隨機數(shù)； 4.將隨機值按照DABC的順序和各加權值比較，當出現(xiàn)隨機值小于等于加權值時停止比較，該加權值所對應的記錄就為本次選中的記錄； 通過上述方法可以選出一條可用的記錄，如果還需要再選出一條，可以將選出的記錄從列表中刪去，然后再按步驟2到步驟4進行一次即可。 6.相關RFC文檔 RFC3263, Session Initial Protocol: Locating SIP Servers, 講述SIP傳輸層的相關細節(jié)； RFC2916, E.164 number and DNS, 講述如何通過NAPTR將E.164轉換為URI的方法； RFC1034, DOMAIN NAMES – Concepts and Facilities, 講述DNS中的基本概念； RFC1035, DOMAIN NAMES – Implementation and Specification, 講述DNS實現(xiàn)的相關問題； RFC2915, The Naming Authority Pointer (NAPTR) DNS Resource Record，講述名稱權威指針的原理、細節(jié)及使用方法； RFC2782, A DNS RR for specifying the location of services, 講述SRV的原理、細節(jié)及使用方法； |
