SRVレコードのTTLを追加する方法｜TTLを指定してSRVを登録する手順と省略したときの扱い

SRVレコードにTTLを付けるには、管理画面ならレコードを追加するときのTTL欄で、ゾーンファイルならレコードの2列目に秒数を書きます。TTLを省略すると、ゾーンファイルでは $TTL の値、マネージドDNSではサービスの既定値が使われるため、意図した値になっているかは追加後に権威サーバーへ問い合わせて確かめます。この記事では、SRVを新しく追加するときにTTLを指定する方法を、ゾーンファイル（BIND）、管理画面、Amazon Route 53 のCLIの3つの場面に分けて説明し、既存のSRVに1行足すときの注意と確認方法もまとめます。

用途ごとにTTLをどの程度にするか、移行前にどう下げるかといった値の決め方は、ここでは深入りしません。登録の手順に絞ります。

SRVレコードを構成する項目

SRVレコードは、サービスがどのホストの何番ポートで提供されているかを示します。追加するときに決める項目は次の7つです。

• 名前: _サービス名._プロトコル の形（例: _sip._tcp）。先頭のアンダースコアも名前の一部です
• TTL: キャッシュしてよい秒数
• 優先度（priority）: 小さい値が優先されます
• 重み（weight）: 同じ優先度の中での振り分け比率です
• ポート: サービスの待ち受けポートです
• 接続先（target）: A・AAAAレコードを持つホスト名を書きます。CNAMEの名前は指定しないことになっています（RFC 2782）
• クラス: ふつうは IN です

接続先に .（ドット1つ）だけを書くと、「このドメインではそのサービスを提供していない」という意味になります。サービスを止めたことを明示したい場合に使います。

TTLを省略するとどうなるか

TTLの欄を空のまま追加しても、レコードにTTLが無い状態にはなりません。どこかで決められた既定値が付きます。

• BINDなどのゾーンファイル: TTLを書かなかった行には、ファイル先頭の $TTL の値が使われます（RFC 2308）。$TTL も無い古いゾーンファイルでは、BINDは警告を出してSOAの最後の値（MINIMUM）を代わりに使います
• マネージドDNS: サービスの既定値が付きます。Cloudflare の「自動」のように、具体的な秒数ではなく選択肢として表示されるものもあります

既定値に任せても動作はしますが、あとから見たときに意図がわかりにくく、$TTL やサービスの既定値が変わると一緒に変わってしまいます。SRVは接続先を変えるときにTTLが効いてくるレコードなので、追加の時点で値を明示しておくと管理しやすくなります。

ゾーンファイル（BIND）で追加する

BINDで管理している場合は、ゾーンファイルに行を足し、SOAのシリアル番号を上げてから読み込み直します。作業前にゾーンファイルのコピーを取っておきます。

$TTL 86400
@   IN SOA ns1.example.com. hostmaster.example.com. (
        2026101801 ; シリアル番号（変更のたびに上げる）
        7200       ; REFRESH
        3600       ; RETRY
        1209600    ; EXPIRE
        3600 )     ; MINIMUM
; NS や接続先ホストの A レコードなど、ほかの行は省略

; TTL を明示した SRV（2列目の 3600 が TTL）
_sip._tcp       3600 IN SRV 10 60 5060 sip1.example.com.
_sip._tcp       3600 IN SRV 10 40 5060 sip2.example.com.

; TTL を省略した SRV（$TTL の 86400 が使われる）
_xmpp-client._tcp    IN SRV 5 0 5222 xmpp.example.com.

接続先の末尾のドットは、ゾーン名を付け足さずにそのまま使う、という意味です。付け忘れると sip1.example.com.example.com. として扱われます。

書き換えたら、構文を検査してから読み込みます。

named-checkzone example.com /etc/bind/zones/db.example.com
sudo rndc reload example.com

ゾーンファイルの場所やゾーン名は、環境に合わせて読み替えます。named-checkzone がエラーを出したときは読み込まずに修正します。

管理画面で追加する

マネージドDNSの管理画面では、レコードの種類にSRVを選ぶと、名前、優先度、重み、ポート、接続先、TTLの欄が表示されるのが一般的です。サービス名とプロトコルを別の欄に分けて入力する画面もあります。項目名や並び、選べるTTLの値はサービスごとに異なり、変わることもあります（2026年10月現在）。

入力でつまずきやすい点は次のとおりです。

• 名前の二重付与: 名前の欄にドメイン名を自動で付け足す画面で _sip._tcp.example.com と入力すると、_sip._tcp.example.com.example.com になることがあります。保存後の一覧で、名前がどう表示されているかを見ます
• TTLの選択肢: 一覧から選ぶ方式では、希望の秒数が無いことがあります。近い値を選び、何を選んだかを作業記録に残します
• SRVに対応していない: レジストラやレンタルサーバーのDNSには、SRVを登録できないものや、TTLを変更できないものがあります。必要ならSRVに対応したDNSサービスにネームサーバーを移すことを検討します
• Cloudflare のプロキシ: SRVはHTTPのプロキシの対象外です。接続先ホストのA・AAAAをプロキシ有効にすると、そのホスト名はCloudflare のIPを返すので、SRVの接続先として期待どおりに動きません。接続先はプロキシを通さない設定にします

Amazon Route 53 でCLIから追加する

Route 53 では、同じ名前・同じ種類のレコードを1つのレコードセットとして扱い、TTLはレコードセットに1つだけ指定します。CLIで追加するときは、変更内容をJSONで用意します。

{
  "Comment": "Add SIP SRV records",
  "Changes": [
    {
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "_sip._tcp.example.com",
        "Type": "SRV",
        "TTL": 3600,
        "ResourceRecords": [
          { "Value": "10 60 5060 sip1.example.com" },
          { "Value": "10 40 5060 sip2.example.com" }
        ]
      }
    }
  ]
}

aws route53 change-resource-record-sets \
  --hosted-zone-id YOUR_HOSTED_ZONE_ID \
  --change-batch file://srv.json

注意したいのは、UPSERT が既存のレコードセットを丸ごと置き換える点です。すでに同じ名前のSRVがある状態で新しい1行だけを書いて実行すると、既存の行が消えます。先に既存の内容を取得し、残す行も含めたJSONを作ってから実行します。

aws route53 list-resource-record-sets \
  --hosted-zone-id YOUR_HOSTED_ZONE_ID \
  --query "ResourceRecordSets[?Type=='SRV']"

取得した結果は、変更前の控えとしてファイルに保存しておきます。

既存のSRVに1行足すときのTTL

同じ名前・同じ種類のレコードの集まり（RRset）は、TTLをそろえる決まりがあります（RFC 2181）。既存のSRVが3600秒なら、足す行も3600秒にします。

• Route 53 のようにレコードセット単位でTTLを持つサービスでは、そもそも行ごとに違う値は入れられません
• 行ごとにTTL欄がある画面では、違う値を入れて保存できてしまうことがあります。その場合の扱いはサービスによって異なるので、既存の行に合わせます
• BINDでは、同じRRsetの中でTTLが違うと、読み込み時に警告を出して値をそろえて扱います

TTLそのものを変えたい場合は、行を足すときに一緒に変えるのではなく、既存の行も含めて全体の値を書き換えます。

追加後の確認

追加したら、権威サーバーに再帰なしで直接問い合わせます。この応答の2列目が、設定したTTLそのものです。

dig +short NS example.com
dig @ns1.example.com _sip._tcp.example.com SRV +norecurse +noall +answer

_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.

公開DNSを経由した問い合わせでは、2列目はキャッシュの残り秒数になるため、設定値より小さく表示されるのが普通です。Windows では nslookup -type=SRV _sip._tcp.example.com でも確認できます。

あわせて、接続先のホスト名が引けるかも確かめます。SRVが正しくても、接続先にA・AAAAが無いとクライアントは接続できません。

dig +short sip1.example.com A
dig +short sip1.example.com AAAA

最後に、そのSRVを使うクライアント（電話アプリ、チャットクライアント、ゲームなど）から実際に接続して確かめます。DNSの応答が正しいのにつながらない場合は、ポートの開放やサーバー側の待ち受けを確認します。

まとめ

• SRVのTTLは、管理画面ではTTL欄、ゾーンファイルでは2列目に秒数で書く
• 省略すると $TTL やサービスの既定値が付く。追加時に明示しておくと管理しやすい
• BINDでは構文検査をしてから読み込み、シリアル番号を上げる
• Route 53 の UPSERT はレコードセットを置き換えるので、既存の行も含めて送る
• 同じ名前のSRVはTTLをそろえ、追加後は権威サーバーへの +norecurse の問い合わせで値を確かめる

• TTLの設定値による反映時間の違い｜変更前に下げるタイミングと値の決め方
• digコマンドでDNSレコードを調査する方法