SRVレコードを追加・変更したのに、メールクライアントやチャット、ゲームサーバーなどのアプリが新しい設定を見つけてくれないとき、原因は「単に反映を待っている」場合と「レコード自体が間違っている」場合に分かれます。見分け方は、権威DNSにSRVの正式な名前で直接問い合わせ、次にキャッシュDNSの残りTTLを読み、最後に接続先のホスト名とポートを確かめることです。この記事では、その順番で確認する手順と、待ち時間の目安の求め方を説明します。
SRVレコードのTTLそのものの決め方は別の記事で扱っているため、ここでは「今、反映待ちなのかどうか」を判断することに絞ります。
SRVレコードの形を確認しておく
SRVレコードは、「あるサービスを、どのホストの何番ポートで提供しているか」を示すレコードです。名前の部分と値の部分は、次の形になっています。
; 名前 TTL クラス タイプ 優先度 重み ポート 接続先
_xmpp-client._tcp.example.com. 3600 IN SRV 10 5 5222 xmpp.example.com.- 名前:
_サービス名._プロトコル.ドメインの形です。先頭のアンダースコアは省略できません。プロトコルは多くの場合_tcpか_udpです。 - 優先度（priority）: 値が小さいほど優先されます。
- 重み（weight）: 同じ優先度のレコードが複数あるとき、振り分けの比率に使われます。
- ポート: サービスの待ち受けポート番号です。
- 接続先（target）: 実際に接続するホスト名です。IPアドレスは書けません。
反映を確認するときは、この「名前」の部分を一字一句そのまま使って問い合わせます。ドメイン名だけで問い合わせても、SRVレコードは見つかりません。
確認1: 権威DNSに直接尋ねる
最初に、DNSの設定そのものが正しく入っているかを確認します。ここで正しい値が返らなければ、どれだけ待っても反映されません。
# ドメインのネームサーバーを調べる
dig example.com NS +short
# 表示されたネームサーバーの1台に、再帰なしで問い合わせる
# ns1.your-dns.example は上の結果に置き換える
dig @ns1.your-dns.example _xmpp-client._tcp.example.com SRV +norec結果の読み方は次のとおりです。
- **
status: NOERRORで ANSWER に値がある**: 権威DNSには正しく登録されています。この時点で値が期待どおりなら、残りはキャッシュの待ち時間の問題です。確認2へ進みます。 - **
status: NXDOMAIN**: その名前が存在しません。名前の入力ミスを疑います（後述のよくある間違いを参照）。 - **
status: NOERRORで ANSWER が空**: 名前はあるがSRVタイプのレコードがない状態です。別のタイプで登録した、あるいは別の名前に登録した可能性があります。 - **
status: REFUSEDや応答なし**: 問い合わせたネームサーバーがこのドメインを担当していません。設定画面を開いたDNSサービスと、実際にドメインが使っているネームサーバーが違う可能性があります。
複数のネームサーバーがある場合は、すべてに同じ問い合わせをして、答えがそろっているかも確認します。一部だけ古い値を返す場合は、ネームサーバー間の同期が遅れているか、止まっています。
確認2: キャッシュDNSの残りTTLを読む
権威DNSが正しい値を返しているのに、アプリ側で古い値が使われる場合は、途中のキャッシュDNSが古い答えを覚えています。公開DNSに問い合わせて、残りTTLを読みます。
dig @8.8.8.8 _xmpp-client._tcp.example.com SRV
dig @1.1.1.1 _xmpp-client._tcp.example.com SRVANSWER の各行の2列目が、そのキャッシュに残っている秒数です。値が古く、残り秒数が減っていく場合は、その秒数が過ぎれば新しい値に入れ替わります。何度か問い合わせても残り秒数が設定したTTL付近から始まる場合は、問い合わせのたびに別のキャッシュサーバーが答えている可能性があります。
追加直後に「存在しない」と覚えられている場合
新しくSRVを追加する前に、アプリや確認作業で一度その名前を問い合わせていると、キャッシュDNSは「存在しない」という答え（否定応答）を覚えます。この否定応答の保持時間は、SRVのTTLではなく、ゾーンのSOAレコードで決まります。
dig example.com SOA +short出力の最後の数値（SOAの minimum フィールド）と、SOAレコード自体のTTLのうち、小さい方が否定応答の保持時間の上限になります。公開DNSに NXDOMAIN と表示され、SOAが AUTHORITY に付いている場合は、そのSOAの行の2列目が残り秒数の目安です。
待ち時間の目安を出す
反映待ちの最大時間は、作業の内容によって次のように考えます。
- 新規追加で、事前に問い合わせていない: 待ち時間はほぼありません。権威DNSに入った時点で見えるようになります。
- 新規追加で、事前に問い合わせてしまった: 否定応答の保持時間（SOAで決まる値）が上限です。
- 既存の値を変更した: 変更前のレコードのTTLが上限です。変更後のTTLではない点に注意します。
- ネームサーバーを移した直後: NSの切り替えの待ち時間が先に加わります。
公開DNSの中には、特定の名前のキャッシュを消す申請ができるものもあります。提供の有無や手順はサービスごとに異なるため、各サービスの案内を確認してください（2026年10月現在）。
確認3: 接続先のホスト名とポートを確かめる
SRVの値が正しく見えていても、接続先のホスト名が引けなければサービスにはつながりません。
# 接続先のホスト名のアドレスを確認する
dig xmpp.example.com A +short
dig xmpp.example.com AAAA +short
# 接続先がCNAMEになっていないか確認する
dig xmpp.example.com CNAME +short
# ポートが開いているか確認する（TCPの場合）
nc -vz xmpp.example.com 5222SRVの仕様（RFC 2782）では、接続先にはCNAMEではなく、A・AAAAレコードを持つ名前を指定することになっています。CNAMEを指定しても動くクライアントはありますが、動かないものもあるため、接続先の名前を直接A・AAAAで引ける名前に変えるのが安全な対処です。また、接続先が .（ドット1つ）になっている場合は「このサービスは提供していない」という意味になります。
確認4: クライアント側を確かめる
DNSの経路がすべて正しくても、端末やアプリが古い答えを持っていることがあります。
# Windows の場合
Resolve-DnsName -Name _xmpp-client._tcp.example.com -Type SRV
ipconfig /flushdnsmacOS や Linux では、dig や nslookup -type=SRV で同様に確認できます。アプリによっては起動時にSRVを読み込んでそのまま使い続けるため、DNSが正しくなった後でアプリを再起動して確認します。
よくある設定ミス
反映待ちだと思っていたら設定ミスだった、という例は少なくありません。確認1で値が返らないときは、次の点を見直します。
- ドメインが二重になっている: 管理画面の名前欄に
_xmpp-client._tcp.example.comと入力すると、画面がドメインを自動で付け足し、_xmpp-client._tcp.example.com.example.comとして登録されることがあります。名前欄には_xmpp-client._tcpだけを入れる画面が多くあります。 - アンダースコアやプロトコルの誤り:
_tcpと_udp、_tlsの取り違えや、アンダースコアの抜けです。使うべき値は、サービスの提供元が案内している形に合わせます。 - 項目の順番の取り違え: 優先度・重み・ポート・接続先の順番を入れ違えると、別のポートに向かいます。管理画面によっては項目が別々の欄になっています。
- ゾーンファイルで末尾のドットがない: BIND形式のゾーンファイルで接続先を
xmpp.example.comと書くと、ゾーンの名前が付け足されます。末尾まで書いた名前（FQDN）には最後に.を付けます。
Microsoft 365 などのサービスが案内するSRVレコードは、サービス側の仕様変更で必要な値が変わることがあります。登録前に、そのサービスの管理画面やドキュメントに表示されている最新の値を確認してください。
まとめ
- SRVの反映確認は、
_サービス._プロトコル.ドメインの正式な名前で問い合わせます。 - まず権威DNSに
+norecで尋ね、NXDOMAIN・空の応答・REFUSED なら待っても直らない設定の問題です。 - 権威DNSが正しければ、公開DNSの残りTTLを読み、変更前のTTLや否定応答の保持時間から待ち時間の上限を見積もります。
- 接続先はA・AAAAで引ける名前にし、ポートが開いているかも確かめます。
- 最後に端末のキャッシュとアプリの再起動を確認します。