2017/03/01 追記 近日中にセルフ赤ペンが入ります。
2017/03/04 追記 ただいま、セルフ赤ペン中です。
2017/03/08 追記 セルフ赤ペンしました。
おはこんばんにちは。なつよです。
プライベートやお仕事が立て込む日々です。
インフラガール活動の時間、もうちょっと増やしたい・・・(ﾉД`)
今回は、先日行ってきたRFC1034読書会について書こうと思います。
なんで参加しようと思ったの？
RFC1034,日本語訳を読んでみたのですがまったくわからんかったのです。
私が読んでみた過去についてはこちらの記事をごらんください。
そんな中、鈴木先生から声をかけていただき、参加することとなりました。
出発から到着まで
開催地は中京大学八事キャンパスでした。
私は富山から高速バスに乗って行きました。
動きやすさを重視したらMA1にリュックにスニーカーという大学生ぽいスタイルになってしまった。大学に行くわけだし場違いじゃなかろ
— ナツヨ@浮上頻度低＋perl入門 (@infragirl755) 2017年2月24日
— ナツヨ@浮上頻度低＋perl入門 (@infragirl755) 2017年2月24日
suica使えるじゃんやったぜ～と思っていたら、「名古屋で地下鉄乗るならドニチエコ切符のほうがお得だよ」と
教えていただきました。ありがたや。
早くつきすぎた
— ナツヨ@浮上頻度低＋perl入門 (@infragirl755) 2017年2月25日
13時半スタートだったのですが、早く着きすぎたので
大学内をぶらぶらしていたら（迷子とも言う）運よく鈴木先生とエンカウントしました。(∩´∀｀)∩ﾔｯﾀｰ
開催されるお部屋は眺めのいいゼミ室？でした。
参加者の方がぞくぞく到着される中、皆さん電源タップを自主的に持参されたり、
お菓子を持参される方がいて、何も持ってこなかった自分がちょっと恥ずかしかったのでした。(；´Д｀)
読書会開始！
読書会は、鈴木先生が解説され、参加者がそのつど質問をする、というスタイルで行われました。
初めて参加だったので、「ついていけなかったらどうしよ」と思っていたのですが、
わからないところを丁寧に解説してくださったので、なんとか着いていけたと思います。
あとから知ったのですがかなりゆっくり解説してくださっていたようです。
ありがたや(´Д｀)
読書会で学んだこと
今回の読書会に参加してみて、自分の中のモヤモヤが晴れたというか・・・アハ( ﾟдﾟ )体験が沢山ありました。
以下、自分のメモをもとに書き起こしてみました。
・DNSは考古学
RFC1034が書かれたのは1987年でした。鈴木先生いわく、当時のとりまく環境を知らないと理解できないよ～、とのことでした。
私は1991年生まれなので、生まれる前の話なんですよね。
telnetとmailが主体で、webが出るのはこれより20年ほどあとなんだとか。
これは誤りで、1989年～1991年がwwwの始まりだそうです。
※ティム・バーナーズ=リーさんが提案したのが1989年「Information Management: A Proposal」、
これをさらに具体的にしたのが1990年「WorldWideWeb: Proposal for a HyperText Project」、
CERN（ティム・バーナーズ＝リーさんが所属する組織）外の人もコミュニティに参加できるようになった（開かれた）のが1991年のようです。
webfoundation.org
・RFC1034はけっこうざっくりとしたRFC
DNSソフトウェアNO.1と名高い（？）BINDの開発元であるISCのサイトに、DNSに関するRFCの一覧が掲載されているとのことです。
DNS RFC | Internet Systems Consortium
その中でRFC1034のタイトルは「Domain names - concepts and facilities」、DNSの概念についてざっくり述べているものだそうです。
これを知って、私は「最近ホスト増えてきたじゃん？管理めんどいよね、こんな感じのもん考えてみたわ、どう？」ぐらいの気持ちで書いたんじゃないかなぁ？と思いました。
RFC1034もがあまりにもざっくり？すぎるので、「っときちんと使おうよ～」ということで書かれたRFC（RFC1912)もあるそうです。
RFC1912 -> 「 Common DNS Operational and Configuration Errors」、
RFC2181 ->「Clarifications to the DNS Specification」
これまだ読んでないんですよね・・・いつ読めるかしら(´Д｀;)
・RFCは1周読んだだけでは分からない。2～3周すべき
最後のほうになって、「最初のほうで言っていたのはそういう意味だったのか！」と分かることもあるとか。
・RFC1034は浸透（percolate)という表現が出てくるが、実装では「浸透」しない
RFCでの表現と、実装は異なるとか。DNSややこしすぎか。
・DNSは「一貫性」よりも「可用性」を取った仕組みである
RFC1034の中に以下のような文があります。
When updates are unavailable due to network or host failure, the usual course is to believe old information while continuing efforts to update it.
これはネットワークが分断されたとき、動作としては「古い情報を信じる」という記述で、
CAP定理を知った上でこのことを知っておくとよいとの話でした。
CAP定理・・・恥ずかしながら知らんかった・・・APとか取るときに出たかもしれないけど・・・
・recursive（再帰問い合わせ）はオプション。iterative（反復問い合わせ）できないサーバがrecursiveする
これは、私の中で一番のアハ体験だった話です。
DNSには「再帰問い合わせ」と「反復問い合わせ」があることは知っていたのですが、何のために2種類存在するのかよく分かっていませんでした。
「DNSの基本はiterativeなんだ、それができないサーバがrecursiveするんだ！」と聞いて「あ！なるほど！」と思いました。
RFC1034が書かれた頃のインターネットの設備は今では考えられないこと貧弱で、iterativeという動作は「とてもリソースを使う動作」だったとか。
それで、iterativeするほどリソースに余裕がないサーバが、iterativeできるサーバにrecursiveしたとのことです。
今の時代ならば、リゾルバをクライアントが直接iterativeできるそうですが
現在の端末ならば、リゾルバを介さずに、クライアントから直接iterativeできるぐらいの性能が出るそうですがNAT環境でそれをやると、NATテーブルがいっぱいになるから注意とのことです。(；´∀｀)
鈴木先生(@tss_ontap_o)より「クライアントのリゾルバに直接 iterative を追わせられるリソースは確保できる」と教えていただきました・・・こっちのほうがしっくりくる・・・。
私の言い方だとリゾルバ不要、と受け取れますね・・・日本語ﾑﾂｶｼｲ
まだまだあるんですが、それは私の復習&予習が終わってからまた書くかもしれません。
読書会に参加して思ったこと
ひとことでいうと・・・とても有意義でした！
富山から片道3時間半かけていきましたが、行った価値があったと思いました。
自分のモヤモヤが晴れたこともよかったんですが、技術的な話する場に行くと、刺激を受けていいなぁ、と思いました。
読書会の後は
読書会の後、近所の居酒屋さん「串太郎」で懇親会がありました。
何気に人生初ガード下居酒屋（＾ω＾）
バスの時間があり1時間ほどでさよならしましたが、とてもとてもおいしかったです。
昼抜いてたせいか、ムシャムシャ食べ過ぎたわ。。。
今度行くときは富山の地酒持参で行きたいなぁと。
今後
第2回が3/24開催とのことです。
それまでに復習と予習をしておかなきゃ( ﾟдﾟ )
他の参加者の方の声など
Togatterにまとめを作成されたそうです！ありがたや～
RFC 読書会 - RFC 1034 第1回 - #1034reading - Togetterまとめ
