DNS入門|ドメイン名の仕組みを基礎から理解する
DNSの仕組み、レコードの種類、ドメイン設定、セキュリティまで、インターネットの名前解決の基礎を解説します。
こんな人向けの記事です
- DNSの仕組みを基礎から理解したい
- ドメインの設定方法を知りたい
- 各DNSレコードの役割を把握したい
Step 1DNSとは|インターネットの名前解決
DNS(Domain Name System)は、ドメイン名(例: example.com)を、コンピュータが通信に使うIPアドレス(例: 93.184.216.34)に変換する仕組みです。インターネットの「電話帳」に例えられます。
ブラウザに https://www.google.com と入力したとき、実際にはDNSが裏側で www.google.com → 142.250.196.68 のような変換を行い、そのIPアドレスのサーバーと通信しています。
人間にとって 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の名前解決は以下の流れで行われます。
名前解決の流れ
ブラウザは過去にアクセスしたドメインのIPアドレスを一定期間キャッシュしています。キャッシュにあればDNSサーバーへの問い合わせは不要です。
ブラウザのキャッシュになければ、OSのDNSキャッシュ(リゾルバキャッシュ)を確認します。/etc/hosts ファイルの記載もここで参照されます。
キャッシュになければ、ISPやパブリックDNS(Google: 8.8.8.8、Cloudflare: 1.1.1.1)などのフルリゾルバに再帰クエリを送ります。フルリゾルバは以下の手順で解決します。
フルリゾルバはまずルートサーバーに「www.example.com のIPアドレスは?」と問い合わせます。ルートサーバーは「.com を管理するTLDサーバーに聞いてください」と返答します。
.com のTLDサーバーに問い合わせると、「example.com を管理する権威DNSサーバーに聞いてください」と返答します。
example.com の権威DNSサーバーが最終的なIPアドレス(例: 93.184.216.34)を返します。フルリゾルバはこの結果をキャッシュし、クライアントに返却します。
再帰クエリと反復クエリ
DNSには2種類のクエリがあります。
| クエリの種類 | 動作 | 使われる場面 |
|---|---|---|
| 再帰クエリ | クライアントがフルリゾルバに「最終的な答えを返してください」と依頼する | クライアント → フルリゾルバ |
| 反復クエリ | フルリゾルバが各DNSサーバーに順番に問い合わせ、「次はここに聞いて」という応答を受ける | フルリゾルバ → ルート/TLD/権威サーバー |
毎回ルートサーバーから問い合わせていては時間がかかります。フルリゾルバは一度解決した結果をTTL(後述)の期間キャッシュするため、実際にはルートサーバーまで遡ることは稀です。キャッシュによりDNSの応答速度は通常1〜50ミリ秒程度に収まります。
DNSキャッシュの確認コマンド
ipconfig /displaydns
ipconfig /flushdns
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
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)を行うこともできます。
dig example.com A ;; ANSWER SECTION: example.com. 86400 IN A 93.184.216.34
AAAAレコード
IPv6アドレス用のAレコードです。IPv6の普及に伴い、AAAAレコードの設定もますます重要になっています。
dig example.com AAAA ;; ANSWER SECTION: example.com. 86400 IN AAAA 2606:2800:220:1:248:1893:25c8:1946
CNAMEレコード
あるドメイン名を別のドメイン名のエイリアス(別名)として設定します。例えば www.example.com を example.com のエイリアスにする場合に使います。
CNAMEレコードは、同じ名前に他のレコード(A、MX等)と共存できません。また、ゾーンの頂点(例: example.com)にはCNAMEを設定できない規約があります。代わりにALIASレコード(一部のDNSプロバイダが提供)を使う方法があります。
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レコードを設定します。
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つ存在します。
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設定が必要です。
ドメイン取得の流れ
ドメインの取得・管理を行うサービス(レジストラ)を選びます。代表的なレジストラには、お名前.com、ムームードメイン、Google Domains、Cloudflare Registrarなどがあります。
希望のドメイン名が利用可能か検索します。TLDによって価格が異なります(.com は年間約1,500円、.jp は年間約3,000円程度)。
WHOIS情報(登録者の連絡先)を入力して購入します。多くのレジストラはWHOIS代理公開サービスを提供しています。
取得したドメインのネームサーバー(NS)を、利用するDNSサービスのものに変更します。
A、CNAME、MXなどのレコードを設定して、Webサーバーやメールサーバーと紐付けます。
Webサーバーの基本的なDNS設定例
VPS(例: IPアドレス 203.0.113.10)でWebサイトを公開する場合の設定例です。
; ドメインのルートをサーバーに向ける 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運用例
現在のTTLが86400(24時間)なら、300(5分)に変更します。24時間後には全世界のキャッシュが新しいTTLに更新されます。
Aレコードを新サーバーのIPアドレスに変更します。TTLが5分なので、最大5分後には新しいIPに切り替わります。
新サーバーで問題がなければ、TTLを元の値(3600〜86400)に戻します。
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
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応答にデジタル署名を付与し、応答の改ざんを検出できるようにする拡張仕様です。
権威DNSサーバーがレコードに電子署名を付与し、リゾルバが署名を検証します。署名が正しくなければ、そのレコードは改ざんされたものとして破棄されます。
ルートゾーン → TLD → ドメインと、上位から下位に向かって署名を検証する「信頼の連鎖」が構築されます。各レベルで上位ゾーンが下位ゾーンの公開鍵を保証します。
# DNSSECの署名情報を表示 dig example.com +dnssec # DNSSEC検証を含む詳細表示 dig example.com +dnssec +multi
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を制御したい環境 |
DNSSECは応答の改ざん防止、DoH/DoTは通信の暗号化と、それぞれ異なるセキュリティを提供します。組み合わせて使うことで、DNSの安全性を大幅に向上できます。まずはブラウザのDoH設定を有効にし、自分が管理するドメインではDNSSECを有効にすることを推奨します。
チェックリスト
- DNSがドメイン名とIPアドレスを変換する仕組みを理解した
- 再帰クエリとキャッシュによる名前解決の流れを把握した
- A、AAAA、CNAME、MX、TXT、NS、SOAレコードの役割を理解した
- ドメインの取得からDNS設定までの手順を把握した
- TTLの役割とサーバー移行時の運用方法を理解した
- DNSSEC、DoH、DoTによるDNSセキュリティ対策を把握した