新規投稿のお知らせを受信されたい方は、サブスクリプションをご登録ください:

DNSリゾルバー、1.1.1.1のご紹介(冗談ではなく)

2018-04-01

7分で読了
この投稿はEnglishFrançaisDeutschEspañol简体中文でも表示されます。

Cloudflareのミッションは、より良いインターネットを構築することです。そして本日、DNSリゾルバー1.1.1.1 - 再帰的なDNSサービスをリリースします。このサービスでは、より速く、安全で、プライバシー中心のパブリックDNSリゾルバーを構築することで、インターネットの基盤をより強固なものにしています。DNSリゾルバー、1.1.1.1は、誰もがパブリックで使用することができます。これは、Cloudflareがこれまでコンシューマー向けにリリースしたはじめてのサービスです。

1.1.1.1

リゾルバーには1.1.1.11.0.0.1のIPv4 アドレスを使用しています。覚えやすいですね。これらのアドレスは、共同研究と本サービスの両方のために、APNICからCloudflareに提供されています。APNICの詳細については、APNICブログをご参照ください。

DNSリゾルバー、1.1.1.1はCloudflareのグローバルエニーキャストネットワークを経由して提供されています。

背景:DNSにおけるリゾルバーの役割に関する簡単な説明

私たちのDNSimpleの友人たちが、DNSの仕組みについての理解を助けてくれる、この素晴らしいDNSチュートリアルを作成しました。リゾルバー、ルートネームサーバーなどの説明がとてもわかりやすく書かれています。

dnsimple-howdns-works

ドメイン名を解決する場合、クエリはユーザーのエンドシステム (Webブラウザなど) から再帰的なDNSサービスに送られます。DNSレコードがサービスのローカルキャッシュにない場合、リカーサーは権威DNS階層にクエリして、必要なIPアドレス情報を検索します。リカーサーはDNSリゾルバー、1.1.1.1 が担当する部分です。それは高速である必要がありますし、最近は安全でなければなりません。

DNSリゾルバー、1.1.1.1の目標

当社のパブリックリゾルバーの目標はシンプルです。Cloudflareは、ユーザーのプライバシー保護の基準を引き上げながら、地球上で最速のパブリックリゾルバーを提供したいと考えています。インターネットの高速化のために、ユーザーからコンテンツまでの距離(遅延)を短縮することを目的として、当社ではすでに世界中にデータセンターを構築しています。最終的に、誰もが少なくとも1つのCloudflareデータセンターから10ミリ秒以内にいられるようにしたいと考えています。

Cloudflare_and_world-population-map

3月だけで、Cloudflareでは世界31か所に及ぶ新しいデータセンターを利用できるようになりました (イスタンブールレイキャビクリヤドマカオバグダッドヒューストン、インディアナポリス、モンゴメリー、ピッツバーグ、サクラメントメキシコシティテルアビブダーバン、ポートルイスセブシティエジンバラリガ、タリン、ビリニュスカルガリー、サスカトゥーン、ウィニペグジャクソンビル、メンフィス、タラハシーボゴタルクセンブルク、キシナウ)、ネットワークの他のすべての都市と同様に、新しいサイトでは初日からDNSリゾルバー、1.1.1.1をご利用いただけます!

当社の高速かつ高度に分散されたネットワークは、あらゆるプロトコルに対応するために構築されており、現在、インターネット上で最速の権威DNSプロバイダーとして、700万を超えるインターネットプロパティにサービスを提供しています。さらに、エニーキャストサービスを、13のルートネームサーバーのうちの2つに提供しています。理論的に考えると、次のステップは、ユーザーに高速な再帰DNSサービスを提供することでした。当社のリカーサーは、当社に併置された権威サーバーを利用できるため、すべてのドメイン名の検索が高速になります。

DNSSECでは、リゾルバーと権威サーバー間のデータの整合性を保証しますが、お客様への「ラストマイル」(最終区間)のプライバシーは保護しません。DNSリゾルバー、1.1.1.1は、新しいDNSプライバシー基準(DNS-over-TLS、およびDNS-over-HTTPS)の両方をサポートしています。これらはどちらも最終行程の暗号化を提供し、DNSクエリーのプライバシーを保ち、改ざんされることもありません。

リゾルバーのプライバシーに向けた取り組み

従来、リカーサーは、ルートまたは権限DNSへ到達する方法を見つけると、完全なドメイン名を任意の仲介者に送信します。これは、www.cloudflare.comにアクセスを試みた場合、ルートサーバーと「.com 」サーバーは両方とも完全なドメイン名 (つまり、www、cloudflare、comの部分)についてクエリーされます。ただし、ルートサーバーはリカーシブをドットコムにリダイレクトするだけで済みます(完全修飾ドメイン名の他のものとは無関係です)。このように、DNSを経由して個人のブラウジング情報すべてに容易にアクセスできることに関しては、たくさんの人が深刻なプライバシーの懸念を表明しています。これは、いくつかのリゾルバーのソフトウェアパッケージによって解決されていますが、すべてのソリューションが広く採用またはデプロイされているわけではありません。

DNSリゾルバー、1.1.1.1 は、初日からスタブリゾルバーと再帰リゾルバーの間での使用のために、定義/提案されたDNSプライバシー保護メカニズムをすべて提供します。少し解説を加えると、スタブリゾルバーとはお客様がお使いのオペレーティングシステムのコンポーネントで、再帰リゾルバーと通信するものです。RFC7816で定義された「DNSクエリ名の最小化(QNAME最小化)」のみを使用すると、DNSリゾルバー、1.1.1.1の働きにより、ルートやTLDなど、中間DNSサーバーに漏洩する情報が減少します。つまり、DNSリゾルバー、1.1.1.1は、リゾルバーに次の質問先を伝えるのに十分な名前しか送信しないことを意味します。

DNSリゾルバー、1.1.1.1 は、ポート853(DNS over TLS)でプライバシー対応のTLSクエリーもサポートしています。このため、Cloudflareではスヌーピングネットワークからクエリーを隠すことができます。さらに、実験的なDoH (DNS over HTTPS) プロトコルを提供することで、ブラウザや他のアプリケーションがDNSとHTTPSトラフィックを 1 つの接続に混在させることができるようになったため、エンドユーザーのプライバシーを高めながら、将来的には高速なサービスを多くの場面で提供できます。

DNSアグレッシブネガティブCachingを使うと、RFC8198で説明されているように、グローバルDNSシステムの負荷をさらに減らすことができます。この手法は、まず、ネガティブな(または存在しない)情報を一定期間保持する既存のリゾルバーのネガティブキャッシュの使用を試みます。DNSSECで署名されたゾーンと、キャッシュ内のNSECレコードから、リゾルバーは、リクエストされた名前が存在しないかどうかをさらにクエリーを実行せずに把握できます。ですから、たとえば、wwwwwww.クラウド、それから wwww.フレアという文字を打ち込んだとすると、2番目のクエリーには瞬時に「いいえ」(DNSの世界ではNXDOMAIN)という回答が返されます。アグレッシブネガティブCachingは、DNSSEC署名付きゾーンでのみ機能し、ルートと1544件のTLDのうち400件で本日から署名することができます。

当社では可能な場合にはDNSSEC検証を行っています。これにより、回答が正確で改ざんされていないことを確認できます。署名検証のコストは低く、積極的なネガティブキャッシュを行うことでもコストを節約できるため、この節約分でも十分これを賄うことができます。当社では、当社が提供する回答をユーザーのみなさまに信頼していただきたいと考えています。そのため、クライアントに悪い回答を提供することを極力避けるために可能なチェックを全て実行したいと考えています。

しかし、DNSSECはどんなエラーも許容しません。権威DNSオペレーターがDNSSEC構成でミスをすると、DNSSECはエラーを含む構成ドメインを解決できないことがあります。この問題を回避するために、Cloudflareでは「Negative Trust Anchors」をドメインに構成する予定です。DNSSECエラーが検出/検証されたドメインで、権威オペレーターによる設定修正が行われたら、それらを削除します。これにより、特定の誤設定された構成ドメインに対するDNSSEC検証を一時的に無効にして、エンドコンシューマーへのアクセスを復元することで、破損したDNSSECドメインの影響を制限できます。

どうやって構築したのか?

当初、当社は独自のリゾルバーを構築することを考えましたが、複雑になることと市場参入を考えてやめることにしました。次に、市場に出回っているすべてのオープンソースリゾルバーを調べました。多くの選択肢の中から、プロジェクトの目標のほとんどを満たすものに、選択肢を2、3に絞りました。結局、CZ NICのKnot Resolverの周りにシステムを構築することに決めました。これはもともと約2年半前にリリースされた最新のリゾルバーです。Knot Resolverを選択することで、ソフトウェアの多様性も向上します。転換点となったのは、同リゾルバーがOpenRestyに似た、当社が求めていたコア機能の多くを備えていることでした。Knot Resolverは積極的に活用されており、現在も改善が加えられています。

他の誰もやらないけれど、当社がやっているおもしろいこと

当社が求めていた高度な最新の機能は次のとおりです。

  • クエリーの最小化 RFC7816

  • DNS-over-TLS (Transport Layer Security) RFC7858

  • DNS-over-HTTPS プロトコルDoH

  • 積極的な否定的回答 RFC8198

小さな免責:Knot Resolverの元々の主要開発者であるMarek Vavrušaは、Cloudflare DNSチームで2年以上にわたり働いていました。

Cloudflareリゾルバーを高速化する方法

リゾルバーの速度に影響する要因はたくさんあります。まず何よりも大切なのは、Cacheに応答できるかどうか、ということです。Cacheへの回答が可能であれば、応答時間は、クライアントからリゾルバへーのパケットのラウンドトリップの時間だけで済みます。

1.1.1.1-dns-resolver-performance

リゾルバーが認証機関から回答を得る必要がある場合、物事は少し複雑になります。リゾルバーが名前を解決するためには、DNS階層に従う必要があります。つまり、リゾルバーはルートから複数の権威サーバーと通信する必要があるのです。例えば、アルゼンチンのブエノスアイレスのリゾルバーは、ドイツのフランクフルトのリゾルバーよりもDNS階層に従うのに時間がかかります。それは後者の方が権威サーバーに近いためです。この問題を回避するために、当社では一般的な名前のためにキャッシュを帯域外で事前入力します。つまり、実際のクエリーが来たときに、応答をキャッシュからフェッチする方がはるかに高速なのです。今後数週間にわたり、リゾルバーをより速くより良くするために、当社での取り組みを、高速Cachingも含めてブログでご紹介する予定です。

当社の広大なネットワークの問題の1つは、キャッシュヒット率が各データセンターで構成されているノード数に反比例することです。データセンターに最も近いノードが 1 つだけ存在する場合は、同じクエリーを2回尋ねると、2回目はキャッシュされた回答を取得するはずです。ただし、各データセンターには数百のノードが存在するため、キャッシュされていない応答が返され、リクエストごとに遅延料金が支払われることがあります。一般的なソリューションの 1 つは、キャッシュロードバランサーをすべてのリゾルバーの前に配置することです。しかし、単一障害点が発生します。当社では単一障害点は発生させません。

一元化されたキャッシュに依存する代わりに、DNSリゾルバ、1.1.1.1は革新的な分散キャッシュを使用しています。これについては、ブログの後半で説明します。

データポリシー

ポリシーの内容をご紹介します。当社では、クライアントIPアドレスを決して保存しません。DNSリゾルバーのパフォーマンス(リージョン内および/または難読化の後の人気のあるドメインに基づいてすべてのキャッシュを事前入力する、APNICの調査など)を向上させるものにのみ、クエリー名を使用します。

Cloudflareは、エンドユーザーを識別する情報は決してログに保存せず、当社のパブリックリゾルバーによって収集されたすべてのログは、24時間以内に削除されます。引き続き、当社ではプライバシーポリシーに準拠して、ユーザーデーターが広告主に販売したり、コンシューマーをターゲットにしないことを保証します。

セットアップする

ぜひ、https://1.1.1.1/ をご覧ください。とてもシンプルですから!

これらのアドレスについて

当社は、IPv4アドレス、1.0.0.1 と1.1.1.1のパートナーであるAPNICに感謝しています。(このアドレスの覚えやすさは誰もが同意することです)。彼らの長年の研究とテストがなければ、これらのアドレスを製品にすることは不可能でした。しかし、まだ道半ばです。今後のブログで、IPとの冒険についてご紹介するので楽しみにしていてください。

IPv6の場合、当社では2606:4700:4700። 1111と2606:4700:4700። 1001をサービスのために選びました。クールなIPv6アドレスを取得するのは簡単ではありません。しかし、数字だけを使用するアドレスを選択しました。

でも、覚えやすいアドレスを使うのはなぜでしょうか?パブリックリゾルバーの何が特別なのでしょう?当社では、自分たちの仕事のほとんどすべてを名前で呼びます。しかし、プロセスには最初のステップというものがあり、そこにこれらの数字が関係してきます。そこで、リゾルバーサービスをみつけるためには、当社側ではお客様がお使いのコンピューターや接続デバイスに入力された数字が必要なのです。

インターネットに接続する人ならだれでも当社のパブリックリゾルバーを使用することができ、その使用方法は https://1.1.1.1/にアクセスして「開始」をクリックすれば参照できます。

なぜ4月1日に発表するか?

日曜日は、2018年4月1日です(アメリカでは、4/1/2018と記述します。)41があるのがわかりますか?それで、1.1.1.1を今日発表することになったのです。1が4つ、だからです!もし、これで1.1.1.1をみなさんに覚えていただけるなら、この名前にして良かったです!

そして、今日はエープリルフールでもあります。多くの人にとって、今日はジョークや、いたずらや、害のない悪ふざけをする日です。この発表は、ジョークでも悪ふざけでも、いたずらでもありません。これは、DNSリゾルバー、 1.1.1.1 です! こちらでフォローしてください:#1dot1dot1dot1

Cloudflareは企業ネットワーク全体を保護し、お客様がインターネット規模のアプリケーションを効率的に構築し、あらゆるWebサイトやインターネットアプリケーションを高速化し、DDoS攻撃を退けハッカーの侵入を防ぎゼロトラスト導入を推進できるようお手伝いしています。

ご使用のデバイスから1.1.1.1 にアクセスし、インターネットを高速化し安全性を高めるCloudflareの無料アプリをご利用ください。

より良いインターネットの構築支援という当社の使命について、詳しくはこちらをご覧ください。新たなキャリアの方向性を模索中の方は、当社の求人情報をご覧ください。
DNS1.1.1.1PrivacyResolver製品ニュース

Xでフォロー

Cloudflare|@cloudflare

関連ブログ投稿

2024年10月24日 13:00

Durable Objects aren't just durable, they're fast: a 10x speedup for Cloudflare Queues

Learn how we built Cloudflare Queues using our own Developer Platform and how it evolved to a geographically-distributed, horizontally-scalable architecture built on Durable Objects. Our new architecture supports over 10x more throughput and over 3x lower latency compared to the previous version....

2024年10月08日 13:00

Cloudflare acquires Kivera to add simple, preventive cloud security to Cloudflare One

The acquisition and integration of Kivera broadens the scope of Cloudflare’s SASE platform beyond just apps, incorporating increased cloud security through proactive configuration management of cloud services. ...

2024年9月27日 13:00

AI Everywhere with the WAF Rule Builder Assistant, Cloudflare Radar AI Insights, and updated AI bot protection

This year for Cloudflare’s birthday, we’ve extended our AI Assistant capabilities to help you build new WAF rules, added new AI bot & crawler traffic insights to Radar, and given customers new AI bot blocking capabilities...