背景
Azure DNSサーバのTTLは60sでA recordを更新したが、なぜか反映は4時間かかりました。
例えば、カスタムドメインはTraffic manager から Azure front doorに切替した場合、DNS上でCnameの変更も必要となります。CNMAE変更後に、Clientからアクセスすると、依然古いTraffic Managerのほうに行っています。
4時間後にようやくAFDにいくようになりました。
基本知識
DNSのクエリ処理は、ユーザーのデバイスから始まり、サーバー間で「再帰的（recursive）」または「イテラティブ（iterative）」に情報を引き継ぎます。最終的に、権威サーバーから正確な情報が得られます。以下に種類ごとの詳細をテーブルでまとめました。
| 種類 | 役割・詳細説明 | 特徴・例 |
|---|---|---|
| ルートネームサーバー (Root Name Server) | インターネットの最上位階層。すべてのDNSクエリの起点で、TLD（トップレベルドメイン、例: .com）のサーバー場所を教えます。クエリを受け取ると、イテラティブ方式で次のサーバーを案内します。 | 世界中に13のルートゾーン（数百台のミラーサーバー）があり、ICANNが管理。非常に安定性が高く、1日あたり数億のクエリを処理。例: a.root-servers.net。 |
| TLDネームサーバー (Top-Level Domain Name Server) | TLD（.com, .jp, .net など）のドメイン情報を管理。ルートサーバーからクエリを受け取り、特定のドメイン（例: example.com）の権威サーバーを案内します。 | 各TLDごとに異なる組織が運用（例: .comはVerisign）。gTLD（汎用）やccTLD（国別）があり、数千のTLDが存在。 |
| オーソリティティブネームサーバー (Authoritative Name Server, 権威サーバー) | 特定のドメインの「最終的な権威」となるサーバー。ドメイン所有者が設定し、DNSレコード（Aレコード: IPアドレス、MX: メールサーバー、CNAME: 別名など）を保持・提供します。クエリに対して直接回答（non-recursive）し、キャッシュされません。プライマリ（主）とセカンダリ（バックアップ）で冗長化。 | ドメイン登録事業者（例: GoDaddy）やホスティング会社（AWS Route 53）が提供。ゾーンファイルで管理。セキュリティのため、DNSSECで署名可能。例: example.comのNSレコードで指定。 |
| リカーシブリゾルバー (Recursive Resolver) | ユーザーのデバイスやISPが最初に問い合わせる「問い合わせ役」のサーバー。クエリをルート → TLD → 権威サーバーと順に再帰的に調べて結果を返します。キャッシュ機能で高速化し、負荷分散のためフォワーディング（他のリゾルバーに転送）も可能。 | ユーザーのローカルDNS（例: 8.8.8.8 Google Public DNS）や企業内サーバー。プライバシー保護のため、DoH（DNS over HTTPS）やDoT（DNS over TLS）対応が増加。負荷が高いため、Anycastで分散。 |
DNSクエリの流れ（権威サーバーとリカーシブリゾルバーを強調した例）
- ユーザーがwww.example.comを入力 → デバイスがリカーシブリゾルバーにクエリ。
- リカーシブリゾルバーがルートサーバーに問い合わせ → ルートは.comのTLDサーバーを紹介。
- リカーシブリゾルバーがTLDサーバーに問い合わせ → TLDはexample.comの権威サーバーを紹介。
- リカーシブリゾルバーが権威サーバーに問い合わせ → 権威サーバーがIPアドレス（例: 192.0.2.1）を直接返却。
- リカーシブリゾルバーが結果をキャッシュしてデバイスに返し、次回高速化。
この流れで、リカーシブリゾルバーは「探偵役」として全体をコーディネートし、権威サーバーは「情報源」として正確性を保証します。全体として、DNSは分散型なので、1つのサーバー障害でも代替経路で動作します。
追加のポイント
- キャッシングサーバー: リカーシブリゾルバーの一種で、頻繁に使われる情報を一時保存。TTL（Time To Live）で有効期限を設定。
- フォワーディングサーバー: リカーシブの一種で、クエリを上位サーバー（例: ISPのDNS）に転送。
- セキュリティの考慮: 権威サーバーはDNSSECで改ざん防止、リカーシブリゾルバーはDDoS攻撃対策（例: Cloudflare 1.1.1.1）。
「再帰的（recursive）」とは、DNSリゾルバーがユーザーのクエリ（例: 「www.example.comのIPアドレスは？」）を完全に解決するまで、自動的に複数のサーバーに順次問い合わせを繰り返す仕組みを指します。リゾルバーが「探偵役」として、すべての階層を自分で掘り下げて結果をユーザーに返すのが特徴です。
「イテラティブ（iterative）」は、各サーバーが次のサーバーを紹介するだけで、リゾルバーが自分で追跡しない方式です。
原因分析
権威サーバでTTLは60sで短いですが、でもリゾルバーにキャッシュしますので、権威サーバにA recordを更新しても
依然キャッシュされた古いIPに解決されます。
DNSキャッシュの影響: ローカルPC、企業プロキシ、ISP（インターネットサービスプロバイダー）、またはCDN/プロキシサーバーが古いレコードをキャッシュするため、TTL（60秒）を超えても古い経路（Traffic Manager）が優先されることがあります。TTLが低い場合でも、キャッシュサーバーがTTLを無視したりします。
グローバルプロパゲーションの遅延: DNS変更は階層的に伝播しますが、ルートサーバーからリゾルバへの反映に最大48時間かかる場合があります。ただし、TTLが低いと通常は数分以内で完了します。4-5時間の遅延は、特定の地域/ISPのキャッシュが頑固に残っている可能性が高いです。
調査方針
まず、切り替え作業後、すぐAzure DNS 権威サーバの状況を確認しました。
以下のコマンドでキャッシュ回避して、確認できます。ns-serverはAzure public DNSのところで確認できます。
dig @ns-server yourdomain.com
例：ちゃんとCNAMEはAFDのCNAMEを指しているかを確認できます。
dig @ns1-02.azure-dns.com tantest.jpninteams.com
; <<>> DiG 9.17.14 <<>> @ns1-02.azure-dns.com tanafdtest.jpninjateams.com
;; ANSWER SECTION:
tanafdtest.jpninjateams.com. 3600 IN CNAME xxxx-xxxxxfaf.b02.azurefd.net.
digがinstallしていない場合、以下のnslookup を使ってもいいです。
注意：もし「Non-authoritative answer」が出たら、キャッシュ経由の応答なので、サーバー指定が効いていない証拠です。
nslookup -type=cname tanafdtest.jpninjateams.com ns1-02.azure-dns.com
サーバー: UnKnown
Address: 13.107.236.2
tanafdtest.jpninjateams.com canonical name = xxxx-xxxx.b02.azurefd.net
PowerShell (Windows)をつかってもいいですね。
Resolve-DnsName -Name tanafdtest.jpninjateams.com -Type CNAME -Server ns1-02.azure-dns.com
online webで該当カスタムドメインのCnameの確認も可能です。
https://dnschecker.org/#CNAME/tanafdtest.jpninjateams.com
次.Local PCのDNS cacheをクリアします。
Windows : ipconfig /flushdns。
Mac OS:
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
Linux OS:
sudo systemd-resolve --flush-caches
Windows PCのDNSキャッシュ（クライアントサイドのローカルキャッシュ）は、デフォルトで**ポジティブなレスポンス（正常に解決されたDNSレコード）を24時間（86,400秒）**保持します。一方、**ネガティブなレスポンス（解決できない場合、例: NXDOMAIN）は5分（300秒）**のみ保持されます。
これはWindowsのDNSクライアントの標準設定で、TTL（Time To Live）に基づいて管理されますが、キャッシュの最大保持時間はレジストリキー（HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\MaxCacheTtl など）で制御可能です。実際の動作では、DNSレコードのTTLがこれを超えない限り、24時間の保持が適用されます。
キャッシュをクリアしたい場合は、ipconfig /flushdns コマンドを実行してください。
最後、Traffic Managerのプロファイルを一時無効化して古い経路を強制切断もあります。
結論：
上記のLocal PCのcacheを実施しても依然古いIP/cnameになる場合、企業プロキシ、ISP（インターネットサービスプロバイダー）、またはCDN/プロキシサーバーが古いレコードをキャッシュするため、そちらのcacheもどうしてもクリアは難しいなので、待つしかないですね。