DNS

DNS入門|ドメイン名の仕組みを基礎から理解する

ネットワーク DNS ドメイン

DNS入門|ドメイン名の仕組みを基礎から理解する

DNSの仕組み、レコードの種類、ドメイン設定、セキュリティまで、インターネットの名前解決の基礎を解説します。

こんな人向けの記事です

  • DNSの仕組みを基礎から理解したい
  • ドメインの設定方法を知りたい
  • 各DNSレコードの役割を把握したい

Step 1DNSとは|インターネットの名前解決

DNS(Domain Name System)は、ドメイン名(例: example.com)を、コンピュータが通信に使うIPアドレス(例: 93.184.216.34)に変換する仕組みです。インターネットの「電話帳」に例えられます。

ブラウザに https://www.google.com と入力したとき、実際にはDNSが裏側で www.google.com142.250.196.68 のような変換を行い、そのIPアドレスのサーバーと通信しています。

なぜDNSが必要なのか

人間にとって 142.250.196.68 のような数字の羅列を覚えるのは困難です。DNSがあることで、覚えやすいドメイン名を使ってWebサイトにアクセスできます。逆に、コンピュータはIPアドレスでしか通信できないため、この変換の仕組みが不可欠です。

ドメイン名の構造

ドメイン名は右から左に向かって階層構造になっています。

ドメイン名の階層構造
www.example.com.
 |     |     |  |
 |     |     |  +-- ルートドメイン(.)※通常省略される
 |     |     +----- トップレベルドメイン(TLD): .com, .jp, .org など
 |     +----------- セカンドレベルドメイン(SLD): example
 +----------------- サブドメイン: www

この階層構造が、DNSの名前解決のプロセスに深く関わっています。

階層 説明
ルートドメイン DNS階層の最上位。全世界に13系統のルートサーバーが存在 .(ドット)
TLD(トップレベルドメイン) gTLD(汎用)とccTLD(国別)がある .com, .jp, .net
SLD(セカンドレベルドメイン) 組織や個人が取得する部分 example, google
サブドメイン SLDの下に自由に設定できる www, mail, blog

Step 2DNSの仕組み|再帰クエリとキャッシュ

ブラウザでWebサイトにアクセスしたとき、DNSの名前解決は以下の流れで行われます。

名前解決の流れ

1. ブラウザのキャッシュを確認

ブラウザは過去にアクセスしたドメインのIPアドレスを一定期間キャッシュしています。キャッシュにあればDNSサーバーへの問い合わせは不要です。

2. OSのキャッシュを確認

ブラウザのキャッシュになければ、OSのDNSキャッシュ(リゾルバキャッシュ)を確認します。/etc/hosts ファイルの記載もここで参照されます。

3. フルリゾルバ(再帰リゾルバ)に問い合わせ

キャッシュになければ、ISPやパブリックDNS(Google: 8.8.8.8、Cloudflare: 1.1.1.1)などのフルリゾルバに再帰クエリを送ります。フルリゾルバは以下の手順で解決します。

4. ルートサーバーに問い合わせ

フルリゾルバはまずルートサーバーに「www.example.com のIPアドレスは?」と問い合わせます。ルートサーバーは「.com を管理するTLDサーバーに聞いてください」と返答します。

5. TLDサーバーに問い合わせ

.com のTLDサーバーに問い合わせると、「example.com を管理する権威DNSサーバーに聞いてください」と返答します。

6. 権威DNSサーバーに問い合わせ

example.com の権威DNSサーバーが最終的なIPアドレス(例: 93.184.216.34)を返します。フルリゾルバはこの結果をキャッシュし、クライアントに返却します。

再帰クエリと反復クエリ

DNSには2種類のクエリがあります。

クエリの種類 動作 使われる場面
再帰クエリ クライアントがフルリゾルバに「最終的な答えを返してください」と依頼する クライアント → フルリゾルバ
反復クエリ フルリゾルバが各DNSサーバーに順番に問い合わせ、「次はここに聞いて」という応答を受ける フルリゾルバ → ルート/TLD/権威サーバー
DNSキャッシュの重要性

毎回ルートサーバーから問い合わせていては時間がかかります。フルリゾルバは一度解決した結果をTTL(後述)の期間キャッシュするため、実際にはルートサーバーまで遡ることは稀です。キャッシュによりDNSの応答速度は通常1〜50ミリ秒程度に収まります。

DNSキャッシュの確認コマンド

Windows: DNSキャッシュの表示
ipconfig /displaydns
Windows: DNSキャッシュのクリア
ipconfig /flushdns
macOS: DNSキャッシュのクリア
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
Linux: systemd-resolvedのキャッシュクリア
sudo systemd-resolve --flush-caches

Step 3DNSレコードの種類

DNSレコードは、ドメインに関する情報をDNSサーバーに登録するためのデータです。目的に応じて様々な種類があります。

主要なDNSレコード一覧

レコード 正式名称 役割 設定例
A Address Record ドメイン名をIPv4アドレスに変換 example.com. IN A 93.184.216.34
AAAA IPv6 Address Record ドメイン名をIPv6アドレスに変換 example.com. IN AAAA 2606:2800:220:1:248:1893:25c8:1946
CNAME Canonical Name Record ドメイン名を別のドメイン名にエイリアス www.example.com. IN CNAME example.com.
MX Mail Exchange Record メールの配送先サーバーを指定 example.com. IN MX 10 mail.example.com.
TXT Text Record テキスト情報を格納(SPF、DKIM、ドメイン認証等) example.com. IN TXT "v=spf1 include:_spf.google.com ~all"
NS Name Server Record ドメインの権威DNSサーバーを指定 example.com. IN NS ns1.example.com.
SOA Start of Authority Record ゾーンの管理情報(シリアル番号、更新間隔等) example.com. IN SOA ns1.example.com. admin.example.com. ...

Aレコード

最も基本的なレコードで、ドメイン名をIPv4アドレスに対応付けます。1つのドメインに複数のAレコードを設定して負荷分散(ラウンドロビンDNS)を行うこともできます。

Aレコードの確認(digコマンド)
dig example.com A

;; ANSWER SECTION:
example.com.    86400   IN  A   93.184.216.34

AAAAレコード

IPv6アドレス用のAレコードです。IPv6の普及に伴い、AAAAレコードの設定もますます重要になっています。

AAAAレコードの確認
dig example.com AAAA

;; ANSWER SECTION:
example.com.    86400   IN  AAAA    2606:2800:220:1:248:1893:25c8:1946

CNAMEレコード

あるドメイン名を別のドメイン名のエイリアス(別名)として設定します。例えば www.example.comexample.com のエイリアスにする場合に使います。

CNAMEの制約

CNAMEレコードは、同じ名前に他のレコード(A、MX等)と共存できません。また、ゾーンの頂点(例: example.com)にはCNAMEを設定できない規約があります。代わりにALIASレコード(一部のDNSプロバイダが提供)を使う方法があります。

MXレコード

メールサーバーの宛先を指定するレコードです。優先度(数値が小さいほど高優先)を設定できます。

MXレコードの確認
dig example.com MX

;; ANSWER SECTION:
example.com.    86400   IN  MX  10 mail1.example.com.
example.com.    86400   IN  MX  20 mail2.example.com.

この例では、優先度10の mail1.example.com に最初にメールが配送され、それが利用できない場合に優先度20の mail2.example.com にフォールバックします。

TXTレコード

自由なテキスト情報を格納できるレコードで、主に以下の用途で使われます。

用途 説明 設定例
SPF メール送信元の正当性を検証 "v=spf1 include:_spf.google.com ~all"
DKIM メールの電子署名を検証 "v=DKIM1; k=rsa; p=MIGfMA0G..."
DMARC SPFとDKIMに基づくポリシーを定義 "v=DMARC1; p=reject; rua=mailto:..."
ドメイン所有権の確認 Google Search Console等のサービスで使用 "google-site-verification=xxxxx"

NSレコード

そのドメインを管理する権威DNSサーバーを指定します。通常、冗長性のために2つ以上のNSレコードを設定します。

NSレコードの確認
dig example.com NS

;; ANSWER SECTION:
example.com.    86400   IN  NS  ns1.example.com.
example.com.    86400   IN  NS  ns2.example.com.

SOAレコード

ゾーン(ドメインのDNS情報全体)の管理情報を定義するレコードです。各ゾーンに必ず1つ存在します。

SOAレコードの確認
dig example.com SOA

;; ANSWER SECTION:
example.com.    86400   IN  SOA ns1.example.com. admin.example.com. (
                        2024010101  ; シリアル番号(ゾーン更新の識別子)
                        3600        ; リフレッシュ間隔(秒)
                        900         ; リトライ間隔(秒)
                        604800      ; 有効期限(秒)
                        86400       ; ネガティブキャッシュTTL(秒)
                        )

Step 4ドメインの取得と設定

自分のWebサイトやメールアドレスに独自ドメインを使うには、ドメインの取得とDNS設定が必要です。

ドメイン取得の流れ

1. ドメインレジストラを選ぶ

ドメインの取得・管理を行うサービス(レジストラ)を選びます。代表的なレジストラには、お名前.com、ムームードメイン、Google Domains、Cloudflare Registrarなどがあります。

2. ドメイン名を検索・決定

希望のドメイン名が利用可能か検索します。TLDによって価格が異なります(.com は年間約1,500円、.jp は年間約3,000円程度)。

3. ドメインを購入・登録

WHOIS情報(登録者の連絡先)を入力して購入します。多くのレジストラはWHOIS代理公開サービスを提供しています。

4. ネームサーバーを設定

取得したドメインのネームサーバー(NS)を、利用するDNSサービスのものに変更します。

5. DNSレコードを設定

A、CNAME、MXなどのレコードを設定して、Webサーバーやメールサーバーと紐付けます。

Webサーバーの基本的なDNS設定例

VPS(例: IPアドレス 203.0.113.10)でWebサイトを公開する場合の設定例です。

基本的なDNS設定
; ドメインのルートをサーバーに向ける
example.com.        IN  A       203.0.113.10

; wwwサブドメインをルートにエイリアス
www.example.com.    IN  CNAME   example.com.

; メールサーバーの設定
example.com.        IN  MX  10  mail.example.com.
mail.example.com.   IN  A       203.0.113.10

; SPFレコード(メール認証)
example.com.        IN  TXT     "v=spf1 ip4:203.0.113.10 -all"
クラウドサービス利用時

AWSやGCP等のクラウドサービスでは、IPアドレスが変わる可能性があるため、Aレコードではなく CNAME(例: xxx.elb.amazonaws.com)やALIASレコードを使うのが一般的です。

Step 5DNSの伝播とTTL

DNSレコードを変更したあと、変更が世界中のDNSサーバーに反映されるまでの過程を「DNS伝播」と呼びます。

TTL(Time To Live)とは

TTLは、DNSレコードがキャッシュに保持される時間(秒数)です。フルリゾルバはTTLの期間だけレコードをキャッシュし、期限が切れると権威DNSサーバーに再度問い合わせます。

TTL値 時間 用途
300 5分 頻繁に変更するレコード、サーバー移行時
3600 1時間 一般的な設定(多くのDNSサービスのデフォルト)
86400 24時間 安定したレコード(変更頻度が低い場合)
604800 7日 ほぼ変更しないレコード(NSレコード等)

DNS伝播が遅れる原因

DNSレコードを変更しても、すぐには全世界に反映されません。これは各所のキャッシュが古い情報を保持しているためです。

伝播の注意点

DNS伝播には通常数分〜最大48時間かかることがあります。特にTTLが長く設定されていた場合、古いキャッシュが残り続けます。サーバー移行などの重要な変更前には、事前にTTLを短く(300秒程度に)しておくのがベストプラクティスです。

サーバー移行時のTTL運用例

1. 移行1〜2日前: TTLを短くする

現在のTTLが86400(24時間)なら、300(5分)に変更します。24時間後には全世界のキャッシュが新しいTTLに更新されます。

2. 移行実施: IPアドレスを変更

Aレコードを新サーバーのIPアドレスに変更します。TTLが5分なので、最大5分後には新しいIPに切り替わります。

3. 移行完了後: TTLを元に戻す

新サーバーで問題がなければ、TTLを元の値(3600〜86400)に戻します。

DNS伝播状況の確認

digで複数のDNSサーバーから確認
# Google Public DNS
dig @8.8.8.8 example.com A +short

# Cloudflare DNS
dig @1.1.1.1 example.com A +short

# OpenDNS
dig @208.67.222.222 example.com A +short
Webツールも活用しよう

whatsmydns.net などのオンラインツールを使うと、世界各地のDNSサーバーでの伝播状況を一覧で確認できます。

Step 6DNSセキュリティ|DNSSEC・DoH・DoT

DNSは1983年に設計されたプロトコルで、当初セキュリティは考慮されていませんでした。そのため、DNSを狙った攻撃手法と、それに対する防御技術が発展しています。

DNSに対する主な脅威

攻撃手法 概要 リスク
DNSキャッシュポイズニング フルリゾルバのキャッシュに偽のレコードを注入 ユーザーが偽サイトに誘導される
DNSスプーフィング 通信経路上でDNS応答を偽造 中間者攻撃によるデータ窃取
DNSトンネリング DNSプロトコルを悪用してデータを外部に持ち出す 情報漏洩、マルウェアの通信
DDoS(DNS増幅攻撃) DNSサーバーを踏み台にした大量トラフィック攻撃 サービス停止

DNSSEC(DNS Security Extensions)

DNSSECは、DNS応答にデジタル署名を付与し、応答の改ざんを検出できるようにする拡張仕様です。

DNSSECの仕組み

権威DNSサーバーがレコードに電子署名を付与し、リゾルバが署名を検証します。署名が正しくなければ、そのレコードは改ざんされたものとして破棄されます。

信頼の連鎖(Chain of Trust)

ルートゾーン → TLD → ドメインと、上位から下位に向かって署名を検証する「信頼の連鎖」が構築されます。各レベルで上位ゾーンが下位ゾーンの公開鍵を保証します。

DNSSECの検証確認
# DNSSECの署名情報を表示
dig example.com +dnssec

# DNSSEC検証を含む詳細表示
dig example.com +dnssec +multi
DNSSECの注意点

DNSSECは応答の「完全性」を保証しますが、通信の「機密性」(暗号化)は提供しません。つまり、レコードが改ざんされていないことは検証できますが、通信内容は第三者に見られる可能性があります。暗号化にはDoH/DoTが必要です。

DoH(DNS over HTTPS)

DoHは、DNS通信をHTTPS(ポート443)で暗号化するプロトコルです。通常のHTTPS通信と区別がつかないため、DNSクエリの傍受やブロックが困難になります。

項目 内容
ポート 443(HTTPS)
プロトコル HTTP/2 over TLS
利点 ファイアウォールでブロックされにくい、プライバシー保護
対応ブラウザ Firefox、Chrome、Edge、Brave
主なプロバイダ Cloudflare(https://cloudflare-dns.com/dns-query)、Google(https://dns.google/dns-query

DoT(DNS over TLS)

DoTは、DNS通信をTLS(ポート853)で暗号化するプロトコルです。DoHと同様にプライバシーを保護しますが、専用ポートを使用するため、ネットワーク管理者がDNSトラフィックを識別・管理しやすいという特徴があります。

項目 DoH DoT
ポート 443 853
暗号化 HTTPS(HTTP/2 over TLS) TLS
識別の容易さ 他のHTTPS通信と区別困難 専用ポートのため識別可能
ブロック耐性 高い(443をブロックすると他の通信も止まる) 低い(853をブロック可能)
適した環境 個人ユーザー、検閲回避 企業ネットワーク、管理者がDNSを制御したい環境
まとめ: DNSセキュリティの選択

DNSSECは応答の改ざん防止、DoH/DoTは通信の暗号化と、それぞれ異なるセキュリティを提供します。組み合わせて使うことで、DNSの安全性を大幅に向上できます。まずはブラウザのDoH設定を有効にし、自分が管理するドメインではDNSSECを有効にすることを推奨します。

チェックリスト

  • DNSがドメイン名とIPアドレスを変換する仕組みを理解した
  • 再帰クエリとキャッシュによる名前解決の流れを把握した
  • A、AAAA、CNAME、MX、TXT、NS、SOAレコードの役割を理解した
  • ドメインの取得からDNS設定までの手順を把握した
  • TTLの役割とサーバー移行時の運用方法を理解した
  • DNSSEC、DoH、DoTによるDNSセキュリティ対策を把握した