Webインフラの基礎知識：DNSレコードの仕組みとSSL/TLS暗号化通信

本業でDX支援を行う中で、インフラのトラブルシューティングにおいて最も頻出するネットワーク知識が「DNS（ドメイン・ネーム・システム）」と「SSL/TLS（通信の暗号化）」です。

今回は、当ブログ（blog.hiscalm.com）の立ち上げの舞台裏で行われていた、DNSレコードの設定とセキュリティ認証の仕組みについて技術的にまとめます。

DNS（Domain Name System）とは：インターネットの世界の電話帳

コンピューターは、インターネット上でお互いを探し出す際、192.0.2.1 のような数字の羅列である「IPアドレス」を使います。しかし、人間にとって数字の羅列は覚えにくいため、hiscalm.com のような文字列（ドメイン）を使います。

この**「ドメインをIPアドレスに翻訳する世界共通の巨大な電話帳システム」**がDNSです。

DNSに登録する情報（レコード）にはいくつかの種類がありますが、個人開発や企業のインフラ構築で必ず登場するのが以下の2つです。

1. Aレコード (Address Record)

ドメインに対して、直接「物理的なサーバーのIPアドレス（IPv4）」をガチッと紐付ける最も基本的なレコードです。

2. CNAMEレコード (Canonical Name Record)

ドメインに対して、IPアドレスではなく「別のドメイン（別名）」を紐付けます。

今回、当ブログはCNAMEを使ってVercelのサーバーにURLの行き先を丸投げしています。これを行うことで、Vercel側のサーバーのIPアドレスが急に変わったとしても、Vercel側が自動で別名の先をコントロールしてくれるため、こちらの設定を書き換える必要がなくなるという強力なメリットがあります。

Cloudflare × Vercel で起きた「Invalid Configuration」の裏側

CloudflareでDNSを管理する際、レコードの横に「オレンジの雲（プロキシON）」と「グレーの雲（DNSのみ）」の切り替えスイッチがあります。

プロキシをONにすると、Cloudflareが通信の「身代わり」となってセキュリティを高めたりキャッシュを効かせたりしてくれます。一見すると良い機能に思えますが、Vercelと組み合わせる初学者が必ずと言っていいほど「Invalid Configuration（認証エラー）」の沼にハマる原因になります。

なぜプロキシをOFFにする必要があるのか？

Vercelは、設定されたドメイン（blog.hiscalm.com）が、本当に自分が指定した暗号ドメインをまっすぐ向いているかを厳しくチェックします。

もしCloudflareのプロキシがONになっていると、Vercelから見た時に「ドメインの行き先が、CloudflareのIPアドレスになっていてうちを向いていない！」と勘違いしてしまいます。その結果、通信を暗号化するための**「SSL/TLS証明書」の自動発行・更新プロセスがストップ**してしまい、サイトが「保護されていない通信」のままエラーになってしまいます。

これを防ぐために、あえてプロキシをOFF（グレーの雲）にし、Cloudflareを純粋な「住所の案内所（DNS）」としてだけ機能させることが、モダンなインフラ構成における鉄板の正解となります。

まとめ

データパイプラインをクラウド上に構築していくフェーズ2以降において、APIサーバー（FastAPI）やデータベース（Supabase）との通信経路をセキュアに保つためにも、このDNSとSSLの基礎知識は絶対的な土台となります。エラーが起きた時に「今、通信のどのレイヤーで問題が起きているか」を構造的に見極める眼を養っていきます。