「IPアドレスが変わりました」で騒がないために
こんにちは！「リナックス先生」です。
BIND9講座、第6回へようこそ。
これまでは「正引き」「逆引き」「冗長化」と、インフラエンジニア目線での構築をしてきました。
しかし、DNSサーバーの主な利用者は誰でしょうか？
そう、Webサイトを作る「Web担当者」や、アプリケーションを作る「開発者」たちです。
彼らはよくこんな無茶振…いえ、相談をしてきます。
「キャンペーン用のサイト、今のWebサーバーと同じ場所でいいから campaign.kou-house.lan って名前で作ってよ」
「WebサーバーのIPが変わるかもしれないから、DNS側でうまくやっといてよ」
いちいちAレコード（IPアドレス）を設定していたら、IP変更のたびにDNS設定も修正しなければならず、管理がパンクします。
そんな時に使うのが、既存の名前に「あだ名」をつける **CNAME（シーネーム）** レコードです。
先生、「あだ名」って便利そうですね！
IPアドレスを書かなくていいなら、全部CNAMEにしちゃえば楽なんじゃないですか？
IPが変わっても勝手についていくわけだし。
コウ君、それは甘い罠よ。
CNAMEは確かに便利だけど、使いすぎると「名前解決の回数」が増えて表示が遅くなるし、何よりDNSには「あだ名をつけてはいけない場所」という絶対的なルールがあるの。
今日はプロでも間違えるその「禁忌」について詳しく話すわね。
1. CNAMEレコード（別名）の基本
まずは基本から。CNAME（Canonical Name）は、あるドメイン名を別のドメイン名に転送するためのレコードです。
1-1. 書式と仕組み
ゾーンファイル（/var/named/kou-house.lan.db）に以下のように記述します。
; 書式: [別名] IN CNAME [本名] web IN CNAME host1
この状態で web.kou-house.lan にアクセスすると、以下のような処理が行われます。
- ユーザー：「web のIP教えて！」
- DNS：「web は host1 の別名だよ。host1 のIPを調べてね」
- ユーザー：「じゃあ host1 のIP教えて！」
- DNS：「host1 は 192.168.1.10 だよ」
つまり、2回問い合わせが発生します。
Aレコードなら1回で済むため、パフォーマンスの観点からは「無闇に多用しない」のが原則です。
1-2. どんな時に使うのか？
パフォーマンスが落ちてでもCNAMEを使うべきシーンは以下の通りです。
- 外部サービスを利用する場合：
「ブログは外部のサービス（例:ghs.google.com）を使いたい」といった場合、相手のIPアドレスは頻繁に変わるため、Aレコードでは追従できません。CNAMEなら相手の名前を指定するだけなので追従可能です。 - 役割ごとに名前を変えたい場合：
実体は1台のサーバーでも、ftp、mail、wwwといった機能別の名前を付けておけば、将来サーバーを分割する時にDNSの向き先を変えるだけで済みます。
2. 【重要】Zone Apex（ルート）問題
ここが今回の最重要ポイントです。
「ドメインそのもの（kou-house.lan）」のことを、専門用語で Zone Apex（ゾーン・エイペックス） と呼びます。
DNSの仕様（RFC）には以下の鉄則があります。
「CNAMEレコードは、他のレコードと同居できない」
どういうことか？
ドメインのルート（kou-house.lan）には、必ず以下の2つのレコードが存在します。
- SOAレコード： ゾーンの管理情報
- NSレコード： ネームサーバー情報
これらは必須です。絶対に消せません。
ここに CNAME を書こうとするとどうなるでしょう？
; これはエラーになります！ @ IN SOA ... @ IN NS ... @ IN CNAME other-server.lan. ; ← SOAやNSと同居しようとしている！
「CNAMEは他のレコードと同居できない」というルールに違反するため、BINDはエラーを出して起動しません。
つまり、「ドメイン名そのもの（kou-house.lan）には、絶対にCNAMEを設定できない」のです。
Web担当者が泣くパターン
よくあるトラブルがこれです。
- Web担当： 「
www.kou-house.lanはCNAMEで外部のクラウドに向けました。これでOK！」 - Web担当： 「あ、
wwwなしのkou-house.lanでもアクセスできるようにしたいから、そっちもCNAMEでクラウドに向けてください」 - あなた： 「（DNSの仕様で）できません」
- Web担当： 「えっ、なんで？ 他の会社はできてるよ？」
解決策
Zone Apex（ルート）に関しては、CNAMEを使わず、必ず Aレコード（IPアドレス）で指定する必要があります。
外部サービス（HerokuやAWS ELBなど）を使っていてIPが固定できない場合は、Webサーバー側で www ありにリダイレクトさせるなどの回避策が必要になります。
※最近のクラウドDNS（AWS Route53のAliasなど）では独自拡張でこれを可能にしていますが、BIND標準の機能ではNGです。基本を知っておきましょう。
3. 魔法の指定「ワイルドカード」
次は、もっと柔軟な設定です。
「どんなサブドメインが来ても、とりあえず全部このIPに飛ばしたい」という場合に使います。
3-1. 書式
アスタリスク * を使います。
* IN A 192.168.1.20
こう書いておくと、test.kou-house.lan でも abc.kou-house.lan でも、定義されていない名前はすべて 192.168.1.20 に解決されます。
3-2. 優先順位のルール
「ワイルドカードを書いたら、個別に設定したレコードはどうなるの？」と心配になるかもしれません。
安心してください。DNSには「明示的に書かれたレコードが優先される」というルールがあります。
; 個別の定義 www IN A 192.168.1.10 ; ワイルドカード * IN A 192.168.1.20
この場合、www.kou-house.lan は 1.10 になり、それ以外の blog.kou-house.lan などは 1.20 になります。
4. 【実践】設定ファイルへの記述
それでは、実際にマスターサーバーの設定ファイル（/var/named/kou-house.lan.db）を編集して、CNAMEとワイルドカードを追加してみましょう。
sudo vi /var/named/kou-house.lan.db
▼追記する内容
; 既存の設定の下に追加 ; CNAMEの設定 ; ftp.kou-house.lan は ns1 (192.168.1.10) の別名 ftp IN CNAME ns1 ; ワイルドカードの設定 ; 未定義のサブドメインはすべて Webサーバー(1.10) へ * IN A 192.168.1.10 ; 【実験】Zone Apex に CNAME は書けないので Aレコードにする ; @ IN CNAME ns1 ; ← これはエラーになる！ @ IN A 192.168.1.10
【忘れずに！】
ファイルを修正したので、SOAレコードのシリアル番号を必ず増やしてください。
反映と確認
sudo named-checkzone kou-house.lan /var/named/kou-house.lan.db sudo systemctl reload named
5. 動作テスト
dig コマンドで挙動を確認します。
CNAMEの確認
dig @127.0.0.1 ftp.kou-house.lan
▼結果の注目点
;; ANSWER SECTION: ftp.kou-house.lan. 86400 IN CNAME ns1.kou-house.lan. ns1.kou-house.lan. 86400 IN A 192.168.1.10
ANSWERセクションが2行になっています。
「ftp は ns1 だよ」「ns1 は 1.10 だよ」と、たらい回しされている様子が見えますね。
ワイルドカードの確認
存在しない適当な名前で引いてみます。
dig @127.0.0.1 random-name.kou-house.lan
ワイルドカードで指定したIPアドレス（192.168.1.10）が返ってくれば成功です！
なるほど！
ワイルドカードを使えば、「ユーザーごとにサブドメインを配りたい」みたいなサービスも簡単に作れそうですね。
あと、ルートドメインにはCNAMEが書けない理由、SOAとぶつかるからって聞いて納得しました！
6. ワイルドカードの副作用（注意点）
非常に便利なワイルドカードですが、副作用もあります。
- タイプミスに気づけない：
ユーザーがww.kou-house.lan（wが2つ）と打ち間違えても、エラーにならずワイルドカードのIPに繋がってしまいます。「ページが見つかりません」ではなく、トップページが表示されたりするため、混乱を招くことがあります。 - 意図しないレコードも解決される：
mail.kou-house.lanなど、本来メールサーバーとして設定すべき名前も、定義し忘れるとWebサーバーのIPを返してしまいます。重要なホスト名は必ず個別に定義しましょう。
まとめ：名前解決をデザインする
第6回では、DNS運用を柔軟にするテクニックを学びました。
- CNAME は「別名」をつける機能。IP変更に強くなるが、使いすぎは遅延の元。
- Zone Apex（ルートドメイン） には CNAME を設定できない（SOA/NSと競合するため）。
- ワイルドカード（*） は「その他すべて」を引き受ける魔法。
- 個別の定義がワイルドカードより優先される。
これで、Web担当者からの「あんなことしたい」「こんな名前にしたい」という要望にも、技術的な根拠を持って答えられるようになりましたね。
さて、次回（第7回）は、セキュリティに関わる重要な機能「ACL（アクセスコントロールリスト）」を深掘りします。
「社内の特定の部署からしかアクセスさせたくない」「あやしい国からの問い合わせは無視したい」。
そんな高度な制御を行うための設定方法を学びます。お楽しみに！
▼Webサーバーと連携して学ぶVPS
CNAMEやワイルドカードは、実際にApacheやNginxのバーチャルホスト設定と組み合わせてこそ真価を発揮します。Webサーバーも同時に構築して実験できるおすすめVPSはこちら。
コメント