kakakakakku blog

Weekly Tech Blog : Keep on Learning 👍

includeIf を使って git config をプロジェクトごとに読み替える

GitHub と AWS CodeCommit を併用したり,プロジェクトごとに別アカウントを使ったり,リポジトリごとに git config を変える場面もある.今までは個人用 GitHub を global 設定とし,別アカウントはリポジトリごとに git config --local コマンドで設定をしていたけど,最近リポジトリが増えて,設定を忘れる場面もあり,direnv のように自動設定をする方法を探していた.

includeIf

Git Documentation を読むと,「Includes (include)」と「Conditional includes (includeIf)」の説明があり,なんと includeIf を使うと,設定ファイルを条件付きで読み込めるため,さっそく検証することにした.

git-scm.com

検証環境

以下のように,ホームディレクトリ直下に github ディレクトリと codecommit ディレクトリを作成した.さらにサンプルリポジトリ g1 / g2 / c1/ c2 を作って git init をしておく.

~/github
    ├── g1
    └── g2
~/codecommit
    ├── c1
    └── c2

~/.gitconfig

今まで通り,ホームディレクトリに ~/.gitconfig を置き,GitHub 用に global 設定をしている.今回は user と email を抜粋した.さらに includeIf と gitdir を組み合わせて,~/codecommit/ 直下にあるリポジトリの場合に ~/.gitconfig_codecommit を読み込む設定を追加した.Git Documentation を読むと,gitdir 以外に onbranch なども使える.

[user]
  name = kakakakakku
  email = y.yoshida22@gmail.com

[includeIf "gitdir:~/codecommit/"]
  path = ~/.gitconfig_codecommit

~/.gitconfig_codecommit

そして,条件付きで読み込む設定を ~/.gitconfig_codecommit に置く.今回は仮で bob と bob@example.com にした.

[user]
  name = bob
  email = bob@example.com

検証結果

global 設定を反映する github/g1 と github/g2 は今まで通りだった.

$ cd ~/github/g1
$ git config user.name
kakakakakku
$ git config user.email
y.yoshida22@gmail.com

$ cd ~/github/g2
$ git config user.name
kakakakakku
$ git config user.email
y.yoshida22@gmail.com

そして codecommit/c1 と codecommit/c2 は,期待通りに bob になり,条件付きで読み込めていることを確認できた.便利だ!

$ cd ~/codecommit/c1
$ git config user.name
bob
$ git config user.email
bob@example.com

$ cd ~/codecommit/c2
$ git config user.name
bob
$ git config user.email
bob@example.com

まとめ

プロジェクトごとに git config を読み替える場合は includeIf を使うと便利!特に git clone した直後にすぐ使えるのは体験として大きく改善した.小規模なら git config --local コマンドも引き続き併用していく.

「Redash v8.0.0」で気になった新機能と機能改善

2019年10月末に Redash の最新バージョン「Redash v8.0.0」がリリースされた.Change Log を読むと機能改善が多くあり,今回は「個人的に気になった Redash v8 新機能と機能改善」を「計10点」紹介しようと思う.Change Log は以下の CHANGELOG.md で確認できる.

目次

  1. ドロップダウンで複数値を選択できるようになった
  2. クエリ名を日本語で正しく検索できるようになった
  3. ダッシュボードがグリッド表示になった
  4. データソース追加/削除
  5. データソース設定画面の UI 改善
  6. クエリ画面にデータソースのアイコンが表示されるようになった
  7. カスタムアラート機能
  8. Query API Key を作り直せるようになった
  9. アラート送信先から Hipchat が削除された
  10. 匿名利用データ共有

1. ドロップダウンで複数値を選択できるようになった

今までも {{}} を使って「パラメータ付きクエリ」を作り,さらに「ドロップダウン」と組み合わせて「候補を選択する」ことはできたけど,あくまで「1個」しか選択できなかった.例えば,以下のクエリだと {{CountryCode}} として JPN などを選択できるようになる.

SELECT *
FROM city
WHERE CountryCode = '{{CountryCode}}'
ORDER BY Population DESC;

なんと Redash v8 では「ドロップダウンから複数値を選択できる」ようになった.例えば,以下のように IN で複数値を検索する「パラメータ付きクエリ」を作れるようになる.

SELECT *
FROM city
WHERE CountryCode IN ({{CountryCode}})
ORDER BY Population DESC;

ドロップダウンを設定するときに,以下のように「Allow multiple values」という項目があり,3種類ある Quotation から選択できる.今回は IN に合わせるため Single Quotation Mark にした.

  • None (default)
    • value1,value2,value3
  • Single Quotation Mark
    • 'value1','value2','value3'
  • Double Quotation Mark
    • "value1","value2","value3"

f:id:kakku22:20191104002553p:plain

実際にクエリ画面を見ると JPN と AUS など,複数値を選択し,クエリを実行できる.これは便利!間違いなく「パラメータ付きクエリ」の用途の幅が広がると思う.

f:id:kakku22:20191104002610p:plain

2. クエリ名を日本語で正しく検索できるようになった

今までは,メニューバーにある検索フォーム(Search queries...)でクエリ名を検索しても,マルチバイト文字に対応してなく,日本語の場合は期待した結果にならず,困っていたと思う.Redash v8 でマルチバイト文字に対応し,クエリ名を日本語で正しく検索できるようになった.ただし,デフォルトでは無効化されていて,Settings 画面で Enable multi-byte を有効化する必要がある.

f:id:kakku22:20191104002632p:plain

3. ダッシュボードがグリッド表示になった

ダッシュボードがグリッド表示になり,罫線を見ながらウィジェットを配置できるようになった.地味な改善ではあるけど,神は細部に宿る!

f:id:kakku22:20191104002650p:plain

4. データソース追加/削除

Redash はバージョンアップごとにデータソースを増やしている.Redash v8 では「計7種類」が追加されて,一部は削除となり「計49種類」になった.データソースの選択肢の多さは Redash を使うメリットになる.

  • 追加
    • Azure Data Explorer (Kusto)
    • Cassandra
    • Couchbase
    • Dgraph
    • JSON
    • Phoenix
    • ScyllaDB
  • 名称変更
    • GoogleSpreadsheet → Google Sheets
  • 削除
    • MemSQL
    • Url

5. データソース設定画面の UI 改善

データソース設定画面で「インクリメンタルサーチ」が使えるようになった.今までは全てのデータソースが並んでいた.バージョンアップごとにデータソースが増えているため,今後さらに増えることを考えると,価値のある改善だと思う.

f:id:kakku22:20191104002806p:plain

6. クエリ画面にデータソースのアイコンが表示されるようになった

クエリ画面で,データソースの左にアイコンが表示されるようになった.地味に良いと思う!

f:id:kakku22:20191104002821p:plain

7. カスタムアラート機能

Redash v8 を起動するときに,環境変数 REDASH_FEATURE_EXTENDED_ALERT_OPTIONS に true を設定し,Feature Toggle を有効化すると「カスタムアラート機能」が使えるようになる.今までも「アラート機能」はあったけど,例えば Slack にアラートを通知しても「アラート名」以外に情報がなく,迅速な状況判断には使えなかった.

そこで「カスタムアラート機能」を使うと,以下のように自由にテンプレートを定義することができ,カスタマイズしたアラートを通知できるようになる.ちなみに Description template は Mustache フォーマットを使う.さらに「プレビュー機能」もあり,これは便利すぎる新機能!今回はサンプルとして「閾値」と「実測値」をテンプレートに埋め込んでみた.

f:id:kakku22:20191104002838p:plain

実際に Slack に通知をすると,以下のように Description が追加されていた.定義するテンプレート次第では,今までよりも格段に情報量が上がるため,障害時の迅速な状況判断に活用できそう.

f:id:kakku22:20191104002852p:plain

8. Query API Key を作り直せるようになった

Redash v8 から Query API Key を作り直せるようになった.実際に API Key のダイアログを確認すると Regenerate ボタンがあった.

f:id:kakku22:20191104015451p:plain

9. アラート送信先から Hipchat が削除された

2018年の Hipchat 廃止に伴って,アラート送信先から今まであった Hipchat が削除された.

f:id:kakku22:20191104002904p:plain

10. 匿名利用データ共有

Redash v8 から「Anonymous Usage Data Sharing(匿名利用データ共有)」の仕組みが追加されていて,オプトインをすると,クエリ数など一部の利用データが Redash 運営側に送信される.今回 Redash トップページ下部にオプトインをするメニューが追加されていた.

f:id:kakku22:20191104002922p:plain

オプトインは Settings 画面から変更できるようになっている.

f:id:kakku22:20191104002932p:plain

まとめ

  • 2019å¹´10月末にリリースされた「Redash v8.0.0」を試した 🎉
  • 個人的に気になった新機能と機能改善を「計10点」紹介した
  • 特に以下は目玉機能だと思う 👀
    • ドロップダウンで複数値を選択できるようになった
    • クエリ名を日本語で正しく検索できるようになった
    • カスタムアラート機能

Redash v7 紹介記事

kakakakakku.hatenablog.com

変更可能なコードを書こう /「レガシーコードからの脱却」を読んだ

9月に発売された「レガシーコードからの脱却」を読んだ.本書はサブタイトルに「ソフトウェアの寿命を延ばし価値を高める9つのプラクティス」と書いてある通り,変更可能なコードを書くための「原則とプラクティス」に対する理解を深めることを目的にして書かれている.よって,意図的に抽象度は高くなっていると思う.実際に読んで,そう感じた.

原著の著者 David Scott Bernstein は IBM などでソフトウェアエンジニアのトレーニングを担当されてきた方で,そのエピソードも本書に多く出てくる.そして「認定スクラムデベロッパー研修」の講師で来日されることもあるらしく,気になる!来年研修を受講する予定なので,開催予定を調べてみようと思う.

レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス

レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス

  • 作者: David Scott Bernstein,吉羽龍太郎,永瀬美穂,原田騎郎,有野雅士
  • 出版社/メーカー: オライリージャパン
  • 発売日: 2019/09/19
  • メディア: 単行本(ソフトカバー)
  • この商品を含むブログを見る

目次

  • 第I部 : レガシーコード危機
    • 1ç«  : 何かが間違っている
    • 2ç«  : CHAOSレポート再考
    • 3ç«  : 賢人による新しいアイデア
  • 第II部 : ソフトウェアの寿命を延ばし価値を高める9つのプラクティス
    • 4ç«  : 9つのプラクティス
    • 5ç«  : プラクティス 1 : やり方より先に目的、理由、誰のためかを伝える
    • 6ç«  : プラクティス 2 : 小さなバッチで作る
    • 7ç«  : プラクティス 3 : 継続的に統合する
    • 8ç«  : プラクティス 4 : 協力しあう
    • 9ç«  : プラクティス 5 : 「CLEAN」コードを作る
    • 10ç«  : プラクティス 6 : まずテストを書く
    • 11ç«  : プラクティス 7 : テストでふるまいを明示する
    • 12ç«  : プラクティス 8 : 設計は最後に行う
    • 13ç«  : プラクティス 9 : レガシーコードをリファクタリングする
    • 14ç«  : レガシーコードからの学び

既に正誤表も公開されている.読んでいて気付いた誤植はほとんど載っていた.あと1箇所気付いたので,記事の最後にメモ程度に残しておく.

www.oreilly.co.jp

9つのプラクティス

本書の軸は,当然ながら「9つのプラクティス」だけど,Extreme Programming (XP) を中心に以下のように構成されている.

  • プラクティス 1 : やり方より先に目的、理由、誰のためかを伝える
  • プラクティス 2 : 小さなバッチで作る
  • プラクティス 3 : 継続的に統合する
  • プラクティス 4 : 協力しあう
  • プラクティス 5 : 「CLEAN」コードを作る
  • プラクティス 6 : まずテストを書く
  • プラクティス 7 : テストでふるまいを明示する
  • プラクティス 8 : 設計は最後に行う
  • プラクティス 9 : レガシーコードをリファクタリングする

そして本書に載っている読者層は以下の5種類で,僕自身は当てはまる.ただし,過去の開発経験と今まで読んだ関連書籍の知識もあり,本書の内容で既知に感じる箇所も多かったので,新しく得られた知識は少なかったように思う.ただし,改めて理解を整理できたという側面でメリットを感じた.

  • ソフトウェア開発者
  • ソフトウェア開発と IT のマネージャー
  • ソフトウェアの利害関係者
  • さまざまな業界のプロダクトマネージャー,プロジェクトマネージャー
  • この欠くことのできない技術に興味を持つ人すべて

今回の書評記事では,個人的に本書を読んで印象に残った「プラクティス」を紹介しようと思う.

完了の完了の完了

「プラクティス 3 : 継続的に統合する」では,コードを書くたびに統合することの大切さを学べる.例えば「継続的インテグレーション」や「継続的デリバリー」など,よく知られたプラクティスの軸になる考え方となる.この「統合された状態」を表現する言葉として「完了の完了の完了」と書かれていて,センスの良さに驚いた.確かに「ローカル環境でビルドができた状態」で「完了」と表現する人も過去にいたし,今後も積極的に「完了の完了の完了」という表現を使おうと思う.

ブランチを避ける

「プラクティス 3 : 継続的に統合する」に載っている「リスクを減らす7つの戦略」の中に「ブランチを避ける」という内容もある.統合されるまでリスクに気付けないので,ブランチを使わずにフィーチャーフラグを使うと書いてあり,まさに先週あたりから議論が巻き起こっていた話題に関連している.

irof.hateblo.jp

スパイク

「プラクティス 4 : 協力しあう」では,質の高いコミュニケーションを作り上げるために協力し合う(協働する)ことの大切さを学べる.ペアプログラミングをしたり,モブプログラミング(モブワーク)をしたり,個人的にも強く意識して実践と推進をしているスタイルなので,共感できる点ばかりだった.

そして「スパイク」という用語は今まで使ったことがなく,新鮮だった.簡単に表現すると「未知の課題に対して技術的な調査などを行うこと」と表現できる.実は書籍「アジャイルコーチング」にも「スパイク」が出てくるので,界隈ではよく知られた用語なのかもしれない.

アジャイルコーチング

アジャイルコーチング

カンファレンスをすっ飛ばす

さらに「プラクティス 4 : 協力しあう」の中に「知識を広げる」というテーマもあり,そこに「カンファレンスに行ったら,カンファレンスをすっ飛ばし,友達を探してペアリングするべし」という面白いテクニックが紹介されている.確かに「カンファレンスに行ったら廊下で話すべし」という話もあるし,著者の素晴らしい体験談から学べるのも本書の魅力かなと思う.今年はほとんどカンファレンスに行ってなく,久し振りに行ってペアリングしたいぞ!

誤植

10.6「テスト可能なコードを書く」の最後に以下の文章があり,文脈的には「トレーニング "で" 教えたり」だと思う.

ブログを書いたりトレーニングを教えたりするには、十分な休憩と大量のカフェインが必要だ。

まとめ

タイトルに惹かれて「レガシーコードからの脱却」を読んだ.最初からレガシーコードを作り出さないように「どんなマインドセットを持っておくべきなのか」という原則とプラクティスを学ぶことができる.黙々と読むよりも,チームで輪読をして,ディスカッションを組み合わせるとより効果が高そうな書籍だと思う.個人的には今まで読んだ関連書籍の知識もあり,書評にまとめたプラクティスに偏りはあるけど,それでも理解を整理できたという側面でメリットを感じた.

レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス

レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス

  • 作者: David Scott Bernstein,吉羽龍太郎,永瀬美穂,原田騎郎,有野雅士
  • 出版社/メーカー: オライリージャパン
  • 発売日: 2019/09/19
  • メディア: 単行本(ソフトカバー)
  • この商品を含むブログを見る

VS Code で Jupyter Notebook を便利に編集できる新機能を試した

今月 Visual Studio Code (VS Code) で Python Extension 機能のリリースがあり,例えば VS Code から直接 .py を実行できるようになった.個人的に注目したのは「Jupyter Notebook サポート」で,日頃から Python のサンプルコードを書いたり,トレーニングでデモをしたり,Jupyter Notebook を使う場面が多く,さっそく試してみた.

devblogs.microsoft.com

devblogs.microsoft.com

前提

VS Code に以下の拡張機能をインストールしておく.IntelliCode(IntelliSense を AI を使って拡張する)は必須ではないけど,インストールしておくと良いと思う.

公式ドキュメントは以下にある.

code.visualstudio.com

Notebook を作成する

VS Code でコマンドパレットから「Python: Create Blank New Jupyter Notebook」を選択すると,簡単に新規 Notebook を作成できる.

f:id:kakku22:20191026164457p:plain

すると,ipynb 形式で Notebook の雛形が開き,すぐに編集できるようになっている.「実行ボタン」も「セル追加ボタン」もある.

f:id:kakku22:20191026164541p:plain

既にある .ipynb ファイルを VS Code で開くと自動的に Jupyter Notebook の編集画面になるし,よく使う Shift + Enter ショートカットもサポートされているし,直感的に(Jupyter Notebook と比較して違和感なく)使えると感じた.

便利機能 : コード補完

IntelliSense と IntelliCode を組み合わせてコード補完を使える点は素晴らしく良かった.サンプルコードを書きながら試したけど,助かる!

f:id:kakku22:20191026165711p:plain

今までも Jupyter Notebook Extensions を使って Hinterland を有効化するとコード補完は使えたけど,個人的には微妙だった.少なくとも,もう Jupyter Notebook エディタには戻れなさそう.

github.com

便利機能 : Variables(変数ビュー)

メニューから選べる「Variables」を使うと,実行中の変数一覧を確認できる.Jupyter Notebook だと,速度優先で print デバッグをしたり,同じく Jupyter Notebook Extensions を使って Variable Inspector を有効化し,変数一覧を確認していたけど,VS Code に標準搭載されているのは便利だ!

f:id:kakku22:20191026170350p:plain

便利機能 : Data Viewer

さらに 「Variables」で Python の list 型や dict 型を確認する場合,値の右側にポップアップアイコンがあり,選択すると Data Viewer 画面に遷移する.大量データを処理するときなど,整形して確認できると助かるし,さらに Key と Value で自由にフィルターする機能もある.

f:id:kakku22:20191026171158p:plain

もし以下のエラーが出る場合は,事前に pip で pandas をインストールしておく.

Python package 'pandas' is required for viewing data.

Debugging

VS Code で Jupyter Notebook をデバッグする場合,現在だとメニューの1番右にある「Convert and save to a python script」を使って,1度 Python スクリプトに変換してから,VS Code の機能でデバッグする必要がある.少し面倒に感じたけど,ブログを読むと「セルデバッグ機能を開発中」とあり,これは期待だ!

We are working on bringing cell debugging into the Jupyter editor in a future release so stay tuned!

まとめ

VS Code で Python Extension 機能のリリースがあった.「Jupyter Notebook サポート」は本当に便利で,今後 Jupyter Notebook を使うときには積極的に VS Code を使うぞー!

インターネットを支える DNS の理解を深めよう /「DNS がよくわかる教科書」を読んだ

2019年10月から2019年12月までの3ヶ月間を「弱点克服期間」と位置付けていて,自分自身「理解が浅いな」と感じる技術領域のインプット/アウトプットを意識的に増やしていく.最近 React 関連のブログを書いているのも,フロントエンド技術に対する弱点克服の第一歩と言える.

今回のテーマは「DNS」にした.DNS の概要は理解できているはずだけど,いざ語ろうとすると,深くは語れないことに気付く.そんな状況を打破するべく「DNS がよくわかる教科書」を読んだ.本書の素晴らしい点は多くあるけど,まず丁寧な図表が多く,初学者でも理解できるように工夫されている.そして,何と言っても「説明の歩幅がとにかく小さく書かれている」ことに驚いた.本書を読み進めながら「徐々にわからなくなっていく...」と感じることがなかった.DNS を基礎から学びたい全ての人にオススメ!

DNSがよくわかる教科書

DNSがよくわかる教科書

  • 作者: 株式会社日本レジストリサービス(JPRS)渡邉結衣、佐藤新太、藤原和典,森下泰宏
  • 出版社/メーカー: SBクリエイティブ
  • 発売日: 2018/11/22
  • メディア: 単行本
  • この商品を含むブログ (1件) を見る

目次

本書は3部構成になっている.無理に飛ばさず,最初から順番に読むと良いと思う.僕自身は「基礎編」に知らなかったこともあり,本当に学びが多く,本書の読者層に限りなく近そうだなと感じた.さらに補足のために多く用意されている「コラム」もとても良かった.今回の書評記事では,学んだことを全てまとめるのではなく,一部を抜粋して紹介しようと思う.

  • 基礎編
    • Chapter.1 : DNS が作られた背景
    • Chapter.2 : ドメイン名の登録管理の仕組みと管理体制
    • Chapter.3 : DNS の名前解決
    • Chapter.4 : DNS の構成要素と具体的な動作
  • 実践編
    • Chapter.5 : 自分のドメイン名を設計する
    • Chapter.6 : 自分のドメイン名を管理する ~ 権威サーバーの設定
    • Chapter.7 : 名前解決サービスを提供する ~ フルリゾルバーの設定
    • Chapter.8 : DNS の動作確認
    • Chapter.9 : DNS に対するサイバー攻撃とその対策
    • Chapter.10 : よりよい DNS 運用のために
  • アドバンス編
    • Chapter.11 : DNS の設定・運用に関するノウハウ
    • Chapter.12 : 権威サーバーの移行(DNS の引っ越し)
    • Chapter.13 : DNSSEC の仕組み
    • Chapter.14 : DNS におけるプライバシーの概要と実装状況

正誤表は以下にある.本書は「第1刷 → 第2刷 → 第3刷」と積極的に修正していることもあり,書店で買うときには確認しておくと良さそう.

www.sbcr.jp

gTLD

Chapter.2-01「レジストリとは」を読むと,後半に TLD (Top Level Domain) の解説がある.現在 gTLD (Generic TLD) は「1300種類」を超えていて,2012年からは Community TLD / Geographic TLD / Brand TLD という新しい分類の gTLD もある.ICANN から委任された gTLD を以下のウェブページで確認すると,NETFLIX や TOKYO や BLOG など,良さそうな gTLD も多くあった!

newgtlds.icann.org

スタブリゾルバー / フルリゾルバー / 権威サーバー

Chapter.4-01「3種類の構成要素とその役割」では,DNS の構成要素の役割の違いがまとまっている.全体像を理解するのに最適だと思う.

  • スタブリゾルバー(情報が欲しい人)
  • フルリゾルバー(情報が欲しい人からの依頼を受けて名前解決をする人)
  • 権威サーバー(情報を提供する人)

そして,本書では「名前解決要求(私の代わりに名前解決をして IP アドレスを教えて下さい)」と「問い合わせ(IP アドレスを教えて下さい)」という表現を明確に使い分けている.「名前解決要求」は「スタブリゾルバーからフルリゾルバーへの問い合わせ」のことで,「問い合わせ」は「フルリゾルバーから権威サーバーへの問い合わせ」のことを意味している.本書は全体的に「初学者のための言葉選び」が秀逸だなと思う.

ゾーン転送

Chapter.6-02「権威サーバーの可用性」では,ゾーン転送の仕組みが紹介されている.ゾーン転送をするときに「AXFR (Authoritative Transfer)」と「IXFR (Incremental Transfer)」の計2種類の方法があったり,「SOA リソースレコード」を問い合わせて「SERIAL 値」を比較したり,基本的な仕組みを改めて整理できた.正直 BIND を運用した経験がなく,1度 BIND を構築すると良さそう(オープンリゾルバーにならないように注意しつつ).

$ dig +nssearch google.com
SOA ns1.google.com. dns-admin.google.com. 276028539 900 900 1800 60 from server 216.239.34.10 in 48 ms.
SOA ns1.google.com. dns-admin.google.com. 276028539 900 900 1800 60 from server 216.239.36.10 in 51 ms.
SOA ns1.google.com. dns-admin.google.com. 276240212 900 900 1800 60 from server 216.239.32.10 in 77 ms.
SOA ns1.google.com. dns-admin.google.com. 276028539 900 900 1800 60 from server 216.239.38.10 in 145 ms.

dig コマンド詳解

Chapter.8-02「コマンドラインツール」では,よく使う dig コマンド以外にも drill コマンドや kdig コマンドなど,知らないコマンドも紹介されていた.特に dig コマンドのオプション解説と出力されるセクションの解説は素晴らしく,今まで感じていた "もやもや" をスッキリと解消できた.今まで ANSWER SECTION 以外は気にしていなかったけど,今なら dig コマンドの出力が "チョット" 読める!

  • HEADER SECTION
  • QUESTION SECTION
  • ANSWER SECTION
  • AUTHORITY SECTION
  • ADDITIONAL SECTION

HEADER SECTION では status と flags に注目する.status は以下の4種類となる.

  • NOERROR ... 通常応答
  • SERVFAIL ... サーバー側の異常で名前解決に失敗した
  • NXDOMAIN ... その名前とその下の階層にはいずれのリソースレコードも存在しない
  • REFUSED ... アクセス制限や管理ポリシーなどによりリクエストを拒否した

そして flags には「応答にどのフラグビットがセットされているか」を意味している.今まで意識してなく,学べて良かったと思う.

  • qr ... Query Response(応答である)
  • rd ... Recursion Desired(名前解決要求をした)
  • ra ... Recursion Available(名前解決が可能である)
  • aa ... Authoritative Answer(権威を持つ応答である)
$ dig google.com A

; <<>> DiG 9.10.6 <<>> google.com A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17477
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

フルリゾルバーになろう!

そして,Chapter.8-04「dig コマンドの応用」では,実際にフルリゾルバーになり,名前解決を試みる.具体的には dig コマンドのオプションとして +recurse と +norecurse の違いを理解する必要がある.+recurse は再帰的な問い合わせを要求し,+norecurse は非再帰的な問い合わせを要求するため,スタブリゾルバーからフルリゾルバーへの問い合わせに +recurse を使うことになる.以下は本書を参考に dig コマンドと +norecurse を使って www.jprs.co.jp の IP アドレスを非再帰的に問い合わせてみた.

# status: NOERROR
# ANSWER が 0
# flags に aa なし(委任情報が応答されている)
$ dig +norecurse @A.ROOT-SERVERS.NET www.jprs.co.jp A

# status: NOERROR
# ANSWER が 0
# flags に aa なし(委任情報が応答されている)
$ dig +norecurse @a.dns.jp www.jprs.co.jp A

# status: NOERROR
# ANSWER が 1
# flags に aa あり(権威を持つ応答がある)
$ dig +norecurse @ns1.jprs.co.jp www.jprs.co.jp A

;; ANSWER SECTION:
www.jprs.co.jp.     300    IN  A   117.104.133.165

なお A.ROOT-SERVERS.NET など,ルートサーバーの情報は公開された「ヒントファイル」から取得した.最新のルートサーバーの一覧を得る仕組みを「プライミング」と呼ぶ.

サイバー攻撃

Chapter.9「DNSに対するサイバー攻撃とその対策」では,以下のような DNS に関係するサイバー攻撃の種類と対策を学べる.特に対策を学べるのは素晴らしく,DNS を実際に運用するときに役立つ知識だと思う.

  • DNS リフレクター攻撃
  • ランダムサブドメイン攻撃
  • BIND の脆弱性を突いた DoS 攻撃
  • キャッシュポイズニング
  • ドメイン名ハイジャック

例えば,DNS リフレクター攻撃の影響を緩和するために「RRL (Response Rate Limiting)」の仕組みを導入し.同じ宛先から同じ応答が閾値を超えて発生した場合に制限をするという話だったり,キャッシュポイズニングの影響を緩和するために「ソースポートランダマイゼーション」で,ソースポート番号をランダムに変化させる話だったり,個人的に「理解が浅いな」と感じる部分を整理できて良かった.IP53B (Inbound Port 53 Blocking) の紹介もある.サイバー攻撃の流れも丁寧な図表でスッキリと理解できた.

DNS Over HTTPS

Chapter.14-04「DNS over HTTPS」では,HTTPS の GET / POST メソッドにより DNS に問い合わせをする「DNS over HTTPS」の紹介がある.RFC 8484「DNS Queries over HTTPS (DoH)」をザッと読むと,レスポンス形式はバイナリになっている.

:status = 200
content-type = application/dns-message
content-length = 61
cache-control = max-age=3709

<61 bytes represented by the following hex encoding>
00 00 81 80 00 01 00 01  00 00 00 00 03 77 77 77
07 65 78 61 6d 70 6c 65  03 63 6f 6d 00 00 1c 00
01 c0 0c 00 1c 00 01 00  00 0e 7d 00 10 20 01 0d
b8 ab cd 00 12 00 01 00  02 00 03 00 04

Google の「JSON API for DNS over HTTPS (DoH)」を使うと,RESTful API として使える.例えば「外形監視」などに活用できそう.

developers.google.com

試しに kakakakakku.hatenablog.com を指定して API を実行すると,以下のようなレスポンスだった.

$ curl -s https://dns.google.com/resolve\?name\=kakakakakku.hatenablog.com\&type\=A | jq .
{
  "Status": 0,
  "TC": false,
  "RD": true,
  "RA": true,
  "AD": false,
  "CD": false,
  "Question": [
    {
      "name": "kakakakakku.hatenablog.com.",
      "type": 1
    }
  ],
  "Answer": [
    {
      "name": "kakakakakku.hatenablog.com.",
      "type": 1,
      "TTL": 59,
      "data": "13.115.18.61"
    },
    {
      "name": "kakakakakku.hatenablog.com.",
      "type": 1,
      "TTL": 59,
      "data": "13.230.115.161"
    }
  ],
  "Comment": "Response from 2600:9000:5307:cd00::1."
}

まとめ

  • DNS に再入門するために「DNS がよくわかる教科書」を読んだ
  • 丁寧な図表が多く,説明の歩幅がとにかく小さく,初学者でも理解できるように工夫されていた
  • 「基礎編 → 実践編 → アドバンス編」と進むため,幅広い読者層に学びがありそう
  • 今年読んだ本の中でもトップレベルに「読んで良かった!」と思える1冊だった

DNSがよくわかる教科書

DNSがよくわかる教科書

  • 作者: 株式会社日本レジストリサービス(JPRS)渡邉結衣、佐藤新太、藤原和典,森下泰宏
  • 出版社/メーカー: SBクリエイティブ
  • 発売日: 2018/11/22
  • メディア: 単行本
  • この商品を含むブログ (1件) を見る