隨著業(yè)務(wù)的復(fù)雜化和多樣化，RFC1035中定義的DNS消息格式和它支持的消息內(nèi)容已經(jīng)不足以滿(mǎn)足一些DNS服務(wù)器的需求，于是，RFC2671 中提出了一種擴(kuò)展DNS機(jī)制EDNS(Extension Mechanisms for DNS)，并在其中推薦了一種傳遞包大小的EDNS0。我將EDNS0中的一些關(guān)鍵內(nèi)容總結(jié)在這篇文章中，以便日后翻閱，同時(shí)希望能夠幫助到像我這樣迷茫 過(guò)的、探尋EDNS很久才知道其概貌的新人。

? ? 一，什么是EDNS？

? ? ?EDNS就是在遵循已有的DNS消息格式的基礎(chǔ)上增加一些字段，來(lái)支持更多的DNS請(qǐng)求業(yè)務(wù)。

? ? ?需要注意的是，像DNS服務(wù)器這樣一個(gè)大型且廣泛應(yīng)用的系統(tǒng)軟件，新增加擴(kuò)展協(xié)議的時(shí)候一定要考慮到向后兼容性(backward compatibility)，即你增加了你這個(gè)特性的消息傳輸給未支持該特性的服務(wù)器時(shí)，后者依然能正確處理。

? ? 二，為什么要有EDNS？

? ? ??RFC2671中指出EDNS被提出來(lái)的幾個(gè)理由：

? ? ? ? ?1）DNS協(xié)議頭部的第二個(gè)16字節(jié)中都已經(jīng)被用的差不多了，需要添加新的返回類(lèi)型(RCODE)和標(biāo)記(FLAGS)來(lái)支持其他需求；

? ? ? ? ?2）只為標(biāo)示domain類(lèi)型的標(biāo)簽分配了兩位，現(xiàn)在已經(jīng)用掉了兩位（00標(biāo)示字符串類(lèi)型，11表示壓縮類(lèi)型），后面如果有更多的標(biāo)簽類(lèi)型則無(wú)法支持；

? ? ? ? ?3）當(dāng)初DNS協(xié)議中設(shè)計(jì)的用UDP包傳輸時(shí)包大小限制為512字節(jié)，現(xiàn)在很多主機(jī)已經(jīng)具備重組大數(shù)據(jù)包的能力，所以要有一種機(jī)制來(lái)允許DNS請(qǐng)求方通知DNS服務(wù)器讓其返回大包；

? ? ? ? 以后我們會(huì)看到，DNSSEC機(jī)制和edns-client-subnet機(jī)制等都需要有EDNS的支持。

? ? ?三，EDNS的內(nèi)容是什么？

? ? ? ??怎樣在DNS消息協(xié)議的基礎(chǔ)上再增加一些字段呢？為了保持向后兼容性，更改已有的DNS協(xié)議格式是不可能的，所以只能在DNS協(xié)議的數(shù)據(jù)部分中做文章。

? ? ? ? 所以，EDNS中引入了一種新的偽資源記錄OPT（Resource Record），之所以叫做偽資源記錄是因?yàn)樗话魏蜠NS數(shù)據(jù)，OPT RR不能被cache、不能被轉(zhuǎn)發(fā)、不能被存儲(chǔ)在zone文件中。OPT被放在DNS通信雙方（requestor和responsor）DNS消息的Additional data區(qū)域中。

? ? ? ? 1，OPT偽資源記錄中的內(nèi)容有哪些呢？

? ? ? ? ? OPT pseudo-RR中的內(nèi)容包含固定部分和可變部分。它的結(jié)構(gòu)如下：

? ? ? ? ? ? ? ? 圖1 OPT內(nèi)容

?

? ? 圖1中最下面的RDATA是可變部分，其余的部分都是固定部分：Name字段目前為空；TYPE字段是OPT RR的類(lèi)型編號(hào)，IANA為其分配的是41（0x29）；TTL中是擴(kuò)展的DNS消息頭部，下面會(huì)有介紹；RDLEN是可變部分RDATA的長(zhǎng) 度；RDATA是KV類(lèi)型的可變部分。

? ? ?原來(lái)的TTL字段被用來(lái)存儲(chǔ)擴(kuò)展消息頭部中的RCODE和flags，它的格式如下：

? ? ? ??

? ? ? ? ? ? ? ? ? ? ? ? ? ?圖2?extended RCODE and flags Detail

? ? ?圖2中高位8個(gè)bit是擴(kuò)展RCODE（返回狀態(tài)碼），這8個(gè)bit加上DNS頭部的4bit總共有12bit（8bit在高位），這樣就可以表示更多的返回類(lèi)型；

? ? ? VERSOION字段表示EDNS的版本（EDNS根據(jù)支持不同的擴(kuò)展內(nèi)容會(huì)有很多版本），這篇文章提到的內(nèi)容的VERSION=0

? ? ? RFC2671中Z一般情況下被發(fā)送者設(shè)置為0，接收方可以忽略它。但是后續(xù)的擴(kuò)展協(xié)議中會(huì)用到這16bit。

?

? ? ? ?OPT RR中可變部分RDATA的結(jié)構(gòu)如下圖所示：

圖3 RDATA格式

? ? 圖3中OPTION-CODE由IANA分配；OPTION-LENGTH是OPTION-DATA的長(zhǎng)度；OPTION-DATA是具體長(zhǎng)度。

? ? ? 上面三個(gè)圖之間的關(guān)系用下圖看或許會(huì)清晰一點(diǎn)：

　　 需要注意的是，每個(gè)DNS 消息中只能有一個(gè)OPT偽資源記錄，當(dāng)有多中EDNS擴(kuò)展協(xié)議時(shí)，各個(gè){attribute, value}對(duì)一個(gè)緊接一個(gè)存儲(chǔ)在RDATA中。如下圖所示

? ?

可以看到當(dāng)有NSID和CSUBNET的時(shí)候，兩個(gè)RDATA緊密排列在OPT的RDATA字段中，它們兩的總長(zhǎng)度由Data length指定。

? ? ? ? 2，example

? ? ? ?好苦澀的理論啊，我們拿一個(gè)實(shí)例看看EDNS0的格式吧！

? ? ? ?我在自己的機(jī)器上用bind-9.8.1-p1中的dig請(qǐng)求Google首頁(yè)，并把包大小參數(shù)設(shè)置為768:

? ? ? ? ? ? ? ? ? ? ? ? ./dig www.google.com.hk +bufsize=768

? ? ? ?用tcpdump抓包，然后用ethereal查看UDP包的內(nèi)容，下圖是請(qǐng)求包的詳細(xì)內(nèi)容：

圖4 request message

? ?圖4中藍(lán)色的是請(qǐng)求消息中的Additional data中的所有內(nèi)容，我們可以看到有一個(gè)OPT RR，需要注意的是：

? ? ? 1）TTL字段中的extended RCODE、VERSION和Z被ethereal拆分來(lái)顯示了；

? ? ? 2）RDATA length為0說(shuō)明沒(méi)有可變消息RDATA，從下面的消息中可以看到確實(shí)沒(méi)有RDATA(...)

?

?下圖是響應(yīng)消息：

圖5 response message

圖5中可以看出，Additional data中除了四個(gè)google權(quán)威域名服務(wù)器詳細(xì)信息外還有OPT RR，響應(yīng)消息包的大小為4096字節(jié)。

? ? ? 3，Others

? ? ? RFC2671中還包含了很多EDNS0實(shí)現(xiàn)時(shí)請(qǐng)求方和響應(yīng)方注意的事項(xiàng)，以及EDNS0帶來(lái)的問(wèn)題，對(duì)它們感興趣的可以移步這里。

? ? ?四，參考文獻(xiàn)

? ? ? 1，RFC2671

? ? ? 2，維基百科 ?http://en.wikipedia.org/wiki/EDNS

總結(jié)

以上是生活随笔為你收集整理的EDNS的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。