ドメイン名、DNS、HTTPS
はじめに
ブラウザに www.google.com と入力して Enter キーを押したとき、裏側では何が起こっているのか？ この一見シンプルな動作の背後には、ドメイン名解決、DNS クエリ、TLS 暗号化ハンドシェイクなどの一連の精密な連携プロセスが含まれています。これらの仕組みを理解することは、すべての開発者にとって必修科目です——ウェブサイトにアクセスできるかどうか、データが傍受されるかどうかに直結するからです。
この記事で学べること
この章を終えると、次のことが身につきます：
- DNS の原理：ドメイン名が IP アドレスに翻訳される完全なプロセスを理解
- レコードタイプ：A、CNAME、MX などの一般的な DNS レコードの用途を習得
- HTTPS の仕組み：TLS ハンドシェイクがどのように安全な接続を確立するかを理解
- 証明書システム：デジタル証明書の信頼チェーンと検証メカニズムを理解
- セキュリティ意識：HTTPS がなぜモダンウェブのベースライン要件なのかを理解
| 章 | 内容 | コア概念 |
|---|---|---|
| 第1章 | DNS 解決 | 再帰クエリ、反復クエリ |
| 第2章 | DNS レコード | A、CNAME、MX、TXT |
| 第3章 | HTTPS と TLS | ハンドシェイクプロセス、暗号化通信 |
| 第4章 | 証明書信頼チェーン | CA、ルート証明書、中間証明書 |
| 第5章 | HTTP vs HTTPS | 平文 vs 暗号化、セキュリティ比較 |
0. 全体像：ドメイン名から安全な接続まで
インターネットの通信は IP アドレス（142.250.80.46 など）に基づいていますが、人間はこれらの数字を覚えられません。そこでドメイン名システム（DNS）が発明されました——人間が読めるドメイン名を機械が読める IP アドレスに翻訳する、インターネットの「電話帳」です。
しかし、サーバーを見つけるだけでは不十分です。通信内容が平文で送信されている場合、中間者は誰でもデータを傍受または改ざんできます。HTTPS がこの問題を解決します——HTTP の上に TLS 暗号化のレイヤーを追加し、転送中のデータの機密性と完全性を確保します。
完全なウェブページアクセスの流れ
- ドメイン解決：ブラウザが DNS に「www.google.com の IP は？」と尋ね、DNS が「142.250.80.46」と回答
- TCP 接続：ブラウザがサーバーと TCP の3ウェイハンドシェイクを確立
- TLS ハンドシェイク：双方が暗号化アルゴリズムを交渉し、証明書を検証し、鍵を交換
- 暗号化通信：すべての HTTP データが暗号化チャネルを通じて転送
1. DNS 解決：インターネットの「電話帳」
DNS（Domain Name System）は電話帳を調べるような仕組みです：相手の名前（ドメイン名）を知っていて、相手の電話番号（IP アドレス）を調べる必要があります。しかし、インターネットの「電話帳」は1冊ではなく、階層的な分散システムです。
🔍 DNS Resolution Simulator
DNS 解決の4つのステップ
- ブラウザキャッシュ：まずローカルキャッシュを確認。以前このドメインにアクセスしたことがあれば、キャッシュされた IP を直接使用
- 再帰リゾルバ：キャッシュにない場合、リクエストが ISP の再帰リゾルバ（8.8.8.8 など）に送られる
- 段階的クエリ：再帰リゾルバがルートネームサーバー → トップレベルドメインサーバー（.com） → 権威ネームサーバー（google.com）の順に問い合わせ
- 結果の返却：権威サーバーが最終 IP を返し、再帰リゾルバが結果をキャッシュしてブラウザに返却
| レベル | サーバー | 責任 | 数量 |
|---|---|---|---|
| ルート | Root Server | すべてのトップレベルドメインのアドレスを知っている | 世界に13グループ |
| トップレベルドメイン | TLD Server | .com、.cn、.org などを管理 | サフィックスごとに1グループ |
| 権威 | Authoritative | 特定のドメインの DNS レコードを保存 | ドメインごとに最低2つ |
| 再帰リゾルバ | Resolver | ユーザーに代わってクエリプロセス全体を完了 | ISP またはパブリック DNS |
2. DNS レコードタイプ：ドメイン名の背後にある「設定テーブル」
DNS は単にドメイン名を IP に翻訳するだけではありません。異なるタイプの DNS レコードを通じて、メール配信、ドメインリダイレクト、サービスディスカバリーなどのさまざまな動作を制御できます。これらのレコードタイプを理解することは、ドメイン名の設定とネットワークのトラブルシューティングの基礎となります。
📋 DNS Record Type Cheatsheet
Maps a domain name to an IPv4 address. This is the most common DNS record type and is ultimately what browsers need when visiting a site.
example.com. IN A 93.184.216.34- Point a website domain to a server IP
- Point subdomains to different servers
- Return multiple IPs for load balancing
| レコードタイプ | 用途 | 例 |
|---|---|---|
| A | ドメイン → IPv4 アドレス | example.com → 93.184.216.34 |
| AAAA | ドメイン → IPv6 アドレス | example.com → 2606:2800:220:1:... |
| CNAME | ドメイン → 別のドメイン（エイリアス） | www.example.com → example.com |
| MX | メールサーバーの指定 | example.com → mail.example.com |
| TXT | テキスト情報の保存 | SPF 検証、ドメイン所有権の検証 |
| NS | 権威ネームサーバーの指定 | example.com → ns1.example.com |
実際のシナリオでの DNS 設定
- ウェブサイトのデプロイ：サーバー IP を指す A レコードを追加、または CDN ドメインを指す CNAME を追加
- メールの設定：メールサーバーを指す MX レコードを追加、スパム対策の SPF/DKIM 用 TXT レコードを追加
- ドメイン所有権の確認：クラウドプロバイダーが特定の TXT レコードの追加を要求し、ドメインの所有を証明
- 負荷分散：同じドメインに複数の A レコードを設定し、DNS ラウンドロビンでトラフィックを分散
3. HTTPS と TLS：データに「防弾チョッキ」を着せる
HTTP プロトコルのデータは平文で送信されます——絵はがきを送るようなもので、郵便配達員（中間者）が自由に内容を読めます。HTTPS は HTTP の上に TLS（Transport Layer Security）暗号化のレイヤーを追加します——絵はがきを密閉された封筒に入れるようなものです。
TLS ハンドシェイクは安全な接続を確立するための重要なステップであり、データの本格的な転送を開始する前に、身元確認と鍵の交渉を完了します。
🤝 TLS Handshake Demo
TLS 1.3 ハンドシェイクのコアステップ
- Client Hello：クライアントがサポートする暗号化アルゴリズムのリストと乱数を送信
- Server Hello：サーバーが暗号化アルゴリズムを選択し、デジタル証明書と乱数を返却
- 証明書の検証：クライアントがサーバーの証明書が信頼できるかを検証（CA 署名、有効期間、ドメイン一致を確認）
- 鍵交換：双方が ECDHE アルゴリズムを通じて共有鍵を交渉（鍵自体はネットワーク上で送信されない）
- 暗号化通信：以降のすべてのデータが交渉された共通鍵で暗号化されて転送
| 特徴 | TLS 1.2 | TLS 1.3 |
|---|---|---|
| ハンドシェイクの往復回数 | 2-RTT | 1-RTT（初回）/ 0-RTT（再開） |
| 鍵交換 | RSA または ECDHE | ECDHE のみ（前方秘匿性） |
| 暗号スイート | 多くのレガシーアルゴリズムをサポート | 安全なアルゴリズムのみ保持 |
| パフォーマンス | やや遅い | より高速 |
4. 証明書信頼チェーン：なぜこのウェブサイトを信頼できるのか？
TLS ハンドシェイクで最も重要なステップは「証明書の検証」です。ブラウザはどうやってウェブサイトの証明書が本物かどうかを判断するのでしょうか？攻撃者が偽造したものではないかどうかは？答えは証明書信頼チェーン——各レベルで保証する仕組みです。
🔗 Certificate Trust Chain
Click each certificate layer to inspect its details and role in the trust chain.
証明書信頼チェーンの3層構造
- ルート証明書（Root CA）：信頼された認証局によって発行され、オペレーティングシステムやブラウザにプリインストールされています。これが信頼の「アンカー」です。
- 中間証明書（Intermediate CA）：ルート CA によって発行され、エンドエンティティ証明書の発行に使用されます。ルート CA が直接ウェブサイトの証明書を発行しないのは、セキュリティ上の分離のためです。
- エンドエンティティ証明書（Leaf Certificate）：ウェブサイトが実際に使用する証明書で、中間 CA によって発行され、ドメイン名、公開鍵、有効期間などの情報が含まれています。
| 証明書タイプ | 検証レベル | 発行速度 | 使用ケース |
|---|---|---|---|
| DV（ドメイン検証） | ドメインの所有権のみ検証 | 分単位 | 個人ウェブサイト、ブログ |
| OV（組織検証） | 組織の身元を検証 | 数日 | 企業の公式サイト |
| EV（拡張検証） | 厳格な身元検証 | 数週間 | 銀行、金融機関 |
| ワイルドカード証明書 | すべてのサブドメインをカバー | タイプによる | 複数サブドメインのシナリオ |
5. HTTP vs HTTPS：なぜ暗号化がベースラインなのか
2024年、世界のウェブトラフィックの95%以上が HTTPS を通じて転送されています。Chrome ブラウザは HTTP ウェブサイトに「保護されていません」という警告を表示し、検索エンジンも HTTP ウェブサイトのランキングを下げます。HTTPS はもはや「オプション」ではなく、モダンウェブのベースライン要件です。
🔐 HTTP vs HTTPS Data Transfer
password=MySecret123&user=zhangsan| Item | HTTP | HTTPS |
|---|---|---|
| Port | 80 | 443 |
| Data encryption | None (plaintext) | TLS symmetric encryption |
| Identity verification | None | CA certificate verifies server identity |
| Data integrity | No guarantee | MAC check prevents tampering |
| SEO impact | Search engines may rank it lower | Preferred by search engines |
| Performance cost | No extra overhead | TLS handshake adds about 1-2 RTT |
| 側面 | HTTP | HTTPS |
|---|---|---|
| データ転送 | 平文、傍受可能 | 暗号化、傍受不可 |
| 身元確認 | なし、サーバーの身元を確認できない | あり、証明書によるサーバー検証 |
| データの完全性 | 保護なし、改ざん可能 | 保護あり、改ざんが検出される |
| ポート | 80 | 443 |
| SEO への影響 | 検索ランキングが低下 | 検索ランキングが向上 |
| ブラウザの表示 | 「保護されていません」警告を表示 | 鍵アイコンを表示 |
無料で HTTPS 証明書を取得する
Let's Encrypt は、無料で自動化された認証局であり、どのウェブサイトでもゼロコストで HTTPS を有効にできます。Certbot ツールと組み合わせることで、ワンクリックで証明書の申請と自動更新が可能です。ほとんどのクラウドプラットフォームや CDN プロバイダーも無料の SSL 証明書を提供しています。
まとめ
ドメイン名、DNS、HTTPS はインターネットインフラの3つの柱です。DNS により人間が読める名前でウェブサイトにアクセスでき、HTTPS により通信プロセスが安全で信頼できるものになります。
この章の重要ポイントを振り返ります：
- DNS は階層型システム：ルート → トップレベルドメイン → 権威、段階的にクエリし、キャッシュで高速化
- レコードタイプにはそれぞれ用途がある：A レコードは IP を指し、CNAME はエイリアスを作成、MX はメールを管理、TXT は検証に使用
- TLS ハンドシェイクが信頼を確立：証明書の検証 + 鍵の交渉、TLS 1.3 はわずか 1-RTT
- 証明書信頼チェーン：ルート CA → 中間 CA → リーフ証明書、各レベルで保証
- HTTPS はベースライン：無料証明書（Let's Encrypt）により暗号化のハードルはゼロ
参考文献
- How DNS Works - コミック形式で DNS の仕組みを解説
- Let's Encrypt ドキュメント - 無料 SSL 証明書の申請ガイド
- Cloudflare Learning Center - DNS とネットワークセキュリティのチュートリアル
- TLS 1.3 RFC 8446 - TLS 1.3 プロトコル仕様
- SSL Labs - オンラインで HTTPS 設定の品質をチェック