ドメイン・DNS・SSL証明書の管理ガイド

ドメイン・DNS・SSL証明書の重要性

「Webサイトにアクセスできない」「SSL証明書の有効期限が切れていた」——こうしたトラブルは、ドメインやDNS、SSL証明書の管理が不十分な場合に発生します。私がコンサルティングを行う中小企業でも、ドメインの更新忘れや、DNS設定のミスによるサービス停止の事例が後を絶ちません。

ドメイン、DNS、SSL証明書は、Webサイトや業務システムを運用する上で欠かせない基盤です。これらを適切に管理することで、安定したサービス提供とセキュリティの確保が可能になります。

本記事では、ドメインの取得と管理、DNSの仕組みと設定、SSL証明書の種類と更新手順まで、Web運用に必要な基礎知識を実例を交えて解説します。インフラ設計全般についてはインフラ設計入門もあわせてご覧ください。

ドメインの基礎知識

ドメインとは

ドメイン（Domain）は、インターネット上の住所に相当するものです。Webサイトにアクセスする際に使う「example.com」のような文字列がドメイン名です。

ドメイン名は、IPアドレス（例: 192.0.2.1）を人間が覚えやすい形式に変換したものです。ユーザーはブラウザに「example.com」と入力すれば、DNS（後述）が自動的にIPアドレスに変換してくれます。

ドメインの構造

ドメイン名は、階層構造になっています。

例: www.example.co.jp

トップレベルドメイン（TLD: Top Level Domain）: .jp
セカンドレベルドメイン（SLD: Second Level Domain）: .co
ドメイン名（組織名）: example
サブドメイン: www

TLDの種類

gTLD（generic TLD）: 一般的なトップレベルドメイン

.com: 商業組織
.net: ネットワーク関連組織
.org: 非営利組織
.info, .biz, .io など

ccTLD（country code TLD）: 国別コードトップレベルドメイン

.jp: 日本
.us: アメリカ
.uk: イギリス

日本の場合、.jpの下にさらに属性型JPドメイン（.co.jp, .ne.jp, .or.jpなど）があります。

ドメインの取得方法

ドメインを取得するには、ドメイン登録サービス（レジストラ）を利用します。

主なドメイン登録サービス

お名前.com（GMOインターネット）
ムームードメイン（GMOペパボ）
さくらのドメイン（さくらインターネット）
Google Domains（※2023年にSquarespaceに事業譲渡）
AWS Route 53
Cloudflare

ドメイン取得の手順

ドメイン名の検索: 希望するドメイン名が利用可能かを検索
登録者情報の入力: 組織名、担当者名、住所、メールアドレスなど
支払い: クレジットカードまたは銀行振込で料金を支払う
登録完了: 数分〜数時間でドメインが利用可能になる

ドメインの料金 ドメインの料金は、TLDやレジストラによって異なります。

.com: 年額1,000〜1,500円程度
.jp: 年額3,000〜4,000円程度
.co.jp: 年額4,000〜5,000円程度

.co.jpは、登記された企業のみが取得できるため、信頼性が高いとされます。

ドメインの管理

ドメインを取得した後は、継続的な管理が必要です。

更新（Renewal） ドメインは通常1年単位で契約し、更新が必要です。更新を忘れると、ドメインが失効し、Webサイトにアクセスできなくなります。最悪の場合、第三者に取得されてしまう可能性もあります。

対策

自動更新を有効にする
更新期限の1〜2か月前にアラート通知を設定
複数年契約で更新忘れを防ぐ

WHOIS情報の管理 ドメインの登録者情報は、WHOIS（フーイズ）というデータベースで公開されます。WHOISには、ドメイン所有者の名前、住所、メールアドレスなどが含まれます。

個人情報保護のため、多くのレジストラは「WHOIS情報公開代行」サービスを提供しています。これにより、レジストラの情報が公開され、個人情報が隠されます。

トランスファーロック ドメインが不正に他のレジストラに移管されないよう、トランスファーロック（移管ロック）を有効にしておくことを推奨します。

DNSの基礎知識

DNSとは

DNS（Domain Name System）は、ドメイン名をIPアドレスに変換する仕組みです。ユーザーがブラウザに「example.com」と入力すると、DNSが「192.0.2.1」というIPアドレスを返し、ブラウザがそのIPアドレスにアクセスします。

DNSがなければ、ユーザーは全てのWebサイトにIPアドレスで直接アクセスする必要があり、非常に不便です。

DNSの仕組み

DNSの名前解決（ドメイン名をIPアドレスに変換すること）は、以下の手順で行われます。

ユーザーがブラウザに「example.com」と入力
リゾルバ（通常はISPのDNSサーバー）にクエリを送信
リゾルバがルートDNSサーバーに問い合わせ: 「.com」の権威サーバーを教えてもらう
リゾルバが.comの権威サーバーに問い合わせ: 「example.com」の権威サーバーを教えてもらう
リゾルバが「example.com」の権威サーバーに問い合わせ: IPアドレスを取得
リゾルバがIPアドレスをユーザーに返す
ブラウザがIPアドレスにアクセスし、Webサイトを表示

この一連の流れは数ミリ秒〜数十ミリ秒で完了します。

DNSレコードの種類

DNSには、様々な種類のレコード（Record）があります。それぞれ異なる役割を持っています。

Aレコード（Address Record） ドメイン名をIPv4アドレス（例: 192.0.2.1）に対応付けます。最も基本的なレコードです。

例:

example.com.  A  192.0.2.1

AAAAレコード（IPv6 Address Record） ドメイン名をIPv6アドレス（例: 2001:0db8::1）に対応付けます。

CNAMEレコード（Canonical Name Record） ドメイン名を別のドメイン名に対応付けます（エイリアス）。

例:

www.example.com.  CNAME  example.com.

これにより、www.example.comにアクセスすると、example.comのIPアドレスが返されます。

MXレコード（Mail Exchange Record） メールサーバーを指定します。メールアドレスuser@example.com宛のメールが、どのサーバーに配送されるかを定義します。

例:

example.com.  MX  10  mail.example.com.

数字（10）は優先度を表し、値が小さいほど優先されます。

TXTレコード（Text Record） 任意のテキストデータを格納します。SPF（送信ドメイン認証）、DKIM（メール署名）、ドメイン所有権の確認などに使われます。

例:

example.com.  TXT  "v=spf1 include:_spf.google.com ~all"

NSレコード（Name Server Record） ドメインの権威DNSサーバーを指定します。

例:

example.com.  NS  ns1.example.com.
example.com.  NS  ns2.example.com.

DNSのTTL（Time To Live）

TTLは、DNSレコードがキャッシュされる時間（秒）を指定します。TTLが長いほど、DNSサーバーへの問い合わせ回数が減り、負荷が軽減されますが、レコードの変更が反映されるまで時間がかかります。

例:

example.com.  3600  A  192.0.2.1

この場合、TTLは3600秒（1時間）です。

TTLの設定の目安

通常時: 3600秒（1時間）〜86400秒（24時間）
サーバー移行前: 300秒（5分）〜600秒（10分）に短縮し、切り替えを迅速化
移行後: 元の長いTTLに戻す

DNS設定の実践

DNS設定の基本手順

Webサイトを公開する際の、基本的なDNS設定手順を紹介します。

ステップ1: ドメインのネームサーバーを設定 ドメイン登録サービス（レジストラ）で、ドメインのネームサーバー（権威DNSサーバー）を設定します。

例えば、AWSのRoute 53を使う場合、Route 53で発行されたネームサーバー（例: ns-123.awsdns-45.com）を、レジストラの管理画面で設定します。

ステップ2: DNSレコードを追加 権威DNSサーバー（Route 53、Cloudflare、お名前.comのDNS機能など）の管理画面で、レコードを追加します。

例: Webサーバーのレコード設定

example.com.       A     192.0.2.1
www.example.com.   CNAME example.com.

例: メールサーバーのレコード設定

example.com.  MX  10  mail.example.com.
mail.example.com.  A  192.0.2.2

ステップ3: DNS反映の確認 設定後、DNSが正しく反映されているかを確認します。

digコマンド（Linux/Mac）

dig example.com

nslookupコマンド（Windows）

nslookup example.com

反映には、最大で24〜48時間かかる場合があります（TTLやキャッシュの影響）。

DNSホスティングサービスの選定

DNSの設定を管理するDNSホスティングサービスは、以下のような選択肢があります。

レジストラ提供のDNSサービス ドメインを取得したレジストラが、無料でDNS機能を提供している場合が多いです。小規模なWebサイトであれば、これで十分です。

クラウド型DNSサービス

AWS Route 53: AWSのDNSサービス。高可用性、低レイテンシー、ヘルスチェック機能あり
Cloudflare: 無料プランでもDNS機能が充実。CDN機能も併用可能
Google Cloud DNS: Google CloudのマネージドDNSサービス

専用DNSサービス

Dyn: エンタープライズ向けの高性能DNSサービス（Oracle傘下）
NS1: 高度なトラフィック管理が可能

推奨中小企業であれば、Cloudflare（無料プラン）またはAWS Route 53を推奨します。Cloudflareは設定が簡単で、CDN機能も無料で使えます。

DNS設定の失敗例と対策

失敗例1: ネームサーバーの設定ミス レジストラで設定したネームサーバーが間違っており、DNSが機能しないケース。

対策

ネームサーバーの設定を慎重に確認
digやnslookupでDNS解決をテスト

失敗例2: CNAMEの多重設定 CNAMEレコードは、他のレコードと同時に設定できません（例えば、example.comにAレコードとCNAMEレコードを両方設定することはできません）。

対策

CNAMEはサブドメイン（例: www.example.com）に使用
ルートドメイン（例: example.com）にはAレコードまたはALIASレコード（Route 53の場合）を使用

失敗例3: MXレコードの優先度ミス MXレコードの優先度を間違えて設定し、メールが意図しないサーバーに配送されるケース。

対策

MXレコードの優先度を正しく設定（メインのメールサーバーに小さい値）
設定後、テストメールを送信して確認

SSL証明書の基礎知識

SSL証明書とは

SSL証明書（正確にはSSL/TLS証明書）は、Webサイトとユーザーのブラウザ間の通信を暗号化するための電子証明書です。SSL証明書を導入することで、通信内容の盗聴や改ざんを防げます。

また、SSL証明書は、Webサイトの運営者が正当であることを証明する役割も持っています。

HTTPとHTTPSの違い

HTTP（Hypertext Transfer Protocol） 暗号化されていない通信プロトコルです。通信内容が平文で送信されるため、第三者に盗聴される可能性があります。

HTTPS（HTTP over SSL/TLS） SSLまたはTLSで暗号化された通信プロトコルです。通信内容が暗号化されるため、盗聴や改ざんのリスクが大幅に低減されます。

ブラウザのアドレスバーに鍵マークが表示され、ユーザーに安全性が視覚的に伝わります。

HTTPSのメリット

通信内容の暗号化（パスワード、クレジットカード情報などを保護）
Webサイトの信頼性向上（ブラウザが「安全な接続」と表示）
SEO効果（Googleは HTTPS を優遇）

2026年現在、HTTPでの運用は推奨されません。全てのWebサイトでHTTPSを使用してください。

SSL証明書の種類

SSL証明書には、認証レベルと用途によっていくつかの種類があります。

認証レベルによる分類

1. DV証明書（Domain Validation） ドメインの所有権のみを確認する、最も簡易的な証明書です。発行が早く（数分〜数時間）、料金も安価です。

用途: 個人サイト、小規模企業サイト
料金: 無料（Let’s Encrypt）〜年額数千円

2. OV証明書（Organization Validation） ドメインの所有権に加えて、組織の実在性を確認する証明書です。認証局が企業の登記情報などを確認します。

用途: 企業サイト、会員制サイト
料金: 年額2〜5万円程度

3. EV証明書（Extended Validation） 最も厳格な審査を経て発行される証明書です。ブラウザのアドレスバーに企業名が緑色で表示されます（一部ブラウザでは表示方法が変更されています）。

用途: 金融機関、ECサイト、大企業サイト
料金: 年額10〜20万円程度

用途による分類

シングルドメイン証明書 1つのドメイン（例: example.com）のみに使用できます。

ワイルドカード証明書 1つのドメインと、そのサブドメイン全てに使用できます。

例: *.example.comで、www.example.com, mail.example.com, shop.example.comなどに対応。

マルチドメイン証明書（SAN証明書） 複数の異なるドメインに使用できます。

例: example.com, example.net, example.orgを1つの証明書でカバー。

Let’s Encryptによる無料SSL証明書

Let’s Encrypt（レッツエンクリプト）は、無料でSSL証明書を発行する認証局です。2016年にサービスを開始し、現在では世界中で広く利用されています。

特徴

完全無料
DV証明書（ドメイン所有権のみ確認）
有効期限90日（自動更新が前提）
自動化ツール（Certbot）で簡単に導入可能

Let’s Encryptの導入手順（Certbot使用）

ステップ1: Certbotのインストール（Ubuntu/Debianの例）

sudo apt update
sudo apt install certbot python3-certbot-apache

ステップ2: SSL証明書の取得（Apacheの場合）

sudo certbot --apache -d example.com -d www.example.com

Certbotが自動的にApacheの設定を変更し、HTTPS対応を完了してくれます。

ステップ3: 自動更新の設定 Let’s Encryptの証明書は90日で期限が切れるため、自動更新の設定が必須です。Certbotは、cronまたはsystemdタイマーで自動更新を設定します。

sudo certbot renew --dry-run

このコマンドで、更新のテストを実行できます。

商用SSL証明書との比較

Let’s Encryptのメリット

完全無料
自動化が容易
小規模サイトには十分

Let’s Encryptのデメリット

DV証明書のみ（OV、EVは発行不可）
ワイルドカード証明書は取得可能だが、DNS認証が必要
サポートが限定的（コミュニティベース）

商用SSL証明書のメリット

OV、EV証明書が取得可能（企業の信頼性をアピール）
ベンダーのサポートあり
証明書の有効期限が1年（手動更新の手間が少ない）

推奨一般的な企業サイトであれば、Let’s Encryptで十分です。金融機関や大規模ECサイトなど、高い信頼性が求められる場合は、OVまたはEV証明書を検討してください。

SSL証明書の更新と管理

SSL証明書には有効期限があり、定期的な更新が必要です。更新を忘れると、Webサイトにアクセスできなくなり、ビジネスに大きな影響を及ぼします。

更新の流れ

1. 有効期限の確認 SSL証明書の有効期限を定期的に確認します。ブラウザでサイトにアクセスし、証明書の詳細を表示すると、有効期限がわかります。

コマンドでの確認（OpenSSL）

openssl s_client -servername example.com \
  -connect example.com:443 -brief \
  | openssl x509 -noout -dates

2. 更新の実施 有効期限の1〜2か月前に更新作業を開始します。

Let’s Encryptの場合 Certbotが自動更新を行うため、基本的に手動作業は不要です。ただし、更新が正常に動作しているかを定期的に確認してください。

商用SSL証明書の場合 認証局から更新の案内メールが届くので、それに従って更新手続きを行います。

3. 証明書のインストール 更新した証明書を、Webサーバーにインストールします。

Apacheの例

SSLCertificateFile /etc/ssl/certs/example.com.crt
SSLCertificateKeyFile /etc/ssl/private/example.com.key
SSLCertificateChainFile /etc/ssl/certs/chain.crt

設定後、Apacheを再起動します。

sudo systemctl restart apache2

4. 動作確認 ブラウザでサイトにアクセスし、証明書が正しくインストールされているかを確認します。

証明書の監視とアラート

証明書の有効期限切れを防ぐため、監視とアラート設定を行います。

監視ツールの活用 サーバー監視ツール（Datadog、Zabbix、CloudWatchなど）で、SSL証明書の有効期限を監視できます。有効期限の30日前、7日前などにアラートを送信する設定を推奨します。

監視の詳細についてはサーバ監視・アラート設計入門をご覧ください。

外部監視サービス

SSL Checker（https://www.sslshopper.com/ssl-checker.html）
SSL Labs（https://www.ssllabs.com/ssltest/）

これらのサービスで、証明書の有効性や設定の安全性を確認できます。

ドメイン・DNS・SSL証明書の運用ベストプラクティス

ドメインの運用

1. ドメインの集約管理 複数のドメインを保有している場合、レジストラを統一し、管理を集約します。バラバラに管理していると、更新漏れが発生しやすくなります。

2. 自動更新の有効化 ドメインの更新忘れを防ぐため、自動更新を有効にします。クレジットカード決済に設定しておくと、更新が自動的に行われます。

3. 重要ドメインは複数年契約 ビジネスに不可欠なドメインは、複数年契約（3年、5年、10年）を検討してください。更新忘れのリスクを大幅に低減できます。

4. トランスファーロックの有効化 ドメインの不正移管を防ぐため、トランスファーロックを有効にします。

DNSの運用

1. プライマリとセカンダリの冗長化 DNSサーバーは、プライマリ（主）とセカンダリ（副）の複数台で運用します。プライマリが障害を起こしても、セカンダリが応答を継続します。

多くのDNSホスティングサービスは、自動的に冗長構成を提供しています。

2. DNS設定の変更履歴を記録 DNS設定を変更する際には、変更内容、変更日時、変更者を記録します。トラブル発生時に、いつ何を変更したかを追跡できます。

3. 短いTTLでの移行準備 サーバー移行やIPアドレス変更の際には、事前にTTLを短く設定（例: 300秒）し、変更が迅速に反映されるようにします。移行完了後は、TTLを元に戻します。

SSL証明書の運用

1. 証明書の有効期限を監視 有効期限の30日前、7日前にアラート通知を設定します。

2. 自動更新の活用 Let’s Encryptを使用する場合、Certbotの自動更新が正常に動作しているかを定期的に確認します。

3. 証明書の秘密鍵を厳重に管理 SSL証明書の秘密鍵は、絶対に外部に漏らさないでください。秘密鍵が漏洩すると、通信が傍受される可能性があります。

秘密鍵は、サーバー上の安全な場所（例: /etc/ssl/private/、パーミッション600）に保管します。

失敗しやすいポイント

ドメイン・DNS・SSL証明書の管理で、中小企業が陥りがちな失敗パターンを紹介します。

1. ドメインの更新忘れ

ドメインの更新を忘れ、失効してしまうケースがあります。Webサイトにアクセスできなくなり、メールも受信できなくなります。

対策

自動更新を有効にする
更新期限の1〜2か月前にアラート通知を設定
重要ドメインは複数年契約

2. DNS設定ミスによるサービス停止

DNS設定を誤って変更し、Webサイトやメールが使えなくなるケースがあります。

対策

DNS設定変更前に、現在の設定をバックアップ
変更後、digやnslookupで動作確認
重要な変更は、事前にTTLを短く設定し、問題があればすぐ戻せるようにする

3. SSL証明書の有効期限切れ

SSL証明書の更新を忘れ、有効期限が切れてしまうケースがあります。ブラウザに「安全でない接続」と表示され、顧客の信頼を損ないます。

対策

有効期限を監視し、アラート通知
Let’s Encryptの自動更新を活用
商用証明書の場合、更新案内メールを見逃さない

4. 秘密鍵の紛失

SSL証明書の秘密鍵を紛失し、証明書の更新ができなくなるケースがあります。

対策

秘密鍵を安全な場所にバックアップ
バックアップは暗号化して保管

5. WHOIS情報の連絡先メールアドレスが無効

ドメインのWHOIS情報に登録されたメールアドレスが、退職者のものだったり、無効になっていたりするケースがあります。レジストラからの重要な通知を受け取れません。

対策

WHOIS情報の連絡先を定期的に確認し、最新に保つ
個人のメールアドレスではなく、部門の共有アドレス（例: admin@example.com）を使用

導入事例: ドメイン・SSL証明書の統合管理

ここでは、複数のドメインとSSL証明書を統合管理した事例を紹介します。

企業プロフィール

業種: マーケティング支援業 従業員数: 50名 保有ドメイン数: 15ドメイン（自社サイト、顧客向けキャンペーンサイトなど） IT体制: 情報システム担当1名、Web担当2名

課題

同社は、複数のキャンペーンサイトを運営しており、ドメインとSSL証明書の管理が煩雑になっていました。

15個のドメインが3つのレジストラに分散
SSL証明書も複数のベンダーから購入しており、更新時期がバラバラ
過去に1度、ドメインの更新を忘れてキャンペーンサイトが停止
SSL証明書の有効期限切れでサイトに「安全でない」と表示される事故が発生

担当者が退職した際に、引き継ぎが不十分で、どのドメインがどこで管理されているかが不明になる事態も発生しました。

導入内容

1. レジストラの統一 全15ドメインを、AWS Route 53に移管しました。Route 53を選んだ理由は、AWSでWebサーバーを運用しており、DNSも統合管理できるためです。

2. DNSホスティングの統一 全ドメインのDNSをRoute 53で管理し、設定を一元化しました。

3. SSL証明書の統一 Let’s Encryptに統一し、全サイトでHTTPS化を実施しました。Certbotの自動更新により、更新忘れのリスクを排除しました。

一部の企業向けサイト（OV証明書が必要）のみ、商用SSL証明書（DigiCert）を継続利用しました。

4. 管理台帳の作成 全ドメインとSSL証明書の情報を、Googleスプレッドシートで一元管理しました。

台帳には以下の情報を記載：

ドメイン名
レジストラ
更新期限
用途（自社サイト、キャンペーンサイトなど）
SSL証明書の種類（Let’s Encrypt、DigiCert）
証明書の有効期限
担当者

5. 有効期限の監視 AWS CloudWatchで、SSL証明書の有効期限を監視し、30日前、7日前にSlackに通知する設定を行いました。

ドメインの更新期限も、Googleカレンダーに登録し、1か月前にアラート通知を設定しました。

成果

管理の一元化 全ドメインとSSL証明書をRoute 53とLet’s Encryptに統一したことで、管理が大幅に簡素化されました。どのドメインがどこで管理されているかが一目瞭然になり、引き継ぎもスムーズになりました。

更新忘れの防止 SSL証明書はLet’s Encryptの自動更新により、更新忘れのリスクがなくなりました。ドメインも、Googleカレンダーでのアラート管理により、更新漏れが発生しなくなりました。

コスト削減 15ドメインのSSL証明書を商用証明書で購入していた場合、年間約30万円のコストがかかりますが、Let’s Encryptに統一したことで、OV証明書の3ドメイン分（年間約12万円）を除き、コストがゼロになりました。

運用のポイント

管理台帳を月次で更新し、新規ドメインの追加や不要ドメインの削除を記録するルールを確立しました。また、担当者が変更になった際には、台帳の引き継ぎを必ず行うようにしました。

まとめ

ドメイン、DNS、SSL証明書は、Webサイトや業務システムの基盤となる重要な要素です。本記事のポイントをまとめます。

ドメイン管理

自動更新を有効にして更新忘れを防止
レジストラを統一し、管理を一元化
重要ドメインは複数年契約

DNS設定

ドメイン名をIPアドレスに変換する仕組み
Aレコード、CNAME、MX、TXTなどのレコードを適切に設定
DNS設定変更時は、TTLを短くして迅速に反映

SSL証明書

全てのWebサイトでHTTPSを使用
中小企業はLet’s Encryptで十分、金融機関などはOV/EV証明書
自動更新を活用し、有効期限切れを防止

運用のポイント

管理台帳で一元管理
有効期限を監視し、アラート通知
秘密鍵を厳重に管理

ドメインやSSL証明書の管理は、一度仕組みを整えれば、日常的な手間はほとんどかかりません。最初にしっかりと基盤を整え、自動化できる部分は自動化することで、安定したWeb運用が可能になります。

ドメイン・DNS・SSL証明書の管理ガイド｜Web運用の基礎知識