managing-dns

DNS 管理

適切な TTL 戦略、DNS-as-code パターン、トラブルシューティング手法を活用して、DNS レコードを設定および自動化します。

目的

以下に重点を置き、アプリケーション、インフラストラクチャ、サービス向けの DNS 設定を案内します。

• レコードタイプの選択（A、AAAA、CNAME、MX、TXT、SRV、CAA）
• 伝播とキャッシュに関する TTL 戦略
• DNS-as-code による自動化（external-dns、OctoDNS、DNSControl）
• クラウド DNS サービスの比較と選定
• DNS ベースのロードバランシングパターン
• トラブルシューティングツールと手法

このスキルを使用する場面

次のような場合に DNS 管理パターンを適用します。

• 新しいアプリケーションやサービス用に DNS を設定するとき
• Kubernetes ワークロードからの DNS 更新を自動化するとき
• DNS ベースのフェイルオーバーやロードバランシングを設定するとき
• DNS の伝播や名前解決の問題をトラブルシューティングするとき
• DNS をプロバイダー間で移行するとき
• ダウンタイムを最小限に抑えた DNS 変更を計画するとき
• グローバルユーザー向けに GeoDNS を実装するとき

レコードタイプの選択

クイックリファレンス

アドレス解決：

• A レコード：ホスト名を IPv4 アドレスにマッピングします（example.com → 192.0.2.1）
• AAAA レコード：ホスト名を IPv6 アドレスにマッピングします（example.com → 2001:db8::1）
• CNAME レコード：別のドメインへのエイリアスを設定します（www.example.com → example.com）
  • ゾーン頂点（@）では使用できません
  • 同じ名前の他のレコードと共存できません

メールの設定：

• MX レコード：優先度を指定してメールをメールサーバーに転送します
• TXT レコード：メール認証（SPF、DKIM、DMARC）と検証に使用します

サービスディスカバリー：

• SRV レコード：サービスの場所を指定します（プロトコル、優先度、重み、ポート、ターゲット）

委任とセキュリティ：

• NS レコード：サブドメインを別のネームサーバーに委任します
• CAA レコード：証明書を発行できる認証局を制限します

クラウド固有：

• ALIAS レコード：CNAME と同様ですが、ゾーン頂点で使用できます（Route53、Cloudflare）

判断ツリー

Need to point domain to:
├─ IPv4 Address? → A record
├─ IPv6 Address? → AAAA record
├─ Another Domain?
│  ├─ Zone apex (@) → ALIAS/ANAME or A record
│  └─ Subdomain → CNAME
├─ Mail Server? → MX record (with priority)
├─ Email Authentication? → TXT record (SPF/DKIM/DMARC)
├─ Service Discovery? → SRV record
├─ Domain Verification? → TXT record
├─ Certificate Control? → CAA record
└─ Subdomain Delegation? → NS record

レコードタイプの詳しい例とパターンについては、references/record-types.md を参照してください。

TTL 戦略

標準的な TTL 値

変更頻度別：

• 安定したレコード：3600-86400s（1-24 時間）- NS、安定した A/AAAA
• 通常運用：3600s（1 時間）- 一般的な Web サイト、MX
• 中程度の変更：300-1800s（5-30 分）- 開発、A/B テスト
• フェイルオーバーのシナリオ：60-300s（1-5 分）- 高速な更新が必要な重要レコード

重要な原則： TTL を短くすると伝播は速くなりますが、DNS クエリの負荷は高くなります。

変更前の手順

DNS の変更を計画する際は、次の手順に従います。

T-48h: Lower TTL to 300s
T-24h: Verify TTL propagated globally
T-0h:  Make DNS change
T+1h:  Verify new records propagating
T+6h:  Confirm global propagation
T+24h: Raise TTL back to normal (3600s)

伝播時間の計算式： Max Time = Old TTL + New TTL + Query Time

例：TTL が 3600s のレコードを変更する場合、完全に伝播するまで最大 2 時間かかります。

ユースケース別の TTL

ユースケース	TTL	理由
本番環境（安定）	3600s	速度と負荷のバランス
変更の予定前	300s	高速な伝播
開発／ステージング	300-600s	頻繁な変更
DNS ベースのフェイルオーバー	60-300s	迅速な復旧
メールサーバー	3600s	変更頻度が低い
NS レコード	86400s	非常に安定

TTL の詳しいシナリオと計算については、references/ttl-strategies.md を参照してください。

DNS-as-Code ツール

ユースケース別のツール選定

Kubernetes DNS 自動化 → external-dns

• Service／Ingress のアノテーションベースの設定
• DNS プロバイダーへの自動同期（20 以上に対応）
• DNS を手動で更新する必要はありません
• examples/external-dns/ を参照してください

複数プロバイダーの DNS 管理 → OctoDNS または DNSControl

• DNS レコードのバージョン管理
• 複数のプロバイダー間で設定を同期
• 適用前に変更をプレビュー
• OctoDNS（Python／YAML）- examples/octodns/ を参照してください
• DNSControl（JavaScript）- examples/dnscontrol/ を参照してください

Infrastructure-as-Code → Terraform

• DNS をクラウドリソースと併せて管理
• プロバイダー固有のリソース（aws_route53_record など）
• examples/terraform/ を参照してください

ツールの比較

ツール	言語	最適な用途	Kubernetes	マルチプロバイダー
external-dns	Go	K8s の自動化	★★★★★	★★★★
OctoDNS	Python/YAML	バージョン管理	★★★	★★★★★
DNSControl	JavaScript	複雑なロジック	★★	★★★★★
Terraform	HCL	IaC との統合	★★★	★★★★

クイックスタート：external-dns

# Kubernetes Service with DNS annotation
apiVersion: v1
kind: Service
metadata:
  name: app
  annotations:
    external-dns.alpha.kubernetes.io/hostname: app.example.com
    external-dns.alpha.kubernetes.io/ttl: "300"
spec:
  type: LoadBalancer
  ports:
    - port: 80

external-dns コントローラーを一度デプロイすれば、アノテーションが付与されたすべての Service／Ingress に対して、DNS レコードが自動的に作成されます。

完全な例については、examples/external-dns/ と references/dns-as-code-comparison.md を参照してください。

クラウド DNS プロバイダーの選択

プロバイダーの特性

AWS Route53

• AWS を多用するインフラストラクチャに最適です
• 高度なルーティングポリシー（重み付け、レイテンシー、地理位置情報、フェイルオーバー）
• 自動フェイルオーバー機能付きのヘルスチェック
• AWS リソース（ELB、CloudFront、S3）向けの ALIAS レコード
• 料金：ゾーンあたり月額 $0.50 ＋ 100 万クエリあたり $0.40

Google Cloud DNS

• GCP ネイティブのアプリケーションに最適です
• 自動キー ローテーションに対応した強力な DNSSEC サポート
• VPC 内部 DNS 向けのプライベートゾーン
• スプリットホライズン DNS（内部と外部で異なるレコード）
• 料金：ゾーンあたり月額 $0.20 ＋ 100 万クエリあたり $0.40

Azure DNS

• Azure ネイティブのアプリケーションに最適です
• Azure Traffic Manager との統合
• Azure Private DNS ゾーン
• アクセス制御用の Azure RBAC
• 料金：ゾーンあたり月額 $0.50 ＋ 100 万クエリあたり $0.40

Cloudflare

• マルチクラウドまたはクラウドに依存しない環境に最適です
• 世界最速の DNS クエリ応答時間
• DDoS 保護を内蔵
• クエリ数無制限の無料プラン
• CDN との統合
• 料金：無料プラン、Pro は月額 $20、Business は月額 $200

選択の判断ツリー

Choose based on:
├─ AWS-heavy? → Route53
├─ GCP-native? → Cloud DNS
├─ Azure-native? → Azure DNS
├─ Multi-cloud? → Cloudflare or OctoDNS/DNSControl
├─ Need fastest global DNS? → Cloudflare
├─ Need DDoS protection? → Cloudflare
└─ Budget-conscious? → Cloudflare (free tier) or Cloud DNS (lowest zone cost)

プロバイダーの詳しい比較と例については、references/cloud-providers.md を参照してください。

DNS ベースのロードバランシング

GeoDNS（地理的ルーティング）

クライアントの位置に基づいて異なる IP アドレスを返し、次のことを実現します。

• レイテンシーを低減する（最寄りのデータセンターにルーティング）
• データの所在地に関する要件に準拠する
• リージョン間で負荷を分散する

パターン例：

Client Location → DNS Response
├─ North America → 192.0.2.1 (US data center)
├─ Europe → 192.0.2.10 (EU data center)
└─ Default → CloudFront edge (global CDN)

重み付けルーティング

次の用途で、割合に応じてトラフィックを分散します。

• ブルーグリーンデプロイ
• カナリアリリース（新バージョンに 10% を振り分け）
• A/B テスト

パターン例：

DNS Responses:
├─ 90% → 192.0.2.1 (stable version)
└─ 10% → 192.0.2.2 (canary version)

ヘルスチェックベースのフェイルオーバー

正常でないエンドポイントからトラフィックを自動的に迂回させます。

パターン：

Primary: 192.0.2.1 (health checked every 30s)
├─ Healthy → Return primary IP
└─ Unhealthy → Return secondary IP (192.0.2.2)

Failover time: ~2-3 minutes
= Health check failures (90s) + TTL expiration (60s)

ロードバランシングの完全な例については、examples/load-balancing/ を参照してください。

トラブルシューティング

基本コマンド

DNS の名前解決を確認する：

# Basic query
dig example.com

# Clean output (just IP)
dig example.com +short

# Query specific DNS server
dig @8.8.8.8 example.com
dig @1.1.1.1 example.com

# Trace resolution path
dig +trace example.com

TTL を確認する：

dig example.com | grep -A1 "ANSWER SECTION"
# Look for TTL value (number before IN A)

伝播を確認する：

# Multiple resolvers
dig @8.8.8.8 example.com +short       # Google
dig @1.1.1.1 example.com +short       # Cloudflare
dig @208.67.222.222 example.com +short # OpenDNS

ローカルの DNS キャッシュをフラッシュする：

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Windows
ipconfig /flushdns

# Linux
sudo systemd-resolve --flush-caches

よくある問題

伝播が遅い：

• 現在の TTL を確認します（古い TTL が先に期限切れになる必要があります）
• 変更の 24～48 時間前に TTL を短くします
• 伝播チェックツールを使用します：whatsmydns.net、dnschecker.org

ゾーン頂点の CNAME：

• エラー：@（ゾーン頂点）では CNAME を使用できません
• 解決策：ALIAS レコード（Route53、Cloudflare）または A レコードを使用します

external-dns がレコードを作成しない：

• アノテーションのスペルを確認します：external-dns.alpha.kubernetes.io/hostname
• ドメインフィルターが一致することを確認します：--domain-filter=example.com
• external-dns のログでエラーを確認します
• プロバイダーの認証情報が設定されていることを確認します

詳しいトラブルシューティングについては、references/troubleshooting.md を参照してください。

よくあるパターン

パターン 1：Kubernetes DNS の自動化

# Deploy external-dns (once per cluster)
helm install external-dns external-dns/external-dns \
  --set provider=aws \
  --set domainFilters[0]=example.com \
  --set policy=sync

# Then annotate Services
apiVersion: v1
kind: Service
metadata:
  annotations:
    external-dns.alpha.kubernetes.io/hostname: api.example.com
    external-dns.alpha.kubernetes.io/ttl: "300"
spec:
  type: LoadBalancer

パターン 2：OctoDNS によるマルチプロバイダー同期

# octodns-config.yaml
providers:
  config:
    class: octodns.provider.yaml.YamlProvider
    directory: ./config
  route53:
    class: octodns_route53.Route53Provider
  cloudflare:
    class: octodns_cloudflare.CloudflareProvider

zones:
  example.com.:
    sources: [config]
    targets: [route53, cloudflare]

パターン 3：DNS ベースのフェイルオーバー

# Route53 with health checks
resource "aws_route53_health_check" "primary" {
  fqdn              = "primary.example.com"
  port              = 443
  type              = "HTTPS"
  resource_path     = "/health"
  failure_threshold = 3
  request_interval  = 30
}

resource "aws_route53_record" "primary" {
  zone_id        = aws_route53_zone.main.zone_id
  name           = "api.example.com"
  type           = "A"
  ttl            = 60
  set_identifier = "primary"

  failover_routing_policy {
    type = "PRIMARY"
  }

  health_check_id = aws_route53_health_check.primary.id
  records         = ["192.0.2.1"]
}

resource "aws_route53_record" "secondary" {
  zone_id        = aws_route53_zone.main.zone_id
  name           = "api.example.com"
  type           = "A"
  ttl            = 60
  set_identifier = "secondary"

  failover_routing_policy {
    type = "SECONDARY"
  }

  records = ["192.0.2.2"]
}

他のスキルとの連携

infrastructure-as-code:

• 他のリソースと併せて、Terraform/Pulumi で DNS を管理します
• IaC リポジトリでゾーンを設定します

kubernetes-operations:

• external-dns で Kubernetes ワークロードの DNS を自動化します
• Ingress コントローラーと連携して DNS を自動設定します

load-balancing-patterns:

• DNS ベースのロードバランシング（GeoDNS、重み付けルーティング）
• ヘルスチェックとフェイルオーバーの設定

security-hardening:

• DNS の整合性を保つための DNSSEC
• 認証局を制御するための CAA レコード
• DNS ベースの DDoS 対策

secret-management:

• DNS プロバイダーの API 認証情報をボールトに保存します
• DDNS の更新メカニズムを保護します

追加リソース

リファレンスドキュメント:

• references/record-types.md - 例を含む詳細なレコードタイプガイド
• references/ttl-strategies.md - TTL のシナリオと伝播時間の計算
• references/cloud-providers.md - プロバイダーの比較と詳細な機能
• references/troubleshooting.md - よくある問題と解決策
• references/dns-as-code-comparison.md - ツール比較表

例:

• examples/external-dns/ - Kubernetes の DNS 自動化
• examples/octodns/ - YAML による複数プロバイダー間の同期
• examples/dnscontrol/ - JavaScript DSL による複数プロバイダーの管理
• examples/terraform/ - クラウドプロバイダーの設定
• examples/load-balancing/ - GeoDNS とフェイルオーバーのパターン

スクリプト:

• scripts/check-dns-propagation.sh - リゾルバー間の伝播を確認します
• scripts/validate-dns-config.py - DNS 設定を検証します
• scripts/export-dns-records.sh - 既存の DNS レコードをエクスポートします
• scripts/calculate-ttl-propagation.py - 伝播時間を計算します

クイックリファレンス

レコードタイプ早見表

レコード	用途	例
A	IPv4 アドレス	example.com → 192.0.2.1
AAAA	IPv6 アドレス	example.com → 2001:db8::1
CNAME	ドメインへのエイリアス	www → example.com
MX	メールサーバー	10 mail.example.com
TXT	テキスト／検証	"v=spf1 include:_spf.google.com ~all"
SRV	サービスの場所	10 60 5060 sip.example.com
NS	ネームサーバーへの委任	ns1.provider.com
CAA	認証局の認可	0 issue "letsencrypt.org"

TTL 早見表

シナリオ	TTL	理由
安定した本番環境	3600s	速度と負荷のバランス
変更前	300s	迅速な伝播
フェイルオーバー	60-300s	迅速な復旧
NS レコード	86400s	非常に安定

プロバイダー早見表

プロバイダー	最適な用途	主な機能
Route53	AWS	高度なルーティング、ヘルスチェック
Cloud DNS	GCP	DNSSEC、プライベートゾーン
Azure DNS	Azure	Traffic Manager との連携
Cloudflare	マルチクラウド	最速、DDoS 対策、無料プラン

ツール早見表

ツール	使用する場面
external-dns	Kubernetes の DNS 自動化
OctoDNS	複数プロバイダー、Python を採用している環境
DNSControl	複数プロバイダー、JavaScript を優先する環境
Terraform	他のインフラストラクチャと併せて DNS を管理する場合