IPv6, ネットワーク

インターネットは、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との相性に関して紹介します。

イベント

こちらでもお知らせしていましたJANOG38に参加してきました。

結論を先に書くと、JANOG38はとっても楽しく有意義でした!

本会議・運営スタッフともに初参加してきた私の目線で色々書いてみます。

スタッフ業務について

まず、運営スタッフについてお話しします。

JANOG Meetingのスタッフは有志で構成されたチームで運営しています。
チーム構成は、ORG(企画編成委員)、PC(プログラム委員)、各チームを統括する実行委員長、それらを統括するSC(実行委員長)で成り立っています。

今回の運営スタッフ一覧は下記ページからご確認いただけます。
https://www.janog.gr.jp/meeting/janog38/stafflist

スタッフの募集は3月に開始され、4月の1週目には1回目のスタッフミーティングが開催されます。
募集からスタートまでがとってもスピーディー!
(スタッフ募集の告知は、JANOGのホームページやツイッター、Facebook、メーリングリストで行われるのでご興味のある方は要チェック!)

さて、私が所属していたのはORGチームなので、ORGチームについての情報を展開していきます!

ORGの仕事は大きく分けて「広報」・「会場設営」・「ものづくり」になります。

・広報の仕事…Webによる広報・SNS広報・ML(attendees等)・写真を撮る・ニュースレターを書く
・会場設営の仕事…会場ファシリティ、懇親会開催、動線アテンド、音響・照明、空調、ストリーミング配信
・ものづくりの仕事…アンケート、ランチ企画、グッズ制作、サイネージ

いずれの仕事も手を挙げればすべて関わることが可能ですし、本職との兼ね合いをみてやれるところだけ対応することもできました。
本会議当日以外は、各々の仕事の合間を見つけて作業を進めていくので、リモートでの調整が必須です。
そのため、Slack、Confluenceが大活躍!

私が主に関わったのは、Webによる広報、SNS広報、ストリーミング配信、会場設営、ランチ企画、グッズ制作あたりです。

広報では、準備期間中からTwitterやFacebookを使って、開催前の情報をUPしていきました。
事前ミーティングの様子を報告したり、今回からアンケートの方法が変わったのでそのアナウンスなどを中心に情報展開を行いました。

本会議中は、会場の様子や注意アナウンスだけでなく、おやつはここにありますよ!などなど現地にいる方、また、ストリーミングでご覧になっている方向けに情報発信を行いました。

グッズ制作では、Tシャツとアロハを作りました。
こちらは、スタッフや司会者が本会議中に着るユニフォームになります。

image (1)image (3)

絵が描けず、デザイン応募に参加できなかったのが無念でした。
次にチャンスがあればやってみたいヾ(*´∀`*)ノ

本会議中のメインタスクは会場設営!
たくさんある協賛ブースの荷物仕分けから始まり、サイネージの設置、張り紙を貼ったり、目まぐるしく動き回っていた気がします…ドタバタし過ぎてあまり覚えていなかったり><

DAY1では会場諸注意を担当しました。
たくさんの人の前で壇上に立ち、会場諸注意をするのはとっても緊張しましたが、いい経験になりました。

IMG_1147
↑懸命に会場諸注意をする私の図

ランチ企画はDAY2に参加しました。
本会議に参加しているエンジニアさん、営業さん、若者支援で参加した学生さんなど様々な人と一緒にランチをしつつ交流しました。

本会場の近くに会場を借り、想定以上の人入りで盛況でした!

IMG_8248IMG_8251

ツチノコブログを見てます!と言ってくださった方もいて、ほっこりしました。

スタッフ仕事をして感じたこと

・「これいいかも!」と提案したらすぐさまGOを出してくれる動きやすい環境!
・たくさんの企業の方々とお仕事ができ、いろんな考えややり方を学べたたのが有意義!
・Facebookの友達がべらぼうに増えた!!

少しだけプログラムのはなし

多品種少量サービス運用について その2

 

ネットワークサービス開始時やユーザ数が多いサービスはオペレータの対応回数が多く、ナレッジを貯めやすくその後も運用がスムーズにいくことが多い。一方、サービスの円熟期でもユーザが少ないままのサービスは、オペレータ対応回数が少なく以下の問題を抱えがちとなる。

1.ナレッジが無いため、一度起こると対応に多くの稼働が使われる
2.サービス開始後に新たに着任した人の習熟が難しく、人事異動が難しい
3.多品種少量サービスだけを纏められ、守備範囲が広くなる

ネットワーク運用部門はこの悩みを抱えていることが多いと思われる。この悩みについてどのように運用対応しているか、JANOGの各オペレータに意見交換、知恵だしを行い、少しでも解消できるようにしていきたい。

ORGスタッフとして上記BoFのお手伝いをしつつ、お話を聞いたのでちょこっとだけですが書きます。

・多品種少量サービスの運用はドキュメントが貯まりにくい
・そもそもドキュメントを書くのが大変
・俗人化してしまう

あるあるな内容で終始うんうんうなずいてしまいました。
みんなで解決していこうよ!という趣旨だったので一緒にまざりたかったのですが、後ろから眺めるだけで終わりました。どこかで続きが聞けると思うので個人的に追いかける所存です!

協賛ブースについて

DMM.comラボとして協賛しブース出展をしました。

IMG_1218IMG_1222

私自身は長い時間ブースに立つことができませんでしたが、それでも少しの時間ブースに立ち寄ってくれた方とお話しすることができました。

若者支援を利用してJANOGに参加されていた学生さんから「刀剣乱舞」で遊んでいます!とキラキラした目で声をかけていただき、こちらもにこにこしてしまいました。
弊社のステッカーを貼って「刀剣乱舞」で遊びます!と話してくださり、DAY3ではステッカーを貼ったスマートフォンを見せに来てくれました。

また、アフリカ事業に興味を示された方も多かった印象です。

持て余してしまうかな?と、心配していたノベルティのひえひえも沖縄で焼いた肌をクールダウンするのに活用していただけたようで、無事に配り終えました。
ブースに来てくださった皆様、ありがとうございました!

最後に

スタッフとして参加したのでなかなかセッションをゆっくり聞くことができませんでしたが、スタッフとして働いたことで学べたこともあり有意義でした。
これから就活をはじめる学生さんから「やりたいことは特別にないし、お金もそこまで稼ぎたいわけじゃない、でも楽しく働きたい場合、どういう会社を選べばいいんだろう?」と、質問されていた運営スタッフの横で話を聞いていたのですが、「JANOGに限らず、こういうイベントに業務として参加させてくれる会社は少なからず働きやすい会社だと思うよ」と回答されていたのが印象に残りました。
直接利益につながるわけではないですが、業務としてスタッフ参加させてくれた会社に感謝します。

業務としてスタッフに参加するチャンスが巡ってきた方はぜひ参加してみると新しい発見があるかもしれませんよ!

次回のJANOG39はDMM.comラボがホストとして、JANOGに関わります。
今回の経験を活かし皆様にとって有意義な会になるように尽力いたします!

イベント

JANOG38 Meeting 2日目が終わりました。

2日目はIPv6やゼロレーティングを支える技術、九州地震などの災害時のインターネットについてや沖縄県のIT戦略などなど、沖縄という土地ならではの講演もありました。

2日目のプログラム終了後には懇親会が催され、発表者を始め、色々な業種の方と交流することができました。

IMG_3487

 

ミス沖縄と泡盛の女王も応援に駆けつけて、沖縄らしい華やかな懇親会でした。

IMG_3495 IMG_3489

IMG_3493 IMG_3491

残すところは最終日。JANOG38 3日目はDMM.comラボのメンバーが4つのセッションに登壇します!

イベント

会場から見える泊埠頭

ハイサイ! 本日より JANOG38 Meeting in Okinawa がはじまりました。心配されていた天候もいまのところは晴れていますが、とにかく暑い! 台風の前だからかもしれません。会場からは泊埠頭が見渡せます。

プログラムのDay3 には、DMM.comラボから登壇予定のセッションが4つ あります。遠隔からストリーム中継による参加もできますよ。(※都合によりストリーム中継がないセッションもあります)

IMG_1130 IMG_1176

DMM.comラボのブースにもぜひお立ち寄りください。暑〜い沖縄にうれしい、パンチすると冷えるノベルティもご用意しております。よろしくお願いします。

ネットワーク

こんにちは。あきみちです。今回は、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、是非、みなさまもお試しください!

PAGE TOP