DNS（Domain Name System）

ドメイン名（人が読む）と IP アドレス（機械が使う）を変換する分散データベース。 インターネットで最も「無いと何も動かない」インフラ。

そもそもなぜ要るのか

• 人は example.com を覚えるが、機械は 93.184.216.34 でしか通信できない
• サーバ移転時に IP が変わってもドメインで隠せる
• 1 ドメインを複数 IP に分散できる（地理分散・LB）
• サブドメインで階層構造を作れる

ドメイン名の階層

www.example.co.jp.
└┘ └─────┘ └┘ └┘ └ ルート (.)
 ↑    ↑    ↑   ↑
 ホスト 2nd  2nd TLD
            (co)
      

• ルート — 末尾の「.」（普通は省略）
• TLD — Top Level Domain（.com / .jp / .org など）
• 2nd Level — example の部分
• サブドメイン — www.example.com の www

TLD の種類

• gTLD: .com / .org / .net / .dev / .app
• ccTLD: .jp / .uk / .de / .io（国別。ただし .io は実質 generic）
• 新 gTLD: .shop / .tokyo / .blog（数百種類）

DNS の階層構造

                Root (.)
               /   |   \
            .com  .jp  .org
             |    /\
        example  co  ne
                 |
              example
                 |
                www
      

各層を管理するネームサーバが連携してクエリに答える。

名前解決の流れ

ブラウザ
  ↓ www.example.com を教えて
スタブリゾルバ（OS）
  ↓
ローカル DNS キャッシュ ── ヒットすれば即返す
  ↓ キャッシュなければ
フルサービスリゾルバ (ISP / 8.8.8.8 / 1.1.1.1)
  ↓
[1] ルートサーバへ問合せ
  → 「.com は次のサーバへ聞け」
[2] .com TLD サーバへ
  → 「example.com は次のサーバへ聞け」
[3] example.com の権威サーバ
  → 「www.example.com は 93.184.216.34」
  ↓
回答 + 各段でキャッシュ
      

レコードの種類

ゾーンファイルの例

$ORIGIN example.com.
$TTL 3600

@   IN  SOA  ns1.example.com. admin.example.com. (
              2026050101 ; serial
              7200       ; refresh
              3600       ; retry
              604800     ; expire
              86400 )    ; min TTL

@   IN  NS    ns1.example.com.
@   IN  NS    ns2.example.com.
@   IN  A     93.184.216.34
www IN  A     93.184.216.34
api IN  A     93.184.216.50
*   IN  A     93.184.216.34   ; ワイルドカード

@   IN  MX    10 mail.example.com.
@   IN  TXT   "v=spf1 include:_spf.google.com ~all"
      

TTL（Time To Live）

各レコードのキャッシュ期限。秒単位。

• 長い (24h) → 安定・負荷軽減、変更が反映されにくい
• 短い (60s) → 反映速い、サーバ負荷増・遅延増
• 移転前は事前に短くしておくと切替がスムーズ

DNS パケット（簡略）

+-------------+
| Header (12B)|  ID, flags, counts
+-------------+
| Question    |  名前 + type + class
+-------------+
| Answer      |  実際の応答
+-------------+
| Authority   |
+-------------+
| Additional  |  glue records 等
+-------------+
      

• UDP 53 が標準（小さい応答）
• 512 B 超 / DNSSEC は TCP 53 にフォールバック
• EDNS0 で UDP 上限を 4096 B 等に拡張

権威サーバとリゾルバ

• 権威 DNS: そのドメインの正式な答えを持つ（Cloudflare DNS / Route53 / Gehirn 等）
• フルリゾルバ: 端末からの問い合わせを順に解決していく（8.8.8.8 / 1.1.1.1 / ISP）
• スタブリゾルバ: OS 内蔵のクライアント

パブリック DNS

DNS over HTTPS / TLS

従来の DNS は平文 UDPのため、ISP / 公衆 Wi-Fi で内容が見える / 改竄できる。

• DoT (DNS over TLS): TCP 853、専用
• DoH (DNS over HTTPS): TCP 443、HTTPS と区別がつかない → 検閲耐性
• DoQ (DNS over QUIC): UDP 443

ブラウザ（Firefox / Chrome）や OS（Win11 / iOS / macOS / Android）で標準対応。

DNSSEC

応答を電子署名で検証する仕組み。改竄や偽応答を検知できる。 ルートからの信頼の連鎖を辿るため設定がやや複雑。日本では .jp ゾーンが対応。

DNS の用途いろいろ

メール認証

• SPF: 「このドメインから送信できるサーバ」を TXT で宣言
• DKIM: 公開鍵署名で本物確認
• DMARC: SPF/DKIM の結果に基づく挙動指定

所有権確認

• Google / Cloudflare 等で「TXT レコードに指定の文字列を入れて」と求められる

サービス検出

• SRV: _jabber._tcp.example.com で接続先を見つける
• mDNS / Bonjour: ローカルネット内のホスト発見（.local）

確認コマンド

# 詳しく
dig example.com
dig example.com AAAA
dig example.com MX
dig example.com TXT
dig +trace example.com   # ルートから順に追跡

# 簡易
nslookup example.com
host example.com

# システムの DNS で解決
getent hosts example.com  # Linux

# 1.1.1.1 で問合せ
dig @1.1.1.1 example.com

キャッシュ問題

• レコード変更は各層キャッシュが切れるまで反映されない
• OS / ブラウザ / リゾルバ / TLD / 権威 と各段階でキャッシュ
• 事前に TTL を短くしておく
• クライアント側でOS DNS キャッシュをフラッシュ:

# macOS
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

# Linux (systemd-resolved)
sudo resolvectl flush-caches

# Windows
ipconfig /flushdns

# Chrome 内蔵キャッシュ
chrome://net-internals/#dns

よくあるトラブル

運用 Tips

• ドメインの更新（renewal）を忘れない（自動更新推奨）
• レジストラと DNS プロバイダは別組織でも可（NS レコードで委任）
• 本番切替前は TTL を 60〜300 にしておき、切替後に戻す
• 変更履歴を Git 管理（Terraform / dnscontrol / OctoDNS など）
• 監視: 各レコードが期待値か定期チェック