Site cover image

Site icon imageけけずん積読消化記録

This is my Tsundoku records.
2024-06-01
書籍

🧪“DNSをはじめよう” を読んだ

はじめに

仕事でDNSレコードを触る必要があったが、DNSを学んだのが大分昔なのと、普段触る機会がないというのもあり、DNSについて完全に分からない状態になっていた。そこで、以前に友人からお勧めされた書籍「DNSをはじめよう」を読み返すことにした。

https://amzn.to/3Xn7aCI

CHAPTER1 ドメイン名とWhois

🗒️ 書かれてること

ドメイン名、ドメイン名を管理する組織、Whois情報など、ドメイン名を購入（登録）する視点から見たときに知っておくべき情報について記載されている。また、トラブルがあった具体的なケースについても紹介している。

💡学び

  • ドメイン名
    • 大文字小文字の区別はない
    • お店によって価格は違うが、品質には違いはない
    • レジストラまたはリセラーから購入（登録）可能
  • レジストラとリセラー
    • レジストラ（登録事業者）
      • ドメイン名をリセラに卸す
      • 一般消費者に販売する
    • リセラー（再販事業者）
      • 一般消費者に販売する
    • レジストラとリセラーどちらから買ってもドメイン名自体の品質に違いはないが、リセラのような中間業者が増えるとリスクが増える
      • 中間業者が倒産した場合に連絡がとれなくなるなど
  • TLD（Top Level Domain）
    • 「example.com」の「.com」の部分のこと
    • TLDはレジストリが管理している（レジストラではない）
    • www.example.com の例
      • www は第3レベルドメイン
      • example は第2レベルドメイン
      • com はトップレベルドメイン
  • ZONE APEX
    • レジストラやリセラで買った一番短い表記のドメイン名のこと（wwwなどのサブドメインを含まないドメイン名のこと）
    • Apex DomainやNaked Domain、ホスト名なしドメインなどと呼ばれることもある
  • レジストリ（登録管理組織）
    • TLDを管理している
      • ドメイン名の一意性を保つため
    • TLDとレジストリは多対1の関係（一つのTLDは一つのレジストリに管理される）
    • ドメインが一般消費者に届くまでの流れ
      • レジストリ → レジストラ → 一般消費者
      • レジストリ → レジストラ → リセラ → 一般消費者
    • TLDごとに価格が異なっているのは、レジストリの管理体制の手厚さなどが理由でもある
  • ドメイン名を検討する際のポイント
    • TLDの可用性が高いかどうか
    • TLDの意味が適切なものかどうか
  • ドメイン購入時のお店選びのポイント
    • 購入時、更新時の価格
    • 購入時、更新時以外の操作で発生する料金の有無
    • 管理画面の使いやすさ
  • ICANN
    • IPアドレスやドメイン名などの資源を世界的に調整・管理する非営利法人
      • 80はhttp、22はsshというようにプロトコルのポート番号も決めてる
    • TLDを作り、TLDを管理するレジストリを決める
    • ICANNに「レジストリになりたいです」と申請を出し、ICANNが承認すればレジストリになれる
  • 「ドメイン」と「ドメイン名」の違い
    • 「example」「com」といった名前空間の領域をドメインという
    • 「exapmle.com」や「example.co.jp」といった名前をドメイン名という
      • 正確にいうとFQDN（Fully Qualified Domain Name / 完全修飾ドメイン名）
      • 「example.co」までだと相対ドメイン名となる
  • サブドメイン
    • ドメインに内包されているドメインのこと
      • 「example.co.jp」の「example」と「co」は「jp」のサブドメイン、「example」は「co」のサブドメイン
      • 「example.co.jp」は「jp」または「co.jp」のサブドメイン
    • ドメイン名を買うとサブドメインは作り放題
  • Whois情報
    • ドメイン名購入時に登録する必要がある所有者の情報をWhois情報（またはWhoisのみ）という
    • レジストラまたはリセラではWhois情報を公開しない機能として、Whois情報公開代行という機能がある
    • レジストリごとにWhoisに登録する項目は異なる
    • Whois情報検索サイトやwhoisコマンドでWhois情報を参照できる
  • ドメイン名の有効期限
    • ドメイン名の有効期限が切れて一定期間が経過すると、そのドメイン名は市場で売りに出されて誰でも買える状態になる
    • 使用実績のあるドメイン名は集客力があるため、そういった価値のあるドメイン名の期限が切れた際にさっと取得して悪用する行為をドロップキャッチと言う
      • リニューアルに伴いドメイン名を変更した場合でも、元々のドメイン名を手放さず責任を持って保持し続けなければドロップキャッチされ悪用される可能性がある
  • ドメイン名を手放す条件
    • 元々のドメイン名でサイトにアクセスしてきている人がいないこと
    • 他サイトから自サイトへのリンクで、元々のドメイン名が使用されていないこと
    • ドロップキャッチされても問題ないと判断できること

💬 感想

ドメイン名のことをドメインと言うことがよくあるが、意味の違いを意識したことはなかった。また、自分もプライベート用で購入し使用しているドメイン名などもあるが、管理には気をつけたい。

CHAPTER2 DNSの仕組み

🗒️ 書かれてること

DNSに関する用語や仕組みの説明、DNSの設定を実際に行う手順などについて記載されている。

💡学び

  • DNS（Domain Name System）
    • ドメイン名の管理システム
  • DNSサーバ
    • ネームサーバ
      • 電話帳のような役割
      • ドメイン名とそれに紐づくIPアドレスが登録されている
      • DNSコンテンツサーバ、権威DNSサーバと呼ばれることもある
    • フルリゾルバ
      • 秘書のような役割
      • ドメインに紐づくIPアドレスを調べて教えてくれ、教えてもらった後はしばらくキャッシュする
      • DNSキャッシュサーバ、フルサービスリゾルバと呼ばれることもある
  • Webページが表示されるまでの流れの例
    • フルリゾルバにキャッシュがある場合： ブラウザ → フルリゾルバ → Webサーバ
    • フルリゾルバにキャッシュがない場合： ブラウザ → フルリゾルバ → ルートネームサーバ → ネームサーバ → Webサーバ
  • ゾーンと委任
    • 「startdns.fun」というドメインがあるとき、「fun」や「startdns.fun」のような範囲をゾーンと呼ぶ
    • ネームサーバが自身に任されているゾーンを分割し、その一部のゾーンを他のネームサーバに任せることを委任と呼ぶ
  • リソースレコード
    • ゾーンの中にある「ドメイン名とIPアドレスの紐づけ」一つ一つのこと
    • 種類
      • Aレコード： ドメイン名に紐づくIPアドレス
      • NSレコード： ドメイン名のゾーンを管理するネームサーバ
      • MXレコード： ドメイン名に紐づくメール受信サーバ
      • TXT（SPF）レコード： このドメイン名のメール送信元サーバ
      • SOA： ドメイン名のゾーンの管理情報
      • CNAME： このドメイン名の別名でリソースレコードの参照先
  • hostsファイル
    • DNSという仕組み生まれる以前から使用されている、名前とIPアドレスの対応が記述されたファイル
    • 現在も使われており、 hostsファイル → フルリゾルバ という順番で問い合わせる
    • ローカル環境でドメイン名を指定した確認作業を行う、といった使い方もできる

💬 感想

DNSの基本的な用語と仕組みは完全に理解できた。リソースレコードについては、AレコードやCNAMEなどはよく使用するが、それ以外はあんまり触る機会がないため忘れがちになる。

CHAPTER3 AWSのネームサーバ（Route53）を使ってみよう

🗒️ 書かれてること

AWSのRoute53を使って実際にゾーンやリソースレコードを操作する方法や、フルリゾルバになりきりdigコマンドを用いてネームサーバに問い合わせをする流れについて記載されている。なおドメイン名自体はお名前.comから購入したものを使用し、お名前.com側でNSレコードをRoute53に向けて設定している。

💡学び

  • TTL（Time To Live）
    • DNSの文脈だと、フルリゾルバのキャッシュ保持時間を指す
    • よく言われる「DNSの浸透」とは、TTLに指定された時間を過ぎてフルリゾルバにリソースレコードの情報が反映されることを指す
      • 逆に「DNSが浸透していない」とはフルリゾルバでキャッシュが使用され続けた状態のこと
    • リソースレコードの情報をすぐに反映したい場合はTTLを短くし、ネームサーバが死んだとしてもキャッシュを参照し続けるようにしたいのであればTTLお長くするといい
  • DNSの名前解決の仕組みはプル型
    • フルリゾルバがネームサーバから情報をプルする型
  • ネームサーバを変更すること ≠ レジストラを変更すること
    • レジストラを変更する場合は「レジストラ移管」を行う必要がある

💬 感想

「お名前.comで購入してNSレコードにRoute53を指定する方が安い」というような記載があったが、個人的にはドメインの購入もRoute53で行うほうが管理上は楽なのでそちらを推したい。

CHAPTER4 digとwhoisを叩いて学ぶDNS

🗒️ 書かれてること

コマンドでDNSレコードの問い合わせをする方法や、各リソースレコードについての説明が記載されている。

💡学び

  • 「推測するな計測せよ」
    • 性能向上のための格言。障害発生時にも同じことが言える
  • dig コマンド
    • DNSサーバにドメイン名に関する情報を問い合わせ出力してくれるコマンド
    • オプションなしで実行すると調査の過程や付加情報まで含めて全部教えてくれる
  • nslookup コマンド
    • 以前は「nslookup は非推奨で将来的に廃止される」という警告が出されていたが、BIND9.9.0a3が公開されたタイミングで警告がでないようになったらしい
      • 非推奨だとか廃止だとかいう話もなくなったらしい
    • dig コマンドに比べると出力される情報に不足があったり下手に加工されていたりするので、dig コマンドを推奨している
  • whois コマンド
    • ドメイン名やIPの持ち主を調べられるコマンド
    • 表示される有効期限については、更新手続きをしたタイミングなのか、有効期限を迎えたタイミングなのかと、TLDによって表示が更新されるタイミングが異なる
  • DNSラウンドロビン
    • 1つのドメイン名に複数のIPアドレスをAレコードとして設定したとき、問い合わせるたびに応答するIPアドレスの順番が変わること
      • 負荷分散の用途で使用できる
      • この場合、レコードごとに異なるTTLを設定することは非推奨とされている
  • Aレコード
    • ドメイン名からIPアドレスを正引きするためのレコード
  • MXレコード
    • 指定したドメイン名のメールサーバで受信します、という設定をするレコード
    • プリファレンス値
      • dig example.com mx +short で返ってくる値の先頭の数字
      • メールサーバが複数台ある場合の優先度を表す
    • MXレコードがない場合、Aレコードに紐づいているIPドレス宛にメールを送ろうとする
      • 知らぬ間に機密情報満載のメールを受信する可能性があるため、プリファレンス値を「0」、メールサーバ名を「.」にしたNull MXを設定し、メールを受信しませんという意図を明示する方がいい
    • メールを受信する要件がなくても、送信する要件がある場合はバウスメール受信のためにMXレコードは設定すべき
    • バウンスメール
      • 宛先メールアドレスが間違ってる等の理由でメールが正常に配信できなかった場合、送信元に戻ってくるメールのこと
      • MAILER-DAEMONやリターンメール、エラーメールとも呼ばれる
  • NSレコード
    • ドメイン名のネームサーバを指定するためのレコード
  • SPFレコード（TXTレコード）
    • 送信元のドメイン名として許容する設定を行うためのレコード
    • 送信元を詐称してメールを送る「なりすましメール」かを確認する手段として使用する
    • 昔はSPFレコードとTXTレコード両方を設定することが推奨されていたが、現在はTXTレコードのみで設定するようになった
    • ipv4のみ設定してもSPFがfailになる場合は、ipv6の設定も必要な場合がある
  • PTRレコード（PoinTeR record の略）
    • IPアドレスからドメイン名を逆引きできるレコード
    • AレコードやMXレコードなどドメイン名のリソースレコードとは異なり、IPアドレスのリソースレコードはIPアドレスの持ち主の管理画面から設定できる
  • CNAMEレコード
    • canonical name（正式名）なドメイン名に、aliases（別名）なドメイン名を設定するレコード
    • dig コマンドで問い合わせたとき、正式名と、正式名のAレコードで設定されたIPアドレスも返される
    • CNAMEと他のリソースレコードを共存させた場合、CNAMEレコードのみ名前解決され、他のリソースレコードの動作は保証されない
  • グルーレコード
    • 自分でネームサーバを立てるときに、上位のネームサーバに登録するIPアドレスのこと
    • フルリゾルバの循環的な問い合わせを解消するためのレコード
  • 例示やテスト専用ドメイン名は、RFC2606やJPRSで定められているドメイン名を使用すべき
    • 適当なドメイン名をサンプルとして使用すると、実際にドメイン名の持ち主に情報が渡る可能性がある
    • RFC2606で定められている example.com や example.net 、またはJPRSで定められ散る example.jp や example.co.jp を使うこと
  • おすすめ資料

💬 感想

dig コマンドをスプラ2のブキチに例えている箇所が面白かった。CNAMEレコードは使うことが多いが、canonical nameやaliasesといった用語は初めて知った。「CNAMEレコードの参照先」というように雰囲気で話していたので、正しい用語を使うようにしたい。

CHAPTER5 トラブルシューティング

🗒️ 書かれてること

実際にありがちなトラブルとその解決方法、事前の対策について記載されている。

💡学び

  • URLはwwwありとなしどちらがいいか
    • 両方用意した場合、検索エンジンが別サイトとして解釈してしまうのでよろしくない
    • ZONE APEXではCNAMEが使えないので、弊害がでないようwwwありを推奨している
  • レコードを更新したが、TTLが長いためすぐに反映されない
    • キャッシュが消えるまでの時間を逆算して予めTTLを短くし、当日にレコードを更新するとすぐに反映されるようにする
  • ネガティブキャッシュ
    • 問い合わせをしたレコードが存在しない場合、NOINDEXとしてキャッシュされる
    • ネガティブキャッシュの保持時間が過ぎたらキャッシュが更新される
  • CAAレコード（Certification Authority Authorizationの略）
    • 指定した認証局以外の認証局から証明書の発行を防ぐ仕組み
    • 証明書を発行したいドメイン名にCAAレコードが設定されていない場合、TLDまで遡ってCAAレコードの有無が確認されるため、証明書が発行できない場合は親ドメインにCAAレコードがある可能性を疑う方が良い

💬 感想

本章に限らず、他の章にもトラブル事例やコラムなどが記載されている。どれも実際にあり得る内容（実際に起きた話などもある）になっているため、読んでおくと役に立ちそう。

おわりに

DNS知らない人向けに、実際にレジストラからドメイン名を取得してレコードを設定する、という流れを踏むことでDNSについて理解しやすいような内容になっている。基礎的な話が多い印象だったので、サクッと読んで大まかに理解したい人にはおすすめ。

あとは、あとがきに書いているお気持ちは共感できる。分からない人の気持ちが分かるから、分からない人にも分かるように説明する、というのは凄く優しい世界だなと思った。

書籍