EDNS

　　隨着業務的複雜化和多樣化，RFC1035中定義的DNS消息格式和它支持的消息內容已經不足以知足一些DNS服務器的需求，因而，RFC2671中提出了一種擴展DNS機制EDNS(Extension Mechanisms for DNS)，並在其中推薦了一種傳遞包大小的EDNS0。我將EDNS0中的一些關鍵內容總結在這篇文章中，以便往後翻閱，同時但願可以幫助到像我這樣迷茫過的、探尋EDNS好久才知道其概貌的新人。

    一，什麼是EDNS？

     EDNS就是在遵循已有的DNS消息格式的基礎上增長一些字段，來支持更多的DNS請求業務。

     須要注意的是，像DNS服務器這樣一個大型且普遍應用的系統軟件，新增長擴展協議的時候必定要考慮到向後兼容性(backward compatibility)，即你增長了你這個特性的消息傳輸給未支持該特性的服務器時，後者依然能正確處理。

    二，爲何要有EDNS？

      RFC2671中指出EDNS被提出來的幾個理由：

         1）DNS協議頭部的第二個16字節中都已經被用的差很少了，須要添加新的返回類型(RCODE)和標記(FLAGS)來支持其餘需求；

         2）只爲標示domain類型的標籤分配了兩位，如今已經用掉了兩位（00標示字符串類型，11表示壓縮類型），後面若是有更多的標籤類型則沒法支持；

         3）當初DNS協議中設計的用UDP包傳輸時包大小限制爲512字節，如今不少主機已經具有重組大數據包的能力，因此要有一種機制來容許DNS請求方通知DNS服務器讓其返回大包；

        之後咱們會看到，DNSSEC機制和edns-client-subnet機制等都須要有EDNS的支持。

     三，EDNS的內容是什麼？

        怎樣在DNS消息協議的基礎上再增長一些字段呢？爲了保持向後兼容性，更改已有的DNS協議格式是不可能的，因此只能在DNS協議的數據部分中作文章。

        因此，EDNS中引入了一種新的僞資源記錄OPT（Resource Record），之因此叫作僞資源記錄是由於它不包含任何DNS數據，OPT RR不能被cache、不能被轉發、不能被存儲在zone文件中。OPT被放在DNS通訊雙方（requestor和responsor）DNS消息的Additional data區域中。

        1，OPT僞資源記錄中的內容有哪些呢？

          OPT pseudo-RR中的內容包含固定部分和可變部分。它的結構以下：

                圖1 OPT內容

 

    圖1中最下面的RDATA是可變部分，其他的部分都是固定部分：Name字段目前爲空；TYPE字段是OPT RR的類型編號，IANA爲其分配的是41（0x29）；TTL中是擴展的DNS消息頭部，下面會有介紹；RDLEN是可變部分RDATA的長度；RDATA是KV類型的可變部分。

     原來的TTL字段被用來存儲擴展消息頭部中的RCODE和flags，它的格式以下：

        

                           圖2 extended RCODE and flags Detail

     圖2中高位8個bit是擴展RCODE（返回狀態碼），這8個bit加上DNS頭部的4bit總共有12bit（8bit在高位），這樣就能夠表示更多的返回類型；

      VERSOION字段表示EDNS的版本（EDNS根據支持不一樣的擴展內容會有不少版本），這篇文章提到的內容的VERSION=0

      RFC2671中Z通常狀況下被髮送者設置爲0，接收方能夠忽略它。可是後續的擴展協議中會用到這16bit。

 

       OPT RR中可變部分RDATA的結構以下圖所示：

圖3 RDATA格式

    圖3中OPTION-CODE由IANA分配；OPTION-LENGTH是OPTION-DATA的長度；OPTION-DATA是具體長度。

      上面三個圖之間的關係用下圖看或許會清晰一點：

　　 須要注意的是，每一個DNS 消息中只能有一個OPT僞資源記錄，當有多中EDNS擴展協議時，各個{attribute, value}對一個緊接一個存儲在RDATA中。以下圖所示

   

能夠看到當有NSID和CSUBNET的時候，兩個RDATA緊密排列在OPT的RDATA字段中，它們兩的總長度由Data length指定。

        2，example

       好苦澀的理論啊，咱們拿一個實例看看EDNS0的格式吧！

       我在本身的機器上用bind-9.8.1-p1中的dig請求Google首頁，並把包大小參數設置爲768:

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

       用tcpdump抓包，而後用ethereal查看UDP包的內容，下圖是請求包的詳細內容：

圖4 request message

   圖4中藍色的是請求消息中的Additional data中的全部內容，咱們能夠看到有一個OPT RR，須要注意的是：

      1）TTL字段中的extended RCODE、VERSION和Z被ethereal拆分來顯示了；

      2）RDATA length爲0說明沒有可變消息RDATA，從下面的消息中能夠看到確實沒有RDATA(...)

 

 下圖是響應消息：

圖5 response message

圖5中能夠看出，Additional data中除了四個google權威域名服務器詳細信息外還有OPT RR，響應消息包的大小爲4096字節。

      3，Others

      RFC2671中還包含了不少EDNS0實現時請求方和響應方注意的事項，以及EDNS0帶來的問題，對它們感興趣的能夠移步這裏。

     四，參考文獻

      1，RFC2671

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