ガイド中級

DNS 移行ガイド — 移行前・移行中・移行後のチェックポイント

2026年4月24日更新所要時間: 30分

DNS 移行の失敗を防ぐには、移行前のレコード全記録、TTL の事前短縮、新旧プロバイダーでの並走が不可欠です。手順を間違えるとサイトの表示停止やメールの不達に直結します。A レコードや CNAME だけでなく、MX・SPF・DKIM・DMARC・CAA・SOA・AAAA など移行対象は多岐にわたります。DNSSEC を運用中のドメインでは、DS レコードの扱いを誤ると名前解決そのものが失敗します。

DNS レコードの管理方法は組織によってさまざまです。レジストラや DNS プロバイダーの管理画面から手動で操作するケースもあれば、Terraform や Pulumi などの IaC（Infrastructure as Code）ツールで DNS レコードをコードとして管理しているケースもあります。IaC を使っていない場合、次の段落は読み飛ばして構いません。Route 53、Cloud DNS、Azure DNS などの API を持つサービスでは、IaC による管理が一般的になりつつあります。このガイドの手順は管理方法を問わず適用できますが、IaC で管理している場合はレコードの変更を直接 DNS プロバイダーの管理画面から行うのではなく、コード側で変更してください。

このガイドでは、移行前の準備から移行後の検証まで、見落としがちなポイントを順番に確認できます。

example.com の部分は実際のドメイン名に置き換えてください。

timeline
    title DNS 移行タイムライン
    移行 48h 前
        : TTL を 300 に下げる
        : 旧 TTL 時間だけ待つ
    移行当日
        : 新プロバイダーにレコードをコピー
        : NS を新プロバイダーに変更
        : 反映を監視（24〜48h）
    移行後（48〜72h 経過）
        : 全レコードの最終確認
        : TTL を元に戻す
        : 旧プロバイダーのレコードは当面保持

チェックリスト一括コピー用

以下をコピーして手元のメモや Issue に貼り付ければ、そのまま確認リストとして使えます。

## DNS 移行チェックリスト

### Step 1 移行前 — 現状を記録する
- [ ] 現在の DNS レコードをすべてエクスポートまたはスクリーンショットで記録した
- [ ] A・AAAA・MX・TXT・CNAME・NS・SOA・CAA の各レコードタイプを個別に取得・保存した
  - `dig A example.com +noall +answer`（タイプごとに実行）
- [ ] 各レコードの TTL 値を記録した
- [ ] サブドメイン（www, mail, api, cdn など）の A・AAAA・CNAME レコードをすべて把握した
- [ ] メール関連レコード（MX・SPF・DKIM・DMARC）を個別にリストアップした
- [ ] DNSSEC を運用中の場合、DS レコードと DNSKEY レコードを記録した
- [ ] CAA レコードの有無と設定内容を確認した

### Step 2 移行前 — TTL を下げる
- [ ] 移行の 24〜48 時間前に主要レコードの TTL を 300（5分）に下げた
  - `dig A example.com`（ANSWER SECTION の TTL 値を確認）
- [ ] TTL 変更後、旧 TTL の時間が経過するまで待った
- [ ] 外部から TTL が反映されていることを確認した
- [ ] SOA レコードの Minimum フィールド（ネガティブキャッシュ TTL）を確認した

### Step 3 移行中 — レコードを新プロバイダーに移す
- [ ] 新プロバイダーにすべての DNS レコードを追加した（A, AAAA, MX, TXT, CNAME, NS, SOA, CAA）
- [ ] MX レコードの priority 値が旧プロバイダーと一致している
- [ ] SPF レコード（TXT）が正しくコピーされている
- [ ] DKIM レコード（TXT）がセレクターごとにコピーされている
- [ ] DMARC レコード（TXT）がコピーされている
- [ ] CAA レコードがコピーされている
- [ ] DNSSEC 運用中の場合、新プロバイダーで DNSSEC を有効化し新しい DS レコードを取得した
- [ ] レジストラでネームサーバーを新プロバイダーのものに変更した
- [ ] DNSSEC 運用中の場合、レジストラの DS レコードを新プロバイダーのものに更新した

### Step 4 移行中 — 反映を監視する
- [ ] NS レコードが新プロバイダーのネームサーバーを指している
  - `dig NS example.com +short`
- [ ] A レコードが意図した IP アドレスに解決されている
  - `dig A example.com +short`
- [ ] AAAA レコード（設定済みの場合）が正しく解決されている
- [ ] MX レコードが正しいメールサーバーを指している
  - `dig MX example.com +short`
- [ ] SPF・DKIM・DMARC が引き続き有効である
- [ ] SOA レコードのシリアル番号が新プロバイダーの値に更新されている
- [ ] CAA レコードが正しく解決されている
- [ ] サブドメインの A・AAAA・CNAME が正しく解決されている

### Step 5 移行後 — 最終確認と復旧
- [ ] すべてのレコードタイプ（A, AAAA, MX, TXT, CNAME, NS, SOA, CAA）が正しく解決されている
- [ ] SSL/TLS 証明書が外部から正常にアクセスできる
- [ ] メール送受信が正常に動作している
- [ ] TTL を運用値（3600 など）に戻した
- [ ] DNSSEC 運用中の場合、DNSSEC 検証が正常に通過している
- [ ] 旧プロバイダーのレコードは最低 72 時間は削除しない

### 一括確認（API）
- `curl "https://labee.dev/api/dns?domain=example.com"`
- `curl "https://labee.dev/api/dns?domain=example.com&type=NS,SOA"`
- `curl "https://labee.dev/api/mail-auth?domain=example.com"`
- `curl "https://labee.dev/api/ssl-cert?hostname=example.com"`

Step 1 移行前 — 現状を記録する

DNS 移行で最も多い失敗は「旧環境のレコードを正確に把握していなかった」です。移行後に初めて MX レコードの漏れに気づき、メールが届かなくなるケースは珍しくありません。移行前に全レコードを記録し、移行後の照合に使えるベースラインを作ります。Terraform などの IaC で管理している場合は、既存のコードがベースラインになりますが、手動で追加されたレコードがないか dig で実態を確認してください。

チェック項目

現在の DNS レコードをすべてエクスポートまたはスクリーンショットで記録した
A・AAAA・MX・TXT・CNAME・NS・SOA・CAA の各レコードタイプを個別に取得・保存した
各レコードの TTL 値を記録した
サブドメイン（www, mail, api, cdn など）の A・AAAA・CNAME レコードをすべて把握した
メール関連レコード（MX・SPF・DKIM・DMARC）を個別にリストアップした
DNSSEC を運用中の場合、DS レコードと DNSKEY レコードを記録した
CAA レコードの有無と設定内容を確認した

確認コマンド

レコードタイプごとに dig で取得します。

dig A example.com +noall +answer
dig AAAA example.com +noall +answer
dig MX example.com +noall +answer
dig TXT example.com +noall +answer
dig NS example.com +noall +answer
dig SOA example.com +noall +answer
dig CAA example.com +noall +answer

example.com.    3600  IN  A     203.0.113.1
example.com.    3600  IN  MX    10 mail.example.com.
example.com.    3600  IN  TXT   "v=spf1 include:_spf.google.com ~all"
example.com.    3600  IN  NS    ns1.old-provider.com.
example.com.    3600  IN  NS    ns2.old-provider.com.
example.com.    3600  IN  SOA   ns1.old-provider.com. admin.example.com. 2024010101 3600 900 604800 86400

出力結果をテキストファイルに保存しておくと、移行後の照合に使えます。

labee.dev の API でも全レコードを一括取得できます。

curl "https://labee.dev/api/dns?domain=example.com"

{
  "success": true,
  "data": {
    "domain": "example.com",
    "records": {
      "A": [{ "address": "203.0.113.1", "ttl": 3600 }],
      "AAAA": null,
      "MX": [{ "priority": 10, "exchange": "mail.example.com" }],
      "TXT": [["v=spf1 include:_spf.google.com ~all"]],
      "NS": ["ns1.old-provider.com", "ns2.old-provider.com"],
      "CNAME": null,
      "SOA": [{ "mname": "ns1.old-provider.com", "rname": "admin.example.com", "serial": 2024010101, "refresh": 3600, "retry": 900, "expire": 604800, "minimum": 86400 }],
      "CAA": [{ "flags": 0, "tag": "issue", "value": "letsencrypt.org" }]
    }
  },
  "error": null,
  "meta": { "responseTime": 245 }
}

data.records の各フィールドがレコードタイプに対応しています。null はそのレコードタイプが存在しないことを意味します。この JSON を保存しておけば、移行後に同じ API を叩いて差分を比較できます。

メール認証レコードは専用のエンドポイントで詳細に確認できます。

curl "https://labee.dev/api/mail-auth?domain=example.com"

{
  "success": true,
  "data": {
    "spf": {
      "record": "v=spf1 include:_spf.google.com ~all",
      "exists": true
    },
    "dkim": {
      "mode": "auto",
      "record": "v=DKIM1; k=rsa; p=MIIBIjAN...",
      "exists": true,
      "selector": "google",
      "matches": [
        { "selector": "google", "record": "v=DKIM1; k=rsa; p=MIIBIjAN...", "exists": true }
      ],
      "checkedSelectors": ["google", "selector1", "selector2", "s1", "s2", "k1", "k2", "k3", "default", "dkim", "mail", "smtp", "mte1", "mte2", "pdk1", "pdk2", "mesmtp", "zoho"],
      "exhaustive": false
    },
    "dmarc": {
      "record": "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com",
      "exists": true,
      "source": "exact",
      "domain": "example.com"
    },
    "bimi": { "record": null, "exists": false }
  },
  "error": null,
  "meta": { "responseTime": 142 }
}

data.spf.exists、data.dkim.exists、data.dmarc.exists がすべて true であることを確認し、各 record の値を記録してください。

Step 2 移行前 — TTL を下げる

TTL（Time to Live）は、リゾルバーが DNS レコードをキャッシュする秒数です。TTL が 3600（1時間）のまま移行すると、ネームサーバーを切り替えた後も最大1時間は旧レコードを参照するクライアントが残ります。移行前に TTL を短くしておくと、切り替え後に新レコードが速やかに浸透します。

TTL を下げるタイミングが重要です。TTL を 300 に変更しても、変更前の TTL（たとえば 3600）がキャッシュに残っている間は効果がありません。旧 TTL が 86400（24時間）であれば、移行の 48時間前 に TTL を下げる必要があります。旧 TTL が 3600（1時間）であれば、移行の 2時間前で十分です。

チェック項目

移行の 24〜48 時間前に主要レコード（A, AAAA, MX, TXT, CNAME）の TTL を 300（5分）に下げた
TTL 変更後、旧 TTL の時間が経過するまで待った（旧 TTL が 3600 なら最低1時間）
外部から TTL が反映されていることを確認した
SOA レコードの Minimum フィールド（ネガティブキャッシュ TTL）を確認した

確認コマンド

dig A example.com

;; ANSWER SECTION:
example.com.    300   IN  A     203.0.113.1

ANSWER SECTION の2列目が TTL です。300 に変わっていれば反映済みです。

SOA レコードの Minimum フィールドも確認します。この値はネガティブキャッシュ（「レコードが存在しない」という応答のキャッシュ）の TTL として使われます。移行中に一時的にレコードが引けなくなった場合、この値が大きいとリゾルバーが「存在しない」という結果をキャッシュし続けます。

dig SOA example.com +short

ns1.old-provider.com. admin.example.com. 2024010101 3600 900 604800 86400

末尾の数値（86400 = 24時間）がネガティブキャッシュ TTL です。RFC 2308 で規定されています。

labee.dev の API で TTL と SOA を確認できます。

curl "https://labee.dev/api/dns?domain=example.com&type=A,SOA"

{
  "success": true,
  "data": {
    "domain": "example.com",
    "records": {
      "A": [{ "address": "203.0.113.1", "ttl": 300 }],
      "SOA": [{ "mname": "ns1.old-provider.com", "rname": "admin.example.com", "serial": 2024010101, "refresh": 3600, "retry": 900, "expire": 604800, "minimum": 86400 }]
    }
  },
  "error": null,
  "meta": { "responseTime": 98 }
}

data.records.A[0].ttl が 300 になっていることを確認してください。type パラメーターにカンマ区切りでレコードタイプを指定すると、必要なタイプだけを取得できます。

Step 3 移行中 — レコードを新プロバイダーに移す

レコードのコピーは「全レコードの追加 → ネームサーバーの変更」の順で行います。ネームサーバーを先に変更すると、新プロバイダーにレコードがない状態でクエリーが到達し、NXDOMAIN（レコード不存在）が返ります。この応答はネガティブキャッシュされるため、後からレコードを追加しても SOA の Minimum フィールドで指定された時間（たとえば 24時間）は名前解決が失敗し続けます。

DNSSEC を運用中のドメインでは、DS レコードと DNSKEY の不整合に注意が必要です。移行手順の詳細は「発展的なトピック」の DNSSEC セクションを参照してください。DNSSEC を運用していない場合、この段落は読み飛ばして構いません。

チェック項目

新プロバイダーにすべての DNS レコードを追加した（A, AAAA, MX, TXT, CNAME, NS, SOA, CAA）
MX レコードの priority 値が旧プロバイダーと一致している
SPF レコード（TXT）が正しくコピーされている
DKIM レコード（TXT）がセレクターごとにコピーされている（{selector}._domainkey.example.com）
DMARC レコード（TXT）がコピーされている（_dmarc.example.com）
CAA レコードがコピーされている（SSL/TLS 証明書の発行元制限）
DNSSEC 運用中の場合、新プロバイダーで DNSSEC を有効化し新しい DS レコードを取得した
レジストラでネームサーバーを新プロバイダーのものに変更した
DNSSEC 運用中の場合、レジストラの DS レコードを新プロバイダーのものに更新した

確認コマンド

新プロバイダーの権威サーバーに直接クエリーを送ることで、ネームサーバー変更前でもレコードが正しく設定されているか確認できます。

dig A example.com @ns1.new-provider.com +noall +answer
dig MX example.com @ns1.new-provider.com +noall +answer
dig TXT example.com @ns1.new-provider.com +noall +answer
dig CAA example.com @ns1.new-provider.com +noall +answer

example.com.    300   IN  A     203.0.113.1
example.com.    300   IN  MX    10 mail.example.com.
example.com.    300   IN  TXT   "v=spf1 include:_spf.google.com ~all"
example.com.    300   IN  CAA   0 issue "letsencrypt.org"

@ns1.new-provider.com の部分を新プロバイダーのネームサーバーに置き換えてください。旧プロバイダーの出力と値が一致していれば、レコードのコピーは正しく完了しています。

Step 4 移行中 — 反映を監視する

ネームサーバーの変更後、新しい NS レコードがルートサーバーや TLD サーバーに反映されるまで、一般的に 24〜48時間 かかります。この期間中、一部のリゾルバーは旧プロバイダーに、一部は新プロバイダーにクエリーを送ります。移行直後は両方のプロバイダーで同じレコードが返る状態を維持してください。

チェック項目

NS レコードが新プロバイダーのネームサーバーを指している
A レコードが意図した IP アドレスに解決されている
AAAA レコード（設定済みの場合）が正しく解決されている
MX レコードが正しいメールサーバーを指している
SPF・DKIM・DMARC が引き続き有効である
SOA レコードのシリアル番号が新プロバイダーの値に更新されている
CAA レコードが正しく解決されている
サブドメインの A・AAAA・CNAME が正しく解決されている

確認コマンド

dig NS example.com +short

ns1.new-provider.com.
ns2.new-provider.com.

新プロバイダーのネームサーバーが返っていれば、NS の変更は反映済みです。

各レコードタイプを順に確認します。

dig A example.com +short
dig AAAA example.com +short
dig MX example.com +short
dig SOA example.com +short

203.0.113.1
10 mail.example.com.
ns1.new-provider.com. admin.example.com. 2024041501 3600 900 604800 86400

labee.dev の API で全レコードを一括確認します。

curl "https://labee.dev/api/dns?domain=example.com"

{
  "success": true,
  "data": {
    "domain": "example.com",
    "records": {
      "A": [{ "address": "203.0.113.1", "ttl": 300 }],
      "AAAA": null,
      "MX": [{ "priority": 10, "exchange": "mail.example.com" }],
      "TXT": [["v=spf1 include:_spf.google.com ~all"]],
      "NS": ["ns1.new-provider.com", "ns2.new-provider.com"],
      "CNAME": null,
      "SOA": [{ "mname": "ns1.new-provider.com", "rname": "admin.example.com", "serial": 2024041501, "refresh": 3600, "retry": 900, "expire": 604800, "minimum": 86400 }],
      "CAA": [{ "flags": 0, "tag": "issue", "value": "letsencrypt.org" }]
    }
  },
  "error": null,
  "meta": { "responseTime": 187 }
}

Step 1 で保存した JSON と比較し、data.records.NS が新プロバイダーに変わっていること、それ以外のレコードの値が一致していることを確認してください。

メール認証の継続も確認します。

curl "https://labee.dev/api/mail-auth?domain=example.com"

{
  "success": true,
  "data": {
    "spf": {
      "record": "v=spf1 include:_spf.google.com ~all",
      "exists": true
    },
    "dkim": {
      "mode": "auto",
      "record": "v=DKIM1; k=rsa; p=MIIBIjAN...",
      "exists": true,
      "selector": "google",
      "matches": [
        { "selector": "google", "record": "v=DKIM1; k=rsa; p=MIIBIjAN...", "exists": true }
      ],
      "checkedSelectors": ["google", "selector1", "selector2", "s1", "s2", "k1", "k2", "k3", "default", "dkim", "mail", "smtp", "mte1", "mte2", "pdk1", "pdk2", "mesmtp", "zoho"],
      "exhaustive": false
    },
    "dmarc": {
      "record": "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com",
      "exists": true,
      "source": "exact",
      "domain": "example.com"
    },
    "bimi": { "record": null, "exists": false }
  },
  "error": null,
  "meta": { "responseTime": 142 }
}

data.spf.exists、data.dkim.exists、data.dmarc.exists がすべて true のままであることを確認してください。Step 1 の結果と照合し、record の値が変わっていないことも確認します。

Step 5 移行後 — 最終確認と復旧

ネームサーバー変更から 48〜72時間 が経過したら、最終確認を行います。TTL を運用値に戻し、SSL/TLS 証明書の到達性を確認し、旧プロバイダーの後処理を進めます。

チェック項目

すべてのレコードタイプ（A, AAAA, MX, TXT, CNAME, NS, SOA, CAA）が正しく解決されている
SSL/TLS 証明書が外部から正常にアクセスできる
メール送受信が正常に動作している
TTL を運用値（3600 など）に戻した
DNSSEC 運用中の場合、DNSSEC 検証が正常に通過している
旧プロバイダーのレコードは最低 72時間 は削除しない

確認コマンド

全レコードタイプを一括確認します。

dig A example.com +short
dig AAAA example.com +short
dig MX example.com +short
dig TXT example.com +short
dig NS example.com +short
dig CAA example.com +short

SSL/TLS 証明書の到達性を確認します。

curl -sI https://example.com | head -1

HTTP/2 200

labee.dev の API でも SSL/TLS の到達性を確認できます。

curl "https://labee.dev/api/ssl-cert?hostname=example.com"

{
  "success": true,
  "data": {
    "hostname": "example.com",
    "port": 443,
    "reachable": true,
    "status": 200
  },
  "error": null,
  "meta": { "responseTime": 312 }
}

data.reachable が true、data.status が 200 であることを確認してください。CAA レコードで証明書発行元を制限している場合、新プロバイダーへの移行後に証明書の自動更新が失敗することがあります。CAA レコードに利用中の認証局（letsencrypt.org、amazon.com、pki.goog など）が設定されていることを dig で確認してください。

DNSSEC の検証状態は dig の +dnssec フラグで確認できます。

dig A example.com +dnssec +short

203.0.113.1
A 13 2 3600 20240501000000 20240401000000 12345 example.com. XXXXXX...

RRSIG レコードが返れば、ゾーンに DNSSEC の署名が設定されています。さらに dig A example.com +dnssec（+short なし）を実行し、ヘッダーの flags: に ad（Authenticated Data）が含まれていれば、リゾルバーによる DNSSEC 検証が正常に通過しています。

よくある設定ミス

MX レコードのコピー漏れ

A レコードや CNAME のコピーに集中し、MX レコードを忘れるケースです。Web サイトは正常に表示されるため移行が成功したと判断し、数日後にメールが届かなくなって初めて気づきます。MX レコードだけでなく、SPF・DKIM・DMARC の TXT レコードも忘れずにコピーしてください。

SPF・DKIM レコードの移行漏れ

MX レコードをコピーしても、SPF の TXT レコードや DKIM のセレクターレコード（{selector}._domainkey.example.com）がなければメール認証は失敗します。Gmail や Microsoft 365 は SPF・DKIM・DMARC のすべてを検証するため、1つでも欠けると配信率が低下するか、受信を拒否されます。

ネームサーバー変更前にレコードを追加していない

ネームサーバーを先に変更し、後からレコードを追加する手順は危険です。新プロバイダーにレコードがない状態でクエリーが届くと NXDOMAIN が返り、この応答は SOA レコードの Minimum フィールドで指定された時間だけキャッシュされます。Minimum が 86400（24時間）の場合、レコードを追加しても 24時間 はキャッシュが残ります。

DNSSEC の DS レコードと DNSKEY の不整合

DNSSEC を運用中のドメインで、旧プロバイダーの DS レコードが残ったまま新プロバイダーのネームサーバーに切り替えると、DS レコードが指す DNSKEY が新プロバイダーに存在しないため DNSSEC 検証が失敗します。リゾルバーは SERVFAIL を返し、ドメイン全体が解決不能になります。移行前に DNSSEC を一時的に無効化するか、新プロバイダーの DS レコードを事前にレジストラに追加する方法があります。

CAA レコードの移行漏れによる証明書更新の失敗

CAA レコードは SSL/TLS 証明書を発行できる認証局を制限します（RFC 8659）。旧プロバイダーで利用中の認証局（letsencrypt.org、amazon.com など）を設定していた場合、新プロバイダーに CAA レコードをコピーしないと証明書の自動更新が失敗します。CAA レコードが存在しなければ全認証局が発行可能ですが、存在するのに不完全な場合は制限として機能します。

TTL を下げずに移行した

旧 TTL が 86400（24時間）の状態で移行すると、最大 24時間 は旧レコードを参照するクライアントが残ります。Web サイトは旧サーバーに、メールは旧メールサーバーに送信され続けます。旧サーバーをすぐに停止すると、この期間中にアクセス不能やメール不達が発生します。

発展的なトピック

DNS 移行が完了したら、名前解決の信頼性や安全性をさらに高める仕組みも検討してください。

DNSSEC

DNS 応答に電子署名を付与し、応答が改ざんされていないことをリゾルバーが検証する仕組みです。DS レコード、DNSKEY レコード、RRSIG レコードで構成され、親ゾーンから子ゾーンへの信頼チェーンで動作します。

DNSSEC を運用中のドメインを移行する場合は、旧・新の DS レコードと DNSKEY を並存させた状態で切り替える必要があります。手順は (1) 旧プロバイダーでの鍵ローテーションを停止、(2) 新プロバイダーで DNSSEC を有効化し新しい DNSKEY を取得、(3) 両プロバイダーが両方の DNSKEY を提供するよう設定、(4) レジストラに新 DS レコードを追加（旧 DS と並存）、(5) NS を新プロバイダーに変更、(6) キャッシュ消失後に旧 DS を削除、の順です。旧 DS レコードと新 DNSKEY の不整合が起きると、DNSSEC 検証に失敗してドメイン全体が解決不能になります。移行手順が複雑な場合は、移行前に DNSSEC を一時的に無効化する方法もあります。

用語解説DNSSEC（Domain Name System Security Extensions）DNS 応答にデジタル署名を付与し、データの完全性と出自を検証可能にするセキュリティ拡張。キャッシュポイズニング対策として RFC 4033-4035 で標準化。

グルーレコード

ネームサーバーのホスト名が委任先のゾーン内にある場合（ns1.example.com が example.com のネームサーバーである場合）、親ゾーンに A/AAAA レコードを「グルー」として登録する必要があります。ネームサーバー変更時にグルーレコードの更新を忘れると、名前解決が循環参照に陥ります。

用語解説グルーレコード（Glue Record）委任先ネームサーバーが自身の配下にある場合に生じる循環参照を解決するため、親ゾーンに登録する A/AAAA レコード。DNS 委任の基盤。

ネガティブキャッシュ

「レコードが存在しない」という応答も、SOA レコードの Minimum フィールドで指定された時間だけキャッシュされます（RFC 2308）。移行中にレコードが一時的に引けなくなった場合、この仕組みにより復旧が遅れます。

用語解説ネガティブキャッシュ（Negative Caching）存在しない DNS レコードへの否定応答をリゾルバーがキャッシュする仕組み。新規レコード追加後に「反映されない」原因となる。

DNS 伝播

ネームサーバーの変更が世界中のリゾルバーに反映されるまでの過程です。TTL やキャッシュの仕組みにより、同じドメインでも参照するリゾルバーによって異なる結果が返る期間が発生します。

用語解説DNS 伝播（DNS Propagation）DNS レコードの変更が世界中のリゾルバーに反映される過程。実態はキャッシュの期限切れであり、TTL の事前短縮で待ち時間を短縮できる。

SOA レコード

ゾーンの管理情報を定義するレコードです。シリアル番号、リフレッシュ間隔、ネガティブキャッシュ TTL などのフィールドを持ち、ゾーン転送やキャッシュの動作に影響します。

用語解説SOA レコード（Start of Authority）DNS ゾーンの管理情報と権威の起点を定義するレコード。シリアル番号やリフレッシュ間隔でゾーン転送を制御する。

実際のドメインで確認してみる

登録不要、無料です。

無料で試す

DNS 移行ガイド — 移行前・移行中・移行後のチェックポイント

チェックリスト一括コピー用

Step 1 移行前 — 現状を記録する

チェック項目

確認コマンド

Step 2 移行前 — TTL を下げる

チェック項目

確認コマンド

Step 3 移行中 — レコードを新プロバイダーに移す

チェック項目

確認コマンド

Step 4 移行中 — 反映を監視する

チェック項目

確認コマンド

Step 5 移行後 — 最終確認と復旧

チェック項目

確認コマンド

よくある設定ミス

MX レコードのコピー漏れ

SPF・DKIM レコードの移行漏れ

ネームサーバー変更前にレコードを追加していない

DNSSEC の DS レコードと DNSKEY の不整合

CAA レコードの移行漏れによる証明書更新の失敗

TTL を下げずに移行した

発展的なトピック

DNSSEC

グルーレコード

ネガティブキャッシュ

DNS 伝播

SOA レコード

実際のドメインで確認してみる

関連ガイド

DMARC ポリシー段階的移行ガイド — p=none から p=reject へ安全に移行する手順

SPF レコード最適化ガイド — 10 lookup 上限を超えた時の対処法

SSL 証明書の管理ガイド — 自動更新の落とし穴と対策