IPアドレスは個人情報・個人データと "即座には" 言えないという話
人間、生きているとIPアドレスを持つけれど、そのIPアドレスは果たして個人情報やそれに類するものに相当するのだろうか、という話。 結論から言うと、「即座には」個人情報であるとは言えない、というのが EU の現在*1の状況だ。これは多分カリフォルニアとかでも同じ。
TL;DR あるいは FAQ
- GDPR のもと、 IP アドレスは個人データになりうるが、それは国のような ISP からデータを引き出しうる存在か、 Tech Giants のように大量のデータを保有していてそれにより個人を特定可能な存在が保有している場合のみ。一般人やそこらの Web ページ管理者には本来そこまで関係はない
- 個人データに相当する場合であっても、外部からの攻撃への対処など、正当な事由があれば、IPアドレスを保持することはできる
- CDN については今のところNGとなる事例は見てない（知ってたら教えてください）
- Web Fonts の件はだいぶきな臭い。配布元を直リンクせず、自環境から配信するようにしとくのが無難
GDPR における重要判決
2016年、ドイツ連邦政府が持つWebサイトにて国民のIPアドレスを保管していることはGDPRに違反している、という訴えがあった。日本では考えられないようなことだけど、なるほど論理は成立している。政府のアンケートサイトでIPアドレスが収集されていたら、政府はその回答が誰によるものかを特定できてしまう可能性がある。したがってIPアドレスは個人データであり、その用途についてユーザに明示されなければならない、と。
これに対するEUの最高司法機関であるところのCJEUは、以下の見解を示した：
- IPアドレスは、ISPのようにアドレスと個人とを紐づけられるリストを持っている場合には個人データにあたる
- 紐づけるデータを自身が持たない場合であっても、それを現実的に紐づけられる可能性がある場合は、個人データにあたる
- 政府は必要に応じて ISP から情報を召し上げることが可能なので、この条件が当てはまる
- 個人データにあたる場合であっても、攻撃への対処など、運用に必要である場合は保持できる
簡単に言うと、政府やISPでなければIPアドレスを個人情報として取り扱う必要はない、ということになる。
個人データに相当するはず？？
GDPR には IP アドレスは個人データの代表的な例として明示されている！！という主張を見たことがある。
It's been made clear in the General Data Protection Regulation ("GDPR") that IP addresses should be considered as personal data as the text includes "online identifier", in the definition of "personal data". Recital 30 clarifies that "online identifier" includes IP addresses.
先ほどの判決が 2016 年である一方、実は GDPR は 2018 年に改訂されている。 2016 年の判決より 2018 年以降の条文のほうが重要だ、というのは完全にその通り。 うーん、でもそんな2年でそこまで正反対に変わるだろうか。 GDPR 原文を見に行ってみよう。
The term ‘personal data’ is the entryway to the application of the General Data Protection Regulation (GDPR). Only if a processing of data concerns personal data, the General Data Protection Regulation applies. The term is defined in Art. 4 (1). Personal data are any information which are related to an identified or identifiable natural person.
（雑な訳）GDPR は、処理されるデータが「個人データ」に相当する場合のみに適用される。個人データは、識別された（あるいは識別可能な）個人に関する情報である。
The data subjects are identifiable if they can be directly or indirectly identified, especially by reference to an identifier such as a name, an identification number, location data, an online identifier or one of several special characteristics, which expresses the physical, physiological, genetic, mental, commercial, cultural or social identity of these natural persons. In practice, these also include all data which are or can be assigned to a person in any kind of way. For example, the telephone, credit card or personnel number of a person, account data, number plate, appearance, customer number or address are all personal data.
（雑な訳）データが識別可能であるとは、名前やID番号、位置情報、オンライン識別子、個人の属性などにより個人を識別可能な場合をいう。
Since the definition includes “any information,” one must assume that the term “personal data” should be as broadly interpreted as possible. This is also suggested in case law of the European Court of Justice, which also considers less explicit information, such as recordings of work times which include information about the time when an employee begins and ends his work day, as well as breaks or times which do not fall in work time, as personal data. Also, written answers from a candidate during a test and any remarks from the examiner regarding these answers are “personal data” if the candidate can be theoretically identified. The same also applies to IP addresses. If the controller has the legal option to oblige the provider to hand over additional information which enable him to identify the user behind the IP address, this is also personal data. In addition, one must note that personal data need not be objective. Subjective information such as opinions, judgements or estimates can be personal data. Thus, this includes an assessment of creditworthiness of a person or an estimate of work performance by an employer.
（雑な訳）定義に「いかなる情報も」と含まれているとおり、管理者は「個人データ」に相当するものが広範であることを認識しなければならない。例えば勤務時間。例えばテストの回答。そのデータから個人を理論上特定できるのであればそのデータは "personal data" 「個人データ」となる。 これは同じことがIPアドレスにも言える。データの持ち主がそのIPアドレスから個人を特定するための情報をISP（プロバイダ）から引き出すことができるのであれば、それは個人データである。
とある。改めて読んでみると、GDPRにおけるIPアドレスの取り扱いは2016年の判決をそのまま定義に落とし込んだようなものであるのがわかる。
一点違っているかもしれないのは、2016年の判決ではあるデータから個人が「現実的に特定可能である」場合に個人データとなるとされていたものが、GDPR原文では「理論上特定可能である」と明記されるようになっている点。2016年は時間的・コスト的に特定が現実的に可能である場合とされていた。これは例えば3年と100億円かけて一人の人間を特定可能だったとしたとき、それを現実的ととらえるかは判断が分かれそうなところだった。のだが、2018年改正GDPRではそれくらいであれば理論上特定可能と判断されるんだろう。
（余談だけど、 GDPR における「個人を特定」という言葉は、必ずしも個人を1人に特定できる必要はない。ある程度の狭い属性に絞れたらそれで充分個人を特定できているものと考えている）
ということで、 GDPR において IP アドレスは即座に個人情報となるわけではない。また基本的には 2016 年の判決をもとに判断していけばよい。
2022年初のドイツの判決は？
で、今話題の。
2022年1月、ドイツ地方裁判所にて、「Web Fontsを利用したことはIPアドレスがGoogleに渡っており、個人データの域外移転にあたる。原告に100ユーロ払え」という判決が出た*2。
これも記事にまとめたかったけど、眠いから今日はここまで。ざっくり言うと
- ストーリー
- 判決の中で述べられている興味深い点
- 所感
- いや IP アドレスを渡してるのはその Web サイトというわけではない（本人が直接アクセスしている）んだけども……でもユーザからの許可なくアクセスさせているからダメということらしい。まあリファラもあればその他 fingerprint もあるから、それで個人を特定できるからダメという話自体は理解できなくはないのだけども
- 所詮100ユーロなので弁護士費用や時間効率を考えるとこれで荒稼ぎするのは難しく、いやがらせに使う程度だろうか。日本の非Health企業に矛先が向かうのはもうちょい先かなあ
- Web サイトの規約に「ここに送信します」って書いただけだと今回の Web Fonts 問題は多分回避できない
- 今回の判決はドイツ地裁なので、今後変わる可能性はある。ただ、オーストリアの件も然り、 EU 全体として今は締め付ける方向に話が向かっており、今後も継続的に様子を見ていかなければならない
- Web Fonts は自分のサーバから配信するようにしておくのが無難
- Google と GDPR とは広告における個人特定に関してずっと確執があった。ここでの IP アドレスは広告における個人の特定という文脈のほうが近そう
あとこの記事が勉強になったので忘れないようリンク張っとく：
色々と勉強中なので有識者からのツッコミ大歓迎です。
個人情報流出疑いは発表すべきかどうかの議論
セキュリティインシデント、とりわけ個人情報等*1流出の疑いがあったときにどういう行動を取るべきかについては大きく分けると二流派あって、かたや絶対に公表しない派、かたや絶対に公表する派。これはセキュリティの専門家のあいだでも議論が完全に分かれる話になっていて、飲み会でうっかり話題にするともう大激論になってしまう、セキュリティ業界のきのこたけのこ（あるいはEmacs-Vim）と言えるネタになっている。らしい。
そんな議論に対して自分自身の考えをいい加減まとめないとなあと思って諸々調べた結果、以下の結論にたどり着いた：
必要があれば公表するし、必要がなければ公表しない
何を当たり前な、と思われそうなので、以下で説明していきたい。 ……と、その前に前提として、公表する・しない両派の考え方を書いておきたい。
公表しない派の考え方
公表しない派の考えはシンプルだ。必要のないことだから、だ。
公表の必要がないものを公表するのは自分勝手な正義に過ぎない。 株式会社には株主というステークホルダーがいる。公表という行動は株価を下げる可能性があり、セキュリティ上の実効性がないにもかかわらず会社のレピュテーションを毀損し、株主に損害を与えるリスクだけがある行為になる。また必要以上の問い合わせを受けることにもつながる。必要がない限りは公表すべきではない。
公表する派の考え方
では、公表する派の人は何を考えて公表すると言っているかというと、これはひとえに「隠すリスクが高すぎるから」、これに尽きる。 隠していたものをあとで「実は問題わかってましたﾃﾍﾍﾟﾛ」と説明するのは取り返しがつかないほど心証が悪い。それであれば予め、漏洩の可能性がわかった時点で公表しておいて、あとで「これは何でもありませんでした」と規模を小さく説明し直すほうがダメージが少ない。
IPA の「情報漏えい発生時の対応ポイント集」4ページ目にも、透明性・開示の原則として以下のように記載されている。
被害拡大防止や類似事故の防止、企業組織の説明責任の観点から必要と判断される場合には、組織の透明性を確保し情報を開示する姿勢で臨むことが好ましいと考えられます。情報公開により被害の拡大が見込まれるような特殊なケースを除いては、情報を公開することを前提とした対応が企業（組織）の信頼につながります。
どちらも組織のためを思ってそれぞれの正義でもって公表する・しないを信念持って定めているわけなので、こうなってくるともうお互いに議論は平行線だ。 しかしそれにしても、法律や業界標準、規制などはないのか、というと……：
法律上の定めでは、公表の義務はなし
実はそのものズバリなガイドラインがある。
個人データの漏えい等の事案が発生した場合等の対応について ｜個人情報保護委員会
これは法律ではないけど、個人情報保護法では大抵のことは個人情報保護委員会が定めるものに従うことになっているので、そのガバナンスの一環としては法体系の一部のような位置づけのようなものととらえてそう遠くはないだろう。
こちらによれば、通知が必要なのは漏洩被害のあった本人、個人情報保護委員会（等）である。公表については以下のように記載がある：
個人情報取扱事業者は、漏えい等事案が発覚した場合は、次の（1）から（6）に掲げる事項について必要な措置を講ずることが望ましい。
（中略）
(6) 事実関係及び再発防止策等の公表
漏えい等事案の内容等に応じて、二次被害の防止、類似事案の発生防止等の観点から、事実関係及び再発防止策等について、速やかに公表する。
素直に読むと、「公表は義務ではないが、必要ならやるべき」ということになる。「必要」かどうかは組織の判断が必要だろう。
一方このガイドラインに関する FAQには、以下のように記載されている：
Q12-5 漏えい等事案が発覚した場合に講ずべき措置（中略）について、「漏えい等事案の内容等に応じて」とされていますが、どのような場合に本人への連絡等や公表をしなくてもよいのですか。
A12-5（略）公表については、サイバー攻撃による場合等で、公表することでかえって被害の拡大につながる可能性があると考えられる場合にはこれを差し控え、専門機関等に相談することも考えられます。また、漏えい等事案の影響を受ける可能性のある本人全てに連絡がついた場合に公表を省略することも考えられます。
公表を前提としているとも、個人情報保護委員会は直接関与しないという姿勢を取っているようにも読める。
全員への連絡のための手段としての「公表」
さておき、このガイドライン FAQ で重要なのは、「本人全てに連絡がついた場合には公表を省略できる」という部分だ。これは裏を返せば、本人すべてに連絡がつかない場合には公表を省略できない*2、ということになる。すなわち、公表は漏洩対象全員への連絡手段として考えられるということだ。
個人情報保護委員会のガイドラインによれば、漏洩の事実や可能性がわかった段階で本人へ連絡をすることが必要なわけだが、全員に連絡がつくとは限らない。たとえば退会していたり、メールアドレスが正しくなかったり解約済みだったり……。こういったケースでは、個人情報保護委員会の定める「全員への連絡」をすることが困難になる。
この「全員への連絡」の手段として、公表というのは非常に現実的な選択肢だ。というかほかにない。
なお漏洩対象の個人への連絡は 2021 年 7 月現在は努力義務である一方、 2022 年施行予定の改正個人情報保護法では必須化される予定となっている。現時点でも、努力義務と言っても遵守する必要は高いもの*3だが、改正後は公表の必然性がより高まるとも考えられる。
[PDF]改正法に関連する政令・規則等の整備に向けた論点について（漏えい等報告及び本人通知）
ちなみに個人情報保護法の令和2年改正では、「個人の権利利益を害する」かどうかが主軸となる。そのため、漏洩させた企業は、その個人の権利利益を保護することを目的として事後対応を行っていくことになる。
「おそれ」段階でも基本的に同じ
では、漏洩のおそれがある段階、すなわち侵害の事実が判明したものの漏洩の事実は確認できていない段階では、公表や通知等はどのようにするべきか？というと、これは非常にシンプルで、基本的に「おそれ」段階でもやるべきことは変わらない。本人に連絡し、個人情報保護委員会等に連絡し、必要に応じて当局（この場合は警察や管轄官庁）と連携をとっていく。
先ほどから挙げている、個人情報保護委員会の「個人データの漏えい等の事案が発生した場合等の対応について（平成 29 年個人情報保護委員会告示第１号）」に以下の通り記載があるとおりだ。付け加えることはない。
１．対象とする事案
本告示は、次の（1）から（3）までのいずれかに該当する事案（以下「漏えい等事案」と いう。）を対象とする。
（1）個人情報取扱事業者が保有する個人データ（特定個人情報に係るものを除く。）の漏えい、滅失又は毀損
（2）個人情報取扱事業者が保有する加工方法等情報（個人情報の保護に関する法律施行規則（平成 28 年 10 月５日個人情報保護委員会規則第３号）第 20 条第１号に規定する加工方法等情報をいい、特定個人情報に係るものを除く。）の漏えい
（3）上記（1）又は（2）のおそれ
公表しない場合
公表を要しない場合についてもガイドライン FAQ に記載がある。 例えば脆弱性があって、公表したらもっと情報が漏れますなんて状態のときは、当然公表はすべきではない。
透明性の原則について
ところで、 IPA の言う「透明性・開示の原則」とは一体何なのか。 IPA の先ほどの情報漏えい発生時の対応ポイント集の記載をもう一度見てみると：
被害拡大防止や類似事故の防止、企業組織の説明責任の観点から必要と判断される場合には、組織の透明性を確保し情報を開示する姿勢で臨むことが好ましいと考えられます。情報公開により被害の拡大が見込まれるような特殊なケースを除いては、情報を公開することを前提とした対応が企業（組織）の信頼につながります。
説明責任や市場から見た好ましさ、組織の信頼性といった要素が挙げられている。 個人として考えてみると、ある企業を信頼するかどうかに、透明性が大きく関わってくるのは当然ではある。
日本製薬工業協会の [PDF]「透明性の確保に関する取り組み 」というドキュメントには以下のように記載がある：
会員会社の活動における医療機関等との関係の透明性を確保することにより、製薬産業が、医学・薬学をはじめとするライフサイエンスの発展に寄与していること及び企業活動は高い倫理性を担保した上で行われていることについて広く理解を得ることを目的とする
やはり、透明性は CSR の一環として確保されるべきものと考えるとややスッキリする。もちろん株式会社や上場会社として果たすべき部分はあるにしても、そうではなく、明確な要請のないところに透明性を確保することで企業活動の信頼性を高める、一種の社会貢献という面があると見るとスムーズだ。業界によっては競争力になるにせよ。
両派の言い分ってほとんど同じだったのではないか？
以上のことをまとめると、個人情報が漏洩した場合の対応というのは、以下のようになる：
- 個人情報漏洩の事実が認められた、あるいはそのおそれが発覚したら、以下の手続きをとる
- 個人情報保護委員会に通知
- 漏洩した本人全員に通知
- 連絡が取れない人に対しては、公表など、本人に連絡を取る努力をする
……と、ここまで来ると、公表するしない両派の考え方って実はほとんど同じか、あるいはすごく狭い範囲での違いを話しているだけに思えた。
公表しない派は、誰か一人でも連絡が取れなければ公表するのはほぼ既定路線。漏洩した全員と連絡が取れるのにわざわざ公表するなんて考えられない、という程度の話だ。
一方で公表する派は、「隠蔽」を嫌っている。「隠蔽」としては、個人情報保護委員会や本人へ通知してないケース、あとから公表が必要だとわかったケース、などが考えられるが、いずれも本来実施すべきことはガイドライン通りの一本道だ。 前者は、個人情報保護委員会や本人に通知してない段階で是正勧告対象。公表以前にアウトな行動だ。 また後者、あとから公表が必要だとわかったケースも、「おそれ」段階で最大漏洩人数を適切に把握できていないのが問題。連絡が取れない人がいるとわかった時点で、公表等の手段を検討する必要がある。
公表する派と公表しない派とが衝突するのは、正しく個人情報保護委員会と漏洩した全員に通知できた場合に、その事案を社会責任として公表するかどうか……というケースだけだ。
「サイバーセキュリティ法務」では？
手元にたまたま「サイバーセキュリティ法務」という本があり、そこに書いてある内容が実に腑に落ちるものだった。（アフィリンク）
こちらの評価では、基本的には透明性原則を優先して公表すべき、という考え方をしている。とくに上場企業であれば適時開示をする必要があるが、そうでなくても、被害の可能性がある場合には可能な限り早い段階で被害者にリーチしておくことで二次被害を防ぐことが重要であるとしている。
一方で、公表の必要がないケースとして、被害拡大のおそれが実質的にない場合、好評により被害が拡大するおそれがある場合のふたつが挙げられている。
とはいえケースバイケースなので、公表する・しないことで生まれる利益不利益を利益衡量することが必要だろう、というところで公表判断のところは締められている。
この考え方は非常にしっくり来る。ただ、結局公開するしないはまさしく透明性に関する組織全体の考え方に依るところが大きい。個人的な方針としては、自分自身としては透明性原則をやや優先しながら、組織としての判断を尊重していくのがよいかな、というところに落ち着きそうだ。
年収、所得、額面、手取り？調べてみました！
年収とか所得とか給与とか、額面なんだか手取りなんだかぜんぜんわからん！って毎回思って、必要に駆られて調べては必ず次回までには忘れている。 でも確か「収入」は何に対して使う言葉だーとか、税務署的にはきちんとした定義があった、というところだけは、おぼろげながらに覚えている。 いい加減忘れては調べるこの無駄ループに飽きてきたので、メモとしてまとめる。
なお、この記事は 2021/04 の税制をもとに非専門家が調べたもの。税制はすぐに変わっていくものなので、細かいところは参考にしないほうがいい。また税に関するアドバイスは税理士でなければ行ってはならないので、この記事もそういうアドバイスではないというところは読者には強く念押ししておきたい。
収入
まずは「収入」。会社員の場合は「給与収入」がこれに相当する。つまりは額面になる。
給与以外でも利子や不動産・配当等で得たものも、税金を引く前の金額が「収入」。
給与所得（→合計所得）
給与収入から、給与所得控除と所得金額調整控除を引いたものが「給与所得」。給与のみの所得の人にとっては、単に中間的な生成物の感がある数値だ。さらに、株や土地など他から得た収入からも同様に所得を計算し、それらを合算して「合計所得」として取り扱うことになる。
給与所得控除は、ようは税金を引かれずにそのままもらえる金額。収入が増えると引かれる割合も減っていき、最大で195万。給与収入等が660万円以下の場合は所得税法の別表を見ろと書いてあるが、これはようは切り上げ切り下げがあるだけなのであまり気にしなくていい。
所得金額調整控除は、 850万以上の収入がある人に子ども等がいるなどするとつく場合があるやつ。最大15万円。
課税所得
給与所得からさらに所得控除を引くと「課税所得」になる。
所得控除は、よく見るやつら。医療費控除、生命保険控除、寄附金控除、配偶者控除、扶養控除、基礎控除といったもの。社会保険で支払った金額やふるさと納税で支払った費用が引かれるのはここ。
- 基礎控除： 48万円。基礎控除引かれない自虐は2400万円超の合計所得がある人なので逃げろ。
- 社会保険料控除： 社会保険料全額。全額と言っても支払った金額の全額なので、会社が負担してくれている分は含まれない。
- その他：どうせ必要なときに調べるので、省略。
課税所得からの納税
よく見る控除を引いたあとの金額に対して、所得税と復興税がかかる。
ここでかかった所得税から、住宅ローン減税や災害減免などの額を直接控除できる。逆に言うと、課税所得が足りないと住宅ローン減税の恩恵は十分に受けられないので、ギリギリの人の場合はふるさと納税が（普通に買うよりも）損になる可能性はわりとある。
で、ここで計算される所得税・復興税の合計と、源泉徴収された額とを比較して、違いがあれば追加で納税したり還付を受けたりして調整することとなる。
住民税
以上は所得税の計算方式で、住民税は控除の方法が異なっている。また所轄も国税庁ではなく地方公共団体の方になってくる。東京都だと東京都主税局。
所得税とはこまごま計算が違う。ただ、基本的には各種控除をしたあとに「課税所得金額」が計算され、そこから約10%の住民税が計算されるという形になり、基本形は同様。これは前年度（1~12月）の収入をもとに計算され、その支払いは翌年6月から。ときどきスポーツ選手とかが給料を使い果たして住民税を払えないみたいな話を見たりするよね。
今日は所得税でおなかいっぱいなのでこの辺で。あとで住民税についてはよりちゃんとした記事を追加するかも知れないしここを編集するかも知れないし何もしないかも知れない。
いかがでしたでしょーか（投げやり）
DNS における Master/Slave vs Primary/Secondary の現状（2020/06）
BLM の関係でコンピュータ業界の Master / Slave という言葉遣いにもメスが入ろうとしているいま、 DNS ではどうなっているんだっけ、というのがふと気になった。
というのも mattn さんの blacklist/whitelist master/slave に関する情報集め を見たから。あとコメントもしたから。
で、調べて行ったところ、ひとことで言えば既に Primary / Secondary になってるんだけど、そもそもこの用語自体そんな使わないよな、と思ったのだけど、そのあたりを解説するのは元記事の関心ごとと全く違うってことで、改めて自分のブログの記事にしてみたというわけ。
DNS は趣味でしかないので、ツッコミ大歓迎です。
Primary/Secondary が正しい用語です
用語に困ったら RFC 8499 (Jan, 2019) が正しい参照先。こう書いてある：
Slave server: See "Secondary server".
Secondary server: "An authoritative server which uses zone transfer
to retrieve the zone." (Quoted from [RFC1996], Section 2.1)
Secondary servers are also discussed in [RFC1034]. [RFC2182]
describes secondary servers in more detail. Although early DNS
RFCs such as [RFC1996] referred to this as a "slave", the current
common usage has shifted to calling it a "secondary".
Master server: See "Primary server".
Primary server: "Any authoritative server configured to be the
source of zone transfer for one or more [secondary] servers."
(Quoted from [RFC1996], Section 2.1) Or, more specifically,
[RFC2136] calls it "an authoritative server configured to be the
source of AXFR or IXFR data for one or more [secondary] servers".
Primary servers are also discussed in [RFC1034]. Although early
DNS RFCs such as [RFC1996] referred to this as a "master", the
current common usage has shifted to "primary".
Current common usage has shifted to "primary/secondary". こちらを使うことが推奨されている。 これ自体は以前からそうだったけど、 2015 年に RFC 7719 （8849 の前身）が出るまではどちらも併用されてしまっていたのだろう。 とはいえ用語としては Primary / Secondary の方が推奨はされていた記憶はある。歴史が気になってきた。
そもそも Primary / Secondary, Master / Slave とはどこから来たか
もともと Paul Mockapetris が RFC 1034, RFC 1035 （November, 1987）やその前身である RFC 882, RFC 883 （November, 1983）を書いたときの用語は Primary server / Secondary server だった。この時点で Zone transfer の機能は DNS のプロトコルにあった。
続いて BIND の開発をしていた Paul Vixie が 1996 年に RFC 1996（August, 1996）を書いた。これは DNS NOTIFY の機能を提供するための OPCODE NOTIFY を定義したもの。ここで初めて Master Slave という言葉が明に出てくる。 NOTIFY は Primary server が Secondary server を叩いて更新を知らせる仕組みなので、このプロトコルのうえで master / slave と言いたくなる気持ちはわからんでもない。サーバ機能を見るときとプロトコルを見るときとで若干インピーダンスが違うよね。
その翌年 1997 年 5 月に BIND 8 がリリースされる。 Zone transfer の設定における master slave の設定項目は BIND 8 から出てきたとの噂（要出典）。当時の BIND の開発責任者には Paul Vixie がいる（ここは事実）ので、自分の書いた RFC を参照して用語を決めるのは自然なことだったと推察される（ここは曖昧な記述）。
なお、同年 7 月に出た RFC 2182 では Secondary DNS サーバの運用方法について書いているが、ここでの用語は Primary / Secondary 推しだ。 Master / Slave という言い方が存在することにも触れているが。
Primary Server An authoritative server for which the zone
information is locally configured. Sometimes
known as a Master server.
Secondary Server An authoritative server that obtains
information about a zone from a Primary Server
via a zone transfer mechanism. Sometimes
known as a Slave Server.
その後長い混乱の時期が続いたあと、 2015 年に RFC 7719 として正式に Primary server / Secondary server が master / slave を override することになった。
BIND 以外のサーバでは？
とは言っても、 DNS は BIND そのもののことではなく、他にいろんなサーバ実装が存在している。他ではどうなっているのかみてみよう。
NSD, Unbound (NLnet Labs)
NLnet Labs の DNS 実装、 NSD / Unbound では Primary / Secondary という言い方をしている。また、設定ファイル内にはゾーン転送を示す xfr しかない。つまり、設定ファイルの中に primary / secondary や master / slave という言葉が入り込まない。実に素晴らしい。
PowerDNS
PowerDNS は BIND こそ DNS と思っているようなところがある（超偏見、多分そんなことない）ので、 Master / Slave という用語をバリバリ使っている。 ゾーンファイルも BIND 形式だしなあ。
↑ブクマにてご指摘いただきました。ゾーンファイルは RFC 1035 の MASTER FILE として定義されているので、これに従っていること自体を BIND と結びつけるのは微妙であるとのこと、たしかにですね
djbdns
DJB 大先生の書いた DNS サーバ。脆弱性が出ないことで有名。 edns0 に対応してないくらい古いのでもう使うべきではないけれども。
DJB 大先生は master / slave の表現を取っているが、 primary / secondary という呼び方にも言及している。が、そもそも rsync + ssh の方がよっぽどいいのにわざわざ脆弱性の多い zone transfer 機能を使うなんてアホかとズタボロにけなしている。今なら git で同期することも簡単だし、さすが大先生、先見の明がありすぎる。
https://cr.yp.to/djbdns/tcp.html
けなしつつ、一応 AXFR するための仕組みは用意してくれるあたりさすが大先生。
https://cr.yp.to/djbdns/axfrdns.html
Bundy
ISC が BIND9 の実装をつらいと考え、次世代 BIND10 としてモジュール型の DNS サーバを 2009 年に開発開始した。モジュール型というか多プロセスシステムというと Postfix を思わせる。
しかしこの BIND10, 最終的には BIND9 をリファクタリングした方がマシという結論になってしまい、2014年に Bundy プロジェクトとして OSS になった。その後はほぼ放置されていて、野性味溢れる草が生える気持ちである。
さて Bundy ではゾーン転送は基本的に primary / secondary である。ただし設定の中には secondary_zones master と、用語が混在しているようで、うーん……。
Windows DNS Server
正直詳しくないのでわかっていないけれど、 FAQ を見る限りでは Primary / Secondary の方の用語を使っている模様。
いまどき DNS の Primary / Secondary
さて、そんなこんなでゾーン転送に関わる Primary / Secondary VS Master / Slave 論争を見てきた。が、さまざまな技術が発展してきた現代においてゾーン転送はいまでも主流なんだろうか。
まあ多分メインストリームの一つではあるんだろうけど、とはいえもっと違う構成がどんどん出てきているのも事実。
- 隠れマスタ構成
- OctoDNS 等、ソフトウェア的同期
- Google Public DNS の事例
隠れマスタ (hidden master) 構成
書いて名の通り、 master (primary) サーバは公開せずに、その master サーバから xfr を受けるサーバだけをインターネット上に公開する方法。 xfr 周りは実装が複雑なため脆弱性も多く、ここをインターネットに晒さないだけで守れる部分が多いということ、 master が多少死んでも顧客影響がないので運用しやすいこと、インターネット公開するサーバ実装をたとえば NSD と PowerDNS Authoritative にするなどベンダ冗長をとりやすいということなど、何かと利点が多い。
下の記事がこのあたりをわかりやすくまとめている。
このほかの記事としては、以下のものも参考になる。
- https://dnsops.jp/event/20130719/20130719-dns-design-yamaguchi-2.pdf
- 私は多分この発表で知った気がする。 P26, 27 を参照
- DNSベストプラクティスとは「隠す」そして「重ねる」 − ＠IT
- 2007 年にもう知られた概念だったのか。ここでは「ヒドゥンプライマリ」という言い方をしている
で、隠れマスタ構成になってくると、もう primary サーバはユーザからは見えないわけで、用語としての primary / secondary に意味あるかなあ？となってくる。
OctoDNS 等、ソフトウェア的同期
DJB も言っていたように、ゾーン転送 xfr はあくまでサーバ間同期のひとつの手段でしかない。今であれば DNS サーバを autoscaling で増やすようなことも可能なわけで、ソフトウェアやサービスを使った同期というのは現実的だ。
また、そもそもゾーンの更新はデプロイであると考えると、 Web 系のデプロイツールや構成管理ツールが便利に使える。つまり、 Chef, Ansible, Puppet のような構成管理ツールで外からサーバを特定の状態にしたり、 Capistrano や Fabric のようなデプロイツールで最新の設定ファイルを配ったりできる。さらには、 consul/serf や AWS SSM のようなツールでもって、同期イベントを発行するようなパターンも考えられる（イベントを受けた各ホストでは git pull でも docker pull でもすればいい）。ゾーンファイルを同期するなんて目的のために、わざわざ xfr する必要はない。
そんな状況下、 OctoDNS を使うという手が提示された。これがおもしろい。
https://dnsops.jp/bof/20191128/octodns-takizawa.pdf
OctoDNS は、各種 DNS サービスへレコードを同期させるだけのソフトウェア。 AWS, GCP, Azure のようなクラウドだけではなく、 DynDNS, Akamai, Cloudflare, DigitalOcean などにも対応しているのが素晴らしい。設定ファイルとゾーンファイルがあれば、あとはそれを自動的に対象プロバイダに同期させてくれる。
同期、というのがポイントで、レコードを追加するだけではなくて削除もこのコマンド一発である。なので野性味溢れる状態のレコードを持っている場合は対応が難しい。
一方で、単一のゾーンファイルを持っていれば、そのゾーンファイルを複数の DNS プロバイダに展開することができる、というのが素晴らしく強い。いまどき単一の DNS プロバイダでも十分すぎるほど冗長化されていたりするけれど、そのプロバイダの根元がやられることっていうのは今でも時々はあるので、まあ、要件によるしクライアント側の実装にもよるんだけど、プロバイダ冗長をしておきたいような人には便利このうえないツールとなるかもしれない。
また、これらの DNS プロバイダはゾーンのマスタ情報として利用することもできる。つまり設定ファイル一発でゾーンを別サービスに丸コピできる。しかも SOA と NS は更新されないので引越しの調整を手でできる。おっそろしく便利。もうここにサポートされていないサービスは使いたくないお……
Google Public DNS の構造
Google Public DNS は Full Resolver なのでそもそも Authoritative Server 側のゾーン転送の仕組みとは全然別の話ではあるんだけど、大規模な DNS サービスの中で既存の DNS の仕組みを使っていない（あるいは大幅なハックが行われている）事例として紹介したい。
世界中に地域分散させたフルリゾルバが二段階のキャッシュをしていると。とはいえキャッシュだけであれば forwarder を設定すれば BIND でも二段階にできる。 ここで Google Public DNS の性能に関する解説を見てみると、 Google 側で明らかに「何か」をしているのが垣間見える。
曰く、「一次受けサーバはローカルにもっともよく使われるキャッシュだけ保持する。二次受けクラスタではその他全てのクエリを受け、キャッシュを保持したサーバへ渡るよういいかんじにロードバランシングする」。二次受け側で FQDN 別のロードバランシングをしているのも実装どころだけど、一次受けサーバで DoS 対策をしてある（Bogus なクエリの Negative Cache だけでキャッシュが埋め尽くされない）仕組みの方も結構なもの。いずれにせよ、全体として明らかにソフトウェア的に対策をしている。
いまどきの DNS 構成
そんなわけで、そもそも今時の DNS 構成では master だ primary だということを考えるシーンは少ない。それこそ DNS サービスプロバイダ以外はほとんど使うことはないだろう、と言いたいところだけどまあ情シスは必要なことも多いか。
さて、だいぶ話がずれてしまった。
元々は DNS において Master / Slave, あるいは Primary / Secondary とはどういう風に言葉が使われてきたか・これから使われていくか、という話だった。だらだら書きたいことを書いてしまったが、最後に結論を述べて終わりにしたいと思う。
結論
DNS においては Master / Slave ではなく Primary / Secondary というのが正式な言葉遣いであると 2015 年に定められた（2019 年に更新されてもいる）。今後はこれを使うのが正しい用法である。
ただ、歴史的経緯により未だに BIND9 等のサーバ実装には設定に master / slave という項目が残っている。一方、 BIND 以外の DNS サーバ実装では、新しいものでは primary / secondary を使う傾向にある。
また、ゾーン転送の仕組みがそもそも必要ではないシーンも増えてきている。完全になくなることはないだろうが、今後 Primary / Secondary という言葉を使う機会自体が減るのかもしれない。
いずれにせよ、 DNS が未来に向かい、 Master / Slave という用語が完全に過去のものとなってくれることを願う。
ホスト名で許される文字って何なんだっけという話
以前の同期の友人と、そういえば数字だけのドメイン名って許されてるんだっけ？という話題で一通り盛り上がった。なかなか面白いことがわかったのと、イマイチよーわからんなーということが出てきたので、せっかくなので記事にしておこうと思う。
TL;DR
数字だけのドメイン
https://0.30000000000000004.com/ というサイトが Twitter で回ってきた。 こういうドメインって RFC 的にどうなんだっけ。数字だけのドメインって大丈夫なんだっけ？
ホスト名の定義（大元）
host name については、元々は RFC952 に記載がある。以下、関係のある部分だけ抜き出し。
GRAMMATICAL HOST TABLE SPECIFICATION
<official hostname> ::= <hname>
<hname> ::= <name>*["."<name>]
<name> ::= <let>[*[<let-or-digit-or-hyphen>]<let-or-digit>]
見ての通り、 name は文字から開始して、あいだにハイフンとか入ってもいいけど、最後は letter or digit で終わること、とある。ホスト名はこれがドット区切りで1つか複数。これが最初のホスト名の定義だ。*1
でも、ホスト名ってドメイン名と同じなんだっけ？定義はよくわからない。
わからないなら、調べるしかないよね。
ドメイン名の定義（大元）
DNS 初期の RFC は結構gdgdなのは業界的に常識だけど、とりあえず RFC1035 を見てみよう。 ホスト名に対して 推奨される 形式がさっそく見つかった。とりあえず定義部分だけを見てみよう：
The following syntax will result in fewer problems with many applications that use domain names (e.g., mail, TELNET).
<domain> ::= <subdomain> | " " <subdomain> ::= <label> | <subdomain> "." <label> <label> ::= <letter> [ [ <ldh-str> ] <let-dig> ] <ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str> <let-dig-hyp> ::= <let-dig> | "-" <let-dig> ::= <letter> | <digit>
The labels must follow the rules for ARPANET host names. They must start with a letter, end with a letter or digit, and have as interior characters only letters, digits, and hyphen.
この定義はホスト名とほぼ同じだ。違いとしては、先ほどは name だったものが label と呼ばれているくらいだろうか。 RFC 952 は ARPANET を念頭に書かれているので、 RFC 1035 の推奨するドメイン名は RFC 952 のホスト名と同等ということになる。
ただし、この部分はあくまで推奨。時代背景を見てみると、この頃はまだプロトコルの統一も完全でなければ商用インターネットもできる前なので、いろんな環境で共通して使えるような命名規則を作ろうとしていた…という面が強そうだ。
The DNS specifications attempt to be as general as possible in the rules for constructing domain names. The idea is that the name of any existing object can be expressed as a domain name with minimal changes. However, when assigning a domain name for an object, the prudent user will select a name which satisfies both the rules of the domain system and any existing rules for the object, whether these rules are published or implied by existing programs. For example, when naming a mail domain, the user should satisfy both the rules of this memo and those in RFC-822. When creating a new host name, the old rules for HOSTS.TXT should be followed. This avoids problems when old software is converted to use domain names. The following syntax will result in fewer problems with many applications that use domain names (e.g., mail, TELNET).
具体的に「何を使っていいか」ということになると、あまり具体的には指定されていないように見える。
ちょっと脱線してしまったので、話に戻ろう。
そう、数字だ。数字だけのドメイン。 結局、数字だけのドメイン名は RFC 違反なわけ？？
いやいやそんなわけ……。調べるしかないので、調べてみる。
ホスト名の定義（更新）
実はホスト名の定義は RFC1123 2.1 で更新されてる。
2.1 Host Names and Numbers
The syntax of a legal Internet host name was specified in RFC-952
[DNS:4]. One aspect of host name syntax is hereby changed: the
restriction on the first character is relaxed to allow either a
letter or a digit. Host software MUST support this more liberal
syntax.
「RFCC952 で定義されたホスト名の先頭の文字、べつに数字でもよくね？」って言ってる。 RFC952 の BNF っぽい記法でこれを書き直してみると：
GRAMMATICAL HOST TABLE SPECIFICATION
<official hostname> ::= <hname>
<hname> ::= <name>*["."<name>]
<name> ::= <let-or-digit>[*[<let-or-digit-or-hyphen>]<let-or-digit>]
ということで、めでたしめでたし。最初の疑問、「数字オンリーのホスト名はRFC違反か」という疑問への答えが出た。 答えは「the Internet 開始前、 1989年からRFC 1123 で許容されている」ということになる。
ドメインにアンダースコア
……が、ここでふと次の疑問が湧いてきた。アンダースコアってどうなんだっけ？
そういやホスト名ってハイフンしか使っちゃダメって書いてあるよね。でも Let's Encrypt とか各種サービスの認証で ACME 使うとき、アンダースコアから始まるドメイン名使うよね。あれは RFC 的にはオッケーなんだっけ？
Informational な RFC で許容されている
実は、 DNS Operation の方法を記した RFC1033 ではアンダースコアが明示的に許容されている。
The domain system allows a label to contain any 8-bit character.
Although the domain system has no restrictions, other protocols such
as SMTP do have name restrictions. Because of other protocol
restrictions, only the following characters are recommended for use
in a host name (besides the dot separator):
"A-Z", "a-z", "0-9", dash and underscore
各種サービス側で問題が出るから色々な制限を入れているけれど、 DNS はただのデータベースなのだから、何をラベルに使ったっていいんだ、アンダースコアはオッケーだよ、と、こう言っているわけ。
一方で、 RFC1912 というドキュメントがある。これは Common DNS Operational and Configuration Errors というタイトルの RFC 。重要な部分だけ抜き出してみると：
2.1 Inconsistent, Missing, or Bad Data Every Internet-reachable host should have a name. The consequences of this are becoming more and more obvious. Many services available on the Internet will not talk to you if you aren't correctly registered in the DNS. DNS domain names consist of "labels" separated by single dots. The DNS is very liberal in its rules for the allowable characters in a domain name. However, if a domain name is used to name a host, it should follow rules restricting host names. Allowable characters in a label for a host name are only ASCII letters, digits, and the `-' character. Labels may not be all numbers, but may have a leading digit (e.g., 3com.com). Labels must end and begin only with a letter or digit. Note there are some Internet hostnames which violate this rule (411.org, 1776.com). The presence of underscores in a label is allowed in [RFC 1033], except [RFC 1033] is informational only and was not defining a standard. There is at least one popular TCP/IP implementation which currently refuses to talk to hosts named with underscores in them.
つまりアンダースコアを使うのはよくあるミスであって、使うべきではないぞと。 また、 RFC1035 の表現は問題を避けたいがゆえの曖昧さでいっぱいなので問題だとも言ってる。著者のクセが強い。
ちなみに RFC2181 の方ではアンダースコアが許容されていると語る人もいて、うーんなるほど曖昧という気持ちになる。
The DNS itself places only one restriction on the particular labels that can be used to identify resource records. That one restriction relates to the length of the label and the full name.
結局、ドメイン名的にはアンダースコアは許容されているのかいないのか、微妙なところだ。
Apache 2.4 ではアンダースコアは使えない
じゃあ現実世界はどうだっけと、ふと Apache に目を向けてみると、なんと。
Apache 2.4 では host name を RFC 準拠にしたことで、 virtualhost などにアンダースコアを使えなくなっていた。まじかよ……
nderscores are not permitted in hostnames and are now rejected. RFC 3986 sec 3.2.2 - https://tools.ietf.org/html/rfc3986#section-3.2.2 -- A registered name intended for lookup in the DNS uses the syntax defined in Section 3.5 of [RFC1034] and Section 2.1 of [RFC1123]. Such a name consists of a sequence of domain labels separated by ".", each domain label starting and ending with an alphanumeric character and possibly also containing "-" characters. Using "HttpProtocolOptions unsafe" should allow the old behaviour.
https://bugzilla.redhat.com/show_bug.cgi?id=1410130
何がまじかよって、この RFC 3986 って URI を定義している RFC なんだよね。ということは、 URI 的には hyphen - は OK で underscore _ は NG とされているわけで。 Web サービスを提供する際は、ハイフンを使うのは必須だった ってことになる。知らなかった……。
Microsoft 的にはハイフンが推奨
とはいっても、やはりアンダースコアは世の中に存在している。存在するものをなかったことにはできない。ウォーハクタク。
ここで、 RFC に準拠しすぎて相互接続に難が出ることで有名な Microsoft のドキュメントを見てみよう。
ドメイン名にアンダースコア (_) を使用することは避けてください。 厳重に RFC に従ったアプリケーションがドメイン名を拒否して、 インストールされなかったり、ドメイン内で機能しなかったりして、 古い DNS サーバーで問題が発生する可能性があります。
意外と柔軟。
そして、こんな文言も見つかる：
アンダースコアには特殊な役割があり、RFC 定義では SRV レコードの 先頭文字として許可されていますが、比較的新しい DNS サーバーでは、 名前の任意の場所での使用が許容される場合もあります。
ん…？ SRV レコードの先頭には使っていいの？
SRV レコードの先頭には underscore を使っていいんです
SRV レコードでのアンダースコアについては、 RFC2782 に明確に記載がある。
The format of the SRV RR
Here is the format of the SRV RR, whose DNS type code is 33:
_Service._Proto.Name TTL Class SRV Priority Weight Port Target
Service
The symbolic name of the desired service, as defined in Assigned
Numbers [STD 2] or locally. An underscore (_) is prepended to
the service identifier to avoid collisions with DNS labels that
occur in nature.
ホスト名やその他の世間的に使われているドメイン名では、先頭アンダースコアなんて変なことしない。だからカブらない。 SRV レコードはこの書式を使っても大丈夫なんだ！と、こう RFC に書かれているわけ。
なるほどー。*4
オチ
だいたい疑問が解決したところで、また違う MS のドキュメントを見て、アレッとなってしまった。
Strict RFC (ANSI) . Allows "A" to "Z", "a" to "z", the hyphen (-), the asterisk (*) as a first label; and the underscore (_) as the first character in a label.
Non RFC (ANSI) . Allows all characters allowed when you select Strict RFC (ANSI) , and allows the underscore (_) anywhere in a name.
Multibyte (UTF-8) . Allows all characters allowed when you select Non RFC (ANSI) , and allows UTF - 8 characters.
Any character . Allows any character, including UTF - 8 characters.
マルチバイト文字が許容されている…？
そう、実は RFC 2181 を読むと、ドメイン名のラベル部分には any binary string が使用可能、と書かれているんです。えー……今更そんな……
11. Name syntax Occasionally it is assumed that the Domain Name System serves only the purpose of mapping Internet host names to data, and mapping Internet addresses to host names. This is not correct, the DNS is a general (if somewhat limited) hierarchical database, and can store almost any kind of data, for almost any purpose. The DNS itself places only one restriction on the particular labels that can be used to identify resource records. That one restriction relates to the length of the label and the full name. （略） Those restrictions aside, any binary string whatever can be used as the label of any resource record. Similarly, any binary string can serve as the value of any record that includes a domain name as some or all of its value (SOA, NS, MX, PTR, CNAME, and any others that may be added). Implementations of the DNS protocols must not place any restrictions on the labels that can be used. In particular, DNS servers must not refuse to serve a zone because it contains labels that might not be acceptable to some DNS client programs.
ということで、ドメイン名にはどんな文字でも使えちゃう、したがって当然ドメイン名にアンダースコアがあっても問題は一切ない、ということでした。*5
ちなみにドメイン名の基本的な挙動*6については case insensitive であることが RFC 的に MUST なんだけど、そうすると（記号類もフルで使えると仮定しても） 1byte が 256 - 26 - 1 = 230 の情報量しか示さないことになって、なんだか中途半端で気持ち悪い。
でも逆に、こういうところが DNS 最高って思うんです（）
終わりに
ということで、以上まとめると、結論としては以下のようになる。
- 数字だけのドメインは RFC 的に許容されている
- アンダースコアについては、 RFC 上、ホスト名はもちろん URI でも許容されていない
- ドメイン名にはどのような文字でも使えるのでアンダースコアを含むドメイン名を作ることには一切問題がない
こうやって調べてみるのも久しぶりでなかなか面白かった。どさにっきさんっぽくなりたい。
でも記事の内容的には、 RFC を 3000番台までしか参照していなくて deprecated かもしれないし、また読み違いもあるかもしれない。 非常に不安なので、詳しいところの読み方については識者からのご指摘を待ちたいところです。
そんなとこ。
*1:ちなみに letter 一文字でも valid な official hostname になる
*2:数字オンリーの name が4桁続くと IP Address Form と同じになってしまう可能性があるじゃないか、とおっしゃる方、実際その通りなのだけど、この RFC では TLD は必ず letter が入るので問題ない、と言っており、この点は問題ないことになっている
*3:このあたりからは、 host name は DNS での lookup が前提とされていることも読み取れる。 host name と domain name との区別はかなり微妙だったようだ
*4:ただこれでも疑問は残って、 TXT レコードに転用されるようになった経緯とかそれに関する RFC とかはよーわからん
*5:バイナリラベルの書き方についてはRFC2673に定義されている。現実世界で有効活用している様子を見たことはないけれど、 C&C との通信や VPN over DNS なんかで使えそうではある。 Punycode あればいらない気がして仕方ない…
*6:case を利用した security extension もあるので、あくまで「基本的に」という表現にはなってしまう
2016年に買ってよかったもの
なんか「2016年に買ってよかったもの」みたいなエントリが大量に生産されているようなので、いまさらながら流行に乗って書いてみる。
コーヒーのハンドドリップセット
2016年で最も買ってよかったものと言うと、まちがいなくハンドドリップセットだった。コーヒーという趣味がひとつ増えた。
コーヒーは、楽しい。コンビニで買ったクッキーを食べるだけでも、ハンドドリップしたコーヒーがあると一気に「コーヒータイム」になる。知らない街で豆を買ったりコーヒーの美味しい店を探して入ったりする楽しみも増えた。
ハンドドリップってどうやって初めていいかよくわからないものだと思うのだけど、そういう人には東急ハンズの福袋をおすすめしたい。必要なものを必要な組み合わせできちんと入れてくれて、しかもリーズナブル。
正月を待てない人には、上リンクのドリッパーセットとケトルを買うのがおすすめ。豆を粉にするミルは、持っていなくても全然問題なし。
ちなみに個人的には Hario めっちゃ使いやすいと思うけど、プロへの憧れとしては Kalita 一式を欲しいなと思うとき結構ある。特に↓このケトル…最高にかっこいい…。
Chromecast
https://www.google.com/intl/ja_jp/chromecast/tv/chromecast/
一人で色々なことをするぶんにはパソコンがあればなんでもできるけれど、コンピュータに疎い人とのコミュニケーションにパソコンはまったく役に立たない。
写真を一緒に見るためにと思って Chromecast を買ったところ、実際これが大正解で、写真はもちろんのこと youtube を見るのにも使えて、結果、お互いにスマホの画面を見ているだけみたいな時間が圧倒的に減った。
本当に期待していたのは Web ページを見ることだったんだけど、こちらは iPhone ではできないのと、 Nexus5 でもちょっと解像度が低くて使えないなとなった。
まあでも、買ってよかったと思う。
AriaProII エレキギター用ギグバッグ AGC-EG
昨年からギターの持ち運びが増えて、これまで使ってきた付属ケースがボロボロに壊れてしまった。仕方ないから持ち運び用にケースを検討したら、これが「ダサい」か「高い」かの二択になっているもんで、とても困ってしまった。NAZCAとか二万くらいするし、そうでなければ5000円くらいだけど使いにくい。
そんな中でずっと探していてこれいいなとなったのがこの Aria 社のケース。実店舗で8000円程度で売っているのに、内容的にはすごくいい。外見も気に入ったので個人的には2016年でいちばんいい買い物のひとつになった。
いいところはこんな感じ：
- 運びやすい
- 背中と腰にぴったり合う形でクッションがついている
- 肩紐が適度に太くて背負いやすい。こちらもクッション付き
- ポケットが多彩
- シールドとエフェクターとチューナーとカポと…と全部入る。このバッグだけ持っていけばスタジオ練習できる
- 楽譜すら入れられる大きなポケット
- 大きさの違うポケットがそれぞれあるので物を入れやすい
- ギターへの負荷も小さい
- 周り全体に7mmくらいのクッションがある
- ネックをマジックテープで留められる
- 12フレットくらいのところに肩の根元が来る（ので背負っていてネックに過剰な負荷がかからない）
- 防水
- 雨でもまったく問題なし
割とマジな話、ソフト（セミハード）ケースの1万円未満部門とかあったら優勝間違いないし、2万円未満部門でもかなり戦えるレベルだと思う。
8インチタブレット
スマホで漫画を読むようになってから常々、5インチのスマホではなくもっと大きな画面で見たいと思っていた。で色々電気屋で試したところ、どうも私は7インチだと中身に入り込めず、9インチは最高だと感じるものの重いのだということがわかった。必要なのは、その中間の8インチだった。
で、何種類もの機種を検討した結果、さほど解像度はよいわけではないが軽くて安い ASUS の 8 インチ Android タブレットを買った。
結果、漫画を紙媒体で買わなくなった。技術書もこの端末で読むようになった。
今となってはもう自分にとっては電子書籍はあって当たり前な存在だけど、一年前はそうでもなかった。それを変えたのは圧倒的に、この8インチタブレットだった。
自転車
自転車、十年くらい乗ってなかったんだけど、久しぶりに手に入れてみたらびっくり。うちから徒歩15〜30分くらいのところにある街々にシュッと行けるようになったし、10分くらいかかっていたスーパーに夜中でも行こうという気になれる。まさに生活が変わった。
…とまあ私にとってはライフチェンジングだったわけだけど、読んでる人からすれば、買ってよかったものに自転車って言われてもねえ、ということになるんじゃないかな。そういう人はあきらめてください。所詮その程度の日記です。
なんでもいいから書こう
iPhoneをやめた。
iPhoneを使っていた、月額6000円くらいのつもりだったけど月によって9000円くらいになることもざらにあってちょっともう耐えられないぞという気持ちになったので電話用端末と通信用端末の二台持ち＋Walkman A10に移行した。月額は2000円以内になった。
で、何か月か利用してみて、色々と生活が変わった。
まず、音楽を聴かなくなった。
iPhoneの頃、通勤途中にイヤホンをして音楽を聴くことが多かったのだけど、それだとiPhoneでゲームをすることができなかったのが不満だった。しかしいざ Android + Walkman にしてみると、端末を二台取り出すのが圧倒的に億劫。Walkman はポケットに入れておくにしても、ずっと入れておくわけにもいかない。
またiPhoneの頃は夜中に仕事中しているときにもよく音楽を聴いていて、しかし聴きすぎると充電が切れてしまうのも悩みだった。Walkmanなら充電も気にならないぞ、となるかというとそうでもなく、Walkmanはケーブルが専用のやつなので一本しか持っていなく、充電とデータ転送の片方しか一度にできない。まあ正確にはデータ転送時にも充電されるけど、夜中にパソコンつけっぱにするのは無駄だし。
それと、ケーブルのこともあって、新曲を入れるのが本当に面倒。まあケーブルさえあればiPhoneとそう変わらない（あるいは少ないくらいの）労力でもって曲を入れられるのだけど、ケーブルが専用というそれだけで圧倒的に使い勝手が悪い。
そしてネットで買えない。買えないわけではないけど、買ってすぐに聴けない。これがいちばん大きい。その時その時に頭に浮かんだあの曲を買うぞと思っても買えない。そうするともう聞く気が失せてしまう。とても残念。
電話にあまり気づかなくなった。
生活に支障はない。LINE時代の今、電話はLINEで済む。メールを受け取ることもまれだし、古典的なメールしか使えない人に対してはGmailアドレスを取得している。これでもう困っていない。
充電をしょっちゅうするようになった。
いやこれは Nexus5 の電池の持ちが悪すぎるだけなのだけど、一日二回充電しないと絶対切れてしまうようになった。
iPhone時代はその3倍くらいは持ったし、かなり酷使していたという認識もある。やはりこのあたりは iPhone が圧倒的に良かった。
まあそれくらいか。ほとんどかわってないな。音楽を聴かなくなったことと、料金が安くなったことくらい。
まあまあ、悪くはない。悪くはないんだ。
