DNSを久しぶりに触ったら、10年エンジニアでも曖昧だったことに気づいた話

新しく作ったサービス「DevLoopRunner」をインターネットに公開して、Google Search Consoleに登録しようとしたときのことです。

DNS設定の画面を開いて、ふと手が止まりました。

「Host Nameって、何を入れるんだっけ……？」

正直に言います。10年エンジニアをやっていても、DNSは触る頻度が少ないから忘れます。

インフラ寄りの仕事をしていた時期もあったし、Route 53の設定も何度かやったことはある。でも、毎日触るものじゃない。だから、いざ久しぶりに触ると「あれ、これどうだったっけ」となる。

今回、ChatGPTと対話しながらDNSの知識を再整理したので、その過程を残しておきます。同じように「なんとなく知ってるけど曖昧」という人の参考になれば。

きっかけ：Search Consoleの「ドメインプロパティ」登録

Google Search Consoleでサイトを登録するとき、「ドメインプロパティ」を選ぶとDNSのTXTレコードを設定するよう求められます。

画面には認証用の文字列が表示されていて、これをDNSに登録すればOK。

……なんだけど、「Host Name」に何を入れるかで詰まりました。

結論：Host Nameは「@」または空欄

答えはシンプルでした。

項目	設定
Type	TXT
Host	@（または空欄）
Value	google-site-verification=xxxx…
TTL	デフォルト

「@」は、そのDNSゾーンのルート（ドメインそのもの）を表します。

たとえば example.com というドメインを管理しているなら、@ = example.com です。

よくあるミス

Hostに example.com と書く → example.com.example.com になってしまう
www を指定する → これはサブドメイン用

ここ、意外と罠です。

「@」の意味をちゃんと理解する

恥ずかしながら、「@」の意味を正確に理解していませんでした。

DNSの管理画面では、こういう計算が行われています。

Host + Zone = FQDN（完全修飾ドメイン名）

つまり：

Host: @ → example.com.（ルート）
Host: www → www.example.com.
Host: example.com → example.com.example.com.（これは意図しない結果）

「@」は「ルートそのもの」を指す記号。これを知っているだけで、DNS設定の見え方が変わります。

レコードの種類を整理する

ついでに、レコードの種類も再整理しました。

全部覚える必要はありません。実務で使うのは8〜10種類程度です。

よく使うもの

レコード	役割	覚え方
A	ドメイン → IPv4アドレス	Address
AAAA	ドメイン → IPv6アドレス	-
CNAME	別名を作る	Canonical Name
TXT	設定・認証用（何でも帳）	Text
MX	メールの配送先	Mail eXchange

あまり触らないもの

レコード	役割
NS	DNS管理者（通常は触らない）
SOA	DNSゾーンの基本情報（自動管理）
SRV	サービス探索（ポート含む）
CAA	証明書発行制御

TXTレコードは「何でも帳」という表現がしっくりきました。Search Console、SPF、DKIM、DMARC、SaaS連携……いろんな用途で使われます。

[📦 商品リンク: moshimo-book-dns-textbook]

[📦 商品リンク: moshimo-book-server-infra]

wwwとルート、両方登録する理由

Webサービスで example.com と www.example.com の両方を登録するのはなぜか。

これも、なんとなく知っていたけど曖昧でした。

歴史的背景

昔のインターネットでは、用途ごとにサブドメインを分けていました。

www.example.com  → Web
ftp.example.com  → FTP
mail.example.com → メール

www は「World Wide Web」の略で、Webサーバー用のサブドメインだったわけです。

今でもwwwを使う理由

ルートにはCNAMEが置けなかった（技術的制約）
CDN・SaaS連携が楽（CNAMEで向き先を変えやすい）
Cookieスコープの制御

実務での正解パターン

https://example.com      ← 正規URL
https://www.example.com  → 301リダイレクト

逆でもOK。重要なのは「正規URLを1つに決めること」。

Googleから見ると、example.com と www.example.com は別サイト扱いです。だから、canonical設定や301リダイレクト、Search Console登録が必要になる。

ここ、意外とここが肝です。

[📦 商品リンク: moshimo-book-aws-operations]

DNS実務チェックリスト

最後に、DNSで事故らないためのチェックリストも整理しておきます。

1. DNSは即時反映されない

世界中にキャッシュがあるので、変更がすぐに反映されるとは限りません。TTL（300秒、3600秒、86400秒など）を意識する。

2. 変更は段階的に

❌ いきなり削除
⭕ 追加 → 確認 → 削除

消す前に足す。これ、基本です。

3. ルート（@）は特別

CNAMEは原則置けない
ALIAS / ANAMEは事業者独自の拡張機能

4. TXTは増え続ける

複数のTXTレコードを置けます。ただし、SPFは1行にまとめる必要があります。

5. メール系は慎重に

最低限必要なもの：

MX
SPF
DKIM
DMARC

メールはDNS設定をミスると届かなくなるので、慎重に。

6. DNSは名前解決だけ

HTTPS、ポート、リダイレクトはDNSの仕事ではありません。

7. 切り分けコマンド

dig example.com
dig TXT example.com
nslookup example.com

困ったときはこれで確認。

8. DNSは最後の砦

DNSが死ぬと、Web、API、メール、すべて止まります。

まとめ

DNSは「分かると地味、分からないと地獄」な基盤技術です。

10年エンジニアをやっていても、触る頻度が少ないから忘れる。「@」の意味も、wwwの歴史的経緯も、なんとなく知っていたけど曖昧だった。

今回、ChatGPTと対話しながら知識を再整理できたのは良かったなと感じています。

覚えておくべきことは、実はそんなに多くない。

@ = ルート
A / CNAME / TXT / MX
TTLを意識
消す前に足す
正規URL統一
メールは慎重

これだけ押さえておけば、実務では困らないはずです。

[📦 商品リンク: moshimo-sasaeru-banner-728x90]