MENU
お酒大好きアラサーOLが雑多にまとめるブログ
  1. ホーム
  2. 80_コトバ
  3. DNSとは？仕組み・レコード種類・設定・セキュリティまでやさしく解説

DNSとは？仕組み・レコード種類・設定・セキュリティまでやさしく解説

ページに広告が含まれる場合があります。
80_コトバ

Webサイトにアクセスしたり、メールを送受信したり、アプリがクラウドに接続したり――そのすべての裏側で静かに働いているのがDNS（Domain Name System）です。人が覚えやすい「名前（例：example.com）」と、機械が通信に使う「IPアドレス（例：192.0.2.10）」を結びつける、この“インターネットの電話帳”。本記事では、DNSの基本から仕組み、主要レコード、設定・運用のコツ、セキュリティ、トラブルシュートまでを一気通貫で解説します。はじめての方にも、運用担当の方にも、今日から役立つ実践的な内容をぎゅっとまとめました。

目次

DNSはなぜ必要か：人間の「名前」と機械の「番号」をつなぐ

インターネット上の端末やサーバは、通信の宛先としてIPアドレスを使います。しかしIPアドレスは人間にとって覚えづらく、サービスの移設や冗長化のたびにアドレスが変わることもあります。そこで登場するのがDNSです。

  • 役割：ドメイン名 → IPアドレス（逆引きはIP → ドメイン名）の相互変換
  • メリット：
    • 人に優しい名前でアクセスできる
    • サーバ移転時も、DNSの記録を更新すれば同じ名前で使い続けられる
    • 負荷分散や冗長化、地理的な振り分け（GeoDNS）にも活用可能

用語の整理：ドメイン、FQDN、ゾーン、レコード

まずは最小限の用語を押さえておきましょう。

  • ドメイン名（Domain）：インターネット上の「名前」の階層構造。example.com など。
  • FQDN（完全修飾ドメイン名）：ホスト名まで含めた完全な名前。www.example.com. のように末尾にドットが付く表記が正確。
  • ゾーン（Zone）：あるドメイン配下の権威情報を管理する単位。example.com のゾーンをどのDNSサーバが正として持つかを決める。
  • レコード（Resource Record）：ドメインに紐づく具体的な情報（A、MX、TXTなど）を1行で表したもの。
  • 権威DNSサーバ：そのゾーンの「正解」を持つサーバ。
  • リゾルバ（キャッシュDNS）：クライアントの代わりに問い合わせを行い、結果を一時保存（キャッシュ）するサーバ。企業やISP、公共DNS（8.8.8.8 など）がこれに当たります。
  • TTL（Time To Live）：キャッシュが有効な秒数。短いほど変更が速く行き渡り、長いほどキャッシュ効果で負荷が下がる。

名前解決の流れ：ルート → TLD → 権威DNS

ブラウザが https://www.example.com/ にアクセスするとき、裏側では次のような段取りでIPアドレスが見つかります。

  1. クライアント → リゾルバ
    PCやスマホは、まず設定されたキャッシュDNS（企業内DNSや公共DNS）に「www.example.com のAレコードを教えて」と問い合わせます。
  2. キャッシュの確認
    もし最近同じ質問をしていて、TTL内なら即座に答えが返ります。なければ次へ。
  3. ルートサーバへ
    リゾルバは「.（ルート）」に聞きます。「com を管轄しているTLDサーバは？」
  4. TLDサーバ（例：.com）へ
    ルートから得た情報をもとに「example.com を管轄している権威DNSは？」と問い合わせ、権威DNSの名前（NS）と必要に応じてグルー（A/AAAA）を受け取ります。
  5. 権威DNSへ最終問い合わせ
    権威DNSに「www.example.com のA（またはAAAA）を教えて」と聞き、IPアドレス（たとえば 192.0.2.10）を回答してもらいます。
  6. クライアントへ返却しキャッシュ
    リゾルバは結果をTTLの間キャッシュし、クライアントへ返します。

この一連の動きはミリ秒～数百ミリ秒単位で完了し、以降しばらくはキャッシュにより高速に解決されます。

主要レコードの種類と使いどころ

DNSレコードは“用途別のカード”のようなもの。代表的なものを表で整理します。

種類概要代表的な用途・例
Aドメイン名 → IPv4アドレスwww IN A 192.0.2.10
AAAAドメイン名 → IPv6アドレスwww IN AAAA 2001:db8::10
CNAME別名（エイリアス）を正規名へblog IN CNAME ghs.googlehosted.com.
MXメール配送先サーバ@ IN MX 10 mail.example.com.
TXT任意の文字列SPF/DKIM/DMARC、所有証明など
NSゾーンを管理する権威DNSの指定@ IN NS ns1.provider.net.
SOAゾーンの基本情報シリアル、リフレッシュ間隔など
SRVサービスの場所を示すSIP、XMPP、_sip._tcp のような用途
PTR逆引き（IP → 名称）メールの信頼性、ログの可読性
CAA証明書発行可否の制御特定のCAにのみ発行を許可

注意点：ゾーンの頂点（apex、例：example.com 自体）には標準的にはCNAMEを置けません。多くのマネージドDNSでは代替として ALIAS/ANAME という疑似レコードが提供されます。

DNSサーバの役割：リゾルバと権威、公開と内部

  • キャッシュDNS（リゾルバ）：ユーザーの近くに置いて、問い合わせ結果をキャッシュ。応答の高速化と権威DNSの負荷軽減に寄与。
  • 権威DNS：自組織のゾーンの正解を保持。複数台・複数ネットワーク・複数事業者で冗長化が基本。
  • フォワーダ：特定の上位リゾルバに問い合わせを転送する構成。企業ネットワークでよく使われます。
  • 公開DNS / 内部DNS：インターネットに公開するレコードと、社内向けにのみ返すレコードを分離する「スプリットホライズン（Split-Horizon）」が実務で定番です。

設定・運用の基礎：ゾーンとTTLの考え方

ゾーンは「ファイル（または管理画面の集合）」として表現され、そこにレコードを並べていきます。BIND風のイメージをつかむため、簡略例を示します（実運用ではプロバイダのGUIやAPIで管理することが多いです）。

$TTL 3600
@       IN SOA  ns1.dns.example. hostmaster.example.com. (
                2025010101 ; serial
                3600       ; refresh
                900        ; retry
                604800     ; expire
                300 )      ; negative cache TTL
        IN NS   ns1.dns.example.
        IN NS   ns2.dns.example.

@       IN A    192.0.2.10
www     IN A    192.0.2.20
mail    IN A    192.0.2.30
@       IN MX   10 mail.example.com.
_dmarc  IN TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

TTL設計のコツ

  • 変更頻度の高いレコード（CDNやロードバランサで動的に切り替える先など）は 300～600秒 程度から始めると扱いやすい。
  • 変えない前提のNSやMXは 3600～86400秒 といった長めのTTLで安定させ、無駄なトラフィックを減らす。
  • 重要変更の直前にTTLを一時的に短くし、切替後に元へ戻す運用が効果的。

「DNS伝播」はなぜ時間がかかるのか（誤解と本質）

「DNSは72時間かかる」という言い回しを耳にしますが、実態は キャッシュの寿命（TTL） に依存します。各地のリゾルバが古い情報をTTLいっぱい保持していると、その間は古い答えを返し続けます。また、存在しない名前を問い合わせた結果も ネガティブキャッシュ として一定時間保持されることがあります。
ポイントは次の通りです。

  • 変更前にTTLを短くしておくと、切替が速く行き渡る
  • 一部ISPや機器は独自に最小/最大TTLを設ける場合があり、設計値どおりにいかないこともある
  • ブラウザやOS自身も短時間キャッシュするため、アプリ側のキャッシュクリア も有効

メールとDNS：SPF・DKIM・DMARCの基本

迷惑メール対策やなりすまし防止のため、メール関連ではDNSのTXTレコードが重要です。

  • SPF：送信を許可する送信元（IPやドメイン）を宣言。
    例："v=spf1 ip4:192.0.2.30 include:_spf.mailprovider.net ~all"
    ※外部参照（include等）の数には制限があり、設計時は「DNS参照10回以内」を意識します。
  • DKIM：公開鍵をDNSに載せ、メール本文が改ざんされていないか受信側が検証。
    例：selector1._domainkey.example.com IN TXT "v=DKIM1; k=rsa; p=..."
  • DMARC：SPF/DKIMの結果に基づく受信側の扱い方針を宣言。
    例：_dmarc.example.com IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

セキュリティ：DNSSEC、暗号化DNS、運用時の落とし穴

DNSはもともと平文で、かつ「だれでも答えられる」性質があるため、対策が不可欠です。

  • キャッシュポイズニング対策
    • ソースポートのランダム化、トランザクションIDのランダム化
    • リゾルバをオープンリゾルバにしない（外部からの再帰問い合わせを遮断）
  • DNSSEC（DNS Security Extensions）
    • レコードに署名（RRSIG） を付け、公開鍵（DNSKEY）と親ゾーンに登録されたDSレコード で信頼の連鎖を検証。
    • 改ざん検知ができる一方、鍵管理やロールオーバー、署名失効の運用が必要。
  • 暗号化DNS
    • DoT（DNS over TLS）：TLSで暗号化、専用ポートを使って秘匿性を高める。
    • DoH（DNS over HTTPS）：HTTPSにカプセル化。ネットワーク的にブロックされにくいが、監視やポリシー設計とのバランスが課題。
  • 権威DNSの堅牢化
    • **AXFR/IXFR（ゾーン転送）**は転送元/先を制限、TSIG（署名）で保護
    • Anycast 配備やDDoS耐性の高いDNS事業者を採用
    • 管理画面のMFA、APIキーのローテーション、変更通知の監査

可用性とパフォーマンス：落ちないDNSの作り方

  • NSの冗長化：少なくとも2台以上、異なるAS・異なるロケーションに分散。
  • Anycast：同じIPを世界各地に広く配置し、ユーザーから最も近いノードが応答。公共DNSや大手権威DNSで一般的。
  • GeoDNS/重み付きレコード：国・地域・ASNなどに応じて異なる応答を返し、遅延を削減。
  • CDNとの連携：CDNのエッジに名前を向ける構成は、グローバル配信の定番。
  • 監視：dig のヘルスチェック、レイテンシ測定、レコード差分監視（意図せぬ変更検出）が有効。

よくあるトラブルと診断の手順

何かがおかしいときは、まず「どの段階で間違っているか」を切り分けます。次のコマンド例（Linux/macOS想定）が役立ちます。Windowsなら nslookup でも概念は同じです。

  • 基本のAレコード確認 dig www.example.com A +short
  • 権威DNSまでの道のりを追跡（ルート→TLD→権威） dig www.example.com +trace
  • 特定のリゾルバに対して問い合わせ（公共DNSや社内DNSに切り替えて比較） dig @8.8.8.8 www.example.com A +nocache
  • NSやSOAの確認（権威構成の一貫性） dig example.com NS +short dig example.com SOA +multiline
  • 逆引き（メールトラブルで重要） dig -x 203.0.113.10 PTR +short

ハマりポイント

  • ApexにCNAME を置こうとして失敗（ALIAS/ANAMEを使う）
  • TTLが長すぎて切替が見えない（事前に短縮、切替後に復帰）
  • NSの登録ミスや不整合（レジストラ側の委任設定と権威DNSのゾーン内容が一致しているか）
  • SPFが参照過多（includeが多すぎて評価失敗）
  • 権威DNSのゾーン転送が解放（AXFRを意図せず誰にでも許してしまう）
  • オープンリゾルバ化（再帰を外部に開放してDDoSの踏み台に）

企業ネットワークでのDNS：スプリットホライズンとログ活用

  • スプリットホライズン：社内から intranet.example.com を引くと内部IP、社外からは存在しない（または別の答え）というように、問い合わせ元に応じて異なる回答を返す設計。混在環境やゼロトラスト移行期によく使われます。
  • 内部リゾルバのキャッシュとフィルタリング：マルウェアのドメインブロックやポリシー適用を行う場合、内部リゾルバが司令塔に。
  • ログ活用：DNSログはセキュリティの「早期警戒レーダー」。異常なクエリ頻度、怪しい新規ドメインへのアクセス増加などは侵害の兆候になり得ます。

プライバシーと近年の動向

  • 暗号化DNS（DoT/DoH）の普及：端末やブラウザが暗号化リゾルバへ直接問い合わせる構成が一般化。プライバシー強化の一方、企業のトラフィック制御・可観測性との整合がテーマ。
  • DNSSECの段階的普及：重要ドメインから優先採用し、鍵管理の運用を確立するのが現実的。
  • CAAの標準化運用：証明書の誤発行リスクを軽減。マルチベンダー発行やワイルドカード証明書利用時は設計に注意。
  • SVCB/HTTPSレコード：新しいプロトコルの発見や接続最適化に関わるレコードも登場し、今後のWeb配信の基盤技術として注目されています。

小さく始める：個人・小規模サイトの実践レシピ

  1. ドメイン取得とDNSホスティング選定
    • レジストラは管理のしやすさ、DNSは冗長化と速度、APIの有無をチェック。
  2. 基本レコードのセット
    • @（apex）にA/AAAA（またはALIAS）
    • www にA/AAAAまたはCNAME
    • MX と SPF（TXT）、DMARC（TXT） を最初から入れておく
  3. TTLは控えめに開始
    • まずは300～600秒で運用し、安定後に延長
  4. 監視とバックアップ
    • 変更履歴を残し、ゾーンのエクスポートを定期的に取得
  5. セキュリティの初期設定
    • リゾルバの再帰制限、ダッシュボードMFA、AXFR制限
    • 可能ならDNSSEC対応プランを検討

中規模以上の運用：信頼性と拡張性の設計ポイント

  • マルチDNSプロバイダ：異なる事業者に同一ゾーンをホスト（セカンダリやプライマリ/セカンダリ、もしくはマルチプライマリ）。単一障害点を排除。
  • Anycast対応DNSの採用：世界各地から安定したレイテンシを確保。
  • 自動化：IaC（Infrastructure as Code）でDNSをコード化し、レビューとCIで変更の品質を担保。
  • 変更フロー：本番前のステージングゾーン、カナリア的な段階適用、ロールバックの手順を用意。
  • 可観測性：権威応答の遅延・失敗率、レコードの整合性チェック、世界各地からの監視（RUM/合成監視）を組み合わせる。

さらに理解を深めるためのQ&A

Q1：CDNの指示どおりCNAMEを作ったら、www は開くのに example.com が開きません。
A：apexにCNAMEを置けないためです。DNSプロバイダの ALIAS/ANAME を使うか、CDN側の推奨手順（A/AAAAまたはALIASの提供）に従いましょう。

Q2：レコードを更新したのに、社内の一部端末だけ古い答えが返ります。
A：OSやブラウザ、社内リゾルバのキャッシュが残っている可能性。TTL短縮、ipconfig /flushdns（Windows）や端末再起動、異なるリゾルバでの確認で切り分けを。

Q3：SPFで include が多すぎると何がまずい？
A：評価時のDNS参照回数に上限があり、超えると「失敗」扱いになります。送信経路の棚卸しと集約が必要です。

Q4：DNSSECは必須？
A：改ざん検知には有効ですが、鍵管理の複雑さが伴います。まずは重要ドメインから段階導入が現実的です。

Q5：DoH/DoTはどちらを選べば？
A：利用環境とポリシー次第。ブラウザ主体ならDoHが導入しやすく、ネットワーク境界での制御を重視するならDoTや社内リゾルバ経由が管理しやすい場合があります。

まとめ：チェックリスト

  • ドメインの権威DNSは冗長化できているか
  • TTLは用途に応じて最適化されているか（変更前短縮→変更後延長）
  • apexのCNAME禁止に注意（必要ならALIAS/ANAME）
  • メール関連のTXT（SPF/DKIM/DMARC）を整備したか
  • オープンリゾルバや開放AXFRになっていないか
  • 監視・変更履歴・バックアップを持っているか
  • 暗号化DNSやDNSSECなどのセキュリティ強化策を検討したか

DNSは“ただの電話帳”に見えて、実際には可用性・性能・セキュリティを支える要。基本を理解しておけば、Webやメールのトラブルは大幅に減り、切替作業や拡張にも自信が持てます。小さく始めて、必要に応じて段階的に高度化していきましょう。

80_コトバ
よかったらシェアしてね！
  • URLをコピーしました！
  • URLをコピーしました！

この記事を書いた人

えりのアバター えり

関連記事

コメント

コメントする

目次