mochikoAsTechのdig日記

当方好きなコマンドはdigです!お友達から!!よろしくお願いします!!!

技術書典4に当選したのでDNS本を書くよ

技術書典4、明らかに申し込みサークル数が多そうな気配をただよわせていたので、
これは落選かなーと思っていたんだけど・・・なんと・・・当選したー!

当選したら考えよう、と先延ばしにしていたので、
まだ本のタイトルも目次もサークルカットも決まってないよ。

慌ててこの本を読んでいます。

booth.pm

オンデマンド・・・オフセット・・・・サークルカット・・・・?
本のサイズってそもそもいくつ・・・何部刷ればいいの?
ていうか何使って書いてどういう形式で出力して印刷会社さんへ渡すの・・・?

という、頭の上に「???」しかない同人誌初心者の疑問にすべて答えてくれる安心本。

親切な人に

と教えていただいたのだけど、GitHubリポジトリあるね、うん、リポジトリあるし見られるけど原稿はこの中のどこですか・・・どういう形式で書いてあるのか全然分からぬ・・・となったのでそっ閉じして、大人しく電子書籍を買いました。

買ってよかったよー。
技術書典4で初めて技術同人誌作る人は、みんなこれ読むとよいと思います。

あとサークルカットとか表紙とか挿絵とかどうしたらいいの、どう頼んだらいいかも分からないし死ぬ、と思ってたんだけど、幸い一緒に面白がってやってくれるデザイナーさんが現れました。なにこれ奇跡。

という訳で、スケジュール引いて、タスクごとの〆切を決めてがんばります!

IT系でエンジニアやってるけど、DNSとかのインフラ周りは実はあんまり分かってなくて、それがちょっとコンプレックス・・・そんなエンジニア向けにドメインDNSを分かりやすく教える一冊を作る(予定)です!

サークル名は「好きなコマンドはdigです」です。

あ!あと誰か、これ教えてください。

 いつなのー!

技術書典4に申し込んでみたー

2018年4月22日 (日) に秋葉原UDX アキバ・スクエアで開催される「技術書典4」にサークル参加で申し込んでみたー。 

techbookfest.org

過去にやってた技術書典3とか、行きたいなーと思いつつ行けなかったので、えいやーで「本を作る側」として申し込んでみた。
作ったことないのに!本って何使って書くの?製本とかどうやんの?!

申し込みフォームすら「サークル名?サークル名ってなに?みんなどんなのにしてるの?」状態だったよ。結局サークル名は「好きなコマンドはdigです」にしました。

本の内容は大好きなドメインとかDNSとかのことにしようと思っている。

サイトリニューアル時、DNSの変更をしたのにいわゆる「浸透に時間がかかって」なかなかリニューアル後のサイトに切り替わらない、みたいな事例を題材にして、あのなRRにはTTLがあってな・・・とか、あるいはDNS設定されたかなーって確認してしまったがためにネガティブキャッシュで死ぬ話とか、そういう「悩み」と「解決策&解説」のセットがいっぱいある本が書きたいなー。

2月4日 (日) が当落通知日だそうで、当選しないとそもそも参加できないんだね。なるほど。当選したらサークル参加費の7,000円を入金して、それでようやく参加確定になる模様。わー、当選するといいなー。

取り合えず「本の作り方」を学ぶべく、どっちか読もうと思うんだが、どっち買うか迷ってる。こっちの方がお勧め、みたいなのあればどなたか教えて>< 

booth.pm

booth.pm

ステージング環境のテストユーザで「test@test.co.jp」みたいなメアド使っていませんか?

たとえばあなたが宅配ピザのサイトリニューアルを担当していて、ステージングサイトで「ログインして注文する」というテストをするため、テスト用のユーザを作ったとします。

名前は適当に田中一郎にして、誕生日も適当に2010年10月10日、メアドも適当に「tanaka@test.co.jp」にしとこう!

ちょっと待ったー!

名前と誕生日はいいとして、そのメアドは待ったー!

昨日のエントリでも書いたけど、自分が買っていない=持っていないドメインを勝手に使うのは、トラブルの元なのでやめましょう。

こういう場合に使うべきなのは、

のどちらかです。

あまり知られていませんが、実はインターネットでは「例示やテストで使っていいドメイン」というものがあります。

こういうケースではRFC2606で定められている「example.com」や「example.net」、もしくはJPRSが定めている「example.jp」「example.co.jp」などを使いましょう。

ところで先ほど「自分が買っていない=持っていないドメインを勝手に使うのはトラブルの元」と書きましたが、具体的にどんなトラブルが起きるのでしょう?

たとえば「test.com」というドメインは(恐らく)DOSarrestというサービスをやっている Internet Security LTD,という会社が所有者ですし、「test.co.jp」というドメイン有限会社教育評価研究所という会社が所有者です。(Whoisを見れば分かる)

そのため最初に書いた宅配ピザのステージングサイトで、仮に「tanaka@test.co.jp」というメアドの登録したユーザでテストを行うと、実際に有限会社教育評価研究所という会社に会員登録完了メールや注文完了メールが飛んでいってしまい、相手方にご迷惑であると共に、情報漏洩の恐れもあります。

誰かがアンケートに適当な住所を書いたせいで、全然関係ない自分の家にダイレクトメールが届いたら迷惑ですよね。実在する他人の住所を勝手に書かないのと同じように、他人のドメインも勝手に使わないようにしましょう。

じゃあ「誰のものでないドメイン」ならいいのでは?と思うかも知れませんが、現時点で誰のものでもなくても、明日には誰かが取得するかも知れないので、これもやはりお勧めしません。

Chromeで.devのドメインがHTTPだと見られない件の解説

glatchdesign.com

本件、あちこちで悲鳴が上がってたけど、色々調べたら面白かったので解説。

元々はgTLDは.comとか.netとかの22種類しかなかったので、各社が組織内のネットワーク(開発環境とか)でオレオレTLDとして勝手に.devを使ってた。

でもgTLDがわんさか増えて、とうとう.devというTLDもできてしまい、色んなところで「やばい名前衝突(Name Collision)するわ・・・」という話題が出たのが2014年ごろ。

ちなみにICANNWikiによると、この.devは元々AmazonGoogleで「俺がレジストリになる!」と奪い合ってたけど、youとtalkAmazonに譲って、代わりにdevをGoogleがゲット、みたいな経緯があった模様。

レジストリってのはあれな、そのTLDの唯一の卸元というか、生産元みたいなもの。だからあちこちで「Googleが.devを買った」って言ってるのは、この「Googleが.devのレジストリになったこと」を指してるんだと思う。

んで今回Googleが「Chromeで.devを開くと強制的にHTTPSにリダイレクトされる」という暴挙に出たのは「Googleは2014年にdevのレジストリ(生産元)になった。でもまだ.devのドメインは一般発売していない。ってことは今.dev使ってるやつは、全部買わずに勝手に使ってるやつなので何してもいいよね。強制リダイレクトさせるわ」っていう考えなのかなと推測してる。

.devだけじゃなくて.appもみたいだし、このドメインがもうHTTPSでしか使えないってことは、Googleは.devを普通に売るんじゃなくて、何か特別な用途で使わせるつもりなのかなー?

で「.devが使えなくなったからとりあえず.testにした!解決!」みたいなのも見るんだけど、なんで.testにしたらいいのか?.testでいいなら.dev2とかでもいいのか?という疑問は浮かばないでしょうか?浮かびますよね?きっと。

ざっくり言うと、.testはいいけど.dev2はだめです。

社内ネットワークにしろ、テスト用のメアドにしろ、「例示として使っていいドメイン」や「テストとして使っていいドメイン」はRFCで定められているので、基本的にはそれを使いましょう。

自分が買ってない=持ってないドメインを勝手に使うのは、今回みたいなトラブルの元なので控えた方がいいよ、という話でした。

blog.jxck.io

sudoとsuで聞かれるパスワードは違う

sudoは「他のユーザとしてコマンドを実行する」ためのコマンド、 suは「他のユーザになる」ためのコマンド。

sudoのとき聞かれるのは、「自分(今のユーザ)のパスワード」で、 suのとき聞かれるのは、「なろうとしている他のユーザ」のパスワード。

たとえば、mochikoユーザでログインして、 sudo cat /root/.ssh/authorized_keys を叩こうとしたら、mochikoユーザのパスワードを聞かれるし、 su - でrootになろうとしたら、rootのパスワードを聞かれる。

今となっては当たり前なんだけど、分かるまでは結構混乱するよね。

ネガティブキャッシュのキャッシュ残り時間が知りたい

DNSキャッシュサーバにネガティブキャッシュ(status:NXDOMAINなどのときの「そんなリソースレコードは存在しない」という情報のキャッシュのこと)が残ってしまって、あとどれだけ待ったらネガティブキャッシュが消えるのか知りたい。

そんなときは、digでキャッシュの残り時間を確認できる。

  1. 存在しないhogehoge.yahoo.com を引いてみる SOAレコードで設定されている値から、ネガティブキャッシュのTTLが600秒であることが分かる。
    $ dig hogehoge.yahoo.com
    
    ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.7 <<>> hogehoge.yahoo.com
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 21575
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
    
    ;; QUESTION SECTION:
    ;hogehoge.yahoo.com.            IN      A
    
    ;; AUTHORITY SECTION:
    yahoo.com.              600     IN      SOA     ns1.yahoo.com. hostmaster.yahoo-inc.com. 2016052509 3600 300 1814400 600
    
    ;; Query time: 164 msec
    ;; SERVER: 127.0.0.1#53(127.0.0.1)
    ;; WHEN: Thu May 26 00:02:54 2016
    ;; MSG SIZE  rcvd: 97
  2. 再度、hogehoge.yahoo.com を引いてみる ネガティブキャッシュの残り時間が380秒であることが分かる
    $ dig hogehoge.yahoo.com
    
    ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.7 <<>> hogehoge.yahoo.com
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 36019
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
    
    ;; QUESTION SECTION:
    ;hogehoge.yahoo.com.            IN      A
    
    ;; AUTHORITY SECTION:
    yahoo.com.              380     IN      SOA     ns1.yahoo.com. hostmaster.yahoo-inc.com. 2016052509 3600 300 1814400 600
    
    ;; Query time: 11 msec
    ;; SERVER: 127.0.0.1#53(127.0.0.1)
    ;; WHEN: Thu May 26 00:06:34 2016
    ;; MSG SIZE  rcvd: 97
  3. 380秒も待てない!ネガティブキャッシュ消したい!というときはrndc flushでDNSキャッシュサーバのキャッシュを消す
    # rndc flush
  4. 再度、hogehoge.yahoo.com を引いてみる ネガティブキャッシュが消えて、問い合わせに行き、そして再びネガティブキャッシュのTTLが600秒になっている。
    # dig hogehoge.yahoo.com
    
    ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.7 <<>> hogehoge.yahoo.com
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 30397
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
    
    ;; QUESTION SECTION:
    ;hogehoge.yahoo.com.            IN      A
    
    ;; AUTHORITY SECTION:
    yahoo.com.              600     IN      SOA     ns1.yahoo.com. hostmaster.yahoo-inc.com. 2016052509 3600 300 1814400 600
    
    ;; Query time: 418 msec
    ;; SERVER: 127.0.0.1#53(127.0.0.1)
    ;; WHEN: Thu May 26 00:09:29 2016
    ;; MSG SIZE  rcvd: 97
    これでやきもき待たなくて済むー。

MXレコードやTXTレコードでは*(アスタリスク)は使えない?

hoge.infra.xyzでもfuga.infra.xyzでもメールを受信できるように、BINDのinfra.xyz.zoneでこんな設定を書いてみた。

mx1     IN      A       153.126.198.20
*       IN      MX 10   mx1.infra.xyz.
*       IN      TXT     "v=spf1 a:mx1.infra.xyz -all"

named-checkzoneでエラーはでない、よしよし、とnamedをrestartして、digで

dig hoge.infra.xyz mx
dig hoge.infra.xyz txt

を叩いてみたら、なんと何も出ない。 statusはNOERRORなのに、ANSWERは0・・・MXとかTXTだと*(アスタリスク)でワイルドカードの指定はできないのかな?と思ったら、ワイルドカードは「個別の設定があればそちらが優先、なければワイルドカードが適用される」ということらしく、そもそも個別の設定が1つもないとワイルドカードも適用されない模様。

つまり、以下のようにワイルドカードしかない状態だと、hoge.infra.xyzのAを引いても、MXを引いても、TXTを引いても、ANSWERは0なんだけど、

*       IN      A       153.126.198.20
*       IN      MX 10   mx1.infra.xyz.
*       IN      TXT     "v=spf1 a:mx1.infra.xyz -all"

以下のように、hoge.infra.xyzという個別の設定をした上で、ワイルドカードの設定をした状態で、fuga.infra.xyzを引くと、AもMXもTXTもちゃんと値が返ってきた。

hoge    IN      A       153.126.198.20
*       IN      A       153.126.198.20
hoge    IN      MX 10   mx1.infra.xyz.
*       IN      MX 10   mx1.infra.xyz.
hoge    IN      TXT     "v=spf1 a:mx1.infra.xyz -all"
*       IN      TXT     "v=spf1 a:mx1.infra.xyz -all"

というわけで、AレコードやMXレコードやTXTレコードでは*(アスタリスク)は使える。 但し、同じ種類のレコードにおいて個別の設定が1つもないと、ワイルドカードも適用されない模様。

という一旦の理解。BINDのDOCUMENTATIONとかちゃんと読めば、説明見つかるかな。