2026年6月16日

SRVレコードのTTLを設定する方法｜用途別の目安と移行前の下げ方

DNS・名前解決

SRVレコードのTTLは、普段は3600秒（1時間）前後、サーバーの移行を控えているときだけ一時的に300秒程度に下げる、という使い分けが基本です。TTLの指定方法自体はほかのレコードと同じですが、SRVには「SRVのTTL」と「接続先ホスト名のA・AAAAレコードのTTL」の2段階があり、何を変える予定なのかで下げるべき側が変わります。この記事では、SRVレコードの書式とTTLの位置、用途別の目安、DNSサービスごとの指定方法、変更が効いているかの確認方法を説明します。

SRVレコードの書式とTTLの位置

SRVレコードは、あるサービスがどのホストの何番ポートで動いているかを示すレコードです。名前は「_サービス名._プロトコル.ドメイン」の形をとります。

; 名前                       TTL   クラス 種類 優先度 重み ポート 接続先
_sip._tcp.example.com.       3600  IN     SRV  10     60   5060   sip1.example.com.
_sip._tcp.example.com.       3600  IN     SRV  10     40   5060   sip2.example.com.
_sip._tcp.example.com.       3600  IN     SRV  20     0    5060   sip-backup.example.com.

優先度（priority）: 小さい値ほど先に使われます。上の例では10の2台を使い、つながらないときに20へ回ります
重み（weight）: 同じ優先度の中での振り分け比率です
ポート: サービスの待ち受けポートです
接続先（target）: ホスト名を書きます。RFC 2782 では、ここにCNAMEの名前を指定しないことになっており、A・AAAAレコードを持つ名前を指定します

TTLは2列目です。同じ名前・同じ種類のレコード（RRset）は同じTTLにそろえるのが決まりで、上の3行のTTLが異なっていると、サーバーやサービスによっては警告を出したり、どれか一つの値にそろえて扱ったりします（RFC 2181）。

2つのTTLを分けて考える

SRVを使うクライアントは、まずSRVを引いて接続先のホスト名とポートを知り、次にそのホスト名のA・AAAAレコードを引いてIPアドレスを知ります。それぞれに別のTTLがあり、キャッシュも別々です。

接続先のホスト名やポート、優先度を変える予定がある: SRVのTTLを下げます
接続先ホストのIPアドレスだけを変える予定がある: SRVはそのままで、接続先のA・AAAAレコードのTTLを下げます

サーバーを引っ越す場面では、新しいサーバーに同じホスト名を付け替えるのか、新しいホスト名に向け直すのかを先に決めておくと、どちらのTTLを下げればよいかがはっきりします。

用途別のTTLの目安

TTLを短くすると変更は早く広まりますが、問い合わせが増え、権威サーバーに障害が起きたときの影響も受けやすくなります。SRVは優先度と重みでもともと予備のサーバーを書けるため、障害対策のためにTTLを極端に短くする必要はあまりありません。

状況	TTLの目安
普段の運用（構成をめったに変えない）	3600〜86400秒
構成を時々見直す	1800〜3600秒
移行作業の前後	300秒前後

数値は一般的な目安で、サービスの性質や利用者数に合わせて調整します。Active Directory のように、サーバー自身がSRVレコードを動的に登録する環境では、TTLもその仕組みの側で管理されるため、手作業で書き換えないようにします。

DNSサービスごとの指定方法

管理画面でSRVを追加するときは、サービス名・プロトコル・優先度・重み・ポート・接続先を別々の欄に入力する形式と、名前と値をまとめて入力する形式があります。TTLは多くの場合、レコードごとに選択か数値で指定します。画面の項目名や入力形式はサービスごとに異なり、変更されることもあります（2026年10月現在）。

Amazon Route 53: レコード名に _sip._tcp を、値に 10 60 5060 sip1.example.com のように「優先度重みポート接続先」を1行ずつ書き、TTLは秒数で指定します
Cloudflare: SRVを選ぶとサービス名や優先度などの欄が分かれて表示されます。TTLには自動設定を選べるほか、一覧から値を選べます。SRVはHTTPのプロキシの対象外なので、接続先ホストのA・AAAAレコードもプロキシを通さない設定にしておく必要がある点に注意します
国内のレジストラやレンタルサーバーのDNS: SRVに対応していない、またはTTLを選べないサービスもあります。対応していない場合は、SRVに対応したDNSサービスへネームサーバーを移すことを検討します

自前のBINDなどで管理している場合は、ゾーンファイルの該当行のTTLを書き換え、SOAのシリアル番号を上げてから named-checkzone で確認し、読み込み直します。変更前にゾーンファイルのバックアップを取っておきます。

移行のときのTTLの下げ方

TTLを下げる効果が出るのは、変更前のTTLのキャッシュが切れたあとです。そのため、作業の直前に下げても間に合いません。

作業予定日の前に、下げる側（SRV、または接続先のA・AAAA）のTTLを300秒程度に変える
変更前のTTL（例えば86400秒なら1日）以上待つ
SRVの接続先・ポート・優先度、またはA・AAAAのIPアドレスを変更する
新しい値が権威サーバーと主要なリゾルバで返ることを確認する
問題が無ければTTLを元の長さに戻す

旧サーバーは、少なくとも変更前のTTLが過ぎるまで止めずに残しておくと、古いキャッシュを持つクライアントもつながり続けます。SRVの優先度を使えば、新サーバーを優先度の高い側、旧サーバーを低い側に置いて、段階的に切り替えることもできます。

設定が効いているかの確認

まず権威サーバーに直接問い合わせて、元のTTLと値を確かめます。リゾルバ経由の結果では、キャッシュの残り時間が表示されます。

# 権威サーバーの名前を調べる
dig example.com NS +short

# 権威サーバーに直接問い合わせる（2列目が設定したTTL）
dig @ns1.example-dns.net _sip._tcp.example.com SRV +norecurse

# 公開リゾルバ経由（2列目はキャッシュの残り秒数）
dig @1.1.1.1 _sip._tcp.example.com SRV
dig @8.8.8.8 _sip._tcp.example.com SRV

# Windows の場合
nslookup -type=SRV _sip._tcp.example.com

結果が返らないときは、TTLより先に名前を疑います。サービス名とプロトコルの先頭のアンダースコアの抜け、管理画面がドメイン名を自動で付け足すのに完全修飾名を入力して _sip._tcp.example.com.example.com になってしまう二重付与が、よくある原因です。

DNSの値が変わっているのにアプリケーションが古い接続先を使い続ける場合は、アプリケーション側のキャッシュも疑います。Java の実行環境のように独自に名前解決の結果を保持するものや、接続中のセッションを張り直さない限り新しい接続先を引かないクライアントもあります。この場合は、アプリケーションの再起動や再接続で確かめます。

まとめ

SRVのTTLは書式の2列目。同じ名前のSRVはTTLをそろえる
接続先の名前やポートを変えるならSRVのTTL、IPだけを変えるなら接続先のA・AAAAのTTLを下げる
普段は1時間〜1日、移行の前後だけ300秒前後。障害対策は優先度と重みで行う
TTLの変更は、変更前のTTLが過ぎるまで効かない。下げる作業は前もって行う
確認は権威サーバーへの +norecurse の問い合わせで行い、名前の書き間違いとアプリケーション側のキャッシュも確かめる