背景

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

https://digwebinterface.com/?hostnames=tanafdtest.jpninjateams.com&type=&norecursive=on&ns=resolver&useresolver=9.9.9.10&nameservers=

次.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もどうしてもクリアは難しいなので、待つしかないですね。