まず考え方を理解し、次のアクティビティで確認しましょう。
レコード、リゾルバ、そして参照の順序
リゾルバが実際に何をどの順序で参照するか、出会うことになるレコードタイプ、そしてなぜ同じ名前があるホストでは解決し別のホストでは失敗するのかを学びます。
できるようになること
- 一般的なレコードタイプと、それぞれが何に答えるかを挙げる
- キャッシュ、hostsファイル、設定済みリゾルバの順で参照をたどる
- なぜ2つのホストが同じ名前について食い違うことがあるのかを説明する
この前に: 基本的な考え方については「DNS - 名前をアドレスに変える」が、リゾルバのアドレスは通常リースの中で届くためDHCPのレッスンも必要です。
重要な理由: 「自分のマシンでは動く」はほとんどの場合、2つのホストの間で異なるDNSの答え - キャッシュされたレコード、hostsファイルのエントリ、あるいは別のスコープが払い出した別のリゾルバ - が原因です。参照の順序を知ることで、それは謎ではなく確認すべき3つの項目に変わります。
リゾルバは最初からDNSサーバーに問い合わせるわけではありません。決まった順序でいくつかの場所を調べ、最初に得た答えで止まります。分かりにくいDNS障害の多くは、どこから答えを得たかの違いに起因します。
知っておきたいレコードタイプ
| タイプ | 答える内容 | 主な用途 |
|---|---|---|
| A | 名前からIPv4アドレス | 日常的な名前解決 |
| AAAA | 名前からIPv6アドレス | IPv6での同様の名前解決 |
| CNAME | 名前から別の名前 | 移転に追従するエイリアス |
| MX | ドメインからメールホスト | メールの配送先 |
| PTR | アドレスから名前 | 逆引きとログ記録 |
| NS | ゾーンから担当サーバー | ゾーン間の委任 |
名前解決で調べる順序
- アプリケーションが保持していれば、そのアプリケーション自身のキャッシュ。
- OSのリゾルバキャッシュ - まだ有効期限が切れていない過去の答え。
- ローカルで静的なhostsファイル - ネットワークへの問い合わせより優先されます。
- 設定済みのリゾルバ - 通常はDHCPリースで配布されたもの。
この4つのうち2つはホストごとに異なる状態です。隣り合うマシンで同じ名前の解決結果が違う理由は、キャッシュに古い答えが残っているか、誰かが2年前にhostsファイルに記した行を忘れているからです。
2台のホスト、1つの名前、2つの答え
在庫システムが予定どおり新しいアドレスに移り、Aレコードが更新されます。その名前を初めて調べるホストは、すぐに新アドレスを受け取ります。のマシンは切り替えの1時間前にその名前を調べており、TTLが1日だったため、残りの一日は古いアドレスを使い続けます。周囲は正常に作業できるのに、彼には在庫システムが停止したように見えます。
TTLは古い情報が残る期間を決める
各レコードにはTTLがあります。リゾルバが再問い合わせするまで答えを保持できる時間です。長いTTLは問い合わせ負荷を減らす一方、変更の反映を遅くします。短いTTLはその逆です。計画的な変更の前にTTLを下げておけば、切り替えを素早く反映できます。
重要なポイント
- リゾルバはキャッシュ、hostsファイル、設定済みサーバーの順に調べ、最初の答えで止まります。
- そのうち2つはホストごとの状態なので、ホスト間で答えが異なることがあります。
- CNAMEはアドレスではなく名前を返します。この間接参照により、切り替えを少ない変更で実現できます。
- TTLは古い答えが残る期間を決めます。計画的な変更の最中ではなく、事前に下げます。
続ける準備はできましたか?
無料アカウントを作成すると、進捗を保存して理解度チェックを受けられます。