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