2019年10月から2019年12月までの3ヶ月間を「弱点克服期間」と位置付けていて，自分自身「理解が浅いな」と感じる技術領域のインプット／アウトプットを意識的に増やしていく．最近 React 関連のブログを書いているのも，フロントエンド技術に対する弱点克服の第一歩と言える．
今回のテーマは「DNS」にした．DNS の概要は理解できているはずだけど，いざ語ろうとすると，深くは語れないことに気付く．そんな状況を打破するべく「DNS がよくわかる教科書」を読んだ．本書の素晴らしい点は多くあるけど，まず丁寧な図表が多く，初学者でも理解できるように工夫されている．そして，何と言っても「説明の歩幅がとにかく小さく書かれている」ことに驚いた．本書を読み進めながら「徐々にわからなくなっていく...」と感じることがなかった．DNS を基礎から学びたい全ての人にオススメ！
目次
本書は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 SECTIONQUESTION SECTIONANSWER SECTIONAUTHORITY SECTIONADDITIONAL 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 アドレスを非再帰的に問い合わせてみた．
$ dig +norecurse @A.ROOT-SERVERS.NET www.jprs.co.jp A
$ dig +norecurse @a.dns.jp www.jprs.co.jp A
$ 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冊だった
