ナビゲーション全体を読み込み中です。

Elevate 2026へのカウントダウンが始まりました。 今すぐ登録 シカゴ、ロンドン、またはシドニーで私たちと一緒に過ごしませんか。

Partners

ドキュメント

LMアカデミー

LMコミュニティ

価格

Platform
解決策
業種
職種
結果はありません。
無料トライアル

14日間フルアクセス LogicMonitor プラットフォーム

DNS監視

DNS TTL値：チュートリアルとベストプラクティス

DNS TTLは、リゾルバがレコードをキャッシュする期間を決定する隠れた設定です。設定値が高すぎると変更の反映が遅くなり、低すぎるとリゾルバの負荷が急上昇します。適切な設定方法をご紹介します。

10〜15分
デントン千倉

章

    ニュースレター

    最新情報のメール配信を登録

    最新のブログ、ホワイトペーパー、電子ガイドなどを直接受信ボックスにお届けします。

    シェア

    クイックダウンロード:

    DNSのTTL（Time to Live）値は、リゾルバがレコードをキャッシュしてから再度クエリを実行するまでの期間を決定するもので、DNSのパフォーマンスとインターネット全体に変更が伝播する速度の両方に直接影響を与える設定です。

    • TTLは、キャッシュ効率と変更伝播速度のバランスを制御します。TTLが短いほど伝播は速くなりますが、リゾルバへのクエリ負荷が高くなります。TTLが長いほどパフォーマンスは向上しますが、DNSの変更は遅くなります。

    • レコードの種類によって、適切なTTL戦略は異なります。NSレコードとSOAレコードは長めのTTLが適していますが、アクティブフェイルオーバーやロードバランシングで使用されるAレコードは短めに設定する必要があります。

    • 動的なTTL管理（計画的な変更の前にTTLを徐々に下げ、その後再び上げる）は、移行やIPアドレス変更時の迅速な伝播を保証する最も確実な方法です。

    • TTLの設定ミスは、2つの一般的な障害モードを引き起こします。1つは、古いサーバーにユーザーが接続されたままになる古いレコードの存在、もう1つは、不必要なクエリ量で権威サーバーに過負荷をかける極端に低い値です。

    インターネットの旅はDNSから始まります。ブラウザにウェブサイトの名前を入力したり、ソーシャルメディアアプリを開いたり、メールを入力したりするたびに、コンピュータやスマートフォンはDNSルックアップを実行して、接続先のIPアドレスを特定します。 

    DNSルックアップのパフォーマンスは、エンドユーザーがアプリケーションやウェブサイトをどれだけ快適に利用できるかを左右する最初の要素です。DNSの実装では、最近解決されたドメイン名を保存することでIPアドレスへの変換にかかる時間を節約するため、キャッシュが一般的に使用されています。Time To Live（TTL）値は、重要なDNS情報がキャッシュに保持される期間を決定するため、DNSパフォーマンス、ひいてはネットワークシステム全体のパフォーマンスを決定する上で重要な役割を果たします。

    この記事では、DNSのTTL値について詳しく解説し、高いネットワークパフォーマンスを確保するためにTTL値を選択および変更する際のベストプラクティスについて説明します。

    主要概念の要約 

    DNS解決DNS解決とは、DNSサーバーとクライアントがDNSアドレスをIPアドレスに変換するために使用するプロセスです。
    DNSレコードのキャッシュとブラウジング体験DNSリゾルバとTTL値は、エンドユーザーエクスペリエンスを決定する上で重要な役割を果たします。
    DNSゾーンファイル形式BIND DNSゾーンファイルは、異なるレコードタイプとTTL値を持つ特殊な形式に従います。
    長いTTL値と短いTTL値の長所と短所TTL値が高い場合も低い場合も、それぞれプラスとマイナスの両面で潜在的な影響がある。
    TTL値の選択に関するベストプラクティスさまざまな種類のDNSレコードに対して適切なTTL値を設定するための推奨事項に従うことで、パフォーマンスを向上させることができます。
    DNSを使用したサービス負荷分散とフェイルオーバーPowerDNSの設定スニペットを使用すると、アプリケーションのチェックやサービスのフェイルオーバーを実行できます。
    ダイナミックDNSのTTLTTL値の選択は、動的DNSレコードに影響を与えます。

    DNS解決プロセス

    DNSのTTL値とその重要性を理解するための前提として、まずはDNS解決プロセスの仕組みについて簡単に説明しましょう。

    DNSルックアップには、再帰型と反復型の2種類があります。再帰型クエリとは、DNSサーバーがエンドクライアントに代わってDNSレコードの完全なルックアップを実行するものです。反復型ルックアップとは、DNSサーバーがリソースレコードを返すか、別のDNSサーバーにルックアップの実行を依頼するものです。 

    再帰的なDNS解決は通常、8つのステップからなるプロセスです。

    1. クライアントは、ウェブサイトのIPアドレスを取得するために、サービスプロバイダのDNSリゾルバにリクエストを送信します。 
    2. DNSリゾルバは、ウェブサイトのIPアドレスを提供する権限を持つネームサーバーを取得するために、最上位のDNSルートサーバーにクエリを送信します。
    3. DNSルートサーバーは、トップレベルドメイン（TLD）サーバーのアドレスを含む応答を返します。
    4. その後、リゾルバはTLDサーバーにリクエストを送信します。
    5. TLDサーバーは、ウェブサイトドメインの権威ネームサーバーを返します。
    6. リゾルバは次にネームサーバーに問い合わせて、ウェブサイトのIPアドレスを取得します。
    7. アドレスはリゾルバに返されます。
    8. ウェブサイトのアドレスは、依頼元のクライアントに提供されます。 

    解決処理が完了すると、クライアントは提供されたIPアドレスを使用してWebサーバーに接続します。

    DNS解決プロセス

    DNSレコードのキャッシュとブラウジング体験

    IPアドレスの取得にかかる時間は、クライアントのブラウジング体験に直接影響するため、DNSリゾルバはクライアントに返された応答をキャッシュすることで、解決プロセスを効率化し、より良いユーザーエクスペリエンスを提供します。このキャッシュされた応答は、同じウェブサイトのアドレスを要求する次のクライアントに返送されます。 

    DNSレコードには、キャッシュにDNS解決レコードが保持される期間と、更新が必要になるタイミングを指定するTTL（Time to Live）値が設定されます。適切な値を選択するには、高いパフォーマンスを維持することと、キャッシュに保存された応答が定期的に更新されるようにすることとのバランスを取る必要があります。

    DNSゾーンファイル形式

    ドメインネームシステム (DNS) は、グローバルインターネット上のすべてのドメイン名にまたがる階層構造です。その巨大な規模のため、DNS を分割する必要があります。 ゾーンこれらは、全体的なネームスペースの特定の部分であり、通常は特定の組織によって管理されます。たとえば、MyDomain という組織が、mydomain.com という DNS ゾーンを担当している場合があります。

    特定の DNS ゾーンがどのように機能するかに関するコア情報は、その DNS に格納されます。 ゾーンファイルゾーンファイルには、DNS名と対応するIPアドレスのマッピングなど、ゾーンの動作を制御するパラメータが含まれています。この記事の目的において重要なのは、ゾーンファイルにはDNSキャッシュを制御するために使用されるさまざまな種類のTTL値も指定されていることです。前述のように、これらの値はDNS、ひいてはサイトのパフォーマンスにおいて重要な役割を果たします。以下に、ドメイン名が構成された構成ファイル形式を示します。 バインドDNSご覧のとおり、ゾーンのデフォルトのTTL値はファイルの一番上に記述されています。この例では3日間です。このTTL値は、明示的に上書きされない限り（後ほど説明します）、ゾーン内のすべてのDNSリソースレコードのデフォルト値として使用されます。 

    $TTL 3d    ; default TTL for zone
$ORIGIN mydomain.com.

@       IN      SOA     ns1.mydomain.com. hostmaster.mydomain.com. (
                                2023021001      ; serial number
                                6h              ; refresh
                                15m             ; update retry
                                4w              ; expiry
                                1h              ; minimum
                                )

;NAME   TTL     CLASS   TYPE    Resource Record

                IN      NS      ns1.mydomain.com.
                IN      NS      ns2.mydomain.com.

                IN      MX      10 mail.mydomain.com.

ns1             IN      A       192.168.10.11
ns2             IN      A       192.168.10.12
mail    1d      IN      A       192.168.10.13
www     1800    IN      A       192.168.10.16
app     300     IN      A       192.168.10.10

    ゾーンドメイン名を指定するORIGINレコードの後に​​は、ゾーンの管理情報を含むStart of Authority（SOA）レコードがあります。SOAレコードは特定の構文を持ち、以下の情報が含まれています。

    • ドメインのプライマリネームサーバー
    • ドメインの管理者メールアドレス（ただし、「@」ではなく「.」で指定）
    • ドメイン情報が変更された日時を記録するためのシリアル番号
    • セカンダリネームサーバーがプライマリネームサーバーにゾーン情報の変更を確認するための更新タイマー
    • プライマリが応答しなくなった場合、セカンダリの再試行タイマーが作動する。
    • プライマリが指定された期間利用できない場合に、セカンダリからドメイン情報を期限切れにするために使用される有効期限タイマー
    • DNSリゾルバが権威サーバーからの否定応答をキャッシュする最小時間

    DNSレコードの構文とTTL値

    DNSリソースレコードの構文は次のとおりです。

    NAME		TTL		CLASS		TYPE		Resource Record

    レコード内の TTL 値はオプションです。指定しない場合、ゾーンファイルの先頭でゾーン TTL として定義されているデフォルト値が使用されます。TTL 値は、m (分)、h (時間)、d (日)、または w (週) が末尾に付かない限り、秒単位で指定します。 

    長いTTL値と短いTTL値の長所と短所

    TTL値は、DNSレコードの更新が反映されるまでの時間に直接影響します。TTL値が長いほど、権威DNSサーバーから提供された情報はDNSリゾルバによってより長い時間キャッシュされます。値が小さいほど、更新頻度が高くなります。

    TTL時間を長く設定する利点は、権威DNSサーバーが処理するクエリ数が少なくなるため、負荷が軽減されることです。さらに、権威DNSサーバーに障害が発生した場合でも、これらのレコードはリゾルバにキャッシュされているため、DNS解決に影響はありません。これにより、エンドユーザーはより快適なウェブサイト閲覧体験を得ることができます。 

    TTL値を長く設定すると、DNSレコードの変更が反映されるまでに遅延が生じるというデメリットがあります。また、キャッシュされたレコードのTTL値が期限切れになるまで、エラーやその他の不具合が発生する可能性があります。 

    当然のことながら、短いTTL値は長いTTL値とは正反対のメリットとデメリットを持ちます。短いTTL値は、DNSレコードの変更がより迅速に反映されることを意味します。その反面、権威DNSサーバーへの負荷と依存度が高まります。

    TTLを短くすると、DNSリゾルバがレコードを保持する期間が短くなり、権威DNSサーバーへのクエリが繰り返されるため、DNS解決の遅延やアプリケーション全体の読み込み時間の延長につながります。

    TTL値の選択に関するベストプラクティス

    TTL値を長く設定すると、変更頻度が低いレコードや、安定した静的なインフラストラクチャの一部であるレコードに最適です。TTL値を短く設定すると、変更頻度が高いレコードに適しています。 

    以下は、さまざまなリソースレコードのTTL値に関する具体的な推奨事項です。

    • ネームサーバーレコード（NS）： ドメイン名のネームサーバーレコードは通常、長期間有効です。これらはTLDサーバーにおいてグルーレコードとして定義され、変更されることはほとんどありません。NSレコードのTTLは日数（通常1～3日）で指定できます。
    • メールエクスチェンジャーレコード（MX）： ドメインのメールサーバーは安定したインフラストラクチャの一部であるべきであり、通常、MXレコードのTTLは他のアプリケーションレコードに使用される値よりも高い値に設定されます。また、複数のメール交換機を使用することで、メール配信の信頼性を高めることができます。MXレコードのTTLは時間単位（12～24時間）で定義できます。
    • エイリアスレコード（CNAME）： このレコードは、さまざまな DNS レコードのエイリアスを定義するために使用されます。最も一般的に使用されるのは www.mydomain.com で、これは mydomain.com レコードを指します。mydomain.com のアドレスは変更される可能性がありますが、このレコードを指すエイリアスが更新されることはほとんどありません。CNAME の TTL 値は、時間 (12～24 時間) または日 (1～3 日) で定義できます。
    • 住所記録（A/AAAA）： このレコードは、リソースの名前と IPv4 (A) アドレスまたは IPv6 (AAAA) アドレスのマッピングを示します。アドレスはインフラストラクチャ リソースまたはアプリケーション エンドポイントのいずれにも適用でき、TTL 値は展開方法によって異なります。静的アプリケーションの場合、TTL は長め（数時間または数日）に設定できますが、高可用性およびフェイルオーバー シナリオで展開されるアプリケーションの場合、TTL 値は短く（数分）設定されます。 

    長期保存記録の変更に関する推奨事項

    TTL値が長いレコード（例えば、メールサービスや権威DNSサービスの変更など）を変更する必要があるシナリオがあり、設定されたTTL値で通常発生するよりも迅速に変更を反映させる必要がある場合があります。このようなシナリオでは、常に適切な計画を立て、次の4つのステップで変更を実行することをお勧めします。

    1. サービス切り替えを実施する際のメンテナンス作業時間帯を計画してください。この時間帯は、予期せぬ問題が発生した場合でもサービスへの影響を最小限に抑えられる時間帯に設定してください。また、設定したTTL値よりも数日または数時間先の時間帯を計画してください。
    2. レコードのTTL（有効期限）を、事前に短い値（分単位）に短縮してください。これは、DNSリゾルバ内のレコードが期限切れになり、新しい短いTTL値でキャッシュされるようにするためです。  
    3. リソースレコードを変更します。手順2でレコードのTTL値が短縮されているため、変更は数分以内に反映されます。これにより、変更の成否を迅速に確認できます。 
    4. 変更が成功した場合は、TTLを元の値に戻してください。失敗した場合は、リソースレコードを元の値に戻すことで、サービスをより迅速に復旧できます。問題を修正し、手順1～4を実行した後、別の作業ウィンドウを計画できます。いずれの場合も、TTL値を変更作業前の値に戻す必要があります。 

    DNSを使用したサービス負荷分散とフェイルオーバー

    現代社会では、サービスの可用性がエンドユーザーエクスペリエンスの重要な要素となっているため、アプリケーションは高可用性設計に基づいて展開されています。サービスの負荷分散と自動フェイルオーバーを実現するために、DNSレコードを使用してエンドユーザーのトラフィックを複数のサーバーにリダイレクトし、アプリケーションエンドポイントのいずれかが稼働または停止した際にレコードの変更を実行できます。リソースレコードに付加されるTTL値は、レコードの変更がエンドユーザーに反映されるまでの速度を決定します。  

    A PowerDNS 権威サーバーは、要求元のクライアントのIPアドレスまたは場所、サーバーの可用性、その他の要因に基づいて動的に生成されるDNSレコードをサポートします。これらのレコードは、以下の方法で生成されます。 LUA コードスニペット。 

    以下に、PowerDNS サーバーのリソース レコード構成例を示します。このレコードは、継続的なヘルス チェックを実行するように構成されています (ifurlup複数のエンドポイント (172.16.16.20 および 172.16.17.30) 上の Web サービス (web.domain.com) の ) をチェックします。この設定では、ヘルスチェックに合格したすべての IP アドレスが返されます。このレコードの TTL 値は 120 秒で、エンドポイントのいずれかでステータスが変更されると、権威サーバーは更新されたレコードを提供し、TTL 値の期限切れ後に DNS リゾルバに反映されます。2 番目のレコードは、受信した DNS リクエストの GeoIP ロケーション検索を実行します。クライアント IP が米国に属している場合 国コードリクエストが米国からの場合は、米国に拠点を置くサーバーのIPアドレスが返されます。リクエストが米国以外の地域からの場合は、米国以外のサーバーのIPアドレスが返されます。情報は5分ごとに更新されます（有効期限は300秒）。

    web.domain.com	120	IN	LUA	A "ifurlup('https://domain.com/', 
					{'172.16.16.20', '172.16.17.30'} )"

app.domain.com	300	IN	LUA	A ";if countryCode('US') 
				then return {'172.16.16.20', '172.16.17.30'} 
				else return {'172.16.18.30', '172.16.19.40'} 
				end"

    ダイナミックDNSのTTL

    ダイナミックDNSとは、動的に変化するIPアドレスにDNSドメイン名を割り当てる仕組みです。DDNSは通常、ISPによってIPアドレスが動的に割り当てられる家庭用ブロードバンド接続上で、インターネットに接続するサービスを実行するために使用されます。 

    DDNSを利用するには、DDNSサービスプロバイダーのいずれかに登録する必要があります。これらのプロバイダーは通常、有料サービスと無料サービスの両方を提供しています。クライアント側のIPアドレスが変更されるたびに、そのIPアドレスをDDNSプロバイダーに登録し、新しいリソースレコード値を反映させる必要があります。有料サービスでは通常、短いTTL値（5分）が設定できますが、無料サービスではより長いTTL値（15～60分）が設定できます。 

    DDNSを使用するには、クライアント側のアプリケーション、またはインターネットルーターのDDNS設定が必要です。アプリケーションまたはルーターは、クライアントのインターネットアドレスをDDNSサービスプロバイダーに登録します。クライアントのインターネットアドレスが変更されると（通常はDHCPリース期間の満了後）、DNSリソースレコードは無効になり、TTL値が期限切れになり、新しいレコードがDNSリゾルバに反映されるまで、ホストされているアプリケーションにアクセスできなくなります。重要なホスト型アプリケーションでは、より迅速な更新を確保するために、有料のDDNSサービスへの加入が必要になる場合があります。

    結論

    この記事では、さまざまなDNSレコードタイプにおけるTTL値の基本的な推奨事項について説明します。DNSのTTL値の設定は、インフラストラクチャの要件、権威DNSサーバーの負荷管理、情報の変更頻度、および必要なエンドユーザーエクスペリエンスに基づいて慎重に計画する必要があります。

    DNSのパフォーマンスについて推測するのはやめましょう。きちんと把握しましょう。

    LogicMonitorは、グローバルな複数の監視ポイントからDNSインフラストラクチャを継続的に監視し、最適化に必要な解決時間データと可用性に関する洞察を提供します。

    よくあるご質問

    DNS TTLとは何ですか？また、それは何を制御しますか？

    TTLはTime to Live（有効期限）の略です。DNSにおいては、リゾルバまたはクライアントがDNSレコードをキャッシュする期間（秒単位）を指定します。キャッシュが期限切れになると、権威サーバーに再度問い合わせを行います。TTLは、キャッシュ効率（パフォーマンス）とDNSの変更がインターネット全体に伝播する速度とのバランスを制御します。

    DNSのTTL値を低く設定しすぎるとどうなりますか？

    TTL値が非常に低い場合（60秒未満）、リゾルバは権威ネームサーバーへのクエリを頻繁に行う必要があり、DNSインフラストラクチャへの負荷が増加し、エンドユーザーの解決遅延が増加する可能性があります。ほとんどの安定したレコードの場合、300秒から3600秒のTTL値は、パフォーマンスと応答性のバランスが取れています。

    DNSのTTL値を高く設定しすぎるとどうなりますか？

    TTL値が高いほど、DNSの変更はゆっくりと伝播します。Aレコードを更新しても、指定された古いTTL値の間は、古いIPアドレスがリゾルバキャッシュから引き続き提供されます。DNS移行やフェイルオーバーのシナリオでは、これはダウンタイムの延長や、世界中のユーザーに影響を与えるトラフィックの誤ルーティングにつながる可能性があります。

    計画的なDNS変更における推奨TTL戦略は何ですか？

    計画的な変更を行う前に、TTLを低い値（60～300秒）に短縮し、すべてのリゾルバが古いレコードのキャッシュコピーの有効期限が切れるまで、少なくとも以前のTTLと同じ時間待機してください。変更後、グローバルに伝播を確認し、TTLを通常の値に戻してキャッシュ効率を回復してください。

    デントン千倉著

    テクニカルライター

    デントン・チクラは、テクニカルライターであり、長年にわたりオブザーバビリティを推進してきた人物です。彼は、サイト信頼性エンジニアやエンジニアリングチームがインターネットの回復力を強化するツールや機能を発見できるよう支援することに注力しています。監視、パフォーマンス、インフラストラクチャの交差点で活動し、複雑なシステムをより理解しやすく使いやすいものにすることで、高度な技術的詳細と実際の運用とのギャップを埋めています。彼の目標は、チームがより迅速に構築し、問題を早期に発見し、よりスマートに復旧できるよう支援し、最終的にはインターネットをすべての人にとってより良く、より信頼性の高い場所にすることです。

    免責事項: このブログで述べられている見解は著者の見解であり、LogicMonitor またはその関連会社の見解を必ずしも反映するものではありません。

    © LogicMonitor 2026 | 無断複写・転載を禁じます。 | ここで言及されているすべての商標、商号、サービス マーク、およびロゴは、それぞれの会社に帰属します。