技術を肴にご飯を食べた 〜 SSL/TLS本、技術書典2、DroidKaigi、ElixirConf、IPv6 〜

先日あきみちさん、鹿野さんと一緒にご飯を食べたときの話が面白かったのでブログに残しておきます。

あきみちさん、鹿野さんには、以前ツチノコブログに寄稿をしてもらっていて、どれも人気エントリになっております。

あきみちさんが寄稿してくれた記事一覧
http://tsuchinoko.dmmlabs.com/?author=14

鹿野さんが寄稿してくれた記事
技術書、それも売れるやつを書きたい人へ、編集者からのアドバイス
http://tsuchinoko.dmmlabs.com/?p=2303

人気エントリになると書くほうも、やったぜ、と感じるんだけど、実際にはそうそうバズることはないんだよねえ。
鹿野さんに、どうすればバズるの?、とつぶらな瞳で聞いたら、「編集者がいたほうが良いですね、ちょっと手直しをするだけで読みやすくなりますよ」と一流の編集者らしい返答。
そ、そうか、なるほど。

 

で、その編集者が出版社を起業して最近出版したばかりの本を見せてもらったら、これがとても良い本なんですわ。


プロフェッショナルSSL/TLS(紙書籍+電子書籍)
https://www.lambdanote.com/collections/frontpage/products/tls

まず、序文がグっとくる。

本書の執筆には2年ほどかかりました。

私が時間をかけた分、読者のみなさんの時間は節約できます。
私がSSL/TLSとPKIの調査に膨大な時間を割くようになってから5年ほどたっていますが、そんな時間を誰もが確保できるわけではありません。
この本には、私が知っていることの中でも特に重要な内容を詰め込んでいるので、読者はわずかな時間で同じ内容で理解してもらえるでしょう。

で、中身をペラペラめくってみたら、理論、基礎、実装、問題点、運用、具体的な設定、が事細かに書かれてる。
これは買うしかないよなあ、と家に帰ってポチりましたよ。
ちょいと高いけど、短縮される時間を考えると、まあペイできるんじゃないかな、と。

ソニーデジタルペーパー DPT-S1という端末で見せてもらったんだけど、これがまた良い端末なんですよ。
薄い、軽い、デカい。
プロはやっぱり良い道具を使っている。

ソニーデジタルペーパー DPT-S1
http://www.sony.jp/digital-paper/products/DPT-S1/

とはいえ、値段が高くて、今は販売終了してるとのこと。
世の中、良いものが売れる、というわけではないね。

(ちなみにでっかい端末じゃなくて手元のKindleでもちゃんと読めました)

 

この本の紙版は4/9に開催される技術書典2でも販売される予定とのこと。
面白そうなので私も顔を出すつもりでいます。

技術書典2
https://techbookfest.org/event/tbf02

技術書典は、TechBoosterと達人出版会の共催で、TechBoosterの代表はDroidKaigiの主催もしている@mhidakaさん。

TechBooster
http://techbooster.org/

DroidKaigi 2017
https://droidkaigi.github.io/2017/

DroidKaigiでは、CONBUがWiFiネットワーク構築を担当させてもらったよー、という話をしたら、鹿野さんもTechBooster関係者だったことが判明。
世の中狭い。
(CONBUはカンファレンスのネットワークを構築する団体でDMMも活動に協力しています)

DroidKaigi & ElixirConf への協力とCONBUプロジェクトメンバ (Droid Kaigi & ElixirConf) 募集のお知らせ
http://conbu.net/info/droid2017/

 

同じメンバーで、4/1(明日!)に開催されるElixirConfでも、WiFiネットワーク構築もすることになっているんだけど、Elixirはマニアックな言語のはずなのに思ったより人が沢山来るみたいで正直ちょっとびっくりしている。

ElixirConf 2017
http://www.elixirconf.jp/

マニアックポイントは以下。

  • ErlangのVM上で動作する(Erlangがマニアック)
  • 関数型言語(関数型ってのもマニアック)
  • 並行処理が得意(並行処理ってのもマニアック)

そんな話をしたら、鹿野さんが、日本のErlang本は全部関わってるんと思う、みたいなことを言うわけですわ。
世の中狭い&すげー。
鹿野さんによると今のElixir人気は、Phoenix人気じゃないか、とのこと。
RubyがRailsでブレイクしたのと同じことが起きているらしい。
なるほどねえ。

参考になりそうなURL
[翻訳] Railsの弟、Phoenix Frameworkで遊ぼう
http://qiita.com/HirofumiTamori/items/316e746948014cfa16e4

 

その鹿野さんがあきみちさんと今度一緒に作ろうとしてるのが、IPv6の教科書。
IPv6はもう実際に使われている技術ではあるんだけど、実際に付き合ってみると、意外と難物なんだよねえ。

  • RFCが沢山ある
  • アップデートが沢山ある。
  • 古くなった情報、間違った情報も残っている
  • デュアルスタックはトラブルシュートがむずかしい
  • IPv4を完全に置換できない
  • 実装がOSによってかなり違っている。
  • DHCPv6サーバとRDNSSサーバを両方用意する必要がある

新しい正しい情報が整理整頓されている本、というだけで手に入れる価値があると思うぞ。
近日中に情報公開されると思うのでそれをお待ちくださいませ。

(4/7追記)
情報公開されました↓
https://www.makuake.com/project/ipv6/

それにしても、Androidが、かたくなにRDNSSだけを使うのはなんとかならないものかしらねえ。
DHCPv6を使いたくない気持ちも理解はできるんだけど、AndroidがDHCPv6を使うようになれば、RDNSSの仕組みを用意しなくても良くなるのに。

 

あとは、DNSがいけてない話とか、身体の動かし方の話とかもしたかな。
いろいろ技術的に面白い話を肴に楽しい時間を過ごせるのは幸せなことだなあと思いました。
花見シーズン到来ですね。
気軽にお誘いくださいませ♪

デュアルスタック環境と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との相性に関して紹介します。

ShowNet 2016でのBGP Flowspec活用法まとめ [Interop Tokyo 2016]

こんにちは。あきみちです。Interop Tokyo 2016取材記事第二弾です。

特定のフローに対する設定情報をBGP(Border Gateway Protocol)のNLRI(Network Layer Reachability Information)で広告できるBGP FlowspecがShowNet 2016で活用されています。

BGP FlowspecのRFCは、RFC 5575として2009年に発行されていますが、その中では、ACL(Access Control List)やファイアウォール設定を行うために使うという用途が紹介されています。

BGP Flowspecの標準化は2009年に行われていましたが、ネットワーク機器への実装が増えてきたのは、ここ2年ぐらいです。ネットワーク機器への実装が増えてきた背景のひとつとして、大規模なDDoSトラフィックへの対処への要求が増え、それを行う要素技術のひとつとしてBGP Flowspecが注目されたことがあげられます。

今年のShowNetでのBGP Flowspec活用は、以下の5種類です。

  • ACLの配布
  • IPv6対応(Rate limit、Discard、Marking)
  • NFV(サービスチェーニング)へとVRFリダイレクト
  • セキュリティオーケストレータからの動的ACL設定
  • DDoS detection装置との連携

ACLの配布は、ShowNet外部からShowNet内部に対するtelnetなどのトラフィックを遮断するなどが行われています。

BGP FlowspecのIPv6対応は、いままさにIETFで標準化が行われていますが、RFC発行に先駆けて実装が登場しているので、今年のShowNetではそれらが活用されています。

今回のShowNetでは、dcwest内にNFV関連の展示をまとめたエリアが作られています。NFVを経由してからShowNet内の出展社ブースなどに転送されるべきトラフィックに関する設定がvMXで行われ、その設定をBGPルータに対して配布するためにBGP Flowspecが使われています。

flowspec-interop-2016

セキュリティオーケストレータからの動的ACL設定、DDoS detection装置との連携に関する話は、別途記事を書きます。

今回のShowNetでは、昨年と比べてBGP Flowspecの活用方法が増えていますが、これら意外にも様々な活用手法のひろがりがありそうです。もはやBorder Gatewayではなくなりつつあるぐらい、様々なものがBGPへと突っ込まれているような気がしている今日この頃です。

サーバ管理者向け、IPv6対応セミナー in 恵比寿 開催のご案内

みなさま、IPv6への接続はできてますか?

ユーザ環境は気付かないうちにIPv6化されていたりするのですが、サービス提供側でのIPv6対応はあまり進んでいません。
その現状を踏まえ、JPNIC様と共同で「サーバ管理者向け、IPv6対応対応セミナー」を開催させていただくことになりました。

↓↓開催案内文


サーバ管理者向け、IPv6対応セミナー in 恵比寿 開催のご案内

北米地域のレジストリであるARINにおけるIPv4アドレス在庫の枯渇や、またApple社でのiOS 9におけるIPv6対応必須化が報道され、IPv6についてのトピックスが増えてきています。
国内での、IPv6接続が容易にできる環境も整いつつあり、知らないうちに利用する環境がIPv6に対応していたということも身近になってきました。
こうした状況の中、コンテンツのIPv6化がなされていないと、ユーザーのところに思うように届けたい情報が届いていないことも起こってくるかもしれません。

そこで、DMM.com ラボとJPNICでは、誰もが気軽に参加できる「サーバ管理者向け、IPv6対応セミナー in 恵比寿」を企画しました。

IPv6の最新動向とともに、サーバのIPv6化に向けた基礎知識を解説します。
また話者は、JPNICにおける「IPv6教育専門家チーム」のメンバーが務めますが、そのメンバーを囲んで、ビアバッシュも開催し、IPv6についてフランクな意見交換会も実施する予定です。

ぜひ多くの方にご参加いただければ幸いです。皆さまのご参加をお待ちしております。

◇日 時:2016年2月16日(火) 16:30~20:00 (開場 16:00)
※19:00頃からはビアバッシュ形式の懇親会です(参加費無料)

◇会 場:株式会社 DMM.com ラボ 本社 会議室
(東京都渋谷区恵比寿4-20-3 恵比寿ガーデンプレイスタワー21F)
http://labo.dmm.com/about/access/

◇主 催:株式会社 DMM.com ラボ
<http://labo.dmm.com/>
一般社団法人 日本ネットワークインフォメーションセンター(JPNIC)
<https://www.nic.ad.jp/>

◇プログラム(予定)

16:30-17:15(45分) IPv6を取り巻く最新動向
話者:株式会社インテック 廣海緑里

17:15-18:45(90分) サーバのIPv6化入門
話者:株式会社ブロードバンドタワー 許先明、國武功一

18:45-19:00(15分) DMMのIPv6に関する取り組み
話者:株式会社 DMM.com ラボ 佐々木健

19:00-20:00(60分) ビアバッシュ懇親会 ~IPv6の小話をしよう~

◇対象者:IPv6に興味のある方・対応を考えたいサーバ管理者など

◇参加費:無料

◇当日の持ち物:名刺2枚と筆記用具

◇定員:70名

◇U R L:https://www.nic.ad.jp/ja/topics/2016/20160126-01.html

◇参加申し込み:tech-seminar[at]nic.ad.jp 宛に以下の情報を、2月15日18時ま
でにお送りください。ただし定員になり次第、締め切ります。

Subjectは、「2月16日 IPv6セミナー申し込み」としてください。

– お名前:
– ご所属先:
– 業種と職種:
– メールアドレス:

◇その他: 当日、会場ではWiFiをご利用いただけます

◇お問い合わせ先:IPv6対応セミナー 事務局 <JPNIC内>
Mail: tech-seminar[at]nic.ad.jp
Tel: 03-5297-2311(月~金、10:00-18:00)