一種高效的DNS 重定向?qū)崿F(xiàn)方法*

戴云偉，沈春苗

（1.江蘇省未來網(wǎng)絡(luò)創(chuàng)新研究院，江蘇 南京 211111；2.南京師范大學(xué)，江蘇 南京 210093）

0 引言

域名系統(tǒng)（Domain Name System，DNS）[1-2]提供了方便記憶的域名與復(fù)雜的IP 地址之間的相互映射，促進(jìn)了互聯(lián)網(wǎng)的普及與發(fā)展?；ヂ?lián)網(wǎng)服務(wù)提供商（Internet Service Provider，ISP）除了提供基礎(chǔ)的用戶接入互聯(lián)網(wǎng)的服務(wù)外，通常還會(huì)自建DNS系統(tǒng)，為用戶提供域名解析服務(wù)[3]。應(yīng)用程序在訪問互聯(lián)網(wǎng)資源之前，一般必須先進(jìn)行域名解析，以獲取數(shù)據(jù)中心（Internet Data Center，IDC）服務(wù)器、內(nèi)容分發(fā)網(wǎng)絡(luò)（Content Delivery Network，CDN）服務(wù)器或緩存服務(wù)器的地址；之后，再與服務(wù)器進(jìn)行數(shù)據(jù)交互。

隨著互聯(lián)網(wǎng)業(yè)務(wù)日新月異，出于利益的考慮，越來越多的用戶主動(dòng)或者被動(dòng)修改了終端設(shè)備DNS解析服務(wù)器地址，這可能會(huì)導(dǎo)致DNS 請求出網(wǎng)，即由其他ISP 完成DNS 解析服務(wù)，因此本地運(yùn)營商對于這部分請求將無法管控。很顯然，運(yùn)營商希望擁有對DNS 的控制調(diào)度權(quán)限，從而盡量減少跨網(wǎng)請求，并盡可能將用戶調(diào)度至本網(wǎng)內(nèi)請求資源。這樣不僅可以降低用戶的解析時(shí)延，還可以減少用戶跨網(wǎng)訪問網(wǎng)絡(luò)資源，尤其是可以減少會(huì)消耗大量帶寬的圖片、語音和視頻類資源，因?yàn)檫@會(huì)導(dǎo)致高昂的跨網(wǎng)結(jié)算費(fèi)用。

本文在分析傳統(tǒng)DNS 引流技術(shù)實(shí)現(xiàn)及其缺陷基 礎(chǔ)上，提出了一種基于IP透明技術(shù)（IP_TRANSPARENT）的DNS 引流方法，不僅可以提高性能，而且部署運(yùn)維也相對簡單。

1 DNS 重定向應(yīng)用場景

通過重定向完成對DNS 系統(tǒng)的管控后，對于運(yùn)營商來說，以下列出幾種有實(shí)際應(yīng)用意義的場景。

1.1 惡意域名攔截

如果終端設(shè)備的DNS 解析服務(wù)器被設(shè)置為不法分子搭建的服務(wù)器，此時(shí)用戶若訪問了惡意域名，則可能會(huì)被引導(dǎo)至色情站點(diǎn)、賭博網(wǎng)站、釣魚網(wǎng)址等[4-6]。

2018 年，黑客利用D-Link 路由器的漏洞，入侵了至少500 個(gè)家用路由器。黑客入侵后更改受害者路由器上的DNS 配置，將受害者的DNS 請求重定向到黑客自己搭建的惡意DNS 服務(wù)器上，最終誘導(dǎo)原本想訪問正常銀行網(wǎng)站的受害者訪問釣魚網(wǎng)站，并惡意竊取受害者的銀行賬號(hào)密碼信息[7]。

對于此類攻擊，ISP 通過DNS 調(diào)度技術(shù)管控域名服務(wù)后，可以攔截DNS 請求，防止用戶被定向到惡意服務(wù)器，從而保護(hù)用戶數(shù)據(jù)。

1.2 提高網(wǎng)絡(luò)質(zhì)量

ISP 網(wǎng)內(nèi)（通常包括省內(nèi)和省外）有大量IDC資源，部分ISP 還會(huì)引入大量CDN 服務(wù)器和緩存服務(wù)器，用以緩存大量熱門圖片、音頻和視頻資源。當(dāng)某個(gè)用戶因出網(wǎng)DNS 請求，導(dǎo)致被調(diào)度到網(wǎng)外的情況時(shí)，ISP 可以通過DNS 引流技術(shù)將用戶引入本網(wǎng)內(nèi)IDC 資源或者緩存服務(wù)器，避免了跨網(wǎng)傳輸。這不僅可以提高用戶訪問速度，還可以降低ISP 網(wǎng)間結(jié)算費(fèi)用[8]。雖然工信部于2020 年7 月起，取消了中國移動(dòng)、中國電信、中國聯(lián)通間的單向結(jié)算政策，實(shí)行對等互聯(lián)，互不結(jié)算；但是對于其他運(yùn)營商，如廣電還是需要進(jìn)行跨網(wǎng)結(jié)算[9]。

1.3 日志獲取與分析

完全掌控DNS 解析服務(wù)情況下，運(yùn)營商可以獲取到完整的DNS 請求響應(yīng)數(shù)據(jù)。通過對數(shù)據(jù)進(jìn)行挖掘，不僅可以幫助運(yùn)營商提高IDC 資源引入的準(zhǔn)確度，還可以將數(shù)據(jù)用于安全分析，如郭烜臻等人提出的重綁定攻擊檢測方法[10]，吉星等人提出的基于DNS 日志的識(shí)別異常查詢[11]，以及王琪等人提出的通過處理DNS服務(wù)器日志來檢測DNS隧道[12]的方法等。

基于以上場景，通過實(shí)現(xiàn)高效DNS 引流技術(shù)來完成DNS 調(diào)度對于ISP 來說有一定的現(xiàn)實(shí)意義。

2 DNS 重定向技術(shù)原理

如圖1 所示，用戶將終端A 的DNS 解析服務(wù)器地址設(shè)置為C。當(dāng)需要解析域名時(shí)，正常的報(bào)文路徑為：

圖1 重定向工作原理

（1）終端A發(fā)出報(bào)文（MacA,IpA-＞MacBA,IpC），其中，MacA 表示A 的網(wǎng)卡物理地址（Media Access Control Address，MAC）地址，IpA 表示網(wǎng)卡的IP，MacBA 表示策略路由器B 與A 連接的網(wǎng)卡MAC 地址，IpC 為非運(yùn)營商DNS 服務(wù)器C 的IP 地址；

（2）策略路由器B 根據(jù)正常的路由策略會(huì)向服務(wù)器C 轉(zhuǎn)發(fā)出報(bào)文（MacBC,IpA-＞MacC,IpC）；

（3）服務(wù)器C 收到請求報(bào)文后，發(fā)出DNS 響應(yīng)報(bào)文（MacC,IpC-＞MacBC,IpA）；

（4）策略路由器B 根據(jù)正常路由策略，轉(zhuǎn)發(fā)報(bào)文（MacBA,IpC-＞MacA,IpA），這里剛好與第（1）步對應(yīng)，解析過程結(jié)束。

DNS 重定向需要向策略路由器下發(fā)重定向策略，但不同運(yùn)營商或者廠家的硬件設(shè)備，下發(fā)方式和命令都不一樣。在Linux 中下發(fā)重定向路由策略類似下面的命令：

該命令表示對于目的地址為IpC 且子網(wǎng)掩碼為255.255.255.255 的報(bào)文，通過與其直連的服務(wù)器D的IpD 地址轉(zhuǎn)發(fā)出去。但是該方法會(huì)將所有流量都引入服務(wù)器D，D 需要將非DNS 報(bào)文重新轉(zhuǎn)發(fā)給C服務(wù)器。如此，終端A 與服務(wù)器C 無法感知重定向服務(wù)器D 的存在。重定向參與情況下，報(bào)文的路徑如下：

（1）終端A發(fā)出報(bào)文（MacA,IpA-＞MacBA,IpC）；

（2）策略路由器B 根據(jù)重定向路由策略轉(zhuǎn)發(fā)出報(bào)文（MacBD,IpA-＞MacD,IpC）；

（3）服務(wù)器D 收到請求報(bào)文后，可以轉(zhuǎn)發(fā)給運(yùn)營商內(nèi)部DNS 解析服務(wù)器，獲取結(jié)果后，發(fā)回DNS 響應(yīng)報(bào)文（MacD,IpC-＞MacBD,IpA）；

（4）策略路由器B 根據(jù)正常路由策略，轉(zhuǎn)發(fā)報(bào)文（MacBA,IpC-＞MacA,IpA），這里剛好與第（1）步對應(yīng)，解析過程結(jié)束。

3 DNS 重定向?qū)崿F(xiàn)

通過向策略路由器下發(fā)策略，將報(bào)文引流至重定向服務(wù)器，此種情況下，報(bào)文的目的地址為非本機(jī)。以（CentOS Linux release 7.8.2003）為例，報(bào)文進(jìn)入內(nèi)核以后，需要通過函數(shù)ip_route_input_slow來查找路由，以下為部分代碼片段：

其中，第1 918 行會(huì)進(jìn)行路由查找。因?yàn)榉潜緳C(jī)目的地址的報(bào)文最終的res.type 為RTN_UNICAST，執(zhí)行至1 936 行。該行相當(dāng)于判斷net.ipv4.ip_forward 是否為1，若為1，那么報(bào)文就會(huì)被轉(zhuǎn)發(fā)；若為0，報(bào)文在此處就會(huì)被刪除。正常情況下，該值默認(rèn)設(shè)置為0，所以報(bào)文會(huì)被刪除。

根據(jù)之前的分析，重定向首先要解決的就是這個(gè)報(bào)文會(huì)被刪除的問題。下面介紹兩種實(shí)現(xiàn)方法。

3.1 基于DNAT 的傳統(tǒng)實(shí)現(xiàn)方法

傳統(tǒng)的實(shí)現(xiàn)方式一般是基于Linux 內(nèi)核中的網(wǎng)絡(luò)地址轉(zhuǎn)換（Network Address Translation，NAT），它由Netfilter 和Iptables 兩個(gè)獨(dú)立的部件構(gòu)成[13-14]。

（1）Netfilter 組件。它是Linux 內(nèi)核空間的一部分，在報(bào)文流經(jīng)內(nèi)核網(wǎng)絡(luò)協(xié)議棧的關(guān)鍵節(jié)點(diǎn)設(shè)置了一系列鉤子（HOOK）點(diǎn)，在每個(gè)HOOK 節(jié)點(diǎn)都設(shè)置了相應(yīng)的鉤子函數(shù)。同時(shí)該框架為用戶提供了接口，用戶可以編寫程序調(diào)用接口在鉤子節(jié)點(diǎn)處注冊鉤子函數(shù)。當(dāng)數(shù)據(jù)分組流經(jīng)每個(gè)鉤子關(guān)鍵檢測節(jié)點(diǎn)的時(shí)候，Linux 內(nèi)核會(huì)判斷是否有鉤子函數(shù)注冊在該鉤子節(jié)點(diǎn)處，如果有將會(huì)根據(jù)鉤子函數(shù)中定義的規(guī)則對數(shù)據(jù)分組的流向做出相應(yīng)的處理。

（2）Iptables 組件。它是Netfilter 框架在用戶空間的體現(xiàn)。使用者可以在用戶空間通過Iptables對Linux 內(nèi)核協(xié)議棧中定義的數(shù)據(jù)分組過濾規(guī)則進(jìn)行增加、修改和刪除等操作?；久罡袷綖椋篒ptables ［-t 表名］命令選項(xiàng)［鏈名］［條件匹配］－ j 目標(biāo)動(dòng)作或跳轉(zhuǎn)］

具體實(shí)現(xiàn)方式以CentOS 7 為例，執(zhí)行以下命令：

該命令會(huì)在網(wǎng)絡(luò)地址轉(zhuǎn)換（Network Address Translation，NAT）表 的NF_INET_PRE_ROUTING上注冊目的地址轉(zhuǎn)換（Destination Network Address Translation，DNAT）目標(biāo)函數(shù)。DNAT 是NAT 的一種，可以對數(shù)據(jù)包中的目的IP 地址和目的端口進(jìn)行地址轉(zhuǎn)換，轉(zhuǎn)換之后地址為本機(jī)地址。

該命令會(huì)將所有目的地址20.1.0.2 的報(bào)文修改為30.1.0.2。Linux 內(nèi)核中有關(guān)報(bào)文的處理流程為ip_rcv-＞NF_INET_PRE_ROUTING 鏈的HOOK 函數(shù)-＞ip_ rcv_finish-＞ip_route_input_slow，因此修改報(bào)文的過程是在路由之前。這樣fib_lookup 函數(shù)執(zhí)行后，res.type 的值為RTN_LOCAL，代碼最終會(huì)執(zhí)行到1 933行，成功提交至本地。這一過程依賴于連接跟蹤表，對于用戶數(shù)據(jù)報(bào)協(xié)議（User Datagram Protocol，UDP）協(xié)議，一次DNS 請求，連接跟蹤表會(huì)新增一條條目，該條目包含16 列，如表1 所示。

表1 連接跟蹤表?xiàng)l目信息表

報(bào)文被修改后，應(yīng)用層軟件就可以接受到該報(bào)文，進(jìn)行解析并提供響應(yīng)，但應(yīng)用層發(fā)出去的報(bào)文源地址為30.1.0.2。此時(shí)，NAT 模塊在內(nèi)核中再次起作用，根據(jù)連接跟蹤表的記錄，即將源地址還原為30.1.0.2。這樣終端就無法感知這一重定向的過程。

該方法的缺陷即是DNAT 本身，因?yàn)樗且粋€(gè)查表的過程。為了完成映射過程，內(nèi)核需要維護(hù)連接跟蹤表，即每個(gè)連接一個(gè)條目，通過增、刪、查等操作，來實(shí)現(xiàn)IP 地址的轉(zhuǎn)換與還原。此外，為了實(shí)現(xiàn)這一過程，內(nèi)核還必須使用鎖機(jī)制及多CPU的之間的同步，而這一操作過程會(huì)降低整體服務(wù)性能。同時(shí)，內(nèi)存占用會(huì)隨著鏈接跟蹤表?xiàng)l目數(shù)的增多而增加。

3.2 基于IP_TRANSPARENT 的實(shí)現(xiàn)方法

基于IP_TRANSPARENT 的實(shí)現(xiàn)方法的技術(shù)優(yōu)勢就在于，使用策略路由表避免了NAT 過程，從而完成重定向的過程。為了實(shí)現(xiàn)這一目標(biāo)需要解決以下3 個(gè)問題。

3.2.1 內(nèi)核如何將非本機(jī)IP 的報(bào)文轉(zhuǎn)送至本機(jī)

根據(jù)第3 節(jié)的描述，目的地址非本機(jī)的報(bào)文會(huì)被刪除，為了將報(bào)文送至本機(jī)，使用策略路由表來實(shí)現(xiàn)。

如圖2 所示，報(bào)文進(jìn)入路由匹配過程后，先根據(jù)rule 匹配找到路由表，然后使用該路由表中的條目進(jìn)行路由匹配。這里面的local 表、main 表和default 表是內(nèi)核內(nèi)置的。在Linux 中，函數(shù)fib_lookup 中的傳遞參數(shù)res.type 將決定報(bào)文的類型。根據(jù)第2 節(jié)中的第1 927 行可知，當(dāng)返回的類型為RTN_LOCAL 時(shí)，報(bào)文就會(huì)被發(fā)送至本機(jī)。通過如下配置可以實(shí)現(xiàn)此目的：

圖2 策略路由表匹配過程

第1 行表示創(chuàng)建新的自定義策略路由表；第2行表示對從eth0 口進(jìn)入DNS UDP 報(bào)文設(shè)置標(biāo)識(shí)為0x66；第3 行表示對于標(biāo)識(shí)為0x66 的報(bào)文，會(huì)進(jìn)行rt_test 自定義路由表的路由查詢；第4 行表示對于該路由表的所有報(bào)文都屬于local 類型，也就是res.type 的返回值RTN_LOCAL。

3.2.2 如何使應(yīng)用層能以非源地址發(fā)送報(bào)文

默認(rèn)情況下IP 路由在發(fā)送報(bào)文之前需要查找路由，中間有一個(gè)步驟就是調(diào)用__ip_dev_find 來查找源地址所屬于的網(wǎng)卡。顯然這里要發(fā)送的源地址是非本機(jī)的，如果不做特殊處理，報(bào)文會(huì)因?yàn)闊o法查找到所屬網(wǎng)卡而刪除。route.c 有如下代碼片段：

第2 266行表示若是設(shè)置了IP_TRANSPARENT，那么就會(huì)跳過源網(wǎng)卡查找階段，這就避免了報(bào)文被刪除。通過如下片段即可設(shè)置IP_TRANSPARENT選項(xiàng)：

第3 行setsockopt 設(shè)置了IP_TRANSPARENT 選項(xiàng)；第7 行將非本機(jī)源地址綁定至socket。

3.2.3 如何實(shí)現(xiàn)源地址的保存與還原

傳統(tǒng)的方法由NAT 幫助完成還原，而基于IP_TRANSPARENT 的方法則必須由應(yīng)用層來自己完成這一還原過程。其實(shí)現(xiàn)方法就是先保存源地址，發(fā)送之前再還原回源地址。為了獲取接受報(bào)文的源地址，需要使用recvmsg 來接受報(bào)文而不是常用的recvfrom，因?yàn)閞ecvmsg 可以獲取源地址，并保存下來。發(fā)送的時(shí)候，將接受時(shí)保存的源地址填充至struct msghdr 結(jié)構(gòu)體，再使用sendmsg 函數(shù)來發(fā)送響應(yīng)報(bào)文。

以Unbound 1.13.1 為例，用于接受UDP 請求報(bào)文的函數(shù)為comm_point_udp_ancil_callback，其內(nèi)部就是調(diào)用的recvmsg 函數(shù)。發(fā)送DNS 響應(yīng)報(bào)文使用的函數(shù)為comm_point_send_udp_msg_if，其內(nèi)部調(diào)用的也就是為sendmsg 函數(shù)。

4 性能對比實(shí)驗(yàn)驗(yàn)證

4.1 測試方案

為了降低中間設(shè)備對時(shí)延的影響，測試采用兩臺(tái)設(shè)備網(wǎng)卡直連方式，網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)如圖3 所示。

圖3 實(shí)驗(yàn)拓?fù)浣Y(jié)構(gòu)

兩臺(tái)設(shè)備均為4 核E3-1225 CPU，千兆網(wǎng)卡。Client 網(wǎng)卡的MAC 地址為00:90:11:7e:03:6a，IP 配置為10.1.0.2，測試軟件為Dnsperf 2.5.2[15]。Server網(wǎng)卡的Mac 地址為00:70:27:f0:00:c，IP 配置為30.1.0.2，DNS 服務(wù)軟件為Unbound 1.31.1[16]。為了測試，需要配置地址解析協(xié)議（Address Resolution Protocol，ARP）和路由如下所述。

（1）Client 的配置：

（2）Server 的配置:

完成以上配置后，再選擇3.1 或者3.2 的配置，就可以使用dig www.nat.test ＠20.1.0.2 進(jìn)行測試，若可以正常解析，則證明配置成功。

4.2 基于DNAT 的性能

為了實(shí)現(xiàn)DNAT，服務(wù)器需要配置iptables 如下：

iptables -t nat -I PREROUTING -p udp -d 20.1.0.0/24 -j DNAT --to 30.1.0.2

基于DNAT 技術(shù)性能測試結(jié)果如下：

可以看出每秒可以處理的請求數(shù)為160 000 左右。單個(gè)請求的平均時(shí)延為612 μs。

共測試了3 次，每秒處理請求數(shù)分別為：158 605、154 992,、160 480。平均每秒處理158 025 個(gè)請求。

4.3 基于IP_TRANSPARENT 的性能

測試服務(wù)器的配置參考3.2 中的說明。基于IP_TRANSPARENT 技術(shù)的性能測試結(jié)果如下：

可以看出每秒處理的請求數(shù)為200 000 左右，單個(gè)請求的平均時(shí)延為469 μs。

共測試3 次，每秒處理請求數(shù)分別為：209 017、206 483、208 769。平均每秒處理208 089 個(gè)請求。

5 結(jié)語

本文介紹了幾種DNS 重定向應(yīng)用場景，分析了常用傳統(tǒng)實(shí)現(xiàn)方法，闡述了內(nèi)核對于UDP 報(bào)文處理的部分流程，再結(jié)合Netfilter/Iptables、策略路由及IP_TRANSPARENT 技術(shù)提出DNS 的重定向方法。經(jīng)實(shí)驗(yàn)驗(yàn)證，特定硬件設(shè)備條件下報(bào)文處理性能提升約為25%，每秒處理約50 000 個(gè)請求。

本文方法不僅性能有所提升，而且與現(xiàn)網(wǎng)廣泛使用的DNAT 技術(shù)相比，由于避免了使用連接跟蹤表，不但節(jié)省了額外的解析時(shí)延和內(nèi)存的開銷，而且不受限于連接跟蹤表的容量，因此具有較高的實(shí)際應(yīng)用意義和技術(shù)參考價(jià)值。