ロードバランサー再入門

こんにちわ。またエライ間隔があいてすんません。
酔っ払い系ツチノコです。

今回はロードバランサーとか ADC ( Application Delivery Controller ) とか呼ばれているもののお話です。

私は元々 L2/L3 のネットワークが専門で最近は仮想基盤なんかも扱っている感じのエンジニアなんですが、久々にロードバランサーに関わる事になりました。

過去にもある程度ロードバランサーについても構築・運用経験はあり、それなりに理解しているつもりだったのですが、実はロードバランサーを通る「パケットの気持ち」になりきれてない事がわかってきました。

同時に、この領域には体系化された教科書的な資料が少ないんだな、ということが見えてきまして、せっかくなのでカンファレンスでしゃべっちゃえ、ついでに同僚向けの研修用資料にしちゃえ、ということで書いちゃいました。

御自由にお使いください。

尚、パケットのウォークスルーを PowerPoint のアニメーションで書いている関係上、ダウンロードしてご覧頂いた方がいいかもしれません。

また、あわせて去年の Internet Week でしゃべったこちらの資料もご覧頂けると幸いです。GSLB なんかと多少からんできます。

 

P.S. 最近は業界の先輩におそわった上野せんべろライフを楽しんでおります。

それでは、よい酒ライフを。

Internet Week 2016に参加しています!

Internet Week 2016に参加してます!

15171040_236303366783504_4489887932392932020_n

インターネットの技術者たちが集まり、最新技術から基礎の話しを持ち寄って喧々諤々するイベントです。
DMM.comラボもインターネットを通じてサービスを提供していることもあり、チームメンバーも興味あるセッションを聞いたり、弊社で使用しているネットワークについてお話しをさせていただきました。

・Wi-Fi”再”入門 見えない電波を知識で見抜く~社会的課題も交えて~
登壇者:熊谷暁

slack-for-ios-upload-1slack-for-ios-upload-2

会場は、ほぼ満員!!
電波を光にたとえWi-Fiの基礎知識から、細かいプロトコルの話、本当は怖いWi-Fiセキュリティ知識について話をしてきました。
とてもボリューミーな内容で、話しきれない!といった様子が印象的でした。
登壇後も参加者さんから質問が飛び交い、盛り上がったセッションでした。

・ネットワーク機器の本当のスペックを見抜く
・DNS DAY
登壇者:高嶋 隆一

slack-for-ios-upload-3

こちらもほぼ満席!
弊社のDNS構成について、お話をさせていただきました。
掴みはもちろん、艦これの秋イベントについて。
会場から笑いが沸き、弊社コンテンツの知名度の高さに驚きました。
セッションは、昨今のセキュリティ問題や、オリンピックなども話題に上がり盛り上がりました。

今回は有料セッションということで、発表資料をすぐに公開することができないのが残念ですが、公開可能になった際は、こちらのブログでお知らせさせていただきます。

また、DMM.comラボでは協賛ブースも出しております。
15284053_236303373450170_116789358700428722_n

会場にいらした際には、お立ち寄りください!

よくあるDNSの振舞いに関する誤解と何だか本当になっちゃいそうな話

秋深まりぼちぼち温泉につかりたいシーズンになってまいりましたが、皆様如何おすごしでしょうか。お久しぶりの酔っ払い系ツチノコです。

温泉といえば、

で有名な ENOG という新潟のネットワーク系のグループが存在しますが、そちらで DNS に関する話題をお話して来ましたのでそちらの話でもさせて頂きたいとおもいます。
(あ、本当は Echigo Network Operators’ Group の略で ENOG らしいです。)

 

唐突ですが、皆さんはDNSってお好きですか?

 

大概の管理者の方は

“BIND の脆弱性とかしょっちゅう出てめんどくせぇYo!”
“一度設定したら何となく動いてるYo!”

ってな感じではないでしょうか。

 

そんななんとなく動いているからなんとなく理解した様になりがちな DNS の振舞いの中でも特に誤解されている DNS の名前解決の動作に関するトピックです。

DNS には

  • ドメイン名とIPアドレス等のリソースレコード を紐付けるデータを持つ権威DNSサーバ
  • 端末から名前解決の要求を受け、権威DNSサーバに問合せを行うキャッシュDNSサーバ

のふたつが存在する事は皆さんご存知かとおもいます。

 

ここで皆さんに質問です。

端末が “酔っ払い.jp” というサイトに接続を行いたいとします。そこで下図の (2)(3) でキャッシュDNSサーバは “.” の権威DNSサーバ (root の権威DNS サーバ) に対してどういったクエリを送り、”.” の権威DNSサーバはどういう返答を返すでしょうか。

よくある答えは、”.” の権威DNSサーバには “.jp” の権威DNSサーバを尋ね (NSレコードを聞き) 、それらを返答として受け取る、というものでした。以下、一階層ずつ下の権威DNSサーバを尋ねるクエリを送っていき、最後の階層でIPアドレスを尋ねる (A/AAAAレコードを聞き)、という形ですね。

ENOG 会場、弊社のエンジニア向けの勉強会共にこれらの答えが大半をしめました。
でも。実は。

これらの答えは、実際の挙動とは異なります。

 

というわけで、答えはこちら。

ちょっと分かりづらいですね。

キャッシュDNSサーバは常に “酔っ払い.jp のIPアドレスは何?( Aレコード)” を常に問合せ続けます。”.” の権威DNSサーバにも、”.jp” の権威DNSサーバにも、実際に紐付けるデータを持つ “酔っ払い.jp” の権威DNSサーバにもです。常に “クライアントから要求された名前解決のクエリ” を送ります。

わざわざ、”.” の権威DNSサーバに次の階層である “.jp” の NSレコードを聞いたりは、しないんですね。

で、”酔っ払い.jp” の A レコードを直接知らない “.” の権威DNSサーバは “.jp” の権威DNSサーバなら知ってるんじゃない、という意味で Authority Section に NS レコードの一覧をいれて教えてあげます。

あとは、実際に紐付けるデータを持っている権威DNSサーバに辿りつくまで繰り返し、です。

 

ところが、現在 IETF の dnsop で提案されている DNS query name minimisation to improve privacy というインターネットドラフトで状況が変わるかも知れません。

上記のドラフトによると、現在の “クライアントが知りたいドメイン名のリソースレコードを root の権威DNSサーバから順番に引いていく” というやり方は、実はプロトコル上の要求ではなく、歴史的にそうやっているだけだ、というのです。

そしてこの従来の振舞いですと、より上位の権威DNSサーバやそれらに到達するDNSクエリのパケットを覗き見できるネットワークの管理者は、ある程度エンドユーザの活動が推測できる、という事になります。

 

こりゃいけねぇ、ってなことで QNAME Minimisation という提案がなされているのですが、こいつの内容って、

  • “.” から問合せを始める際、一階層下の権威DNSサーバを尋ねる ( NS レコードを聞く )
  • 一番下の階層に辿りついたら実際に聞きたいリソースレコードを尋ねる

というものなのです。これって、さっきのよくある間違いと同じ事ですよね。

現在、Experimental RFC になる予定になっていますが、従来の挙動から変更しても特に互換性に問題がない為、メジャーな実装で機能が入るとあっさり普通の動作になったりするかも知れません。

 

というわけで、今日は DNS についてよく誤解されている振舞いと、将来的にそれが本当の動作になっちゃうかも、ってなお話をさせて頂きました。

詳細はこちらのスライドの中身もご覧頂ければとおもいます。

 

あ、そういえば新潟にはよく遊びにいくのですが、新潟市は古町にあるバー、Jazz Flash はホントおすすめですよ。先月はいきそこないましたが、年内にまた遊びにいこうかとおもってます。
では、また。

googleとakamaiは仲良し?

昨日、geekなページのあきみち氏ご本人からアカマイの本をいただいたので、早速、読んでみました。

いただいた本↓
Geekなページ:『アカマイ 知られざるインターネットの巨人』を書きました

Akamaiのsurerouteサービスがispにどのような影響を与えるのか、
また、そのサービスはもろ刃の剣でありispに対する優位性が変化してきているというくだりが面白かったです。
あきみちさん献本ありがとうございました。

ところで、この本を読んでいて、ふと
パブリックDNSとCDNの相性問題を思いだしまして、突然ではありますが調べてみようと思い立ってしまいました^^;

一度、こう思ってしまうと寝る間を惜しんで調べてしまうところがツチノコ親分の性なんでしょうかね。

では調査結果を共有します。

googleの運用する8.8.8.8や8.8.4.4などのパブリックDNSは巷ではCDNとの相性は良くないと言われています。

確かに8.8.8.8はanycastのアドレスで台湾に設置されているサーバに振られます。

かつてはakamaiやその他のCDNを利用しているサイトのFQDNで名前解決を行うと台湾のサーバに振られるようになっていました。

結構前の話なので最近はどうなっているのかコマンドを叩いて調べてみます。

akamaiの場合

$ dig @8.8.8.8(台湾DNS) www.akamai.com
e8921.dscx.akamaiedge.net. 19 IN A 23.66.109.233(日本エッジ)

$ dig @168.95.1.1(台湾DNS) www.akamai.com
e8921.dscx.akamaiedge.net. 11 IN A 23.53.77.233(台湾エッジ)

$ dig @202.248.37.74(日本DNS) www.akamai.com
e8921.dscx.akamaiedge.net. 20 IN A 23.44.173.233(日本エッジ)

これを見ると8.8.8.8でもJPのエッジサーバに振り分けられています。
8.8.8.8は間違いなくRTTをみてもTRACEをみても国内のサーバではなさそうです。

limerightの場合

$ dig @8.8.8.8(台湾DNS) www.limelight.com
llnw.vo.llnwd.net. 349 IN A 203.77.189.7(香港エッジ)

$ dig @168.95.1.1(台湾DNS) www.limelight.com
llnw.vo.llnwd.net. 350 IN A 203.77.189.7(香港エッジ)

$ dig @202.248.37.74(日本DNS) www.limelight.com
llnw.vo.llnwd.net. 350 IN A 117.121.254.136(日本エッジ)

limerightは台湾にエッジがなく香港に設置されているのかもしれません。
いずれにしても台湾のDNSに対しては香港のエッジが返されています。
8.8.8.8を利用した環境においてlimerightを利用しているサイトを利用すると海外のサーバに飛ばされパフォーマンスが低下する可能性があります。

cdnetworksの場合

$ dig @8.8.8.8(台湾DNS) www.cdnetworks.co.jp
www.cdnetworks.co.jp.cdngc.net. 19 IN A 175.41.1.2(韓国エッジ)

$ dig @168.95.1.1(台湾DNS) www.cdnetworks.co.jp
www.cdnetworks.co.jp.cdngc.net. 20 IN A 14.0.63.201(台湾エッジ)

$ dig @202.248.37.74(日本DNS) www.cdnetworks.co.jp
www.cdnetworks.co.jp.cdngc.net. 20 IN A 14.0.33.242(日本エッジ)

ここはまた違った結果が。。
KDDIが買収する前は韓国資本の会社
ここの会社はもしかすると、アジア地域のanycastのアドレスは標準で韓国のエッジに飛ばすようになっているのかもしれません。
いずれにしても8.8.8.8を利用しCDNをcdnetworksを利用したサイトを訪れる際は韓国へ飛ばされパフォーマンスが低下する恐れがありそうです。

この3社の結果をまとめると
Akamaiだけが台湾の8.8.8.8でも日本のエッジが返されるようになっている。

ここから見えることは
※あくまで想像です。^^;

8.8.8.8を利用してもakamaiであれば遅延が発生しない

googleとakamaiは仲良しでgoogleがakamaiに顧客のIPを渡している可能性がある。

渡していないのであればJPアドレスなのか否かの情報は渡している可能性がある。

というところでしょうかね。

結論

改善はしている。ただしAkamaiだけで。

パブリックDNSを利用するにはまだ早いかもしれません。
※過去の記事で8.8.8.8に話しをしているのですが浅はかだったかもしれません。^^;

利用するにしても日本国内のpublic dnsを利用するといったところでしょうか。

推測を含んでいる部分が多く、
いろんな誤解が含まれている可能性がありますのでご指摘いただけると助かります。

resolverの特性から見るDNSキャッシュサーバ運用の勘所

仰々しいタイトルですが小ネタです。

options timeout:n

上記でnameserverの切り替わりの秒数を制御できますが

IPの接続性がありDNSのサービス自体が落ちている場合はtimeout値まで待たずに瞬時に切り替わります。

※IPの接続性が失われるとoption timeout:nの値(デフォルト5秒)が適用されその分遅延します。

この特性を覚えておけば、ミッションクリティカルな環境ではDNSキャッシュサーバの再起動は控えるようになりますし、LVSや負荷分散アプライアンスを利用し障害やメンテナンス時の遅延を最小に抑えることも検討できるようになります。

ちなみに、うちではネットワークに問題を抱えるXenServerでDNSキャッシュサーバを構築禁止です。^^;