Cloudflareのサービス1.1.1.1および1.0.0.1、または「パブリックDNSシェルフが到着しました！」

Cloudflare は次の場所でパブリックDNSを導入しました。

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

ユーザーがリクエストの内容について落ち着くことができるように、「プライバシー優先」ポリシーが使用されていると言われています。

このサービスは、通常のDNSに加えて、 DNS-over-TLSおよびDNS-over-HTTPSテクノロジーを使用する機能を提供するという点で興味深いものです。これにより、プロバイダーは、リクエストの途中でリクエストをリッスンしたり、統計の収集、監視、および広告の管理を行えなくなります。 Cloudflareは、発表日（2018年4月1日、または米国の表記では04/01）が偶然選択されなかったと主張しています。

Habrオーディエンスは技術的に精通しているため、従来のセクション「なぜDNSが必要なのですか？」 これを投稿の最後に掲載します。ここでは、より実用的な有用事項の概要を説明します。

新しいサービスの使用方法は？

最も簡単なのは、DNSクライアント（または使用しているローカルDNSサーバーの設定の上流）で、上記のDNSサーバーアドレスを指定することです。 GoogleのDNSの通常の値（8.8.8.8など）、またはあまり一般的ではないYandexパブリックDNSサーバー （77.88.8.8など）をCloudflareのサーバーに置き換えることは意味がありますか？回答は、どのCloudflareがすべての競合他社よりも速いかを示しています（明らかにします：サードパーティのサービスによって測定が行われ、特定のクライアントへの速度はもちろん異なる場合があります）。

上記のDNS-over-TLSおよびDNS-over-HTTPSという、暗号化された接続（実際には応答が返される）を介して要求がサーバーに送信される新しいモードで作業することは、はるかに興味深いです。 残念ながら、それらは「そのまま」ではサポートされていません（著者は「これまで」と考えています）が、ソフトウェア（またはハードウェア）で作業を整理することは難しくありません。

DNS over HTTP（DoH）

名前が示すように、通信はHTTPSチャネルの上で行われます。

1. タッチポイント（エンドポイント）の存在-https://cloudflare-dns.com/dns-queryにあります 。
2. 要求を送信して回答を受け取ることができるクライアント。

要求は、 RFC1035 （HTTP POSTおよびGETメソッドで送信）で定義されたDNS Wireformat形式またはJSON形式（HTTP GETメソッドを使用）のいずれかです。 個人的には、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" } ] }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

明らかに、まれに（少なくとも1つは）ホームルーターがこの方法でDNSを使用できますが、これはサポートが明日表示されないという意味ではありません-そして、興味深いことに、ここでアプリケーションでDNSを完全に使用できます（既に行うように） Mozilla 、Cloudflareサーバー上のみ）。

DNS over TLS

デフォルトでは、DNSクエリは暗号化なしで送信されます。 DNS over TLSは、安全な接続でそれらを送信する方法です。 Cloudflareは、 RFC7858で規定されているように、標準ポート853でDNS over TLSをサポートしています。 cloudflare-dns.comホスト用に発行された証明書が使用され、TLS 1.2およびTLS 1.3がサポートされます。

通信の確立とプロトコルでの作業はほぼ次のようになります。

• DNSとの接続を確立する前に、クライアントはbase64 SHA256ハッシュ（SPKIと呼ばれる）でエンコードされたcloudflare-dns.comのTLS証明書を保存します
• 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サーバーにより適しているようです。 確かに、標準をサポートすることはあまり良くありませんが、期待しましょう！

会話の内容について説明する2つの言葉

DNSの略語はドメインネームサービスの略語です（つまり、「DNSサービス」はやや冗長であり、略語には「サービス」という単語が既にあります）。特定のホスト名がどのIPアドレスであるかを理解するための簡単なタスクを解決するために使用されます ユーザーがリンクをクリックするか、ブラウザーのアドレスバーにアドレスを入力するたびに（「 https://habrahabr.ru/post/346430/ 」など）、ユーザーのコンピューターはリクエストを送信するサーバーを見つけようとしますページのコンテンツを受信します。 habrahabr.ruの場合、DNSからの応答には、WebサーバーのIPアドレス178.248.237.68の指示が含まれます。その後、ブラウザーは、指定されたIPアドレスでサーバーに接続しようとします。

次に、「habrahabr.ruという名前のホストのIPアドレスは何ですか？」という要求を受け取ったDNSサーバーは、指定されたホストについて何かを知っているかどうかを判断します。 そうでない場合、彼は世界の他のDNSサーバーに要求を行い、ステップバイステップで、質問に対する答えを見つけようとします。 その結果、最終的な回答を見つけると、見つかったデータはまだ待機しているクライアントに送信され、さらにDNSサーバー自体のキャッシュに保存されます。これにより、次回同様の質問にはるかに速く回答できるようになります。

一般的な問題は、最初に、DNSクエリのデータがオープンフォームで送信されることです（これにより、トラフィックフローにアクセスできるすべての人がDNSクエリと受信した回答を分離し、独自の目的で分析できるようになります;これにより、 DNSクライアントの広告を正確にターゲティングする機能。これは非常に多くのことです！）。 第二に、一部のインターネットプロバイダー（私たちは指を指さず、最小のものではありません）は、1つまたは別の要求されたページの代わりに広告を表示する傾向があります（非常に簡単に実装されます：ホスト名habranabr.ruによるクエリの指定されたIPアドレスの代わりに、人はランダムですこれは、広告を含むページが返されるプロバイダーのWebサーバーのアドレスを返します）。 第三に、ブロックされたWebリソースのIPアドレスに関する正しいDNS回答をスタブページを含むサーバーのIPアドレスに置き換えることにより、個々のサイトをブロックする要件を満たすメカニズムを実装するインターネットアクセスプロバイダーがあります（その結果、著しく複雑なサイト）、またはフィルタリングを実行するプロキシサーバーのアドレスに送信されます。

ここでは、おそらく、サービスへの接続を説明するhttp://1.1.1.1/のサイトから画像を配置する必要があります。 ご覧のように、著者はDNSの品質に絶対的な自信を持っています（ただし、Cloudflareに別のものを期待することは困難です）。

サービスの作成者であるCloudflareを完全に理解できます：彼らは世界で最も人気のあるCDNネットワーク（コンテンツの配信だけでなく、DNSゾーンのホスティングも含む機能）の1つをサポートおよび開発することで利益を得ています。サーバーのアドレスをブロックすることで非常に頻繁に苦しむグローバルネットワークのどこに行くべき かを知らない人に教えるために 、 あまり知らない人 、つまり「叫び、who、落書き、「会社にとって、彼らのバイへの害が少ないことを意味します 知ってるよ。 そして、技術的な利点（些細なことですが、特に、無料のCloudflare DNSの顧客にとって、会社のDNSサーバー上にあるリソースのDNSレコードの更新は瞬時に行われます）により、この記事で説明されているサービスをさらに興味深いものにすることができます。