Client Subnet in DNS Requests (draft-vandergaast-edns-client-subnet) を読んだ

先日googleとakamaiは仲良し？というエントリを読んだとき，恐らくEDNS Client Subnet Optionだろうとは思った*1ものの，EDNS Client Subnet Optionの動作をきちんと把握してはいなかったので，この機会にdraftを読んでみた．

概要

DNS権威サーバの中には，クエリ送信元のDNSキャッシュサーバのIPアドレスによって応答を変えるものが存在する
クライアントとキャッシュサーバのネットワーク的な距離が離れている場合，権威サーバは適切でない応答を返す恐れがある
キャッシュサーバから権威サーバへのクエリ内にクライアントのIPアドレスの一部を含めることで，権威サーバがより適切な応答を返すことを実現する
利用にはキャッシュサーバと権威サーバの対応が必要 (クライアントの対応は不要)

問題: Public DNSと"不適切"な応答の発生

CDN事業者やWebサービス事業者が運用しているDNS権威サーバの中には，問い合わせ元のDNSキャッシュサーバのIPアドレスの応じて応答を変えるものが存在する．例えば，日本のISP Aのキャッシュサーバからの問い合わせに対しては日本に設置されたエッジサーバのIPアドレスを返せば，クライアントからエッジサーバへのレイテンシは抑えられると考えらえる．

ここで問題となるのは，クライアントとキャッシュサーバのネットワーク的な距離が離れている場合に，適切でない応答が発生することである．例えば，日本のISP A内のクライアントが台湾のキャッシュサーバを利用していた場合，権威サーバは台湾に設置されたエッジサーバのIPアドレスを返してしまう．これにより，クライアントにとってより適切なエッジサーバが存在するにも関わらず適切でないサーバに接続してしまい，結果としてパフォーマンス上の問題が発生する．

以前であればISPのキャッシュサーバを利用することが殆どであったため問題は発生しなかった*2．しかし，最近はGoogle Public DNSをはじめとした公開DNSキャッシュサーバの普及によって，クライアントとDNSキャッシュサーバの距離が離れているケースが生じるようになった。その結果、上述したような問題が顕著化するようになった．

解決策: クライアントのIPアドレスをクエリに埋め込む

この問題を解決するために考えらえたのが、キャッシュサーバから権威サーバへのクエリ内にクライアントのIPアドレスを埋め込むことで，権威サーバが適切な応答を返せるようにする，というもの．

EDNS Client Subnet Optionに対応したキャッシュサーバは，クライアントのIPアドレスの一部 (ADDRESS) とプレフィクス長 (SOURCE NETMASK; 標準ではIPv4で/24*3 ) をOPT RRに埋め込んで権威サーバに送信する．

f:id:yunazuno:20140817180611p:plain

これを受け取ったEDNS Client Subnet Option対応権威サーバは，クライアントのIPアドレスに応じた応答を返す．このとき，適切な応答を生成するのに必要だったプレフィクス長 (SCOPE NETMASK) を含める．たとえば，キャッシュサーバからSOURCE NETMASKが24のIPアドレスが与えられたとして，権威サーバは/22の情報しか使用しなかった場合，SCOPE NETMASKは22となる．

f:id:yunazuno:20140817180615p:plain

キャッシュサーバはクライアントに対して応答を返すと共に，権威サーバからの応答を自身のキャッシュに格納する．このときのキーは (FAMILY, ADDRESS, SCOPE NETMASK) の組となる．

ちなみに，EDNS Client Subnet Optionに対応していない権威サーバにオプション付きのクエリを投げたとしても，単純に未対応のオプションとして無視されるだけである．

実際に試してみる

Client Subnet Option付きクエリを投げる機能を追加するpatchを当てたdigで実験．ns1-4.google.comはClient Subnet Option対応権威サーバとして謳われているので，今回はこれを使用．

まずは適当な日本国内のIPアドレス帯でクエリを投げる．

$ dig @ns1.google.com. www.google.com. +norecurse +client=122.102.128.0/24

; <<>> DiG 9.9.3 <<>> @ns1.google.com. www.google.com. +norecurse +client=122.102.128.0/24
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42644
;; flags: qr aa; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
; CLIENT-SUBNET: 122.102.128.0/24/21
;; QUESTION SECTION:
;www.google.com.                        IN      A

;; ANSWER SECTION:
www.google.com.         300     IN      A       173.194.126.209
www.google.com.         300     IN      A       173.194.126.210
www.google.com.         300     IN      A       173.194.126.211
www.google.com.         300     IN      A       173.194.126.212
www.google.com.         300     IN      A       173.194.126.208

;; Query time: 44 msec
;; SERVER: 216.239.32.10#53(216.239.32.10)
;; WHEN: Sun Aug 17 15:46:53 JST 2014
;; MSG SIZE  rcvd: 134

続いてシンガポールの適当なIPアドレス帯で同様に．

$ ./bin/dig/dig @ns1.google.com. www.google.com. +norecurse +client=118.189.0.0/24

; <<>> DiG 9.9.3 <<>> @ns1.google.com. www.google.com. +norecurse +client=118.189.0.0/24
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57557
;; flags: qr aa; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
; CLIENT-SUBNET: 118.189.0.0/24/20
;; QUESTION SECTION:
;www.google.com.                        IN      A

;; ANSWER SECTION:
www.google.com.         300     IN      A       74.125.130.104
www.google.com.         300     IN      A       74.125.130.105
www.google.com.         300     IN      A       74.125.130.147
www.google.com.         300     IN      A       74.125.130.103
www.google.com.         300     IN      A       74.125.130.106
www.google.com.         300     IN      A       74.125.130.99

;; Query time: 52 msec
;; SERVER: 216.239.32.10#53(216.239.32.10)
;; WHEN: Sun Aug 17 15:48:30 JST 2014
;; MSG SIZE  rcvd: 150

最後にイギリスの適当なIPアドレス帯で．

$ ./bin/dig/dig @ns1.google.com. www.google.com. +norecurse +client=212.140.0.0/16

; <<>> DiG 9.9.3 <<>> @ns1.google.com. www.google.com. +norecurse +client=212.140.0.0/16
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47653
;; flags: qr aa; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
; CLIENT-SUBNET: 212.140.0.0/16/18
;; QUESTION SECTION:
;www.google.com.                        IN      A

;; ANSWER SECTION:
www.google.com.         300     IN      A       74.125.230.112
www.google.com.         300     IN      A       74.125.230.115
www.google.com.         300     IN      A       74.125.230.114
www.google.com.         300     IN      A       74.125.230.113
www.google.com.         300     IN      A       74.125.230.116

;; Query time: 42 msec
;; SERVER: 216.239.32.10#53(216.239.32.10)
;; WHEN: Sun Aug 17 15:49:24 JST 2014
;; MSG SIZE  rcvd: 133

各クエリで得られたIPアドレス宛に東京からpingを打ってみたところ，下のような結果になった．

173.194.126.209 (東京): 12ms
74.125.130.104 (シンガポール): 80ms
74.125.230.112 (イギリス): 230ms

東京-シンガポール，東京-イギリス間の一般的なRTTに近い値であることから，それぞれのクエリにおいてクライアントに近いサーバのアドレスが返されていると考えられる．

まとめ

EDNS Client Subnet Optionのdraftを読み，おおまかな動作の流れをまとめてみた．

現時点での対応状況として，キャッシュサーバ側ではGoogle Public DNSやOpenDNSが，権威サーバ側(コンテンツ提供側)ではAkamaiやCloudFrontが対応しているようである．逆に言うと，普通のキャッシュサーバや権威サーバが対応するメリットは無いので，特に気にする必要は無い．

ただし，Public DNSに限らずISPのDNSキャッシュサーバが対応するとメリットが出るような場合もある．たとえば，この資料ではインドネシアのように国土が分散している場合におけるClient Subnetのメリットが述べれらている．また権威サーバ側でも，海外など広い範囲でサービスを提供していて，かつ海外にもPOP (Point of Presence) を設置しているような事業者の場合，対応することでクライアントのレイテンシ改善を実現できるかもしれない．

何にせよ，現状はパブリックなサーバ側実装が無い状態なので，まずはオープンかつ信頼できる実装が出てくると良いのかなぁ，と感じた*4．