| 您當(dāng)前位置：保定理工學(xué)院 >> 信息技術(shù)中心 >> 行業(yè)動(dòng)態(tài) >> 瀏覽文章 |
|
DNS的演進(jìn) 適應(yīng)不斷變化的互聯(lián)網(wǎng)格局 【行業(yè)動(dòng)態(tài)】 加入時(shí)間：2025年01月28日 信息來源：本站原創(chuàng) 作者：xjzx 訪問量： |
DNS（域名系統(tǒng)）是當(dāng)今互聯(lián)網(wǎng)的重要組成部分。隨著IPv4地址的耗盡和IPv6過渡期的延長(zhǎng)，網(wǎng)絡(luò)地址空間出現(xiàn)分裂，DNS名稱空間現(xiàn)已是讓互聯(lián)網(wǎng)成為一個(gè)網(wǎng)絡(luò)的決定性屬性。然而，DNS并非一項(xiàng)僵化且一成不變的技術(shù)。在互聯(lián)網(wǎng)的發(fā)展過程中，它發(fā)生了很大的變化，在此，讓我們看看DNS在哪些方面發(fā)生了變化，哪些方面保持不變。
早期的DNS
早期的互聯(lián)網(wǎng)體系結(jié)構(gòu)使用名稱作為IP地址的便捷別名。每臺(tái)主機(jī)都維護(hù)一個(gè)由名稱和地址對(duì)組成的本地列表文件。應(yīng)用程序從該文件中查找主機(jī)名稱，并在隨后的數(shù)據(jù)包交換過程中使用相對(duì)應(yīng)的地址。在許多方面，該文件都可以直接類比為電話網(wǎng)絡(luò)中的電話簿。
這種簡(jiǎn)單的框架有一個(gè)重大的缺點(diǎn)，即可擴(kuò)展性。隨著網(wǎng)絡(luò)中連接主機(jī)數(shù)量的增加，分發(fā)該文件更新副本的負(fù)擔(dān)也隨之增加，而且在所有這些本地名稱文件副本間保持寬松一致性的任務(wù)也變得更具挑戰(zhàn)性。描述互聯(lián)網(wǎng)名稱服務(wù)器的IEN61號(hào)文件于1978年發(fā)布，它似乎是當(dāng)今DNS最基本的前身。
大約5年后，在1983年，RFC 882使用樹形結(jié)構(gòu)名稱層次定義了分層名稱空間。該文件還將名稱服務(wù)器定義為一種服務(wù)：它擁有關(guān)于名稱層次結(jié)構(gòu)中某一部分的信息，并可轉(zhuǎn)介到其他名稱服務(wù)器，后者擁有關(guān)于名稱層次結(jié)構(gòu)中較低部分的信息。該文件還定義了域名解析器：該解析器能夠通過遵循轉(zhuǎn)介信息尋找到要查詢的目標(biāo)名稱服務(wù)器，然后從服務(wù)器獲取所需的信息，從而將名稱解析為其所存儲(chǔ)的屬性。RFC 883將DNS查詢和響應(yīng)定義為一個(gè)簡(jiǎn)單的無狀態(tài)協(xié)議。
這就是早期DNS規(guī)定的基本內(nèi)容。僅此而已。
現(xiàn)今DNS的大部分內(nèi)容都是在這些早期規(guī)范中定義的，而我們?cè)谶@過去的40年間所做的只是填補(bǔ)其中的細(xì)節(jié)。在此期間，DNS并沒有發(fā)生任何實(shí)質(zhì)性的變化。
演進(jìn)的壓力
不過，我認(rèn)為以上觀點(diǎn)忽略了DNS世界已經(jīng)出現(xiàn)的大量改進(jìn)。
DNS并非完美無缺。DNS的域名解析速度極慢，將變更引入分布式數(shù)據(jù)框架的速度更慢。DNS查詢的解析完全未考慮到用戶隱私。任何一方只要能觀測(cè)到用戶的DNS查詢數(shù)據(jù)包，便能輕易拼湊出用戶活動(dòng)的準(zhǔn)確信息。用于解析名稱的分布式無狀態(tài)方案很容易受到各種企圖竊聽DNS解析事務(wù)和操縱DNS響應(yīng)信息的影響。DNS不易抵御破壞性攻擊，經(jīng)常被用于開展高效的拒絕服務(wù)攻擊（DoS）。由于客戶端無法驗(yàn)證響應(yīng)的真實(shí)性和時(shí)效性，它也并不安全。
DNS解析名稱的操作可能極其不透明。使用并行服務(wù)器和解析器來提高DNS的恢復(fù)能力，會(huì)導(dǎo)致用于探索分布式數(shù)據(jù)結(jié)構(gòu)的路徑數(shù)量的組合“爆炸”。我們不可能事先知道哪些服務(wù)器可能被用于查詢解析，也不可能知道一個(gè)原始查詢可能會(huì)觸發(fā)多少個(gè)附加查詢。由于解析器可以直接從本地緩存對(duì)查詢做出響應(yīng)，因此無法預(yù)先知道響應(yīng)來自何處或響應(yīng)是否真實(shí)。
對(duì)于一項(xiàng)每個(gè)用戶不僅會(huì)使用，而且會(huì)暗中依賴的常見基本服務(wù)來說，DNS在實(shí)踐中遠(yuǎn)非一個(gè)可靠運(yùn)行工程的典范。
技術(shù)社區(qū)已經(jīng)在積極發(fā)展和改進(jìn)DNS，旨在彌補(bǔ)其中的一些不足，包括加快DNS解析速度、改善DNS解析的隱私性、提升DNS響應(yīng)的可信度以及抵御破壞DNS名稱解析完整性的行為。
DNS隱私
DNS并不是所謂的一個(gè)獨(dú)立的協(xié)議。默認(rèn)情況下，查詢是明確的。查詢者的IP地址、被查詢的服務(wù)器和被查詢的名稱對(duì)任何有能力檢查DNS流量的實(shí)體都是可見的。這不僅包括網(wǎng)絡(luò)中潛在的竊聽者，還包括發(fā)起DNS查詢的應(yīng)用程序所在的操作系統(tǒng)平臺(tái)、接收查詢的遞歸解析器以及遞歸解析器所使用的任何轉(zhuǎn)發(fā)代理。根據(jù)本地緩存的狀態(tài)，遞歸解析器可能需要在名稱服務(wù)器層次結(jié)構(gòu)中執(zhí)行一定程度自上而下的探索，向每一級(jí)的權(quán)威服務(wù)器詢問完整的原始查詢名稱。遞歸解析器通常會(huì)將自己列為這些查詢的來源，因此原始用戶的身份會(huì)被隱去，但查詢名稱仍然可見。
RFC 7858提供了通過傳輸層安全（Transport Layer Security，TLS）會(huì)話進(jìn)行DNS的規(guī)范，簡(jiǎn)稱為DoT。DoT允許客戶端和服務(wù)器以安全的方式設(shè)置共享會(huì)話密鑰，然后用于加密雙方之間的所有后續(xù)交互。TLS還可用于驗(yàn)證服務(wù)器名稱，以確?？蛻舳诉B接到的是指定服務(wù)器的實(shí)例。設(shè)置TLS會(huì)話需要一定的開銷，而這種方法最有效的應(yīng)用是在存根（Stub）解析器到遞歸（Recursive）解析器的環(huán)境中。在這種環(huán)境中，單個(gè)TLS會(huì)話可以保持開放并在后續(xù)查詢中被重復(fù)使用，從而在這些查詢中分?jǐn)偝跏荚O(shè)置的開銷。DoT標(biāo)準(zhǔn)規(guī)范定義其標(biāo)準(zhǔn)端口為TCP端口853，它允許旁觀者識(shí)別DoT的使用，并通過IP地址識(shí)別終端雙方，但不包括DNS查詢和響應(yīng)。
隨后的標(biāo)準(zhǔn)工作定義了基于QUIC（快速UDP互聯(lián)網(wǎng)連接）協(xié)議的DNS，即RFC 9250（DoQ）。QUIC提供的加密功能與TLS提供的功能類似，而QUIC傳輸解決了TCP固有的鏈路阻塞問題，并提供比UDP（用戶數(shù)據(jù)報(bào)協(xié)議）更高效的丟包恢復(fù)機(jī)制。
此外，DNS消息還可以通過HTTP（超文本傳輸協(xié)議）傳輸，即RFC 8484（DoH）。DoH使用端口443作為服務(wù)接收端口，在HTTP/2下使用TCP，而在基于QUIC的HTTP/3下使用UDP，因此DNS流量在很大程度上與Web流量沒有區(qū)別。HTTP在傳統(tǒng)DNS模型的基礎(chǔ)上，增加了對(duì)象緩存、重定向、代理、身份驗(yàn)證和壓縮的功能，但在DNS環(huán)境下如何使用上述功能尚不清楚。HTTP還允許服務(wù)器向客戶端推送內(nèi)容。在DoH方案中，可以允許使用無查詢DNS，即服務(wù)器向客戶端推送DNS響應(yīng)，而無需觸發(fā)任何初始DNS查詢。
在這些DNS加密傳輸方法中，遠(yuǎn)程服務(wù)器會(huì)知道客戶端的IP地址和客戶端正在進(jìn)行的查詢。在存根到遞歸（stub-to-recursive）方案中，即使雙方之間的網(wǎng)絡(luò)路徑是安全的，遞歸解析器也能知道用戶的DNS操作。使用基于HTTPS的遺忘式DNS（Oblivious DNS，RFC 9230），可以獲得更高的隱私級(jí)別。在這種情況下，沒有一個(gè)DNS服務(wù)器能夠同時(shí)知道客戶端的IP地址和DNS查詢的內(nèi)容。在這里，雙重加密與網(wǎng)絡(luò)內(nèi)的兩個(gè)獨(dú)立代理結(jié)合使用。客戶端使用DoH向第一個(gè)代理發(fā)送加密DNS查詢。該代理知道客戶的IP身份，但無法解密DNS查詢。該代理使用DoH向第二個(gè)代理發(fā)出自身的查詢，隱去客戶端的IP地址。第二個(gè)代理可以解密查詢，并使用傳統(tǒng)遞歸解析器的模式進(jìn)行解析。
這四項(xiàng)技術(shù)規(guī)范表明，DNS交互有可能披上一層安全的神秘“面紗”，但這些技術(shù)的普及程度仍是一個(gè)值得猜測(cè)的話題。加密傳輸會(huì)話給DNS基礎(chǔ)設(shè)施（遞歸解析器和權(quán)威服務(wù)器）的運(yùn)行帶來了更高的成本，目前尚不清楚如何將這些更高的成本納入當(dāng)前的DNS經(jīng)濟(jì)模式。因?yàn)樵诋?dāng)前的模式下，客戶端基本上無需為單個(gè)DNS查詢產(chǎn)生任何花銷。
DNS查詢名稱最小化（RFC 7816）則描述了一種完全不同的改善DNS隱私的方法。傳統(tǒng)的DNS解析模式規(guī)定，遞歸解析器在DNS層次結(jié)構(gòu)中自上而下交互時(shí)，會(huì)使用原始查詢名稱來詢問權(quán)威名稱服務(wù)器，從而將查詢名稱共享給一組服務(wù)器。而這種方法的基本原理是，客戶端不一定事先知道在哪里可能存在區(qū)域切割（Zone Cut）。查詢名稱最小化建議通過向距離原始查詢名稱最近的、已知的祖先權(quán)威名稱服務(wù)器發(fā)送請(qǐng)求，并要求提供委托記錄（NS）而不是原始查詢類型，從而最大限度地減少向權(quán)威名稱服務(wù)器披露的名稱信息量。這種方法不會(huì)增加DNS服務(wù)器基礎(chǔ)設(shè)施的開銷。它不提供通道安全，但限制了DNS名稱解析過程中的信息“泄漏”量。
從更廣泛的層面來看，這些DNS隱私保護(hù)措施都無法保證用戶收到的DNS響應(yīng)的真實(shí)性。這些措施限制了第三方竊聽DNS查詢和響應(yīng)的能力，但檢測(cè)（并可能拒絕）不真實(shí)的DNS響應(yīng)是DNS的另一個(gè)問題。
DNS真實(shí)性——DNSSEC
DNSSEC（域名系統(tǒng)安全擴(kuò)展）是對(duì)DNS的擴(kuò)展，由RFC 4033規(guī)定，它將每條記錄與加密生成的數(shù)字簽名關(guān)聯(lián)起來并存于DNSSEC簽名區(qū)域。DNSSEC不改變DNS名稱空間，也不改變DNS名稱解析協(xié)議。支持DNSSEC的客戶端可以要求DNS響應(yīng)包含DNSSEC簽名（如果該區(qū)域有DNSSEC簽名），然后可以使用該簽名驗(yàn)證響應(yīng)的真實(shí)性。
你可能會(huì)認(rèn)為，允許客戶端驗(yàn)證DNS響應(yīng)的工具會(huì)立即流行起來。如果應(yīng)用程序和服務(wù)使用的名稱與協(xié)議層使用的IP地址之間的關(guān)系被破壞，那么用戶就很容易被欺騙。然而，在最初的規(guī)范制定近30年后，DNSSEC仍難以獲得主流采用。問題的部分原因在于DNS協(xié)議與UDP傳輸?shù)膹?qiáng)綁定，當(dāng)附加簽名和密鑰導(dǎo)致響應(yīng)大小膨脹時(shí)，就會(huì)產(chǎn)生一系列問題。有一些問題在于，管理加密密鑰需要小心謹(jǐn)慎，以及加密驗(yàn)證的不可控性。還有很大一部分原因是，當(dāng)網(wǎng)絡(luò)開始使用TLS作為驗(yàn)證遠(yuǎn)程服務(wù)器身份的方法時(shí)，人們認(rèn)為，DNSSEC在創(chuàng)建DNS會(huì)話時(shí)所帶來的任何增量效益，與使用DNSSEC所花費(fèi)的大量精力和成本相比，都顯得不足為道。
由于這些原因，DNSSEC在DNS領(lǐng)域內(nèi)仍是一項(xiàng)“正在進(jìn)行的工作”。
查詢機(jī)制的演變
DNS基本規(guī)范使用一種有限的數(shù)據(jù)格式，其中查詢包含查詢名稱和查詢類型，而DNS響應(yīng)（如果通過UDP傳輸）的長(zhǎng)度被限制為512字節(jié)。DNS基本規(guī)范中對(duì)若干標(biāo)志字段、返回代碼和標(biāo)簽類型的大小限制，阻礙了DNSSEC的發(fā)展。解決這一問題的方法是使用所謂的偽資源記錄（OPT記錄），該記錄包含在DNS消息的附加數(shù)據(jù)區(qū)域。為確保向后兼容性，應(yīng)答者不應(yīng)使用OPT記錄，除非它出現(xiàn)在查詢中。這就是DNS的一般擴(kuò)展機(jī)制（EDNS）。
迄今為止，EDNS選項(xiàng)已用于支持DNSSEC功能、填充、TCP保持設(shè)置和客戶端子網(wǎng)字段。它還通過使用EDNS緩沖區(qū)來擴(kuò)展基于UDP的DNS消息的最大容量。
通常需要將服務(wù)名稱與提供服務(wù)的服務(wù)平臺(tái)位置分開，而服務(wù)記錄類型就是為了實(shí)現(xiàn)這一目的。服務(wù)記錄（SRV記錄）可以提供這種形式的靈活性。服務(wù)由主機(jī)名、端口標(biāo)識(shí)符和協(xié)議標(biāo)識(shí)符定義，相關(guān)的資源記錄用以提供TCP或UDP端口號(hào)和目標(biāo)服務(wù)平臺(tái)的規(guī)范服務(wù)名稱。SRV記錄可以指定多個(gè)服務(wù)目標(biāo)，并提供相關(guān)的使用偏好。使用SRV記錄的功能轉(zhuǎn)變是在DNS查詢中加載服務(wù)配置文件，而不是簡(jiǎn)單的域名。相對(duì)應(yīng)地，用戶接收到足夠的信息，能夠直接連接到所需的服務(wù)，而無需執(zhí)行進(jìn)一步的DNS查詢。
SVCB記錄規(guī)范（RFC 9460）對(duì)此進(jìn)行了進(jìn)一步擴(kuò)展。通過在客戶端嘗試建立連接之前向其提供更多信息，這些記錄為性能和隱私提供了潛在的好處。這代表了DNS設(shè)計(jì)方法的轉(zhuǎn)變，以前使用DNS資源記錄類型是為了分割與DNS名稱相關(guān)的信息，以便通過一系列查詢獲得有關(guān)服務(wù)名稱的完整信息集合。SVCB記錄高效地為服務(wù)查詢提供了一個(gè)“總括式”響應(yīng)，這樣客戶端只需進(jìn)行一次DNS查詢便可連接到服務(wù)，獲取足夠的信息。
授權(quán)記錄
授權(quán)（NS）記錄是DNS數(shù)據(jù)結(jié)構(gòu)的基本組成部分之一，它將DNS層次結(jié)構(gòu)中整個(gè)子樹的控制權(quán)從一個(gè)節(jié)點(diǎn)傳遞到另一個(gè)節(jié)點(diǎn)。
雖然NS記錄自DNS誕生以來就一直為其服務(wù)，但它也有一些局限性。授權(quán)記錄的目標(biāo)是一個(gè)或多個(gè)DNS服務(wù)器名稱，而不是它們的IP地址。在傳統(tǒng)模式下，IP地址是作為“膠水記錄”（Glue Records）提供的，被包含在DNS轉(zhuǎn)介響應(yīng)的附加區(qū)域中。但這種膠水記錄的真實(shí)性無法確定，多年來一直是許多DNS攻擊的焦點(diǎn)。NS記錄的目標(biāo)不能是CNAME別名。NS記錄由父區(qū)域和子區(qū)域共享，子區(qū)域則被視為該記錄的權(quán)威。這意味著，雖然父區(qū)域名稱服務(wù)器可以（也必須）使用此NS記錄作出轉(zhuǎn)介響應(yīng)，但不能為其提供DNSSEC簽名，無法在轉(zhuǎn)介響應(yīng)中提供DNS服務(wù)配置文件。如果可以使用加密傳輸協(xié)議訪問區(qū)域的權(quán)威服務(wù)器，NS記錄則不能提供這種能力。
IETF的授權(quán)工作組（Deleg Working Group）正在開展工作，研究如何將現(xiàn)有的DNS服務(wù)器的服務(wù)綁定映射規(guī)范（RFC 9461）用作更靈活的授權(quán)記錄，以解決現(xiàn)有NS授權(quán)形式中存在的部分或全部缺陷。
替代名稱系統(tǒng)
互聯(lián)網(wǎng)協(xié)議套件可被視為一系列元素的集合，包括尋址、路由、轉(zhuǎn)發(fā)和命名，用不同的技術(shù)替代某一元素并不一定會(huì)對(duì)其他元素產(chǎn)生影響。例如，在尋址領(lǐng)域，從IPv4過渡到其它IP版本并不要求對(duì)路由、轉(zhuǎn)發(fā)或命名進(jìn)行任何根本性的改變。DNS名稱系統(tǒng)也是如此。替代名稱系統(tǒng)可以使用，而且在某種程度上可以與DNS共存。
在傳統(tǒng)的DNS解析模式中，用戶幾乎無法控制自己的DNS設(shè)置。一些懂技術(shù)的用戶可能會(huì)選擇與默認(rèn)設(shè)置不同的設(shè)置，但這樣做的動(dòng)力不大，絕大多數(shù)用戶的DNS設(shè)置都是由管理員通過DHCP（動(dòng)態(tài)主機(jī)配置協(xié)議）等協(xié)議配置的。
目前使用的許多替代名稱系統(tǒng)都與使用它們的特定應(yīng)用程序捆綁在一起：特定的替代名稱系統(tǒng)通常與相應(yīng)的應(yīng)用程序綁定，而該應(yīng)用程序通常會(huì)繞過管理員控制的設(shè)置和任何預(yù)先配置的DNS設(shè)置。例如，Tor項(xiàng)目使用自己的名稱系統(tǒng)，繞過了傳統(tǒng)的DNS解析。用戶可以安裝Tor瀏覽器，它將對(duì)以.ONION結(jié)尾的名稱使用Tor名稱系統(tǒng)，而將其他任何名稱轉(zhuǎn)發(fā)給本地DNS解析庫。應(yīng)用程序開發(fā)人員可以選擇使用哪種名稱系統(tǒng)，而用戶甚至不知道他們正在使用另一種名稱系統(tǒng)，也不了解潛在的影響。
各種形式的試驗(yàn)都采用了去中心化模式，這種模式摒棄了單一名稱層次結(jié)構(gòu)，允許單個(gè)名稱存在于非結(jié)構(gòu)化的扁平名稱空間中。將名稱與“所有者”關(guān)聯(lián)起來的底層注冊(cè)框架通常依賴于某種類似于區(qū)塊鏈的方法，將名稱與公鑰值的關(guān)聯(lián)存入?yún)^(qū)塊鏈中。目前存在許多這樣的替代名稱系統(tǒng)，包括以太坊名稱服務(wù)的ENS（在其區(qū)塊鏈中使用所謂的“智能合約”）和Unstoppable Domains（使用區(qū)塊鏈平臺(tái)，但將名稱空間作為一個(gè)集中運(yùn)營(yíng)的空間）。GNU名稱系統(tǒng)（GNS）也是一個(gè)提供名稱持久性的去中心化平臺(tái)。GNS沒有根區(qū)的概念。相反，GNS使用“起始區(qū)域”（Start Zone）的概念，由本地配置并決定從哪里開始解析。由于本地用戶可以完全控制自己的起始區(qū)域，因此每個(gè)GNS用戶都可能使用不同的名稱空間。因此，GNS無法保證名稱的全局唯一性，也無法保證特定名稱對(duì)不同用戶的解析結(jié)果相同。GNS唯一能保證的是，具有相同起始區(qū)域的用戶將擁有相同的名稱空間視圖。每個(gè)唯一的起始區(qū)域都定義了自己的名稱空間。這實(shí)際上與使用不同根區(qū)的DNS解析類似。GNS的主要?jiǎng)?chuàng)新之處在于用分布式哈希表取代了搜索層次結(jié)構(gòu)，而分布式哈希表可以包含與其他哈希表的鏈接。
這些替代名稱系統(tǒng)與現(xiàn)有的DNS名稱空間的交互方式多種多樣。有些系統(tǒng)試圖與DNS共存，其替代名稱是DNS名稱空間某種形式的擴(kuò)展，可能與不同的名稱解析協(xié)議相關(guān)聯(lián)。而其他系統(tǒng)則完全獨(dú)立，不與DNS共存。這種情況多見于特定應(yīng)用環(huán)境，即應(yīng)用環(huán)境只與替代名稱空間相關(guān)聯(lián)。
結(jié)論
只有完全奄奄一息的技術(shù)才能不受變化的影響！隨著數(shù)字技術(shù)和服務(wù)的發(fā)展，對(duì)相關(guān)名稱空間的要求也在以新型和不可預(yù)測(cè)的方式發(fā)生變化。
DNS是一個(gè)有趣的例子，因?yàn)榈侥壳盀橹?，它能夠在不需要?duì)其名稱空間的結(jié)構(gòu)、分布式信息模型或名稱解析協(xié)議進(jìn)行根本性修改的情況下，對(duì)不斷發(fā)展的互聯(lián)網(wǎng)做出反應(yīng)。迄今為止，DNS中的大多數(shù)演變都是以保持向后兼容性的方式進(jìn)行的，而且在很大程度上保持了基本名稱空間的內(nèi)聚性。
然而，展望未來，在整個(gè)互聯(lián)網(wǎng)上保持這種內(nèi)聚性并不是必然結(jié)果。國(guó)家和地區(qū)層面對(duì)內(nèi)容訪問設(shè)置限制的壓力，往往表現(xiàn)為對(duì)內(nèi)容服務(wù)名稱的解析設(shè)置選擇性阻礙，而DNS卻要承擔(dān)支持互聯(lián)網(wǎng)中這種選擇性碎片化的擔(dān)子。EDNS客戶端子網(wǎng)擴(kuò)展可能被用來實(shí)施這一點(diǎn)，其中對(duì)查詢的響應(yīng)可能不僅依賴于查詢的名稱，還依賴于查詢者是誰。很可能這種更精確且更碎片化的名稱空間模型將持續(xù)存在，并導(dǎo)致一個(gè)日益碎片化的互聯(lián)網(wǎng)。
來源：APNIC |