Cloudflare：DNS解析器1.1.1.1

背景：快速了解解析器在DNS中的作用

我們?cè)贒NSimple的朋友制作了這個(gè)很棒的DNS教程，任何人都能從中學(xué)習(xí)DNS的工作原理。他們?nèi)娴亟忉屃怂杏嘘P(guān)解析器、根名稱服務(wù)器等的信息。

瀏覽器在解析域名時(shí)，query（詢問(wèn)請(qǐng)求）會(huì)從您的終端系統(tǒng)（即Web瀏覽器）傳輸?shù)竭f歸DNS服務(wù)。如果DNS記錄不在服務(wù)的本地緩存中，recursor將查詢權(quán)威DNS層次結(jié)構(gòu)找到您正在查找的IP地址信息。 DNS解析器1.1.1.1在recursor服務(wù)器中運(yùn)作。它必須是高速高效的，并且，在現(xiàn)在的網(wǎng)絡(luò)環(huán)境下它必須是安全的！

DNS解析器1.1.1.1的目標(biāo)

我們推出公共解析器的目標(biāo)很簡(jiǎn)單:Cloudflare希望在提高用戶隱私保護(hù)標(biāo)準(zhǔn)的同時(shí)，并做出全球速度最快的公共解析器。為了使互聯(lián)網(wǎng)運(yùn)行速度更快，我們已經(jīng)在全球各地建立數(shù)據(jù)中心，以縮短用戶的延遲時(shí)間。我們希望每個(gè)人都能在10毫秒內(nèi)至少連接到我們的一個(gè)數(shù)據(jù)中心點(diǎn)。

僅在3月份，我們就在全球啟用了31個(gè)新的數(shù)據(jù)中心（伊斯坦布爾，雷克雅未克，利雅得，澳門(mén)，巴格達(dá)，休斯頓，印第安納波利斯，蒙哥馬利，匹茲堡，薩克拉門(mén)托，墨西哥城，特拉維夫，德班，路易港，宿霧市，愛(ài)丁堡，里加，塔林，維爾紐斯，卡爾加里，薩斯卡通，溫尼伯，杰克遜維爾，孟菲斯，塔拉哈西，波哥大，盧森堡市，基希訥烏），并且我們所服務(wù)的其他城市一樣，這些數(shù)據(jù)中心從第一天就開(kāi)始運(yùn)行DNS解析器1.1.1.1！

我們建立如此高速且高度分布的網(wǎng)絡(luò)的目的在于服務(wù)所有的協(xié)議。我們目前是互聯(lián)網(wǎng)上最快的權(quán)威DNS提供商，擁有超過(guò)700萬(wàn)的互聯(lián)網(wǎng)資產(chǎn)。此外，我們已經(jīng)為十三個(gè)根域名服務(wù)器中的兩個(gè)提供了任播服務(wù)。邏輯上，下一步我們將為用戶提供更快速的遞歸DNS服務(wù)。我們的recursor服務(wù)器可以利用與我們位于同一位置的權(quán)威服務(wù)器，從而加快所有域名的查找速度。

雖然DNSSEC可確保解析器與權(quán)威服務(wù)器之間的數(shù)據(jù)完整性，但它并不能保護(hù)您“最后一英里”的隱私。而DNS解析器1.1.1.1達(dá)到了新興的DNS隱私標(biāo)準(zhǔn) - DNS-over-TLS和DNS-over-HTTPS，它們都提供最后一英里加密，以保證您的DNS查詢的私密性，免受篡改。

令解析器擁有隱私保護(hù)意識(shí)

以前，recursor找到了通向根或權(quán)威DNS的路徑時(shí)會(huì)將完整的域名發(fā)送給任意中介。這意味著，如果你要訪問(wèn)www.cloudflare.com，根服務(wù)器和.COM服務(wù)器均會(huì)對(duì)域名進(jìn)行完整的查詢（即www , cloudflare 和 com 的部分），即便是在根服務(wù)器僅僅需要將遞歸重定向到dot com（獨(dú)立于完全的域名信息中的任何其他內(nèi)容）的情況下。因此通過(guò)DNS用戶的所有個(gè)人瀏覽信息很容易暴露，這對(duì)許多人來(lái)說(shuō)是一個(gè)嚴(yán)重的隱私問(wèn)題。盡管一些解析器的軟件包已經(jīng)能夠解決這個(gè)問(wèn)題，但并非所有解決方案都能夠被適配或部署。

DNS解析器1.1.1.1從第一天使用開(kāi)始就提供了所有已定義和擬建的DNS隱私保護(hù)機(jī)制，用于存根解析器和遞歸解析器之間。對(duì)此不太熟悉的人僅需了解，存根解析器是操作系統(tǒng)中與遞歸解析器通信的組件。通過(guò)使用RFC7816中定義的DNS查詢名稱最小化，DNS解析器1.1.1.1減少了泄漏到中間DNS服務(wù)器（如根和TLD）的信息。這意味著DNS解析器1.1.1.1只要發(fā)送足夠的名稱，權(quán)威解析器就能告訴解析器下一個(gè)查詢的問(wèn)題在哪里。

DNS解析器1.1.1.1還支持在853端口（DNS over TLS）上啟用隱私的TLS查詢，因此我們可以將查詢隱藏在監(jiān)聽(tīng)網(wǎng)絡(luò)之外。此外，通過(guò)提供試驗(yàn)性DoH（DNS over HTTPS）協(xié)議，我們可以為終端用戶改善隱私保護(hù)以及之后的一些加速，因?yàn)闉g覽器和其他應(yīng)用程序現(xiàn)在可以將DNS和HTTPS流量混合到一個(gè)連接中。

而使用DNS主動(dòng)否定緩存（主動(dòng)負(fù)緩存），如RFC8198中所述，我們可以進(jìn)一步減少全局DNS系統(tǒng)的負(fù)載。該技術(shù)首先嘗試使用現(xiàn)有的解析器否定緩存，其在一段時(shí)間內(nèi)保持否定（或不存在）信息。對(duì)于標(biāo)識(shí)DNSSEC的區(qū)域和緩存中的NSEC記錄，解析器可以在不進(jìn)行任何進(jìn)一步查詢的情況下確定所請(qǐng)求的名稱是否不存在。因此，如果您鍵入 wwwwwww.某內(nèi)容，然后輸入 wwww.某內(nèi)容，第二個(gè)查詢可以很快地返回得到“否”（DNS世界中的NXDOMAIN）。主動(dòng)否定緩存僅適用于DNSSEC標(biāo)識(shí)區(qū)域，其中包括根和今天簽署的1544個(gè)TLD中的1400個(gè)。

我們盡可能使用DNSSEC驗(yàn)證，因?yàn)檫@樣可以確保返回響應(yīng)準(zhǔn)確無(wú)誤。信號(hào)驗(yàn)證本身成本很低，而我們從主動(dòng)否定緩存中所節(jié)省的費(fèi)用可以彌補(bǔ)這一點(diǎn)。我們希望我們的用戶信任我們給出的解決方案，并盡可能執(zhí)行所有檢查以避免我們給客戶帶來(lái)錯(cuò)誤的解答。

但是，DNSSEC非常不近人情。權(quán)威DNS運(yùn)營(yíng)商在DNSSEC配置中的錯(cuò)誤可能會(huì)使這些配置錯(cuò)誤的域無(wú)法解析。要解決此問(wèn)題，Cloudflare將在檢測(cè)和審查DNSSEC錯(cuò)誤的域上配置“不信任錨”，并在權(quán)威運(yùn)營(yíng)商糾正配置后將其刪除。這可以通過(guò)暫時(shí)禁用特定配置錯(cuò)誤的域的DNSSEC驗(yàn)證來(lái)限制損壞的DNSSEC域的影響，從而恢復(fù)最終使用者的訪問(wèn)通道。

我們是如何構(gòu)建它的？

最初，我們考慮構(gòu)建自己的解析器，但最終我們因其復(fù)雜性和進(jìn)入市場(chǎng)的種種因素而否決了這種方案。接著我們查看了市場(chǎng)上所有的開(kāi)源解析器; 從這個(gè)長(zhǎng)長(zhǎng)的清單中，我們將選擇范圍縮小到兩到三個(gè)能夠適應(yīng)大多數(shù)項(xiàng)目的目標(biāo)。最后，我們決定圍繞CZ NIC的Knot Resolver構(gòu)建系統(tǒng)。這是一款現(xiàn)代解析器，發(fā)布于兩年半前。選擇Knot Resolver還提高了我們的軟件多樣性。關(guān)鍵在于Knot Resolver具有我們想要的更多核心功能，它的模塊化架構(gòu)類似于OpenResty。目前Knot Resolver也正在積極應(yīng)用和開(kāi)發(fā)中。

我們正在做其他人還未嘗試的有趣的事情

我們目前想要的更先進(jìn)的功能是：

最小化查詢 RFC7816

DNS-over-TLS（傳輸層安全性） RFC7858

DNS-over-HTTPS協(xié)議 DoH

主動(dòng)否定響應(yīng) RFC8198

免責(zé)聲明：最初的Knot Resolver主要開(kāi)發(fā)商MarekVavru?a已經(jīng)在Cloudflare DNS團(tuán)隊(duì)工作了兩年多。

如何讓我們的解析器更快

有許多因素會(huì)影響解析器的速度。其中最主要的是：它可以通過(guò)緩存返回響應(yīng)嗎？如果可以，那么響應(yīng)時(shí)間僅僅相當(dāng)于從客戶端到解析器的數(shù)據(jù)包往返時(shí)間。

當(dāng)解析器需要從權(quán)威機(jī)構(gòu)獲得答案時(shí)，事情會(huì)變得復(fù)雜一些。解析器需要遵循DNS層次結(jié)構(gòu)來(lái)解析名稱，這意味著它必須與從根開(kāi)始的多個(gè)權(quán)威服務(wù)器通信。例如，我們?cè)诎⒏⒉家酥Z斯艾利斯的解析器比在德國(guó)法蘭克福的解析器需要用更長(zhǎng)時(shí)間來(lái)遵循DNS層次結(jié)構(gòu)，因?yàn)楹笳弑惹罢吒拷鼨?quán)威服務(wù)器。為了解決這個(gè)問(wèn)題，我們?yōu)橹髁饔蛎A(yù)先進(jìn)行帶外（光纖網(wǎng)絡(luò)通道外的管理協(xié)議信息傳輸）緩存，這意味著當(dāng)實(shí)際查詢開(kāi)始時(shí)，響應(yīng)內(nèi)容可以從緩存中獲取，這樣一來(lái)速度要快得多。在接下來(lái)的幾周內(nèi)，我們將陸續(xù)發(fā)布一些博客，講述其他我們?cè)谧龅氖沟媒馕銎鞲旄玫氖虑椋ㄎ覀兊目焖倬彺妗?/span>

我們擴(kuò)展網(wǎng)絡(luò)存在的一個(gè)問(wèn)題是：緩存的準(zhǔn)確率與每個(gè)數(shù)據(jù)中心中配置的節(jié)點(diǎn)數(shù)成反比。如果數(shù)據(jù)中心中只有一個(gè)節(jié)點(diǎn)離您最近，那么可以肯定，如果您兩次詢問(wèn)相同的查詢，那么第二次將得到緩存的答案。但是，由于我們每個(gè)數(shù)據(jù)中心都有數(shù)百個(gè)節(jié)點(diǎn)，您可能會(huì)得到一個(gè)未緩存的響應(yīng)，令每個(gè)請(qǐng)求延遲增加。有一個(gè)常見(jiàn)的解決方案是在所有解析器前面設(shè)置一個(gè)緩存負(fù)載均衡器，然而不幸的是它引入了單點(diǎn)故障。而我們不做單點(diǎn)故障。

DNS解析器1.1.1.1并非依據(jù)集中式緩存，而是使用創(chuàng)新的分布式緩存，這一點(diǎn)我們將在后面的博客中討論。

數(shù)據(jù)政策

我們保證永遠(yuǎn)不會(huì)存儲(chǔ)客戶端IP地址。我們只需要使用查詢名稱，用于改善DNS解析器的性能（例如，根據(jù)區(qū)域中的熱門(mén)網(wǎng)域和/或混淆后預(yù)緩存，APNIC研究）。

Cloudflare永遠(yuǎn)不會(huì)在日志中存儲(chǔ)任何標(biāo)識(shí)終端用戶的信息，我們的公共解析器收集的所有日志將在24小時(shí)內(nèi)刪除。我們會(huì)一直遵守我們的隱私政策，并確保沒(méi)有用戶數(shù)據(jù)出售給廣告商或用于定位消費(fèi)者。

設(shè)置

很簡(jiǎn)單，請(qǐng)?jiān)L問(wèn)https://1.1.1.1/ 。

關(guān)于地址

我們感謝APNIC，我們IPv4地址 1.0.0.1和 1.1.1.1（每個(gè)人都認(rèn)為這兩個(gè)地址非常容易記?。┑暮献骰锇椤Ｈ绻麤](méi)有多年的研究和測(cè)試，這些地址將無(wú)法投入建設(shè)。然而，我們?nèi)杂幸欢温芬?。?qǐng)持續(xù)關(guān)注我們接下來(lái)的博客，了解我們開(kāi)發(fā)這些IP的經(jīng)歷。

對(duì)于IPv6，我們選擇 2606:4700:4700::1111以及 2606:4700:4700::1001為我們的服務(wù)。獲得酷炫的IPv6地址并不容易; 但是，我們選擇了一個(gè)僅由數(shù)字組成的地址。

但為什么要使用易記的地址呢？公共解析器有什么特別之處？我們幾乎做什么都需要用到名字，然而這些過(guò)程總是需要有第一步，那就是這些數(shù)字的來(lái)源。我們需要一個(gè)數(shù)字輸入到您正在使用的任何計(jì)算機(jī)或連接設(shè)備中，以便找到解析器服務(wù)。

互聯(lián)網(wǎng)上的任何人都可以使用我們的公共解析器，您可以通過(guò)訪問(wèn)https://1.1.1.1/并點(diǎn)擊GET STARTED來(lái)了解如何操作。