智能DNS解析之edns-client-subnet篇

標籤：width   圖片   https   auth   工作方式   ati   根據   方式   需要   

　　摘要：智能DNS解析是CDN的重要組成部份，所謂的智能也就是根據請求使用者來對同一網域名稱作出相應不同解析(目前大多數網域名稱註冊商還沒提供線路解析的服務），所以CDN的調度準確性也就完全依靠DNS智能解析，但於由DNS是互連網上較早設計的協議但沒有考慮到今天網路的情況於應用。

 　

一、前言

　　智能DNS解析是CDN的重要組成部份，所謂的智能也就是根據請求使用者來對同一網域名稱作出相應不同解析(目前大多數網域名稱註冊商還沒提供線路解析的服務），所以CDN的調度準確性也就完全依靠DNS智能解析，但於由DNS是互連網上較早設計的協議但沒有考慮到今天網路的情況於應用。讓我們簡單的來看看傳統DNS的工作方式——

 

　　

 

　　在整個解析過程中。公用DNS代替使用者向根，頂級域，權威DNS去查詢結果並把結果返回給使用者，被查詢的權威DNS伺服器是無法知道具體是哪個使用者來查詢，這也是問題所在，既然無法獲得使用者IP又如何能精準調度呐？google提交了一份DNS擴充協議，允許DNS resolver傳遞使用者的ip地址給authoritative DNS server。

 

二、協議

 

DNS query會包含header和RR兩個部分

 

TYPE=41 為EDNS擴充內容

　　 

　　

 

OPTION-CODE： 2個位元組（在RFC裡最新定義是 0×0008, 老闆本為0x50fa）

OPTION-LENGTH： 2個位元組，描述它之後的內容長度(BYTE)

FAMILY： 2個位元組，1表示ipv4, 2表示ipv6

ADDRESS： 實際存放IP地址的地方，ipv4長度為4

 

三、測試

 

　　目前BIND不能支援EDNS需要打補丁後才能發送EDNS的查詢包，請先下載edns-client-subnet dig patch並安裝進BIND中。

 

1. 先將測試網域名稱做多線路的網域名稱解析

 

　　 

 

分別為edns.dns.com做了兩條DNS智能解析，分別來自上海電信的使用者解析到3.3.3.3，北京電信的使用者解析到2.2.2.2，其它的都解析到1.1.1.1。

2. 使用打過edns-client-subnet patch的DIG來查詢

 

　　

 

當client為180.149.128.1（上海電信IP）時可以正確返回對應的線路解析。

 

　　

 

當client為58.32.1.1（北京電信IP）時也可以正確返回對應的線路解析。

四、總結

經上測試使用edns-client-subnet可以解決當前CDN不能精準高度的痛點。但也可以看到真正要支援EDNS0還需要中間各個環節的給力。

 

　　1. 首先權威DNS要有智能解析的能力，一份精準的IP庫；

　　2. 權威要支援EDNS0的格式並且正確取出用戶端IP；

　　3. 公用DNS需要將用戶端IP資訊打包成EDNS0的格式發送查詢。

 

 

參考文檔

　　https://tools.ietf.org/html/draft-ietf-dnsop-edns-client-subnet-08

　　RFC2671中還包含了很多EDNS0實現時請求方和回應程式注意的事項，以及EDNS0帶來的問題。

 

智能DNS解析之edns-client-subnet篇