0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@freefreefree1222

DNSレコードのTTL設定、デフォルトのまま運用していませんか？反映遅延を防ぐ実践的ガイド

0
Posted at

環境情報

  • 対象サービス: AWS Route53、Cloudflare、さくらのDNS、お名前.com DNS
  • 検証ツール: dig、nslookup、curl -I
  • サンプルコード: Bash、Python（DNSクエリ確認用）
  • 前提知識: DNSの基本動作（名前解決、キャッシュ）

はじめに

DNSレコードの変更後、「反映までに時間がかかる」という経験はエンジニアなら誰しも一度はあるでしょう。先日開催した某管理システムの勉強会でも、このテーマで大いに盛り上がりました。特にTTL（Time to Live）の設定値がデフォルトのままになっているケースが多く、それが原因で想定外の遅延が発生している実態が浮き彫りになりました。

本記事では、TTLの基本から実践的な設定方法、トラブルシューティングまでを具体的なコード例と共に解説します。

TTL（Time to Live）とは

TTLはDNSレコードがDNSキャッシュサーバーに保持される最大時間（秒）です。この値が大きいほどキャッシュは長く残り、小さいほど頻繁に問い合わせが発生します。

TTLの動作イメージ

クライアント → キャッシュDNSサーバー（TTL秒間保持） → 権威DNSサーバー

代表的なTTL値とその影響

TTL値 秒数 利用シーン メリット デメリット
300秒 5分 開発環境、緊急変更時 変更が即座に反映 DNSクエリ増加
3600秒 1時間 本番環境の標準 負荷と即時性のバランス 1時間の反映遅延
86400秒 24時間 静的リソース（CDN等） 負荷最小 変更反映に最大1日

実践: TTL設定の手順

ステップ1: 現在のTTL値を確認する

まずは現在の設定を確認しましょう。digコマンドで確認できます。

# AレコードのTTLを確認（例: example.com）
dig example.com A +noall +answer

# 出力例
# example.com. 300 IN A 192.0.2.1
# ↑この300がTTL（秒）

ステップ2: 変更前にTTLを短くする

DNSレコードを変更する前に、既存レコードのTTLを短く設定します。これを忘れると、変更後も古いTTLに基づいてキャッシュが残り続けます。

# 例: Route53でTTLを300秒に変更（AWS CLI）
aws route53 change-resource-record-sets \
  --hosted-zone-id ZONE_ID \
  --change-batch '{
    "Changes": [{
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "example.com",
        "Type": "A",
        "TTL": 300,
        "ResourceRecords": [{"Value": "192.0.2.1"}]
      }
    }]
  }'

ステップ3: 変更を実施する

TTLを短くしてから、実際のレコード値を変更します。この間にキャッシュは徐々にクリアされていきます。

# PythonでDNS変更の反映状況を確認する簡易スクリプト
import dns.resolver
import time

def check_dns_propagation(domain, record_type, expected_value, interval=30, max_retries=10):
    resolver = dns.resolver.Resolver()
    resolver.nameservers = ['8.8.8.8', '1.1.1.1']  # グローバルDNS
    
    for i in range(max_retries):
        try:
            answers = resolver.resolve(domain, record_type)
            for rdata in answers:
                current_value = str(rdata)
                if current_value == expected_value:
                    print(f"反映完了！ {domain} -> {current_value}")
                    return True
                else:
                    print(f"未反映（{i+1}/{max_retries}）: {current_value}")
        except Exception as e:
            print(f"エラー: {e}")
        time.sleep(interval)
    return False

# 使用例
check_dns_propagation('example.com', 'A', '192.0.2.2')

ステップ4: 反映確認とTTLの戻し

変更が全DNSサーバーに反映されたことを確認したら、TTLを元の値（または適切な値）に戻します。

# 複数のDNSサーバーから確認
for ns in "8.8.8.8" "1.1.1.1" "208.67.222.222"; do
  echo "=== $ns ==="
  dig @$ns example.com A +short
done

ハマりポイントと対策

1. TTL変更を忘れる

問題: レコード値を変更する前にTTLを短くしないと、古いTTL（例: 86400秒）のままキャッシュが残る。

対策: 変更手順書に「TTLの事前短縮」を必ず含める。CI/CDパイプラインに自動化する。

# GitHub ActionsでTTLを自動変更する例
name: DNS Update
on:
  push:
    branches: [main]
jobs:
  update-dns:
    runs-on: ubuntu-latest
    steps:
      - name: Shorten TTL before update
        run: |
          aws route53 change-resource-record-sets \
            --hosted-zone-id ${{ secrets.ZONE_ID }} \
            --change-batch '{
              "Changes": [{
                "Action": "UPSERT",
                "ResourceRecordSet": {
                  "Name": "example.com",
                  "Type": "A",
                  "TTL": 300,
                  "ResourceRecords": [{"Value": "192.0.2.1"}]
                }
              }]
            }'
      - name: Wait for propagation
        run: sleep 600
      - name: Update actual record
        run: |
          # 実際のレコード更新処理

2. キャッシュの階層を考慮しない

問題: ブラウザ、OS、ルーター、ISPのDNSキャッシュなど、複数階層でキャッシュされる。

対策: 全階層のキャッシュをクリアする方法を理解する。

# ブラウザキャッシュクリア（Chromeの場合）
chrome://net-internals/#dns

# OSキャッシュクリア（macOS）
sudo killall -HUP mDNSResponder

# OSキャッシュクリア（Linux）
sudo systemctl restart systemd-resolved

3. TTLを極端に短くしすぎる

問題: TTLを1秒などに設定すると、DNSサーバーへの負荷が急増する。

対策: 最低でも60秒以上に設定。大規模サービスでは300秒以上推奨。

実践的なTTL設計パターン

開発環境

  • TTL: 60秒～300秒
  • 理由: 頻繁な変更に対応するため
  • 注意: 開発用DNSサーバーを分ける

ステージング環境

  • TTL: 300秒～600秒
  • 理由: テストと本番のバランス
  • 注意: 本番とは別ゾーンで管理

本番環境

  • TTL: 600秒～3600秒
  • 理由: 負荷と即時性のバランス
  • 注意: 変更時は事前にTTL短縮

CDNや静的リソース

  • TTL: 86400秒（24時間）以上
  • 理由: 変更頻度が低く、負荷軽減優先
  • 注意: 緊急時はTTL短縮を忘れずに

トラブルシューティングFAQ

Q1: レコード変更後、3日経っても反映されない

A: TTLが86400秒（24時間）に設定されていませんか？事前にTTLを短くするか、強制的にキャッシュをクリアしてください。

Q2: 短いTTLで運用しても問題ない？

A: クエリ数が増えるため、DNSサーバーの負荷とコストが上昇します。本番環境では300秒以上を推奨します。

Q3: 複数のDNSプロバイダを使っている場合の注意点は？

A: 各プロバイダでTTL設定が異なる場合があるため、統一することを推奨します。また、変更は全プロバイダで同時に行ってください。

まとめ

TTL設定はDNS運用における基本的かつ重要な要素です。以下のポイントを押さえておけば、反映遅延のトラブルを大幅に減らせます。

  1. 変更前にTTLを短くする（事前作業としてルール化）
  2. 適切なTTL値を選択する（用途に応じて60秒～86400秒）
  3. キャッシュ階層を理解する（ブラウザ、OS、ISP、権威DNS）
  4. 自動化する（CI/CDパイプラインに組み込む）

皆さんはTTLをどれくらいに設定していますか？ぜひコメントで教えてください。

この記事を書いた人

BENTEN Web Works — 業務自動化・システム開発のフリーランスエンジニアです。

GAS / Python / RPA を使った業務自動化や、Web制作・システム開発のご相談を承っています。
「こんなこと自動化できる？」というご質問だけでもお気軽にどうぞ。

👉 業務自動化サービス — 詳細・お問い合わせはこちら
🐦 X（旧Twitter） — 日々の知見を発信中

0
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?