週刊BCN主催 全国キャラバン2019 in 大阪 講演ダイジェスト
週刊BCN主催 全国キャラバン2019 in 大阪 講演ダイジェスト

本記事は、2019年12月6日に大阪にて開催された「週刊BCN全国キャラバン2019」の講演レポートをお届けします。 なお、記事の末尾には、講演資料のダウンロードリンクを設置しています。あわせてご利用ください。 ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー 昨年末に開催された週刊BCN主催のリセラー向け全国キャラバン/大阪会場に、CDNetworksが協賛・講演いたしました。 年末の慌ただしい中、会場に足をお運びいただきました皆様には厚く御礼申し上げます。 誠にありがとうございました。 講演では、当社のコンテンツ・デリバリ・ネットワーク(以下、CDN)サービスをベースに、現在提供している各種サービス、パートナープログラム概要についてご紹介させていただきました。 ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー   <CDNetworks講演> 「Web高速化だけじゃない! CDNベンダが提供するネットワーク高速化サービスの効率的活用術、教えます」     CDNetworksご紹介   CDNetworksは、他社がカバーしていない中国・ロシアにも進出し、全世界すべて自社プラットフォームでサービスを展開する唯一のグローバルCDNプロバイダとしてこれまで歩んできました。 現在、弊社が提供するサービスはCDNによるWeb高速化からWebセキュリティ、ネットワーク高速化、また、Webサイト以外の拠点間通信やWebアプリケーションの高速化、クラウドインフラまでをサポートし、幅広くサービスを展開しています。   (クリックで拡大)   CDNetworksのサービスラインアップについてご紹介させていただきます。   CDNサービスと基本概念   Webサイトはいつでも早く見られて当然という時代背景からも、CDNサービスは今や必要不可欠なものとなっています。 (クリックで拡大)   一般に、Webサイトの表示が3秒以内であればそれほど不都合に感じることはないですが、 5秒を超えると約70%の人がイライラしてほかのWebサイトに移ってしまい、 10秒を超えてしまうと、そのサイトへはもう見に行かない、と言われています。   (クリックで拡大)   弊社のCDNサービスは、グローバルで数十Tbps以上のキャパシティを保有しており、常時大量のトラフィックを配信しています。     Webセキュリティ   CDNによるWebサイトの安定化の次に必要なのが、Webサイトを外部の攻撃から守るということです。Webサイトは、日々DDoS攻撃やアプリケーションの脆弱性を狙った攻撃にさらされています。これらの攻撃からWebサイトを守るためのセキュリティサービスもCDNサービスに組み込む形で提供しています。 (クリックで拡大)   CDNにDDoS防御機能を付加することで、常時監視とDDoS攻撃をブロックし、正常なリクエストのみが処理されるようになります。   (クリックで拡大) WAFサービスもCDNプラットフォームに統合しているもので、静的なシグネチャベースによる防御と動的なBot検知のブロックを行います。 これら双方を取り入れることで、より効果的に、かつ強固にWebサイトを攻撃から守ることができます。     CDNetworksインフラの応用活用(ネットワーク高速化)   ここからは、弊社インフラを活用した新分野のサービスのご紹介です。   (クリックで拡大)   クラウド型WANアクセラレータ(HDT:ハイスピード・データ・トランスミッション)は、CDNの概念とは異なる仕組みの高速化サービスです。CDNの技術を組み合わせることで、あらゆる通信の最適化を行うサービスです。 HTTP/HTTPSだけでなく、VPNをはじめとする様々な通信の高速化に対応します。 利用シーンの例を挙げると、海外拠点間とのデータやファイルのやり取りの高速化など、企業の生産性向上にもつながります。   また、クラウド型WANアクセラレータのオプションサービスとして、中国・香港限定の仮想専用線サービスも提供しています。…

[第4回]KSKロールオーバーへの備え~KSKロールオーバー実施前に必ず確認すべきこと
[第4回]KSKロールオーバーへの備え~KSKロールオーバー実施前に必ず確認すべきこと

  第1回はDNSの仕組みとDNSSECについて解説しました。 第2回は電子署名の仕組みとZSK(ゾーン署名鍵)の役割について解説しました。 第3回はZSKでは十分でない信頼性を補完するKSK(鍵署名鍵)について解説しました。 最終回となる本稿では、KSKロールオーバーが実施される前に必ず確認しておくべき事項をお伝えします。   いよいよKSKロールオーバーがJST(日本時間)の10月12日 午前1時(UTC 10月11日 午後4時)に実施されます。 実施前に改めて必要事項を確認し、万全の体制を整えることをお勧めします。     誰が対策するのか   (クリックで拡大)   第1回で触れた通り、KSKロールオーバーの対策を行うのはキャッシュDNSサーバの管理者です。しかし利用者であるユーザも影響の有無について理解する必要があります。     確認事項   KSKロールオーバーに関連して確認が必要な点を記載します。以下のキャッシュDNSサーバ環境はCentOS 7+BIND 9.9.4(chrootなし)を前提としています。     ●DNSSECの検証機能を利用しているか確認する   digコマンドが利用できる環境で以下のコマンドを実行します。「xxx.xxx.xxx.xxx」にはチェック対象のキャッシュDNSサーバのIPアドレスまたはFQDNを入力します。    $ dig @xxx.xxx.xxx.xxx dnssec-failed.org a +dnssec   DNSSECの検証機能が有効なキャッシュDNSサーバであれば、「status: SERVFAIL」の応答となります。「dnssec-failed.org」はDNSSECの検証に失敗するドメインなので、ステータスがサーバエラーとなるのは正常です。    ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL   DNSSECの検証機能が無効なキャッシュDNSサーバであれば、「status: NOERROR」の応答となります。DNSSECの検証を行わないため、ステータスがエラーなしとなります。    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR     ●トラストアンカー(ルートゾーンKSK公開鍵)の確認…

[第3回]KSKロールオーバーへの備え~ZSKでは十分でない信頼性を補完するKSK(鍵署名鍵)とは
[第3回]KSKロールオーバーへの備え~ZSKでは十分でない信頼性を補完するKSK(鍵署名鍵)とは

第1回はDNSの仕組みとDNSSECについて解説しました。 また、第2回は電子署名の仕組みとZSK(ゾーン署名鍵)の役割について解説しました。 第3回となる本稿では、ZSKでは十分でない信頼性を補完するKSK(鍵署名鍵)について説明します。     上位ゾーンとの信頼の架け橋となるKSK   ZSKだけでもDNSの応答データが改ざんされていないことは可能です。 しかし応答したDNSサーバが不正なサーバで、DNS応答データ(リソースレコード)も元から不正なデータであれば意味がありません。   KSKはこの問題を解消します。   KSKは上位のゾーンとの信頼関係を結ぶ役割を持ちます。 上位ゾーンに登録されたKSK公開鍵と対になるKSK秘密鍵を利用してZSK公開鍵を署名することにより、ZSK公開鍵もまた、上位ゾーンに信頼されたものとして扱うことができます。     KSKの役割   KSKの役割は大きく分けて2つあります。   ● KSK秘密鍵でZSK公開鍵を署名する ZSK公開鍵は自ゾーンのDNS応答データの検証を行うために利用します。 不正に作成されたゾーンのDNS応答データに対する検証が成功する場合、そのゾーンを署名したZSK秘密鍵/公開鍵もまた不正であるということです。 そこで自ゾーンに対してもう1種類の鍵、KSK秘密鍵/公開鍵を生成します。     KSKの秘密鍵を利用してZSK公開鍵を署名します。 そして自ゾーンにKSK公開鍵、ZSK公開鍵(KSKによる署名あり)を登録します。     しかしこのKSKが不正なものであれば意味がありません。 そのため後述する上位ゾーンへの登録により、自ゾーンのKSK公開鍵が信頼できるものであることを確認できるようにします。     ● KSK公開鍵を上位ゾーンへ登録し、信頼の連鎖を構築する KSK公開鍵が信頼できるものであれば、そのKSK公開鍵で署名の検証が成功するZSK公開鍵もまた信頼できるものとなります。このKSK公開鍵の信頼性は上位のゾーンによって担保されます。     DNSSECを利用する場合はKSK公開鍵のハッシュ値を含む情報「DS(Delegation Signer)」を上位ゾーンに登録します。これは上位ゾーンにKSK公開鍵を登録することとほぼ同義になります。   自ゾーンのKSK公開鍵と上位ゾーンのKSK公開鍵が一致した場合、自ゾーンのKSK公開鍵は信頼できるものと考えられます。上位のゾーンにDSとしてKSK公開鍵を登録できるのは、そのゾーンに対するドメイン管理者でなければできないからです。     信頼できるKSKによって検証が成功したZSKは信頼できる   前述に通り、上位ゾーンのDSにより自ゾーンのKSK公開鍵が信頼できるものとなります。 ZSK公開鍵はKSK秘密鍵で署名されているので、KSK公開鍵で検証します。     信頼されたKSK公開鍵で検証に成功した場合、そのZSK公開鍵もまた信頼できるものと考えられます。 なぜなら信頼されたKSK公開鍵の対となるKSK秘密鍵は正規のゾーンを管理する者でなければ利用できないためです。     たとえば不正に作成された同名ゾーンに信頼されたKSK公開鍵を登録するとします。 攻撃者はこのKSK公開鍵の対となるKSK秘密鍵で不正なZSKを署名する必要がありますが、KSK秘密鍵は公開されていないため手に入れることができません。そこで不正なKSK秘密鍵を自身で生成し、不正なZSK公開鍵を署名することもできますが、不正なKSK秘密鍵と信頼されたKSK公開鍵は対となっていないためZSK公開鍵の検証に失敗します。   ZSK公開鍵の検証に失敗した場合はDNSSECの検証失敗、つまり名前解決が失敗となります。…

[第2回]KSKロールオーバーへの備え~電子署名とZSK(ゾーン署名鍵)の役割について
[第2回]KSKロールオーバーへの備え~電子署名とZSK(ゾーン署名鍵)の役割について

  第1回はDNSの仕組みとDNSSECについて解説しました。 第2回となる本稿では、DNSSECの仕組みのひとつである署名、そして署名に利用される鍵のひとつZSK(ゾーン署名鍵)について説明します。     DNSSECに利用される公開鍵暗号   DNSSECにはZSKとKSKの2つの鍵が利用されることを前回お伝えしました。どちらも公開鍵暗号という仕組みの鍵で、電子署名として利用されます。まずは公開鍵暗号について理解を深めましょう。     RSA暗号と電子署名   ● DNSSECの電子署名に利用される暗号アルゴリズム DNSSECの電子署名は複数の暗号アルゴリズムに対応しています。 http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml   本稿では比較的理解しやすく、また広く使われているRSA暗号を利用したケースを説明します。     ● 閉める鍵と開ける鍵が異なる RSA暗号では秘密鍵と公開鍵の2つの鍵が利用されます。   これらは暗号化と復号に使われますが、秘密鍵で暗号化したデータは公開鍵で復号することができ、公開鍵で暗号化されたデータは秘密鍵で復号ができるという特性があります。別の言い方をすれば暗号化に利用した鍵では復号することができません。   公開鍵は名前が示す通り利用者に公開され自由に利用できる鍵です。一方で、秘密鍵は公開鍵を作成した人が厳重に管理して外部に漏れないようにします   機密情報を送って欲しい場合は、秘密鍵と公開鍵のペアを作成し相手に公開鍵を送ります。そして相手から公開鍵で暗号化した機密情報を送ってもらいます。   仮に悪意を持つ人が公開鍵を取得し、暗号化された機密情報を傍受したとしても復号できません。公開鍵で暗号化された機密情報は、もう一方の鍵である秘密鍵でなければ復号できない(極めて困難である)からです。     ● 秘密鍵で暗号化して電子署名とする 機密情報をやり取りするのであれば前述の通り、公開鍵で暗号化して秘密鍵で復号する必要があります。しかしその逆の処理、つまり秘密鍵で暗号化し公開鍵で復号するケースがあります。それは電子署名です。   まず秘密鍵と公開鍵のペアを作成し、公開鍵を誰でも取得できるようにします。   相手にデータを送る際、そのデータを秘密鍵で暗号化して署名として付与します。   署名付きのデータを受け取った人は署名を公開鍵で復号します。署名を復号すると暗号化する前の情報、つまり取得したデータと同等の情報が得られます。これにより2つのことがわかります。     まず1つは公開鍵を公開している人が送信したデータであるということ。手に入れた公開鍵で復号できるのはペアとなる秘密鍵で暗号化されたデータだからです。秘密鍵は公開鍵を公開している人が厳重に管理しているはずなので、秘密鍵で暗号化できる人、すなわち公開鍵を公開している人が送信したデータであると考えられます。     そしてもう1つは通信途中でデータが改ざんされていないことです。データを改ざんしたとしても、署名という形で暗号化されたデータを同じように改ざんすることはできません。そのため、データと署名を復号したときのデータで不一致が発生し、署名の検証に失敗します。   このように署名の検証に成功すると、得られたデータが改ざんされていないことが分かります。この役割を果たすのがZSK(ゾーン署名鍵)です。     ZSKだけでは足りない信頼性   ZSKがあればDNSの問い合わせをした先のサーバの応答であること、そして応答データが改ざんされていないことが分かります。しかしこれだけでは安全とは言えません。   ●問い合わせ先の権威DNSサーバが信頼できるものとは限らない 「example.com」のDNS情報を応答するのは「example.comゾーン」の情報を持つ権威DNSサーバです。その権威DNSサーバ情報は上位の「comゾーン」の権威DNSサーバからの応答で知ることになります。つまり上位ゾーンの権威DNSサーバの応答を改ざんすることができれば、「example.comゾーン」を持つ不正な権威DNSサーバへ誘導することが可能です。   ●権威DNSサーバは他者のドメインのゾーンファイルを作成することができる…

CDNのネットワークインフラは、どのように計画されているのか?
CDNのネットワークインフラは、どのように計画されているのか?

  まず、CDN(コンテンツデリバリネットワーク)のネットワークインフラについて述べる前に、サービスコンポーネントについて簡単に説明しましょう。   CDNサービスのためには、キャッシュシステム、GSLB(グローバルサーバロードバランシング)、ネットワークという3つの主要コンポーネントを開発・構成・運営しなければならず、これを総称してCDNと呼んでいます。     キャッシュシステムとは   お客様Webサーバ(オリジン/配信元)から受け取ったWebコンテンツを各地に分散配置したPoP(配信拠点)内のCDNのWebサーバ(CDNサーバ/エッジ)にキャッシュ(コピー)し、エンドユーザからのリクエストに対して一番近いPoPから配信することでWebページの表示を高速化する最も一般的なCDNのシステムです。CDN事業者が利用するキャッシュは、”リバースプロキシキャッシュ”と言われる場合もあります。     GSLBとは   DNS(ドメインネームシステム)の一種で、エンドユーザの位置情報をIPデータベースを照会して調べ、エンドユーザの近くにあるCDNのPoPに知らせる役割に加えて、複数の場所に分散しているPoPの状態を監視する役目も担います。     ネットワークとは   ISPやIXを利用して、PoPおよびゾーン単位のIPネットワーク上にあるキャッシュシステムに、キャッシュされているお客さまコンテンツおよびエンドユーザを、安定的に接続させるための役割を果たします。     CDNetworksのネットワークインフラについて   CDNetworksは、2000年に設立されたグローバルCDNサービスプロバイダで、日本・韓国・中国・シンガポール・イギリス・ドイツ、そしてアメリカに現地法人を設置しサービスを提供しています。   現在、世界6大陸、100都市200以上の地域にPoPを展開してグローバルな配信ネットワークを運営していますが、さらなる通信品質向上のためにPoPを継続的に新設しており、そのカバーエリアは年々拡大し続けています。   CDNetworksが新しいPoPを開設する理由は、世界中のCDNを利用するお客様のコンテンツをエンドユーザへ、”いつ・どこへでも・どんなときでも“安定的に高速配信するためです。そして、PoP新設の可否は、CDNetworksのコストエンジニアがさまざまな調査やデータを参照し、費用対効果を意識しつつ、慎重に決定しています。   <図1>CDNetworksのグローバルPoPマップ     CDNetworksの技術ユニットでは、各チームに役割を設けています。 – エンジニアチーム:キャッシュ/GSLBの開発 – 運用・サービスチーム:キャッシュ/ GSLBを利用してお客様のコンテンツをエンドユーザに配信 – ネットワーク・システムチーム:キャッシュ/ GSLBのシステムレベルでのマネージメントやIPネットワークの構築など、システムの管理・向上の促進   <図2>5つの地域に分散されたGoogleのAnycast DNS(8.8.8.8)の例     CDNetworksでのネットワークインフラ管理/運用におけるタスクとは?   主な業務内容は次のとおりです。 – PoPの新設 – PoPのステータスと使用量の監視 – 障害対応 – バックエンドオペレーション – コストエンジニアリング   今回は、一般的な事項は省き、「PoP新設」と「コストエンジニアリング」について解説をします。  …

[第1回] KSKロールオーバーへの備え~DNSの仕組みとDNSSECについて解説

  2017年10月に予定されていたルートゾーンKSKロールオーバーが延期されました。 ICANNは2018年10月11日に実施することを計画しています。 https://www.icann.org/news/blog/announcing-draft-plan-for-continuing-with-the-ksk-roll   KSKロールオーバーは対策をしなければ大きな問題となることが知られています。しかし誰が、何に、どのような対策をすればよいのかよく分からないという方もいらっしゃると思います。   本ブログではKSKロールオーバーへの対策、それらに関連する技術、そしてその基盤となるDNSについて複数回に分けて説明します。     1.KSKとは何なのか   ◇ KSK(鍵署名鍵)とは KSKはDNSSECという仕組みに利用される2種類の鍵のうちの1つです。DNSSECはDNSの名前解決に検証機能を導入し、信頼できる応答であるか確認する仕組みです。     DNSSECにはZSK(ゾーン署名鍵)とKSK(鍵署名鍵)の2種類の鍵があり、それぞれに秘密鍵、公開鍵が存在します。ZSKはゾーン内のリソースレコードを署名するために利用され、KSKはゾーン内の公開鍵を署名するために利用されます。KSKの役割は上位のゾーンと下位のゾーンの信頼を確立し、信頼の連鎖を構築することです。     ◇ KSKロールオーバーとは KSKは各ゾーンごとに存在し、それぞれのゾーン管理者が管理しています。 KSKロールオーバーはこのKSKの鍵を更新する作業のことです。     本稿で触れているKSKロールオーバーはルートゾーンのKSKの更新作業を指します。ルートゾーンのKSKはDNSSECを利用する多くのキャッシュDNSサーバに設定されています。ほとんどの場合、このルートゾーンKSKがトラストアンカー(信頼の基点)となるため、新しいルートゾーンKSKを設定しなければ、そのキャッシュDNSサーバを利用した名前解決ができなくなります。     2.誰が、何に、どのような対策をすればよいのか   ◇ 誰が対策するのか KSKロールオーバーの影響を受けるのはキャッシュDNSサーバです。そのため、対策が必要なのはキャッシュDNSサーバの管理者です。ゾーンを管理する権威DNSサーバの管理者の対応は不要です。        ◇ 何に対策すればよいのか キャッシュDNSサーバにKSKロールオーバーの対策がされているか確認する必要があります。     ◇どのような対策すればよいのか 以下の2つの作業が必要です。 ①キャッシュDNSサーバが新しいルートゾーンKSKを利用できる設定になっているか確認する(トラストアンカーの更新確認) ② キャッシュDNSサーバがDNS応答サイズ増大に対応しているか確認する   詳細は次回以降に記載します。     3.CDNetworksのサーバは影響を受けるのか   CDNetworksはキャッシュDNSサーバの提供をしていません。 そのため、CDNetworksが提供するサービスはKSKロールオーバーの影響を受けることはありません。   なお、配信システムに利用しているキャッシュDNSサーバはKSKロールオーバーの影響を受けないことを確認済です。     4.DNSの仕組み  …

近づくSSL/TLS リスク、どう対応するのか

    最近、IT関連メディアでよく目にするニュースがあります。   それは、Chromeブラウザを提供しているGoogleが、2018年7月からはHTTPSでないすべてのHTTPサイトに対し、Chromeブラウザで「Not secure」メッセージを表示させることを明らかにしたことです。今まではHTTPでもログインなどの入力フォームがある場合のみ表示させてきましたが、これからはHTTPであればすべてアラートメッセージを表示させるということになります。   参照元 : Google 告知: https://security.googleblog.com/2018/02/a-secure-web-is-here-to-stay.html   Google Chromeに続いて他のブラウザもこのポリシーに従うと予想されますが、ただ、日本国内においてはGoogle Chromeブラウザのシェアが40%を占めているため、このポリシー変更の影響は少なくないと思われます。「個人情報や重要なデータを扱っていないからHTTPで問題ない」と考えているWebサイト担当者がいれば、これからは真剣にHTTPSへのサービス転換を準備する時期に来ていることを認識すべきです。   ところで、HTTPSへ切り替えるためには考慮すべき点が多く複雑ですが、この解決にはCDN(コンテンツ・デリバリ・ネットワーク)の導入をお勧めします。   そこで本ブログでは、なぜCDNの導入が確実で簡単な解決策になれるかをお伝えします。     1. HTTPSはHTTPに比べパフォーマンスに大きな影響を与える   HTTPSはクライアントとサーバの間の通信でcipherや証明書の交換などはるかに多いプロセスを処理するためHTTPに比べて遅くなりがちで、Webサーバに何倍もの負荷を発生させます。   例えば下記のイメージはwww.cdnetworks.co.jpから小さいイメージファイル1つをダウンロードするプロセスですが、既存のHTTPより多くの過程が必要ということが分かります。また、各々の通信では転送データの圧縮や暗号化・復号化を繰り返し行うため多くのリソースが必要とされます。     従って既存のHTTPのみでサービスを運用している場合、今後はこれまでの何倍ものWebサーバやロードバランサなどのIT設備を準備する必要に迫られます。   しかしCDNを利用すればこれらすべてをCDNプラットフォームで処理するため安心です。   実際にCDNetworksのお客様の中では、イベントがあるたびに予約が集中しサーバが耐え切れず、Webサイトが遅くなったりエラーが頻繁に発生したりなどユーザからの不満が多く発生していましたが、CDNサービスを導入してからはいつでも安定、かつ快適にサービスを提供できるようになり顧客利用満足度が上がった事例が多くあります。   また、CDNを導入すればend to endまですべてのプロセスを HTTPSでサービスすることが可能で、クライアント <—-> CDNプラットフォーム間はHTTPSでサービスしつつ、CDNプラットフォーム<—> お客様のWebサーバの間はHTTPでサービスすることも可能なため、お客様のニーズに合わせて柔軟にさまざまな設定ができます。     2. 複雑なSSL/TLSの証明書やcipherを常にチューニングしなければならない   SSL/TLSを適用しただけでWebサイトの安全性が確保されたということではありません。   SSL/TLSでもSweet32、DROWN、FREAKなど用語も難しく理解しづらい新しいセキュリティ脆弱性が次々と公開されています。   また、セキュリティ・コンプライアンスのためにSSL/TLS プロトコル・バージョンもマッチさせる必要があり、RC4のような脆弱性のあるcipherを無効にしないとウェブサイトの評判が悪くなる課題もあります。   さらに、セキュリティを強化するために強力なcipherだけを有効にすると、まだアップグレードしていない古いバージョンのデバイスやブラウザのユーザはWebサイトにアクセスすらできないなど、きちんと管理しなければむしろ多くの問題を発生させることになります。   https://www.ssllabs.com/ssltest/ を見ると、直接自分のHTTPSサイトに対し評価したり、さまざまなサイトの成功・失敗事例を比較することもできます。   2018年月現在ssllabsの画面    さらにSSL/TLS証明書の場合は、毎年契約満了日前に契約更新しなければなりません。…

CDNetworksのDNSはなぜ優れているのか

  CDN(コンテンツ・デリバリ・ネットワーク)を含めオンラインビジネスを運営するにあってドメインをIPアドレスに変換してくれるDNS(ドメイン・ネーム・システム)の役割はもっとも重要な要素の一つと言えます。   CDNetworksでは、長い期間に渡るCDNの提供経験に基づき、独自開発したGSLB(グローバル・サーバ・ロードバランシング:広域負荷分散)を利用してCDNおよびDNSを提供しています。   本ブログでは、なぜCDNetworksのDNSが性能(パフォーマンス)や安定性の面で他社よりも優れているかについてご紹介したいと思います。     1. AnycastベースのグローバルなDNS   CDNetworksのDNSはAnycast(エニーキャスト)ベースでグローバル展開するCDNプラットフォーム上に分散配置されており、世界中のあらゆる地域からのアクセスに対して数ミリ秒以内でレスポンスを返すことができます。   Anycastとは、世界に1つだけのIPであるUnicast(ユニキャスト)とは違い、同じIP帯域(最低/24 C Class 単位)で世界中のPoP(配信拠点)から同時にBGP(ボーダ・ゲートウェイ・プロトコル)を用いたアドレスのアナウンス(※1)をすることで、常に最寄りのPoPにアクセスできるようにする技術であり、最上位のルートDNSやGoogleのパブリックDNSの8.8.8.8などが代表的な例です。   つまり、見た目上はIPが1つだけなので特定地域に置かれているものと勘違いされがちですが、実際には、このAnycast技術により仮想的に数十~数百の場所に均等に分散配置されています。   画像 : 5つの地域に分散配置されているGoogleのAnycast DNS(8.8.8.8)   Anycastのメリットは速いレスポンスだけでなく、可用性にもあります。利用中のPoPで障害が発生すると、次に近いPoPのDNSへすぐにフェイルオーバー(自動切換え)されるため、クライアントは障害の影響を受けません。   また、PoP内ではロードバランサによりトラフィックが振り分けされるため、アクセス急増時などでも偏らず均等に分配されます。これによりリクエストが多いPoPでも安定的にサービスを提供することができます。   さらに、セキュリティ面では、グローバルに分散配置されているPoPのDNSが常に速いレスポンスを返すため「DNS Cache Poisoning」などのサイバー攻撃に対しても不安はなく、大量のリクエストやトラフィックにより通信量を溢れさせて機能停止に追い込む「DDoS攻撃」を受けたとしても心配をする必要はありません。   CDNetworksは、世界中でAnycastの DNSを他のCDNプロバイダやDNSホスティングベンダよりも数多く運営しています。CDNetworksのウェブパフォーマンスを管理するチームでは、常に最適な配信環境を維持し続けるために、定期的なモニタリングとチューニングを行っており、これにより安定したサービス の提供を実現しています。   画像 : CDNetworksのグローバルPoPマップ     2. オープンソースや商用ソリューションではない独自開発のGSLB    最も代表的なDNSのオープンソースソフトウェアであるBind(バインド)や、商用のDNSソリューションの場合、DoS攻撃やバッファオーバーフロー(Buffer Overflow)など多くのセキュリティ脆弱性が毎年公開されています。   例) ISC Bind セキュリ値脆弱性(脆弱性情報データベース:CVE) 現状 :  https://www.cvedetails.com/product/144/ISC-Bind.html?vendor_id=64   画像 : 年度別CVEによるBindの セキュリティ脆弱性発見状況  …

[第2回]パブリックDNSがCDNに与える影響

  本記事は、2014年9月にCDNetworks USが発表した記事を翻訳、一部改訂したものです。実験自体は2年前(2014年)に行なわれたものですが、CDNを検討される方にとっては今なおある程度有益であると考え、日本語でも公開いたします。 パブリックDNSがCDNに与える影響(1) パブリックDNSがCDNに与える影響(2) ←本記事   前回の記事をうけて、この記事ではEDNS-Client-SubnetがCDNのグローバルなロードバランシングにどんな影響を与えるかについて紹介したいと思います。CDNetworksは、Cedexisを適用したドメインにおいてEDNS-Client-Subnetが有効になるようGSLBに設定し、その前後の結果を比べました。その違いは明らかでした。 Cedexis RadarはRUMの一つで、比較した2つの期間のエンドユーザのサンプルは厳密には同じではありません。しかし、大変多くのサンプルを集めることができたため、比較するに値するものと考え、結果を公表いたします。   EDNS-Client-Subnetを利用したロードバランシングの仕組み CDNがEDNS-Client-Subnetに対応することで、Google DNSなどのパブリックDNSを利用したユーザに対しても正確にロードバランシングを行なうことができるようになります。 インドネシアのユーザがDNSリゾルバにGoogle DNSを利用してDNSリクエストを送信すると、おそらくシンガポールにあるGoogle DNSのPoPに届くでしょう。インドネシアのユーザにとってネットワーク的に最も近いのはシンガポールだからです。このとき、EDNS-Client-SubnetをサポートしていないCDNは、これをシンガポールからきたリクエストだと判断し、シンガポールにあるエッジサーバへ誘導するはずです。 もしCDN側がEDNS-Client-Subnetを適切にサポートしていたら、Google DNSはその情報をCDNに提供し、CDNはこの情報をDNSクエリの発信元IPのかわりに使うことで適切にロードバランシングします。そうすることでCDNは、このユーザがシンガポールではなくインドネシアにいるということを理解し、GSLBはインドネシアのエッジPoPのIPアドレスを返すことができます。 なお、Google DNSはDNSサーバがEDNS-Client-Subnetを受け入れるかどうかを検知する仕組みになっていますので、EDNS-Client-SubnetをサポートしていないDNSサーバへDNSリクエストを送信する場合は、クライアントIPの情報を送りません。しかしオープンDNSは、CDN側がEDNS-Client-Subnetに対応したかどうかを検知しません。CDN側は、EDNS-Client-Subnetに対応したということを彼らに連絡し、適切にクライアントIPの情報を受け取れるよう準備する必要があります。 補足として、他のDNSサーバに対してどんな情報を送るかというのはDNSリゾルバの自由です。Google DNSとオープンDNSはクライアントのパブリックIPのうち24ビットまでしか送信しませんので、CDNetworksのGSLBは最後の8ビットを知ることができません。これは、地理情報の正確性という意味では確かに問題は残りますが、一般的には十分であると考えます。   EDNS-Client-Subnetをサポートすることによるトラフィックのシフト 前回の記事では、Google DNSとオープンDNSの利用率が50%を超えるのは、インドネシア、ベトナム、アルジェリアの3つの国であることがわかりました。それぞれの国について、私たちがEDNS-Client-Subnetを有効化した際にトラフィックパターンがどのように変わったのかを見てみましょう。これらの国にあるCDNetworks PoPを通ったすべてのトラフィックを比較しました。   1.インドネシア PoP EDNS-Client-SubnetOFF EDNS-Client-SubnetON Diff (%) Jakarta-1, Indonesia 16.13% 53.60% +37.47 Jakarta-2, Indonesia 5.52% 24.78% +19.26 Singapore 8.28% 14.09% +5.81 Taipei, Chinese Taipei 66.34% 0.1% -66.24 etc 3.73% 7.43%   インドネシアでは62.4%がGoogle DNS、6.3%がオープンDNSのリクエストです。EDNS-Client-Subnetを有効化する前は、70%以上のトラフィックがシンガポールや台北PoPへ誘導されていましたが、有効化後は台北経由だったトラフィックのすべてがジャカルタの2つのCDN…

ネイキッド・ドメインでCDNを利用するには

  はじめに ネイキッド・ドメインとは何か ネイキッド・ドメインとは、wwwといった文字列を頭に持たない(ホスト名なしの)ドメインのことです。例えば、www.foo.comに対して、foo.comを指します。Zone Apex、bare、ルートドメインなどとも呼びます。   ネイキッド・ドメインの何が問題なのか 調査によると、ウェブページの第一印象は50ミリ秒以内に作られるといいます。そのため、ウェブサイトの表示速度はその第一印象に大きく関わります。表示速度はまた、直帰率、滞在時間、コンバージョン数、顧客満足度や収益にも影響を及ぼします。 ウェブサイトの表示速度に影響を及ぼす要素は数多くありますが、ネイキッド・ドメインはその一つです。ほとんどのCDNユーザ企業はwwwなどを含むドメインのみを高速化し、ネイキッド・ドメインを高速化していません。その状況は、大きく次の二つに集約されます。   1) CNAMEの問題で、ネイキッド・ドメインにCDNを適用していない CDNを使うには、DNSのCNAMEレコードと呼ばれる設定を変更する必要があります。CNAMEレコードは、そのドメインへのすべてのトラフィックをCDNへ転送します。しかし、ネイキッド・ドメインではCNAMEを使うことができません。結果、www.foo.comを訪れたユーザはCDNの恩恵にあずかることができますが、foo.comを訪れたユーザにはCDNは使われない(=高速化されない)ということになります。 ※まれにCNAMEレコードを作成できても、メールなどで影響が出たり、閲覧できない環境が出てしまったりするようです。   2) リダイレクトによりCDNを利用しているが、実際には遅延が生じている ネイキッド・ドメインではCNAMEを使えないため、応急措置として、ネイキッド・ドメインへのトラフィックをすべてwwwドメインへ転送する、という設定をウェブサーバ上に施すこともできます。これによってウェブサイトを訪問したユーザはみんな、CDNにより高速化されたウェブサイトを閲覧することができます。 しかし、これは完璧な方法ではありません。実際、wwwホストを含むドメインに直接アクセスするよりもわずかに表示速度が落ちてしまいます。下記のウォーターフォールチャートを見ると、ネイキッド・ドメインの名前解決、サーバ接続、リダイレクトの読み込みといったステップが、wwwホストを含むドメインの名前解決が始まる前に行なわれていることがわかります。こうした数ミリ秒が追加されることで、貴社のウェブサイトに対する第一印象に悪影響を及ぼしているかもしれません。     ネイキッド・ドメインとCDNの問題をCDNetworksがどのように解決するか CDNetworksはこうしたネイキッド・ドメインに対し、クラウドDNSのなかで、リゾルブCNAMEという機能を提供しています。このリゾルブCNAMEを使えば、通常のCNAMEと同じようにネイキッド・ドメインへのトラフィックをCDNetworksサーバ(CDN配信プラットフォーム)へ向け、高速化することができます。   ネイキッド・ドメインを使ったURL表現は、ブランディングの意味で重要です。クラウドDNSのリゾルブCNAMEはブランディングと高速化の両方を満たすことのできるソリューションです。詳しく知りたいという方はCDNetworksへお問い合わせください。   >> クラウドDNSについて 詳しくはこちら クラウドDNSは信頼性の高いクラウド型のDNS サービスです。あらゆるインターネットトランザクションはDNSを経由するため、DNSのパフォーマンスと信頼性は非常に重要です。クラウドDNSは世界中どこからでも、どのようなトラフィック条件でも、高パフォーマンスを提供します。