戴云偉，沈春苗

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

0 引言

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

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

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

1 DNS 重定向應用場景

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

1.1 惡意域名攔截

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

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

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

1.2 提高網(wǎng)絡質量

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

1.3 日志獲取與分析

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

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

2 DNS 重定向技術原理

如圖1 所示，用戶將終端A 的DNS 解析服務器地址設置為C。當需要解析域名時，正常的報文路徑為：

圖1 重定向工作原理

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

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

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

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

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

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

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

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

（3）服務器D 收到請求報文后，可以轉發(fā)給運營商內部DNS 解析服務器，獲取結果后，發(fā)回DNS 響應報文（MacD,IpC-＞MacBD,IpA）；

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

3 DNS 重定向實現(xiàn)

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

其中，第1 918 行會進行路由查找。因為非本機目的地址的報文最終的res.type 為RTN_UNICAST，執(zhí)行至1 936 行。該行相當于判斷net.ipv4.ip_forward 是否為1，若為1，那么報文就會被轉發(fā)；若為0，報文在此處就會被刪除。正常情況下，該值默認設置為0，所以報文會被刪除。

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

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

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

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

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

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

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

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

表1 連接跟蹤表條目信息表

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

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

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

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

3.2.1 內核如何將非本機IP 的報文轉送至本機

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

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

圖2 策略路由表匹配過程

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

3.2.2 如何使應用層能以非源地址發(fā)送報文

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

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

第3 行setsockopt 設置了IP_TRANSPARENT 選項；第7 行將非本機源地址綁定至socket。

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

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

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

4 性能對比實驗驗證

4.1 測試方案

為了降低中間設備對時延的影響，測試采用兩臺設備網(wǎng)卡直連方式，網(wǎng)絡拓撲結構如圖3 所示。

圖3 實驗拓撲結構

兩臺設備均為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 服務軟件為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 進行測試，若可以正常解析，則證明配置成功。

4.2 基于DNAT 的性能

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

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

基于DNAT 技術性能測試結果如下：

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

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

4.3 基于IP_TRANSPARENT 的性能

測試服務器的配置參考3.2 中的說明。基于IP_TRANSPARENT 技術的性能測試結果如下：

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

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

5 結語

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

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