主持人 > 博客 > 管理 > 我們在地址 1.1.1.1 和 1.0.0.1 處遇到了來自 Cloudflare 的服務，或者“公共 DNS 架已到達！”

我們在地址 1.1.1.1 和 1.0.0.1 處遇到了來自 Cloudflare 的服務，或者“公共 DNS 架已到達！”

我們在地址 1.1.1.1 和 1.0.0.1 處遇到了來自 Cloudflare 的服務，或者“公共 DNS 架已到達！”

雲耀公司 呈現 公共 DNS 地址：

  • 1.1.1.1
  • 1.0.0.1
  • 2606：4700：4700 :: 1111
  • 2606：4700：4700 :: 1001

據說該政策是“隱私第一”，以便用戶可以放心地了解其請求的內容。

該服務的有趣之處在於，除了通常的 DNS 之外，它還提供了使用技術的能力 TLS上的DNS и DNS-過HTTPS，這將極大地防止提供商沿著請求路徑竊聽您的請求 - 並收集統計數據、監控、管理廣告。 Cloudflare 聲稱，宣布的日期（1 年 2018 月 04 日，或美國符號中的 01/XNUMX）並非偶然選擇的：一年中的哪一天會出現“四個單位”？

由於 Habr 的受眾精通技術，所以傳統的部分“為什麼需要 DNS？” 我會把它放在文章的最後，但在這裡我會說一些更實際有用的東西：

如何使用新服務？

最簡單的事情是在您的 DNS 客戶端中指定上述 DNS 服務器地址（或在您使用的本地 DNS 服務器的設置中指定為上游）。 替換通常的值是否有意義 谷歌域名系統 （8.8.8.8 等），或稍微不太常見 Yandex 公共 DNS 服務器 （77.88.8.8 和其他類似的）到 Cloudflare 的服務器 - 他們會為您決定，但適合初學者 時間表 響應速度，據此，Cloudflare 比所有競爭對手都快（我要澄清一下：測量是由第三方服務進行的，當然，特定客戶端的速度可能會有所不同）。

我們在地址 1.1.1.1 和 1.0.0.1 處遇到了來自 Cloudflare 的服務，或者“公共 DNS 架已到達！”

使用新模式會更有趣，其中請求通過加密連接發送到服務器（事實上，響應是通過它返回的），即提到的 DNS-over-TLS 和 DNS-over-HTTPS。 不幸的是，它們不支持“開箱即用”（作者認為這“還”），但在您的軟件（甚至在您的硬件）中組織它們的工作並不困難：

基於 HTTP 的 DNS (DoH)

顧名思義，通信是通過 HTTPS 通道進行的，這意味著

  1. 著陸點（端點）的存在 - 它位於該地址 https://cloudflare-dns.com/dns-query和
  2. 可以發送請求並接收響應的客戶端。

請求可以採用 DNS Wireformat 格式中定義的 RFC1035 （使用 POST 和 GET HTTP 方法發送），或以 JSON 格式（使用 GET HTTP 方法發送）。 對於我個人來說，通過 HTTP 請求發出 DNS 請求的想法似乎出乎意料，但其中有一個合理的顆粒：這樣的請求會經過許多流量過濾系統，解析響應非常簡單，生成請求甚至更容易。 通常的庫和協議負責安全性。

直接從文檔請求示例：

DNS Wireformat 格式的 GET 請求

$ curl -v "https://cloudflare-dns.com/dns-query?ct=application/dns-udpwireformat&dns=q80BAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB" | hexdump
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7f968700a400)
GET /dns-query?ct=application/dns-udpwireformat&dns=q80BAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB HTTP/2
Host: cloudflare-dns.com
User-Agent: curl/7.54.0
Accept: */*

* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
HTTP/2 200
date: Fri, 23 Mar 2018 05:14:02 GMT
content-type: application/dns-udpwireformat
content-length: 49
cache-control: max-age=0
set-cookie: __cfduid=dd1fb65f0185fadf50bbb6cd14ecbc5b01521782042; expires=Sat, 23-Mar-19 05:14:02 GMT; path=/; domain=.cloudflare.com; HttpOnly
server: cloudflare-nginx
cf-ray: 3ffe69838a418c4c-SFO-DOG

{ [49 bytes data]
100    49  100    49    0     0    493      0 --:--:-- --:--:-- --:--:--   494
* Connection #0 to host cloudflare-dns.com left intact
0000000 ab cd 81 80 00 01 00 01 00 00 00 00 03 77 77 77
0000010 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00
0000020 01 c0 0c 00 01 00 01 00 00 0a 8b 00 04 5d b8 d8
0000030 22
0000031

DNS Wireformat 格式的 POST 請求

$ echo -n 'q80BAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB' | base64 -D | curl -H 'Content-Type: application/dns-udpwireformat' --data-binary @- https://cloudflare-dns.com/dns-query -o - | hexdump

{ [49 bytes data]
100    49  100    49    0     0    493      0 --:--:-- --:--:-- --:--:--   494
* Connection #0 to host cloudflare-dns.com left intact
0000000 ab cd 81 80 00 01 00 01 00 00 00 00 03 77 77 77
0000010 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00
0000020 01 c0 0c 00 01 00 01 00 00 0a 8b 00 04 5d b8 d8
0000030 22
0000031

相同但使用 JSON

$ curl 'https://cloudflare-dns.com/dns-query?ct=application/dns-json&name=example.com&type=AAAA'

{
  "Status": 0,
  "TC": false,
  "RD": true,
  "RA": true,
  "AD": true,
  "CD": false,
  "Question": [
    {
      "name": "example.com.",
      "type": 1
    }
  ],
  "Answer": [
    {
      "name": "example.com.",
      "type": 1,
      "TTL": 1069,
      "data": "93.184.216.34"
    }
  ]
}

顯然，很少有（如果至少有一個）家庭路由器可以通過這種方式使用DNS，但這並不意味著明天不會出現支持- 並且有趣的是，在這裡我們可以在我們的應用程序中完全實現使用DNS（正如已經 將使 Mozilla，僅在 Cloudflare 服務器上）。

基於 TLS 的 DNS

默認情況下，DNS 查詢不加密傳輸。 DNS over TLS 是一種通過安全連接發送它們的方法。 Cloudflare 按照規定在標準端口 853 上支持 DNS over TLS RFC7858。 這使用為 cloudflare-dns.com 主機頒發的證書，支持 TLS 1.2 和 TLS 1.3。

建立連接並按照協議工作的過程如下：

  • 在建立 DNS 連接之前，客戶端會存儲 cloudflare-dns.com 的 TLS 證書（稱為 SPKI）的 base64 編碼的 SHA256 哈希值
  • DNS 客戶端與 cloudflare-dns.com:853 建立 TCP 連接
  • DNS客戶端發起TLS握手
  • 在 TLS 握手過程中，cloudflare-dns.com 主機會提供其 TLS 證書。
  • 一旦建立了 TLS 連接，DNS 客戶端就可以通過安全通道發送 DNS 請求，從而防止請求和響應被竊聽和欺騙。
  • 通過 TLS 連接發送的所有 DNS 查詢必須符合 通過 TCP 發送 DNS.

通過 DNS over TLS 進行請求的示例：

$ kdig -d @1.1.1.1 +tls-ca +tls-host=cloudflare-dns.com  example.com
;; DEBUG: Querying for owner(example.com.), class(1), type(1), server(1.1.1.1), port(853), protocol(TCP)
;; DEBUG: TLS, imported 170 system certificates
;; DEBUG: TLS, received certificate hierarchy:
;; DEBUG:  #1, C=US,ST=CA,L=San Francisco,O=Cloudflare, Inc.,CN=*.cloudflare-dns.com
;; DEBUG:      SHA-256 PIN: yioEpqeR4WtDwE9YxNVnCEkTxIjx6EEIwFSQW+lJsbc=
;; DEBUG:  #2, C=US,O=DigiCert Inc,CN=DigiCert ECC Secure Server CA
;; DEBUG:      SHA-256 PIN: PZXN3lRAy+8tBKk2Ox6F7jIlnzr2Yzmwqc3JnyfXoCw=
;; DEBUG: TLS, skipping certificate PIN check
;; DEBUG: TLS, The certificate is trusted.
;; TLS session (TLS1.2)-(ECDHE-ECDSA-SECP256R1)-(AES-256-GCM)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 58548
;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 1536 B; ext-rcode: NOERROR
;; PADDING: 408 B

;; QUESTION SECTION:
;; example.com.             IN  A

;; ANSWER SECTION:
example.com.            2347    IN  A   93.184.216.34

;; Received 468 B
;; Time 2018-03-31 15:20:57 PDT
;; From 1.1.1.1@853(TCP) in 12.6 ms

此選項似乎最適合滿足本地網絡或單個用戶需求的本地 DNS 服務器。 確實，標準的支持不是很好，但是 - 讓我們希望吧！

用兩個詞解釋對話內容

DNS 縮寫代表域名服務（所以說“DNS 服務”有點多餘，該縮寫已經包含“服務”一詞），用於解決一個簡單的任務 - 了解特定主機名具有的 IP 地址。 每當有人點擊鏈接或在瀏覽器地址欄中輸入地址（例如“https://habrahabr.ru/post/346430/”），人類計算機正在嘗試找出向哪個服務器發送請求以獲取頁面內容。 對於 habrahabr.ru，DNS 的響應將包含 Web 服務器 IP 地址的指示：178.248.237.68，然後瀏覽器將嘗試聯繫具有指定 IP 地址的服務器。

反過來，DNS 服務器在收到請求“名為 habrahabr.ru 的主機的 IP 地址是什麼？”後，會確定它是否知道有關指定主機的任何信息。 如果沒有，它會向世界上的其他 DNS 服務器發出請求，並逐步嘗試找出所提出問題的答案。 因此，在找到最終答案後，找到的數據會發送到仍在等待的客戶端，並且存儲在 DNS 服務器本身的緩存中，這將使您下次更快地回答類似的問題。

一個常見的問題是，首先，DNS 查詢數據以明文形式傳輸（這使得有權訪問流量的任何人都能夠隔離 DNS 查詢和他們收到的響應，然後根據自己的目的對其進行解析；這使得能夠為DNS 客戶端準確定位廣告，這是相當多的！）。 其次，一些 ISP（我們不會指責，但不是最小的）傾向於顯示廣告而不是一個或另一個請求的頁面（實現起來非常簡單：而不是由 habranabr.ru 查詢指定的 IP 地址）主機名，隨機人因此，返回提供商的網絡服務器的地址，其中提供包含廣告的頁面）。 第三，有些互聯網接入提供商實施了一種機制，通過將有關被阻止 Web 資源的 IP 地址的正確 DNS 響應替換為包含存根頁面的服務器的 IP 地址來滿足阻止單個站點的要求（因此，訪問此類網站明顯更複雜），或執行過濾的代理服務器的地址。

這應該是網站上的圖片。 http://1.1.1.1/，用於描述與服務的連接。 作者似乎對其 DNS 的質量非常有信心（但是，很難對 Cloudflare 抱有任何其他期望）：

我們在地址 1.1.1.1 和 1.0.0.1 處遇到了來自 Cloudflare 的服務，或者“公共 DNS 架已到達！”

人們可以充分理解該服務的創建者 Cloudflare：他們通過維護和開發世界上最受歡迎的 CDN 網絡之一（其功能不僅包括分發內容，還包括託管 DNS 區域）來謀生，並且，由於那些人的願望， 誰不精通，教那些 他們不認識誰, 對此 去哪兒 在全球網絡中，經常會遭受服務器地址被封鎖的困擾 我們先不說是誰 - 因此，對於公司來說，擁有一個不受“喊叫、口哨和塗鴉”影響的 DNS 意味著對其業務的損害較小。 技術優勢（雖然微不足道，但很好：特別是對於免費 DNS Cloudflare 的客戶來說，可以即時更新公司 DNS 服務器上託管資源的 DNS 記錄）使得使用帖子中描述的服務變得更加有趣。

只有註冊用戶才能參與調查。 登入， 請。

您會使用新服務嗎？

  • 是的，只需在操作系統和/或路由器上指定即可

  • 是的，我將使用新協議（DNS over HTTPs 和 DNS over TLS）

  • 不，我有足夠的當前服務器（這是公共提供商：Google、Yandex 等）

  • 不，我什至不知道我現在在用什麼

  • 我使用遞歸 DNS 和通往它們的 SSL 隧道

693 位用戶投票。 191 位用戶棄權。

來源： www.habr.com

添加評論