ブログ公開で学ぶ DNS・ドメイン・HTTPS の仕組み

GitHub Pages にカスタムドメインを設定してブログを公開しました。その過程で DNS、ドメイン、TLS 証明書といった技術に触れたので、それぞれの役割と仕組みを整理します。

ドメイン名 ― インターネット上の住所

コンピュータ同士は 185.199.108.153 のような IP アドレスで通信しますが、人間には覚えにくいものです。そこで mizukichi.dev のような名前を IP アドレスに紐づける仕組みが ドメイン です。

ドメインの構造

ドメイン名は右から左に階層構造になっています。

mizukichi.dev

• dev … TLD（トップレベルドメイン）
• mizukichi … セカンドレベルドメイン（自分で取得した部分）

• TLD（トップレベルドメイン）: .com、.jp、.dev など。管理団体がそれぞれ異なります
• セカンドレベルドメイン: レジストラ（ドメイン販売業者）を通じて取得します

.dev ドメインの特殊性

.dev は Google が管理する TLD で、HSTS preload が適用されています。これはブラウザが .dev ドメインへのアクセスを 強制的に HTTPS にする仕組みです。そのため、HTTPS の設定が完了するまでブラウザからアクセスできません。

レジストラとレジストリ

• レジストリ（.dev の場合は Google）… TLD 全体のデータベースを管理
• レジストラ（Cloudflare など）… ユーザーがドメインを購入・管理する窓口

今回は Cloudflare がレジストラ（購入先）と DNS ホスティングの両方を担っています。

DNS ― インターネットの電話帳

DNS（Domain Name System） は、ドメイン名を IP アドレスに変換する仕組みです。

ブラウザが mizukichi.dev にアクセスするとき、裏側では以下のような問い合わせが段階的に発生します。

1. ブラウザ → リゾルバ（ISP などの DNS サーバ）に問い合わせ
2. リゾルバ → ルートサーバ（. の管理）に問い合わせ
3. ルートサーバ → .dev サーバ（TLD の管理）を紹介
4. .dev サーバ → Cloudflare NS（mizukichi.dev の管理）を紹介
5. Cloudflare NS → 「185.199.108.153 です」と回答

DNS レコードの種類

DNS にはいくつかのレコードタイプがあり、用途が異なります。

レコード	役割	設定例
A	ドメイン → IPv4 アドレス	mizukichi.dev → 185.199.108.153
CNAME	ドメイン → 別のドメイン（エイリアス）	www → mzkii.github.io
TXT	任意のテキスト情報（検証用途が多い）	ドメイン所有権の証明
NS	DNS を管理するサーバの指定	Cloudflare の NS サーバ
MX	メールサーバの指定	（今回は未使用）

A レコードを 4 つ設定する理由

GitHub Pages は 4 つの IP アドレスを持っています。複数の A レコードを設定することで DNS ラウンドロビン（アクセスを分散する仕組み）が働き、1 台が停止しても他のサーバで応答できます。

TTL（Time To Live）

DNS レコードには TTL（キャッシュ有効期間）が設定されています。例えば TTL が 300 秒なら、DNS リゾルバは 300 秒間その結果をキャッシュし、期間中は再問い合わせしません。TTL が長いほど DNS の変更が反映されるまで時間がかかります。

TLS 証明書 ― 暗号化と身元証明

TLS（Transport Layer Security）証明書 は、通信の暗号化とサーバの身元証明を行うデジタル証明書です。旧称の SSL 証明書と呼ばれることもあります。

HTTPS 通信の流れ

1. ブラウザがサーバに接続要求
2. サーバが証明書を提示（「私は mizukichi.dev です」）
3. ブラウザが証明書の正当性を検証
4. 暗号化された通信路を確立
5. 以降のデータはすべて暗号化されてやり取りされる

証明書が保証する 3 つのこと

• 暗号化: 通信内容を第三者が盗み見できない
• 認証: 接続先が本物のサーバであること
• 改ざん防止: 通信途中でデータを書き換えられない

Let’s Encrypt による自動発行

GitHub Pages は Let’s Encrypt という無料の認証局（CA）を使って証明書を自動発行・更新しています。

1. GitHub が Let’s Encrypt に証明書を要求
2. Let’s Encrypt がドメインの管理権を検証（DNS の A レコードが GitHub Pages を指しているか確認）
3. 検証 OK → 証明書を発行（有効期間 90 日、自動更新）

Enforce HTTPS

Enforce HTTPS を有効にすると、http:// でアクセスしても自動的に https:// にリダイレクトされます。

ドメイン検証 ― 所有権の証明

GitHub がカスタムドメインの所有権を確認するために、DNS の TXT レコード を使った検証を行います。

1. GitHub が検証用の文字列を提示
2. ユーザーが DNS に TXT レコードとして登録
3. GitHub が DNS を問い合わせて値を確認
4. 一致すれば所有権を認定

「DNS レコードを追加できる ＝ そのドメインの管理権限を持っている」という理屈です。Google Search Console やメールの SPF/DKIM 認証でも同じ原理が使われています。

全体の通信フロー

https://mizukichi.dev にアクセスしたときに起きることを順に追うと、ここまでの技術がどう連携しているかがわかります。

1. DNS 解決 — ブラウザが DNS リゾルバ経由で Cloudflare NS に問い合わせ、mizukichi.dev の IP アドレス 185.199.108.153 を取得
2. TLS ハンドシェイク — GitHub Pages（185.199.108.153）に接続し、証明書を検証して暗号化通信路を確立
3. HTTP リクエスト — GET / HTTP/2（Host: mizukichi.dev）を送信
4. レスポンス — GitHub Pages がビルド済みの HTML を返却

まとめ

技術	役割
ドメイン	人間が覚えやすい名前を提供する
DNS	ドメイン名を IP アドレスに変換する
TLS 証明書	通信の暗号化とサーバの身元証明を行う
ドメイン検証	DNS レコードを使ってドメインの所有権を証明する

これらは普段意識することが少ない技術ですが、ブラウザでサイトを開くたびに裏側で動いています。カスタムドメインの設定を通じて、一連の仕組みを体感できました。