ロードバランサー再入門

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

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

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

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

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

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

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

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

 

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

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

「NTT西日本杯」第6回 ICTトラブルシューティングコンテスト 問題解説 “調子が悪いんでしょうか?”

こんにちは、saiです。
「NTT西日本杯」第6回 ICTトラブルシューティングコンテスト(以下、トラコン)にて運営委員を務めさせて頂きました。

第6回トラコンでは15問の問題が学生の手によって出題されました!

今回は、私が担当した問題の内一つを紹介していきます。

Continue reading “「NTT西日本杯」第6回 ICTトラブルシューティングコンテスト 問題解説 “調子が悪いんでしょうか?””

デュアルスタック環境とCDN

前回、DNSサーバを利用した名前解決と利用するIPバージョンの組み合わせに関して紹介しました。今回は、IPv4とIPv6を別々のISPで接続しているような場合、DNSを利用するCDNとの相性が問題になる可能性について紹介します。

問題が発生するのは、以下の図のようにIPv4とIPv6で別々のISPを利用しつつ、キャッシュDNSサーバはどちらか片方のISPを利用しているような環境です。たとえば、フレッツでIPv4とIPv6を別々のISPにするような設定をしていたり、IPv4しか提供されていない環境で、Hurricane Electricなどが提供しているようなIPv6 over IPv4トンネルを使っているようなときに発生する可能性があります。

この図では、家庭に対してIPv4はISP Aによって提供され、IPv6はISP Bによって提供されます。ユーザが利用しているPCに設定されているキャッシュDNSサーバは、IPv4を利用しているISP Aのものを利用しています。

このような環境で、CDNによって負荷分散が行われているコンテンツをユーザが取得するときの流れをみます。

まず、最初にユーザがISP AにあるキャッシュDNSサーバを利用して名前解決を行います(1)。このとき、ユーザはIPv4とIPv6の接続性を両方持っているので、AAAAレコードの問い合わせを先に行っているものとします。また、AAAAレコードの問い合わせに使われるキャッシュDNSサーバまでのトランスポートはIPv4とします。

ISP AにあるキャッシュDNSサーバは、権威DNSサーバにAAAAレコードの問い合わせ行い、回答を得ます。ISP AとISP Bは、双方ともにIPv4とIPv6両方で運用されており、IPv6で運用されたCDNキャッシュが両方のISP内にあるものとします。

このような環境下では、権威DNSサーバは問い合わせを行ったキャッシュDNSサーバの最寄りコンテンツキャッシュであるCDNキャッシュAを、キャッシュDNSサーバへと返答します(2)。

キャッシュDNSサーバからの名前解決結果を受け取ったユーザは、CDNキャッシュAからコンテンツを取得します。このとき、コンテンツ取得に利用されるトランスポートはIPv6となるため、ユーザはISP Bを経由してCDNキャッシュAにあるコンテンツを取得します。

しかし、ISP BにもCDNキャッシュBというコンテンツキャッシュがある場合、ユーザは遠回りをしてコンテンツを取得していることになってしまいます。このような遠回りが発生するのは、CDNによる負荷分散機能の一部である権威DNSサーバが「ユーザはISP Aにいる」と認識しているために発生しています。

ISP BのキャッシュDNSサーバを利用すれば、ユーザはCDNキャッシュBからIPv6トランスポートを利用してコンテンツを取得できるようになりますが、今度は逆にIPv4でのCDNキャッシュコンテンツ取得が遠回りになってしまいます。

DNSのリソースレコードごとに、利用するキャッシュDNSサーバを設定できれば、このような問題は軽減できると推測されます。たとえば、IPv4のAレコードを取得するときと、IPv6のAAAAレコードを取得するときに利用するキャッシュDNSサーバをそれぞれ設定することによって、キャッシュDNSサーバとのトランスポートとリソースレコードをマッチさせることができれば回避可能です。しかし、現時点では、そういった使い分けが行われることは稀であるため、このような問題が発生していると思われます。

ただし、このような状況に陥ったとしても、単に遅くなるだけでユーザが気がついていない可能性も考えられます。そもそも、CDNとの相性を追求するような設定をユーザ側が行うことが正しいのかどうかという問題もあります。

この話は多少マニアックではありますが、IPv4とIPv6のデュアルスタック環境において発生する課題発見や運用ノウハウの蓄積は、まだまだこれからかも知れません。

IPv6とIPv4とDNSの話

インターネットは、IPパケットを利用した通信です。IPパケットの宛先や、そのIPパケットの送信元はIPアドレスという固定長の識別子によって示されています。しかし、IPアドレスだけだと人間がわかりにくいので、www.example.comのような「名前」が利用されます。

名前のままでは通信ができないので、名前に対応するIPアドレスを調べる「名前解決」が行なわれます。この名前解決を行うためにDNSが使われる場合、ユーザはDNSサーバに対してIPv4アドレスやIPv6アドレスを問い合わせます。

DNSへの問い合わせは1回に1つだけ

DNSプロトコルの基本は、1987年に発行されたRFC 1034RFC 1035が基本となり、その後各種変更が別途RFCとして発行されています。

RFC 1034には、基本的なDNSの仕組みとして、UDPデータグラムかTCPコネクションを通じた問い合わせに対して、回答するか、エラーを通知するか、他のネームサーバを参照するといった返答が行なわれるとあります。

このときやりとりされるDNSメッセージは、RFC 1035に以下のように記載されています。DNSメッセージは、Header、Question、Answer、Authority、Additionalの5つのセクションに分かれています。

DNS message format

Questionセクションは、問い合わせの内容を記述するために使われます。Questionセクションに含まれる”question”は、以下のようになっています。

Question Section

この”question”は問い合わせを行う文字列が含まれます。RFC 1035に記載されている仕様上は同時に複数の”question”をQuestionセクションに含むことが可能と読めますが、現在は事実上単一のレコードに対してしか問い合わせは行えません。

そのため、IPv4とIPv6の両方のIPアドレスをDNSサーバに問い合わせる場合には、DNSサーバに対する問い合わせは、Aレコード(IPv4アドレス)の問い合わせと、AAAAレコード(IPv6アドレス)の問い合わせが別々にそれぞれ1回ずつ、合計2回発生します。

DNSサーバへの問い合わせとトランスポート

さて、さらに話がややこしくなるのですが、DNSサーバに対する問い合わせのトランスポートと、問い合わせの内容は全く独立です。

たとえば、上記図のようにDNSサーバへのトランスポートはIPv4 UDPで行い、IPv6を示すAAAAレコードを問い合わせることが可能です。逆に、IPv6 UDPをトランスポートとして利用し、IPv4を示すAレコードを問い合わせることも可能です。

組み合わせとしては、以下の4パターンが可能です。

  • IPv4トランスポート、Aレコードを問い合わせ
  • IPv4トランスポート、AAAAレコードを問い合わせ
  • IPv6トランスポート、Aレコードを問い合わせ
  • IPv6トランスポート、AAAAレコードを問い合わせ

このように、IPv4でもIPv6の名前解決が行えるようにすることで、IPv6が整備されていない環境においても、IPv6に関連する名前解決が可能とするためという意味合いもあります。もし、IPv6でのみAAAAの検索可能という仕様であれば、特定の名前解決を行う際に関係する全てのDNSサーバがIPv6対応している必要が生じます。

13系統あるDNSルートサーバのうちの6系統にIPv6アドレスが設定され、IPv6トランスポートによるDNSルートサーバへの問い合わせが可能になったのが2008年2月4日です。もし、IPv6トランスポートでしかAAAAレコードの問い合わせができない仕様であったのであれば、2008年2月以前はAAAAの名前解決が全て不可能であったと予想できます。

RFC 3901(DNS IPv6 Transport Operational Guidelines)には、すべてのDNSゾーンはIPv4のみか、IPv4とIPv6のデュアルスタックで運用されるべきであると書かれています。IPv6のみでDNSゾーンを運用すべきではないとあるのです。

このように、IPv4とIPv6は直接的な互換性がない別々のプロトコルでありながら、名前空間は共有しているのです。

次回はCDNとの相性の話です

次回は、DNSサーバに対するトランスポートとしてIPv4とIPv6のどちらを使うのかと、CDNとの相性に関して紹介します。

WHOISの後継!使いやすくなったRDAP

こんにちは。あきみちです。今回は、WHOISの後継プロトコルとして誕生したRDAP(Registration Data Access Protocol)を紹介します。

WHOISとRDAP

IPアドレス、AS番号、ドメイン名などの、番号や名前の資源を管理するレジストリが保持する情報を公開するための「WHOIS」というプロトコルがあります。whoisというコマンドをご存知の方も多いと思いますが、実はwhoisコマンドはWHOISプロトコルを使っているのです。このプロトコルは非常に古く「NICNAME/WHOIS」というタイトルのRFC 812は1982年に発行されています。

WHOISプロトコルを最初に定義したRFC 812と、RFC 812を上書きしたRFC 954の両方を上書きするものとして、RFC 3912が2004年に発行されていますが、TCPによる単純なプロトコルであるという基本的な部分は過去のWHOISを踏襲しています。

WHOISプロトコルの例としてRFC 3912に、以下のような図が記載されています。WHOISは、TCP接続が確立してすぐに問い合わせ文字列を入力して改行コードを送りつけると、相手が応答を返すという非常に単純なものです。

telnetコマンドを使って簡単に行えてしまうという意味では便利なWHOISプロトコルですが、応答の内容が特に定義されておらず、レジストリによってフォーマットがバラバラであるという使いにくさがあります。そういった問題を解決するために、IRIS(IRIS: The Internet Registry Information Service)というプロトコルがRFC 3981として2005年に発行されましたが、複雑過ぎるといった理由によって普及しませんでした。

その後、ARINやRIPE NCCなどのRIR(Regional Internet Registry)がRESTfulなWebサービスとしてWHOISデータを提供する試みを開始し、そこでの知見を標準化するという流れでweirds(Web Extensible Internet Registration Data Service)というワーキンググループが2012年に開始されました。weirdsワーキンググループは、RDAPというプロトコルに関連する以下のRFCを発行して終了しています。

  • RFC 7480 : HTTP Usage in the Registration Data Access Protocol (RDAP)
  • RFC 7481 : Security Services for the Registration Data Access Protocol (RDAP)
  • RFC 7482 : Registration Data Access Protocol (RDAP) Query Format
  • RFC 7483 : JSON Responses for the Registration Data Access Protocol (RDAP)
  • RFC 7484 : Finding the Authoritative Registration Data (RDAP)
  • RFC 7485 : Inventory and Analysis of WHOIS Registration Objects

RDAPの大きな特徴として、HTTPプロトコルで問い合わせが行なわれ、それに対する応答がJSON形式で統一されているという点があげられます。応答を機械的に処理する場合には、フリーフォーマットで運用者ごとにバラバラなフォーマットで返していたWHOISとは違い、レジストリごとに異なる解析方法を作り込む必要がなくなります。

もうひとつの大きな特徴がbootstrapと呼ばれる機能です。WHOISでは、各レジストリは自分が管理している資源であるかどうかだけの判断を行っていたため、どのレジストリが情報を持っているのかをWHOISクライアント側が知ってなければ正しい結果を得られませんでした。RDAPのbootstrapでは、その情報を持つレジストリのRDAPサーバへとリダイレクトが行われます。

実際に使ってみよう!

では、実際にRDAPを使ってみましょう。RDAPを試しに使ってみるのは非常に簡単です。RDAP用のURLの最後に 「/ip/○○○」(○○○部分がIPアドレス)、「/domain/▲▲▲」(▲▲▲部分が名前)、「/autnum/□□□」(□□□部分がAS番号)とすれば結果が返ってきます。

試しに、203.211.186.48 (本稿執筆時点でGeekなぺーじが運用されているIPv4アドレス)に関するRDAPの問い合わせを行ってみましょう。本稿執筆時点で、世界5つのRIRがRDAPサービスを運用しているURLは以下の通りです。

  • AFRINIC : https://rdap.afrinic.net/rdap/
  • ARIN : https://rdap.arin.net/bootstrap/
  • APNIC : https://rdap.apnic.net/
  • LACNIC : https://rdap.lacnic.net/rdap/
  • RIPE : https://rdap.db.ripe.net/

203.211.186.48は、日本国内で運用されているWebサイトでIPv4アドレス情報を持っているレジストリがAPNICであることはあらかじめわかっていますが、ここはあえて北米およびカリブ海のRIRであるARINで試してみましょう。

次のURLをブラウザでクリックしていただくと、APNICのRDAPサーバにリダイレクトされるのが確認できるはずです。

WHOISと比べて非常に便利であるRDAPですが、本稿執筆時点では、まだIPアドレスとAS番号での運用がメインのように見えます。

ARINが誰でもRDAPのbootstrapサーバを建てられるようにgithubでソースコードを公開していますが、ドメイン名に関するRDAPサーバで記載されているのは.infoのレジストリ(Afilias Limited)だけです。

試しに http://rdg.afilias.info/rdap/domain/example.info を見てみましたが、JSONでの結果が返ってきているのを確認できました。その他にも、いくつか .info のドメイン名を試してみましたが、普通に結果が返っています。

WHOISと比べると非常に良い感じのRDAP、是非、みなさまもお試しください!