GitHub Pages の独自ドメイン設定手順についての深掘り

はじめに

前回までの記事でドメインを取得してGitHub Pagesに独自ドメインを設定しました。この記事では主に設定内容について疑問に感じた部分を深掘りして理解していきたいと思います。前回までの記事の内容に関する学習記録になりますので、設定手順は以下をご参照ください。

「ブログ用に Cloudflare Registrar で .dev ドメインを取得した」

「Cloudflare Registrar で GitHub Pages に独自ドメインを設定する」

体系的に学習したわけではないので全体構成が不自然になっているかもしれません。X（旧Twitter）上で度々見かける「DNSがよくわかる教科書」という書籍を今度読もうと思っているので、深掘りしすぎないようにしたいと思います。

DNS レコードとは

DNSレコードとは、ドメイン名に関連付けられた IP アドレスや、ドメインへのリクエストをどのように処理するかなどの情報を定義したものです。たとえばcloudflare.comというドメインに対しては、104.17.210.9というIPアドレスを返すというように決まっています。

A レコード

「A」は「アドレス」の略で、最も基本的なDNSレコードの種類です。特定のドメインとIPアドレスを結びつけます。IPv4の場合はAレコード、IPv6の場合はAAAAレコードが使用されます。例えば cloudflare.comの場合は104.17.210.9というIPアドレスが返されます。

今回はGitHub Pagesの4つのIPアドレスをAレコードとして登録しています。

CNAMEレコード

CNAMEレコードは「別名」を定義するレコードです。あるドメインを、別のドメインにまるごとリダイレクトします。例えば alias.example.com → target.example.net のように異なるドメイン同士を結びつけることができます。

このような例の場合、内部では2段階の名前解決が行われます。 まずalias.example.comの名前解決でtarget.example.netを取得、2段階目でtarget.example.netから具体的なIPアドレスを取得します。

今回はwwwというサブドメインを「(GitHubユーザ名).github.io」に結びつけています。

設定内容

今回は以下のような合計5つのレコードを追加しました。次でこの意味について詳しく見ていきます。

A レコード追加で感じた疑問

Q1. なぜ 4 つのレコードを追加したのか

A1. ラウンドロビンDNSと呼ばれる負荷分散技術が使われているから

ラウンドロビンDNSとは、DNSレベルの負荷分散技術のことです。ひとつのホスト名に対して複数のIPアドレスを登録し、DNSサーバーがそのIPアドレスを順番に返します。これにより、クライアントのアクセスをIP間で分散させることができます。

たとえば先ほどの設定内容では4つのIPアドレスが登録されていました。仮に①〜④とすると、DNSサーバは「①→②→③→④→①→...」のようにループで返すIPアドレスを変更していきます。これによりクライアントごとに違うIPアドレスにアクセスさせることができます。（正しくはIPアドレスのリストを返すらしいです。なのでDNSサーバはリストの順番を入れ替えるだけで、返すIPアドレスを一つに決定しているわけではありません。またクライアント側の選択方法も一つには定まっているわけではないらしいです。）

ラウンドロビンDNSの特徴

ラウンドロビンDNSを使用するメリットとして実装が極めてシンプルになるという点があります。複数のサーバを用意してAレコードをその分設定すれば負荷分散が可能になります。また新たにロードバランサを立てる必要がないので、DNS管理サービスの料金のみ（低コスト）で負荷分散を行うことができます。

一方でデメリットも存在します。レコードの切り替えを行なったときにDNSキャッシュの有効期限（TTL）まで待つ必要があります。Cloudflareではデフォルトで300秒なので、最低限300秒以上は待つ必要があります。

Q2. プロキシステータスはなぜ「DNSのみ」に設定しないといけないのか

A2. GitHub Pages のドメイン検証が失敗するため

プロキシステータスとは？

まずプロキシステータスについて説明していきます。詳しくは「Cloudflare Docs - Proxy status」に記載されています。プロキシステータスで「プロキシ」に設定すると次のようなことができるようになります。

• DDoS攻撃からの保護
• CDNキャッシュ
• アクセス解析・ロギング

要するに仲介役のサーバをCloudflareが入れてくれて、セキュリティ強化、キャッシュ、ロギングなどを行なってくれるオプションです。

GitHub Pages 側のドメイン所有権確認が通らない

先ほどのプロキシをオンにするとドメイン所有権確認が通らなくなります。GitHub PagesではAレコードがGitHub PagesのIPアドレスを直接指しているかをチェックします。プロキシが有効化されていると、DNSの名前解決の際にCloudflareのプロキシのIPアドレスが返ってきてしまうのでドメイン検証に失敗するというわけです。

おわりに

他にも疑問点はたくさんあったのですが、体系的に学んだほうがいいと思ったので「DNSがよくわかる教科書」という書籍を読んだ後にもう一度振り返ってみたいと思います。