一種基于應(yīng)用層dns消息分割的dns包擴(kuò)展方法
【技術(shù)領(lǐng)域】
[0001]本發(fā)明屬于互聯(lián)網(wǎng)通信技術(shù)領(lǐng)域，特別涉及一種基于應(yīng)用層DNS消息分割的DNS包擴(kuò)展方法。
【背景技術(shù)】
[0002]DNS提供了互聯(lián)網(wǎng)上的一個(gè)重要的服務(wù)，其本質(zhì)是建立了人的名字世界和底層的二進(jìn)制協(xié)議地址世界的橋梁，每次，當(dāng)我們通過互聯(lián)網(wǎng)開始任何的事務(wù)之前，一個(gè)DNS的查詢過程首先要完成；所以一個(gè)輕量級的、快速響應(yīng)的DNS協(xié)議是非常必要的，這樣DNS查詢過程可以對用戶而言透明地完成，DNS解析框架使用UDP作為傳輸協(xié)議，并通過地理分布的具有緩存功能的遞歸解析器來實(shí)現(xiàn)。
[0003]同時(shí)在互聯(lián)網(wǎng)發(fā)展過程中，傳統(tǒng)的DNS協(xié)議也凸顯了一些問題，由于IPv4協(xié)議對包尺寸的限制，DNS協(xié)議使用UDP傳輸DNS消息的最大包尺寸是固定的。在RFC 1035中規(guī)定，DNS消息的UDP包的大小不應(yīng)超過512字節(jié)，這個(gè)強(qiáng)制性的限制隨著DNS協(xié)議的發(fā)展已經(jīng)不能滿足新的需求；512字節(jié)的限制⑴限定了 DNS系統(tǒng)根服務(wù)器的數(shù)量，⑵限制了基于IPv6的DNS服務(wù)器的部署，(3)同時(shí)也阻礙了一些新的擴(kuò)展協(xié)議的部署JnDNSSEC，由于DNSSEC攜帶大量的密鑰和簽名等信息(如DNSKEY，RRSIG, NSEC資源記錄等)，響應(yīng)包的大小很容易超過512字節(jié)的限制。
[0004]傳統(tǒng)的DNS協(xié)議將UDP支持的DNS作為必選，將TCP支持的DNS作為候選。在DNS協(xié)議的發(fā)展過程中，DNS包擴(kuò)展問題已經(jīng)被仔細(xì)考慮過了，EDNS0作為DNS協(xié)議的一個(gè)擴(kuò)展版本很早就被提出。EDNS0給出了而一個(gè)向后兼容的機(jī)制，其定義了一些新的擴(kuò)展字段來支持DNS協(xié)議的進(jìn)一步演進(jìn)，其中說明了對包尺寸的擴(kuò)大。在支持EDNS0的擴(kuò)展消息中，在Addit1nal Data區(qū)中定義了一個(gè)所謂的OPT偽資源記錄。支持EDNS0協(xié)議的發(fā)送消息和接收消息都要包括一個(gè)OPT資源記錄。在OPT資源記錄的CLASS域中指定了解析器請求和接收的UDP響應(yīng)消息的長度，其范圍可以在512-4096字節(jié)。當(dāng)一個(gè)支持了 EDNS0的服務(wù)器收到這樣的請求消息后，如果響應(yīng)消息能夠包括在解析器定義的字節(jié)長度范圍之內(nèi)，服務(wù)器會(huì)返回一個(gè)未被截?cái)嗟淖銐蛉菁{各類查詢信息的響應(yīng)消息。EDNS0能夠容納的最大包長為4096字節(jié)，基本能夠滿足各方面的需求，如支持DNSSEC的DNS響應(yīng)消息的尺寸。結(jié)果DNS系統(tǒng)更多的依賴EDNS0協(xié)議來解決包擴(kuò)展的問題，降低了因?yàn)?12字節(jié)限制而對TCP的依賴。
[0005]EDNS0提出了一個(gè)理想的機(jī)制解決包尺寸的擴(kuò)展，同時(shí)保持了傳統(tǒng)DNS基于UDP的方案的靈活性和高效性。但是情況并非如此。當(dāng)一個(gè)服務(wù)器返回了一個(gè)支持m)Nso的響應(yīng)消息超過了路徑中的MTU最大包尺寸限制，中間設(shè)備將會(huì)對包分割成多個(gè)分片傳輸。網(wǎng)絡(luò)中的防火墻或其它一些中間件，只允許一個(gè)響應(yīng)包的第一個(gè)分片通過，而丟棄剩余的分片。特別是隨著DNSSEC的部署超過2000字節(jié)的包非常的普遍。結(jié)果解析器不能夠?qū)⑺械姆制匦陆M裝成完整的響應(yīng)消息。為避免響應(yīng)包被分片，可以同服務(wù)器協(xié)商一個(gè)盡可能小的包尺寸。但這時(shí)就有可能導(dǎo)致包尺寸仍不能滿足響應(yīng)包的需求而被截?cái)唷?br>[0006]除了 UDP，TCP協(xié)議也被用于傳輸DNS消息。在DNS協(xié)議中規(guī)定DNS解析器和服務(wù)器“必須”支持UDP，“應(yīng)該”支持TCP，用于發(fā)送非AXFR的查詢請求。這意味著許多DNS實(shí)現(xiàn)版本將UDP作為一個(gè)必選的解決方案，而將TCP作為一個(gè)候選的解決方案，其只有在響應(yīng)消息被截?cái)嗷駻XFR傳輸時(shí)被啟用。實(shí)際上，很多存在的解析器并沒有真正的支持TCP。但是，考慮到UDP內(nèi)在的各種缺陷，一些研究者強(qiáng)調(diào)應(yīng)該在DNS協(xié)議實(shí)現(xiàn)版本中更廣泛的支持TCP，進(jìn)一步全面的支持TCP。甚至，一些研究者將TCP作為DNS首選的傳輸協(xié)議。分別將DNS對TCP的利用的兩種方式分別稱為TCP候選方式和TCP首選方式。TCP候選方案首選UDP確保DNS協(xié)議的簡單性和靈活性，同時(shí)利用TCP作為一種候補(bǔ)方案。當(dāng)發(fā)生由于分割帶來的重新組裝失敗或名字服務(wù)器的響應(yīng)包截?cái)嗟葐栴}帶來的基于UDP的DNS請求失敗，TCP提供了最后的保障。除了包尺寸的限制，UDP弱的隱私保護(hù)、易受DoS攻擊等問題使得一些研究者試圖拋棄UDP協(xié)議，而直接使用TCP傳輸DNS消息，并通過對TCP協(xié)議的一些優(yōu)化方案改善TCP的性能。但是，總的來說，由于TCP協(xié)議更長的延時(shí)和更大的資源消耗，人們對采用TCP進(jìn)行DNS消息傳輸?shù)姆绞饺匀徊扇》浅Ｖ?jǐn)慎和保守的態(tài)度。
[0007]傳統(tǒng)的DNS協(xié)議以及一些擴(kuò)展和改善方案，都不能很好的解決DNS協(xié)議的可擴(kuò)展性問題。為實(shí)現(xiàn)DNS根名字服務(wù)器數(shù)量的擴(kuò)展，IPv6根節(jié)點(diǎn)的部署、DNSSEC協(xié)議的支持，以及未來不斷的出現(xiàn)的一些基于DNS的新特性，同時(shí)保證DNS解析協(xié)議的簡單性、靈活性和高效性，提出了 DNS名字服務(wù)器在應(yīng)用層將DNS消息進(jìn)行分割成中間設(shè)備不會(huì)進(jìn)一步分割的片段，通過傳統(tǒng)的UDP消息傳輸DNS的分片，在DNS的解析器將經(jīng)過分片的DNS消息進(jìn)行重組，形成完整的DNS響應(yīng)消息。

【發(fā)明內(nèi)容】

[0008]本發(fā)明的目的是提出一種基于應(yīng)用層DNS消息分割的DNS包擴(kuò)展方法，其特征在于，基于應(yīng)用層DNS消息分割的方案能夠突破DNS響應(yīng)消息512字節(jié)的限制，采用在應(yīng)用層進(jìn)行DNS消息的分割和重組，并通過UDP協(xié)議傳輸，保持了 DNS協(xié)議的靈活性同時(shí)實(shí)現(xiàn)了DNS消息的可擴(kuò)展性；該方法包括:需要說明DNS消息分割的標(biāo)準(zhǔn)、DNS消息分片信息的表示、應(yīng)用層DNS消息分割功能的標(biāo)識(shí)和識(shí)別、分片重裝的工作原理；
[0009]所述說明DNS消息分割的標(biāo)準(zhǔn)，傳統(tǒng)的DNS協(xié)議已經(jīng)沒有足夠的字段進(jìn)行協(xié)議擴(kuò)展，而EDNS0協(xié)議是一個(gè)向后兼容并支持DNS進(jìn)一步擴(kuò)展的協(xié)議。所以擴(kuò)展方案是以H)NS0為基礎(chǔ)，并在H)NS0之上增加一些新的字段來實(shí)現(xiàn)；
[0010]所述DNS消息分片信息的表示，首先在ENDS0的OPT偽資源記錄的Z域中定義一個(gè)AF(Applicat1n Fragmentat1n,應(yīng)用分段)位來標(biāo)識(shí)當(dāng)前的DNS邏輯實(shí)體對應(yīng)用層DNS消息分割的支持，由于在Z字段中第一個(gè)位已經(jīng)被DNSSEC所使用，所以將第二個(gè)位定義為AF位；
[0011]所述應(yīng)用層DNS消息分割功能的標(biāo)識(shí)和識(shí)別，在OPT的RDATA字段擴(kuò)展一個(gè)新的FRAGMENT選項(xiàng)字段來標(biāo)識(shí)每個(gè)分片的信息，考慮到UDP不存在ACK機(jī)制，一個(gè)8bit位的分片數(shù)量是比較適中的；選項(xiàng)的數(shù)據(jù)部分包含兩個(gè)字節(jié)，第一個(gè)字節(jié)定義當(dāng)前的DNS消息包含幾個(gè)分片，第二個(gè)字節(jié)表示當(dāng)前分片的序號(hào)；基于應(yīng)用層DNS消息分割的工作流程，需要在DNS標(biāo)準(zhǔn)協(xié)議中擴(kuò)展的新的字段，EDNS0規(guī)定最大的DNS消息的尺寸是4096字節(jié)，這個(gè)長度基本能夠滿足當(dāng)前的各方面需求，如果像TXT資源記錄那樣不能容納在一個(gè)最大為4096的DNS包中，可以切換到基于TCP的DNS傳輸方案。
[0012]所述應(yīng)用層DNS消息分割的工作流程，當(dāng)服務(wù)器端接受到請求消息后，確認(rèn)DNS請求消息的AF位置為1，同時(shí)認(rèn)為響應(yīng)消息足夠大，將進(jìn)行分片；如果當(dāng)前的服務(wù)器不支持應(yīng)用層DNS消息分割方案，將忽略AF位，將TC(轉(zhuǎn)換)位置為1，按照協(xié)議中的流程返回響應(yīng)消息；如果當(dāng)前的服務(wù)器支持應(yīng)用層DNS消息分割的方案，將會(huì)對響應(yīng)消息進(jìn)行分片；分片的標(biāo)準(zhǔn)是建議每個(gè)分片盡量不超過512字節(jié)，并按照資源記錄的邊界進(jìn)行分割，且每個(gè)分片的大小不一定必須一致，但同時(shí)分片的大小不能太小，以防止碎片化；同時(shí)將AF位置為1，將TC位置為0。FRAGMENT選項(xiàng)中填寫所有分片的數(shù)量和每個(gè)分片的序號(hào)。同時(shí)按照每個(gè)DNS分片中的各類資源記錄的數(shù)量，如實(shí)填寫每個(gè)分片中DNS報(bào)頭的資源記錄的計(jì)數(shù)值。其它字段的填寫按照一般的DNS協(xié)議執(zhí)行，且每個(gè)分片所填的信息都一致。
[0013]所述分片重裝的工作原理以DNS系統(tǒng)中不同實(shí)體的行為來說明:
[0014]一個(gè)支持應(yīng)用層DNS消息分割的解析器，將其OPT中Z域的AF位置為1，將FRAGMENT選項(xiàng)中的Total Fragment Number和Current Fragment Number分別置為0，由于擴(kuò)展了該方案后已經(jīng)不存在包尺寸的限制，所以在解析器中，應(yīng)該將所支持的最大UDP負(fù)載指定為最大值4096字節(jié)，4096字節(jié)的DNS響應(yīng)消息尺寸目前足夠能夠滿足當(dāng)前各種需求；請求消息的其它部分同普通的支持H)NS0的DNS消息一致；支持應(yīng)用層DNS消息分割的解析器需要記錄從發(fā)送時(shí)刻到接收到第一個(gè)DNS響應(yīng)消息分片的時(shí)刻的時(shí)間間隔，作為一個(gè)DNS請求的RTT值，當(dāng)解析器接收到第一個(gè)DNS響應(yīng)消息的分片并確認(rèn)AF位為1后，啟動(dòng)計(jì)時(shí)器和重裝隊(duì)列等待剩余分片；計(jì)時(shí)器的等待時(shí)間是一個(gè)RTT，如果在一個(gè)RTT時(shí)間間隔之內(nèi)接收到了所有的分片，則終止計(jì)時(shí)器，將所有分片重新組裝成完整的DNS響應(yīng)消息，并銷毀隊(duì)列；如果RTT到期，仍未收到所有的分片，則認(rèn)為部分的分片丟失或其它情況存在，這時(shí)已終止計(jì)時(shí)，并銷毀等待隊(duì)列；并認(rèn)定DNS請求失敗，則采用TCP發(fā)送DNS請求；
[0015]所述支持應(yīng)用層消息分割的服務(wù)器，DNS服務(wù)器支持應(yīng)用層DNS消息分割機(jī)制確認(rèn)響應(yīng)消息足夠大需要被分割，且確認(rèn)請求服務(wù)的解析器也支持應(yīng)用層DNS消息分割，則DNS服務(wù)