Public DNS：CDNへの影響

Public DNS(1.1.1.1や8.8.8.8)を使うと、CDNが遅くなる（海外のサーバを割り振られる）と言われています。しかし、実際にはその影響は限定的です(国内ではほぼない)。今回は、その詳細をまとめます。

CDNのリクエストナビゲーション

昔はCDNのリクエストナビゲーションというとDNSによる名前解決を利用したものが主流でしたが、現在は、エニキャストが増加しています、またトラフィック発生源となっているメジャーな動画系サービスは、リクエストナビゲーションにURL生成を使っているなど、昔とは状況が変わっています。まず、それぞれのナビゲーション方法について、現状を見ていきます(細かな所は次回のBoFでお話します)：

• エニキャスト
  • 概要
    • 同じIPアドレスを複数のBGP経路で使う
  • Public DNSの影響
    • 受けません
      • CDNサーバのIPアドレスは、国・地域によらず同じです
  • 使用会社
    • 新興系CDN事業者(Cloudflare)、古参系(LimeLight、CDNetworks)
  • 補足
    • 採用しているCDN事業者数からすると、今やエニキャストが主流です
    • CDNがエニキャストを利用しているかは、DNS Looking Glassにより調査できます
• URL生成
  • 概要
    • ユーザは、まずリダイレクターにhttpアクセスし、ユーザはリダイレクターから最適なメディアURL(最適なホスト名)を受け取ります
    • 詳細にについてはYoutbeのリクエストナビゲーションを参照してください
  • Public DNSの影響
    • 受けません
      • リダイレクターは、クライアントのIPアドレス(最初のhttpリクエストを受けた時に判明）により、最適なメディアURLを決定します
  • 使用会社
    • Youtube、Netflix

最後にDNSベースのものですが、もはやメジャーどころではAkamai、Cloudfront、Fastlyぐらいしか使っていません(Fastlyはエニキャスト＋DNS)。

• DNSベース
  • 概要
    • DNSでユーザに合わせたサーバのIPアドレスを返します
  • Public DNSの影響
    • 限定的にあります。細かな分類が必要なので次節で詳しく見ていきます
  • 使用会社
    • Akamai、Cloudfront
    • Fastly
      • 国別はDNSベース、国内はエニキャストという複合構成だと思われます

Public DNSのCDNへの影響

前述のように、Public DNSは、DNSベースのCDNにしか影響を与えません。また、Public DNSは、リクエストナビゲーションの視点では以下に分類でき、それぞれ影響が異なります：

• メジャー系、広く使われており、CDN側もその存在を認知しているもの
  • ECSを権威DNSに送信する
    • Google (8.8.8.8)
  • ECSを権威DNSに送信しない
    • Cloudflare (1.1.1.1)、Quad9(9.9.9.9)
• マイナー(勝手)系、一般には知らていない勝手に作ったPublic DNS(あと企業内のDNSキャッシュサーバ)、CDN側で認識していないもの
  • ECSを権威DNSに送信する
  • ECSを権威DNSに送信しない

メジャー系Public DNS(ECS送信)

8.8.8.8を代表とする、ECSを権威DNSに送信するPublic DNSの場合、Akamai、CloudfrontともにECSにより最適なサーバのIPアドレスを返すようです(リクエストナビゲーションに対する悪影響なし）。Fastlyは検証していません。

メジャー系Public DNS(ECSなし)

1.1.1.1を代表とする、ECSを権威DNSに送信*しない*Public DNSについて見ていきます。

まず、1.1.1.1の場合、国内にバックエンドがあるようなので、CDNのGSLBは、ユーザからのリクエストが日本から来ていることは判別できます。そのため、各CDNの振る舞いは以下のようになります：

• Akamai：Akamai ASのうち国内サーバのIPアドレスが返ります（Akamaiサーバを内部に持つISPであっても、クライアントの情報は見えないため、ざっくりと国内のサーバを使います）
• Cloudfront：国内サーバのIPアドレスが返ります(もともとCloudforntの国内配信拠点は1か所なので、結局、通常のナビゲーションと同じです）
• Fastly:未検証

一方、9.9.9.9の場合、バックエンドはシンガポールにあるようなので、CDNのGSLBは、ユーザからのリクエストがシンガポールから来ていると思い込み、各CDNの振る舞いは以下のようになります：

• Akamai：シンガポールのサーバが返ります
• Cloudfront：マレーシア？のサーバが返ります
• Fastly:未検証

※Public DNSバックエンドの配置については、以下のnoteを参考にしました。

• https://note.com/note_s/n/na4319b4e159b

マイナー系Public DNS

マイナー系Public DNSの場合、以下のような対応となります：

• Akamai、マイナー系Public DNSのECSを無視するようです(検証済み)
• Cloudfont、不明(未検証)
• Fastly、不明(未検証)

チェック方法

Akamai

Akamaiの国内サーバ配置はだいたい判明しているので、Akamaiの配信サーバを内部にもつISPのユーザであれば、nslookupとAS番号調査でリクエストナビゲーションの結果が分かります。例えば、www.akamai.com.edgesuite.netやwww.akamai.com.edgekey.netに対しnslookupを実行し、得られたIPアドレスからAS番号を調べれば、GSLBが正常に動作しているか(Akamaiサーバを内部に持つISPからのnslookupには、そのISP AS内のサーバIPアドレスが返る)チェックできます：

• nslookupによるIPアドレスチェック
  • > nslookup
  • server 8.8.8.8
  • www.akamai.com.edgesuite.net
• 得られたIPアドレスに対するAS番号チェック
  • https://iptoasn.com/

また、マイナーPublic DNSは、BoF用に運用しているもの(ECS付き)が有ります。それを使ってください。

ただし、AkamaiのGSLBは、たまに海外のサーバや他のASのサーバを返すことがあります(このあたりはBoFで議論します）。想定した動作が得られない場合は、何回か時間を分けてチエックする必要があります。

Cloudfront

Cloudfrontも同様にチェック可能です。ホスト名としては、cloudfont-test.kosho.org (テスト用、cloundfront.netにcname済)が使えます。

補足：エニキャスト系の調査方法

DNS Looking Glassで複数の場所からリクエストを投げることにより判定できます(どこから投げても同じIPアドレスが返る)。

• サービス例
  • http://www.dns-lg.com/
• 使用例 (limelightの場合)
  • 米国
    • http://www.dns-lg.com/us01/www.limelightnetworks.com/a
  • スイス
    • http://www.dns-lg.com/ch01/www.limelightnetworks.com/a

補足：ECS (EDNS-Client-Subnet)

以下のようなパケットフォーマット(UDPペイロード)で、クライアントのIP情報を権威DNSに送信します：

0010 0001 0000 0000 0001 046b 6569 6f02
6163 026a 7000 0001 0001 0000 2910 0000
0080 0000 0b00 0800 0700 0118 00c0 a864

初めの部分は通常のリクエスト（keio.ac.jp A IN)。赤字がEDNS部分で、最後の”0800 0700 0118 00c0 a864”がECS情報です

• Option Code: 08 00 (8, Client Subnet)
• Option Length: 07 00 (7)
• Family: 01 (IPv4)
• Source Nettmask: 18 (/24)
• Scope Netmask: 00
• クライアントサブネット：c0 a8 64 (192.168.100)

また、ECS付きPublic DNSはunboundを使えば簡単に実装できます。

• unbound.conf
  • server:
  • module-config: “subnetcache validator iterator”
  • send-client-subnet:0.0.0.0/0