DNSと名前解決の徹底解説:TTL・レコード・セキュリティ対策・運用ベストプラクティスまで網羅
はじめに:名前解決とは何か
「名前解決」は、ヒトにとって覚えやすい名前(例:example.com)をネットワーク上で機械が扱える情報(例:IPアドレスやサービス位置情報)に変換する仕組みです。インターネットや社内ネットワークでサービスを使う際、ユーザーがホスト名やドメイン名を入力するとOSやアプリケーションは名前解決を行い、通信先を特定します。本稿では、DNS(Domain Name System)を中心に、ホストファイルやローカル名解決手法、セキュリティや運用上の注意点までを包括的に解説します。
名前解決の全体像:どのように解決されるか
典型的な名前解決の流れは次の通りです。まずアプリケーション(ブラウザ等)がライブラリを通じてOSのスタブリゾルバ(stub resolver)に照会を行い、スタブはローカルのキャッシュまたは設定された再帰型リゾルバ(recursive resolver)に問い合わせます。再帰型リゾルバは必要に応じてルートサーバー→TLDサーバー→オーソリティブネームサーバーへと問い合わせを辿り、最終的に該当するDNSレコード(A/AAAA/CNAMEなど)を取得して返します。
主要コンポーネント
- スタブリゾルバ:クライアント側の最小限のDNSクライアント。一般にOSに組み込まれています。
- 再帰型リゾルバ(リカーシブリゾルバ):クライアントの代理で名前解決を行い、結果をキャッシュします(例:ISPのDNS、Google Public DNS、Cloudflare 1.1.1.1)。
- オーソリティブネームサーバー:ドメインについて正引き/逆引きの権威を持つサーバー。ゾーンの管理者が運用します。
- ルートネームサーバー:最上位の案内役(ルート)で、TLDサーバーの情報を返します(. , 13組の論理ホスト)。
主要DNSレコードと用途
- A:IPv4アドレスを返す正引きレコード。
- AAAA:IPv6アドレスを返す正引きレコード。
- CNAME:別名(canonical name)。別名から正規名へリダイレクトする。ルート(ゾーンの apex)には置けない制約がある。
- MX:メール交換を示すレコード。優先度(priority)を持つ。
- NS:そのゾーンの権威サーバーを示す。
- SOA:Start Of Authority。ゾーンの管理情報(Serial, Refresh, Retry, Expire, Minimum/Negative TTLなど)を含む。
- PTR:逆引き(IP→名前)に使われるレコード。通常はIPの逆引きゾーン(in-addr.arpa / ip6.arpa)に配置される。
- TXT:任意テキスト。SPF、DKIM、検証情報などで利用。
- SRV:サービスレコード。サービス名とプロトコル、ポート、優先度/重みを定義する(例:_sip._tcp)。
キャッシュとTTL(Time To Live)
DNSレスポンスにはTTLが設定され、再帰リゾルバやOSはその期間レスポンスをキャッシュします。適切なTTL設計は可用性と運用性のバランスです。短いTTLは変更反映が速い一方でキャッシュヒット率を下げ、問い合わせ負荷を増やします。長いTTLは問い合わせ負荷を減らすが、レコード変更時の反映遅延を招きます。
負のキャッシュ(NXDOMAINなどの否定応答)にもTTLがあり、SOAの最小値(negative TTL)に従います(RFC の規定を参照)。また、再帰リゾルバはTTLが残っている応答をそのまま返すため、TTLの設計は重要です。
名前解決の方式:再帰 vs 反復(iterative)
再帰問い合わせでは、リゾルバが最終解答を得るまで他のサーバーへ問い合わせを繰り返し行い、クライアントに返します。反復(または逐次)問い合わせでは、クライアントが各サーバーに直接問い合わせて最終的な権威サーバーを自分で辿ります。インターネットでは、一般的にクライアント→ローカルリゾルバは再帰で、ローカルリゾルバ→他サーバー間は反復的に扱われます。
逆引きとPTRの注意点
逆引き(IP→名前)はPTRレコードで行いますが、IPの所有者(ISP等)が逆引きゾーンを管理するケースが多い点に注意してください。サーバーの正引きと逆引きが一致しないと、一部のメールサーバーで受信拒否されることがあるため、メール運用では合わせるのがベストプラクティスです。
ローカル名前解決:hostsファイル、mDNS、LLMNR、NetBIOS
- hostsファイル:/etc/hosts(Unix)やC:\Windows\System32\drivers\etc\hosts(Windows)などに静的な名前解決を定義。優先順位が高くDNSをバイパスできますが、管理が煩雑になるため多数のホストには向きません。
- mDNS(Multicast DNS):ローカルリンクでの名前解決。.local を使ってゼロコンフィギュレーションでホスト名解決を行う(例:Apple Bonjour、Avahi)。
- LLMNR(Link-Local Multicast Name Resolution):Windows環境でのローカル名解決。セキュリティ上のリスクが指摘されるため、不要なら無効化することが推奨されます。
- NetBIOS名解決:古いWindowsネットワークで使われる名前解決方式。現代ではDNSに移行しているケースが多い。
DNSセキュリティとプライバシー
- キャッシュ汚染(Cache Poisoning):偽の応答をキャッシュさせる攻撃。DNSSECや送信元ポートのランダム化、トランザクションIDの強化で軽減できます(Kaminsky脆弱性以降の対策)。
- DNSSEC:DNS応答に署名を付与し整合性とオリジンを検証する仕組み(RFC4033/4034/4035)。DNSSECは改竄検出に有効ですが、導入と鍵管理、チェーンの構築(ルート→TLD→ドメイン)の運用が必要です。
- DoT(DNS over TLS)/ DoH(DNS over HTTPS):問い合わせの暗号化により、盗聴や中間者攻撃を防ぐ。DoTは専用ポート(853)、DoHはHTTPS上で動作(RFC7858、RFC8484)。プライバシー向上に有効だが、中央集約によるトラッキングや運用上の可視性低下などのトレードオフがある。
- DNSアンプ攻撃:大量の小さなクエリで増幅された応答を踏み台に送信先へDDoSを仕掛ける。オープンリゾルバを放置しないことが重要。
運用・技術的トピック
- ゾーン転送(AXFR/IXFR):セカンダリDNSはゾーン転送でマスターからデータを取得。TSIGなどで認証を行い、安全に運用する必要があります。
- 動的DNS(DDNS):DHCPと連携してホストのIP変更を自動でDNSに反映。社内環境やISPの割当変更に便利ですが、認証と更新制御が重要です。
- 分散・分割DNS(Split-horizon / Split-brain):同じドメイン名に対して内部向けと外部向けで異なる応答を返す構成。セキュリティや構成ミスによる情報漏洩に注意。
- KubernetesとDNS:kube-dns / CoreDNS がクラスタ内サービス名を解決。サービスディスカバリやヘルス状態の反映にDNSが重要な役割を果たします。
- CNAMEの使い方:便利だが、CNAMEは同じ名前に他のレコード(MXなど)と共存できない制約や、エイペックス(example.com)には通常置けない制約がある点に注意。
トラブルシューティングと診断ツール
問題が起きたときは、以下のツールと手順が有効です。
- dig:詳細なクエリモードや権威応答、トレース(+trace)でルートから辿ることができます。
- nslookup:シンプルな名前解決確認に便利。プラットフォームにより挙動が異なるのでdigと合わせて使うと良いです。
- host:A/AAAA/CNAME 等の簡単確認に便利。
- キャプチャツール(tcpdump/Wireshark):DNSパケットを確認してDoT/DoHの利用有無や応答の内容、TCP/UDP切替挙動を調べます。
- ログ確認:リゾルバや権威サーバーのログ(エラー、転送失敗、拒否応答など)を確認します。
ベストプラクティス(運用上の注意)
- DNSサーバーを冗長化し、複数リージョンに分散する。
- ゾーン転送はIP制限とTSIGで保護する。
- 不要なオープンリゾルバを公開しない(リフレクション攻撃対策)。
- DNSSEC導入の際は事前検証とロールバック手順を用意する。
- TTLは変更時の影響を考えて段階的に調整する(メンテ前に短くする等)。
- ログとモニタリングでパターン異常(急増するNXDOMAIN、増える再試行等)を検出する。
- DoH/DoTの利用は組織ポリシーと可観測性のバランスを考慮する。
参考となる標準と技術文書(主要RFC・ガイド)
名前解決は長年にわたる標準化と進化の上に成り立っています。特にRFC1034/1035はDNSの基礎、DNSSECや暗号化に関するRFC群は実装と運用で重要です。下記参考文献を参照してください。
参考文献
- RFC 1034 - Domain Names - Concepts and Facilities
- RFC 1035 - Domain Names - Implementation and Specification
- RFC 4033 - DNS Security Introduction and Requirements
- RFC 4034 - Resource Records for the DNS Security Extensions
- RFC 4035 - Protocol Modifications for the DNS Security Extensions
- RFC 7858 - DNS over TLS
- RFC 8484 - DNS Queries over HTTPS (DoH)
- RFC 6891 - Extension Mechanisms for DNS (EDNS(0))
- Google Public DNS ドキュメント
- Cloudflare 1.1.1.1 - DNSとプライバシー
- ICANN - Root Servers


