なんでAレコードが必要なの？

ドメインを取得しただけでは、hibitsuiki.comとVPSのIPは紐付いていません。 DNS機能を利用できないことにはアクセスすらできないのです。 AレコードでドメインとIPを対応させることで、ブラウザからドメイン名でVPSにアクセスできるようになります。

ConoHa VPSでWordPress＋ツール系アプリを公開するまでの奮闘記4【ドメイン・DNS設定～SSL証明書取得編】

WordPressで技術ブログを運営しつつ、練習がてら作ったツール系アプリも同じサーバーで公開したい！
そんな~~ケチな~~目標を掲げ、ConoHa VPSを契約して本番環境を構築した記録です。

前回はVPS環境で必須になるパッケージ・アプリケーションのインストールまで実施しました。
今回はドメインの取得・DNS設定、そしてSSL証明書の取得までを追っていきます。

前回の記事はこちら。

ConoHa VPSでWordPress＋ツール系アプリを公開するまでの奮闘記3【パッケージ・アプリケーションのインストール編】

ConoHa VPS構築記録の第3回。パッケージ更新・Docker動作確認・自動セキュリティアップデート設定から、リバースプロキシとして機能するNginxのインストール、SSL証明書取得に備えたcertbotの導入まで、手順を丁寧に解説します。

前提環境

ConoHa VPS	Ubuntu 24.04 LTS / メモリ2GB / SSD 100GB / Dockerプリインストール
ローカルPC → VPS	SSH鍵認証（ed25519）、ポート2222
VPSログインユーザー	user
WordPressテーマ	Cocoon（親テーマ）+ cocoon-child-master（子テーマ＋自作）

前提環境

前回までのあらすじ
ConoHaでドメイン取得
DNSの設定
SSL証明書の取得（Let’s Encrypt）

前回までのあらすじ

ConoHaセキュリティグループ：2222/80/443のインバウンドを許可（22番は削除済み）
SSH：ポートを2222に変更、root直接ログイン禁止、パスワード認証無効、鍵認証のみ
UFW：2222/80/443を許可
Docker：インストール済み
Nginx：インストール・自動起動設定済み
certbot：インストール済み

ConoHaでドメイン取得

せっかくConoHa VPSを契約したので、ドメインも同サービスで契約していきます。
同じ管理画面で管理できるのも便利だし。

他社レジストラでドメインを取得した場合はネームサーバーの変更作業が別途必要になりますが、ConoHaドメインならその手間が省けます。

さっそく、ConoHaの管理画面で購入してみましょう。

まだ空っぽのドメインリスト画面にて、「ドメイン取得」を押下。

こんな感じで、お好きなドメインを選べます。

今回はコスパと信頼性を重視ということで.comに。
「次へ」を押下し、個人情報を入力します。

お支払が完了すると、ドメインリストに追加されますね。

追々、認証用メールが届きますので2週間以内にちゃんと認証しておきましょう。

【取得時に設定したこと】
自動更新：ON（切れるとサイトが停止する）
WHOIS代行：ON（個人情報の公開を防ぐ）
移管ロック：ON（ドメインが第三者によって移管されるのを防ぐ）

なぜか移管ロックはデフォルトでOFFでしたね。
OFFにするのって、自分でドメインを別のレジストラに移管したい場合のみじゃないかな…？

よって、今回はONに。乗っ取られるのも怖いし。

DNSの設定

ドメインへAレコード追加

Q なんでAレコードが必要なの？: A

ドメインを取得しただけでは、hibitsuiki.comとVPSのIPは紐付いていません。
DNS機能を利用できないことにはアクセスすらできないのです。
AレコードでドメインとIPを対応させることで、ブラウザからドメイン名でVPSにアクセスできるようになります。

ConoHa管理画面「DNS」に、先ほど契約したドメインを入力しましょう。
追加後、編集ボタンでAレコードを設定できます。

黒く塗りつぶしていますが、ここは全て同じIP（このVPS）を指していてOKです。
Nginxがサブドメインを見て振り分けるので、DNS側は全部同じIPで大丈夫、ってことですね。

また、もともと設定されていたNSレコードはそのまま変更しません。
これは「このドメインのDNSはConoHaが管理しています」というネームサーバーの宣言です。
正常な状態なので、変更・削除は不要です。

【A（通常）を選んだ理由】
ConoHa VPSに割り当てられているのはIPv4アドレス
AレコードはIPv4アドレスとドメインを紐付けるためのレコード
→よって今回はA（通常）を選択。

【悲報】7時間経ってもDNSが反映されない

DNSの反映を待つこと7時間。一向に反映される気配がない。
最大72時間とはいえ音沙汰がなさすぎない…？？？

てことで、確認コマンドを叩いたところ…

$ dig NS hibitsuiki.com
# 結果
ns-a1.conoha.io   ← 実際に使われているネームサーバー
ns-a2.conoha.io
s-a3.conoha.io

Aレコードを登録していた場所：a.conoha-dns.com ← 別のサーバー

ん…？？？　ネームサーバーがconoha.ioなのに、Aレコードはconoha-dns.comに登録されてる？？？
そりゃ反映されないわ。

原因：管理画面のドメインリストが二種類ある

これは本当に混乱した部分なんですが、ConoHaの管理画面には、なんと「ドメインリスト」が2つあるんですよね。

「ドメイン」→ ドメインリスト	ドメイン取得時の付属DNS管理
「DNS」→ ドメインリスト	VPS側のDNS管理（実際に使われる）

「ドメイン」メニュー→「ドメインリスト」の「ホスト設定」は全く別の機能でした。

ConoHaのヘルプには以下の記載があります。

ドメインに対してホスト設定をするとネームサーバー名として使うことができるようになります。※ネームサーバー内に設定するDNSレコード設定のホストとは異なりますので、ご注意ください。

つまり「ドメイン」メニューのホスト設定は「ns1.hibitsuiki.com」のような独自ネームサーバーを作る場合に使うもので、今回の用途とは全く関係ありません。
わかりづらくない？？？？？？

解決方法

ネームサーバーの設定が「カスタム（ns-a1.conoha.io）」になっていたため、「ConoHa（a.conoha-dns.com）」に変更することに。
まじでなんで初期値がカスタムなんだよ…。

ConoHa管理画面　→「ドメイン」→「ネームサーバー設定」→「カスタム」を「ConoHa」に変更

変更後、以下のコマンドで反映を確認しました。2時間くらい空けましたね。

$ dig @a.conoha-dns.com www.hibitsuiki.com +short
$ dig @8.8.8.8 www.hibitsuiki.com +short
$ dig @1.1.1.1 www.hibitsuiki.com +short

ネームサーバーが切り替わっていたら、自分のIPアドレスが表示されます。
3つ全てのDNSサーバーで正しいIPアドレスが返ってきて、DNS設定が完了。

7時間もかかるはず…ないじゃんね…。

SSL証明書の取得（Let’s Encrypt）

気を取り直して、次はHTTPSに対応するサイトにしていきましょう。
SSL証明書（Let’s Encryptなら無料）を取得します。

なぜSSL証明書が必要か

セキュリティ：通信が暗号化されないとパスワードや個人情報が盗聴できてしまう
信頼性：ブラウザが「保護されていない通信」と警告を出すのを避けたい
SEO：GoogleはHTTPS非対応サイトの評価を下げる

certbotで証明書を取得

前回の作業でインストールは済んでおりますが、一応確認しておきます。

$ bashcertbot --version
期待する出力：
certbot 2.x.x

証明書の取得時は、以下のように自分のサイトのドメインを指定します。

$ sudo certbot certonly --nginx \
  -d hibitsuiki.com \
  -d www.hibitsuiki.com \
  -d test_app1.hibitsuiki.com
  -d test_app2.hibitsuiki.com

実行中に聞かれたことは以下。

メールアドレスの入力　　Enter email address: →有効なメールアドレスを入力
利用規約への同意　　(A)gree/(C)ancel: →A を入力
EFFからのメール受信　　(Y)es/(N)o: →どちらでもOK（筆者はNにしました）

成功時の出力

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/hibitsuiki.com/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/hibitsuiki.com/privkey.pem
This certificate expires on 2026-08-16.
Certbot has set up a scheduled task to automatically renew this certificate in the background.

証明書は90日有効で、certbotが自動更新のスケジュールを設定してくれます。

当たり前ですが、certbotの実行はDNS反映後でないと失敗するのでお気をつけて。
Let’s EncryptがドメインのIPを確認するため、DNSが正しく反映されていることが前提条件になります。

自動更新の確認

$ sudo certbot renew --dry-run

--dry-runオプションで、テスト更新したところ以下のエラーが出ました。

Saving debug log to /var/log/letsencrypt/letsencrypt.log
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/hibitsuiki.com.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Account registered.
Simulating renewal of an existing certificate for hibitsuiki.com and 2 more domains
Failed to renew certificate hibitsuiki.com with error: urn:ietf:params:acme:error:rateLimited :: There were too many requests of a given type :: Service busy; retry later.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
All simulated renewals failed. The following certificates could not be renewed:
 /etc/letsencrypt/live/hibitsuiki.com/fullchain.pem (failure)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1 renew failure(s), 0 parse failure(s)

ヒヤッとしましたが、これはLet’s Encryptのサーバーが一時的に混雑しているだけらしく。

実際の自動更新タイミング：証明書期限の30日前
現在の証明書有効期限：2026-08-16

この場合、実際に更新が必要になるのは2026年7月中旬頃ですよね。
その時点でLet’s Encryptのサーバーが空いていれば正常に更新されますし、仮に失敗しても数日以内に自動でリトライする仕組みになっているとのこと。

もし7月に更新されないようであれば、その記事でも書きますね…（遠い目）。

ではまた次回、Nginxリバースプロキシ設定からDocker起動編にて！