SRV レコードが問い合わせるクライアントだけを助ける理由

ゾーンに SRV レコードを追加しても、どの VPN クライアントもそれを検索するようにはなりません。クライアントがラベルを知り、問い合わせを送ると決め、返ってきた内容に従って動作する必要があり、DNS はそのうち最初の二つを提供できません。したがって、失敗する SRV 計画のほとんどは DNS の衣装を着たクライアント側の問題です。まずクライアントの発見動作を読み、次にそれが実際に問い合わせるラベルだけを公開してください。

誰も問い合わせないレコードは誰の役にも立たない

SRV はサービスの所在を公開するもので、サービスを告知するものではありません。レコードをクライアントへ押し出す仕組みはなく、求められていない名前をレゾルバが勝手に差し出すこともありません。検索はアプリケーションが行うと決めた時点で始まるため、ラベルは製品の文書か、ネットワーク上でのソフトウェアの観察から得る必要があります。クライアントに発見の手順がなければ、レコードはゾーンを変えるだけで、それ以外の何も変えません。

だからこそ、同じ変更で一方の製品は動き始め、もう一方は影響を受けないということが起こります。変わるのはソフトウェアであり、DNS サーバーは言われたとおりに動いているだけです。編集後は、打ち間違えたラベルがどれも同じに見えるレコードの中に容易に紛れるため、ゾーンを読み直してください。

書く前にフィールドを読む

レコードは四つの値を持ち、それぞれが別の問いに答えます：優先度はクライアントが試せる宛先を順序づけ、重みは同じ優先度の宛先の間で負荷を分け、ポートは転送ポートを名指しし、宛先はホストを名指しします。仕様では . という宛先を、サービスが意図的に提供されていないという意味にすることも認めており、これは壊れた応答ではなく有用な応答です。

これらのフィールドはいずれも資格情報、証明書ポリシー、アプリケーションのバージョンを運ばず、重みを無視するクライアントも接続はしますが、意図した配分にはなりません。宛先には独自のアドレスレコードが必要で、別名ではなく正規名であるべきです。待ち受けのないホストを指すレコードを公開すると、DNS の障害のように読める接続エラーが生じます。これは最も高くつく誤誘導であり、連鎖全体を公開するか、まったく公開しないかです。

クライアントが実際に送るラベルを見つける

製品名についての推測ではなく、証拠からラベルを確定してください。文書がサービス名を示すか、あるいはキャプチャが起動時にクライアントから出る問い合わせを示します。どちらの道も、レゾルバに対して試すべき正確な名前とタイプという同じ場所に着きます。

dig +short SRV _vpn._tcp.gw.example
dig +short A edge2.gw.example
tcpdump -ni any udp port 53

アンダースコアと末尾のドットも名前の一部なので、応答を公開したレコードと一文字ずつ比較してください。実際に送られた問い合わせに対する空の応答はゾーンを指す一方、問い合わせがまったくない場合はクライアントを指し、この違いは対応するチームを分けます。実際の応答は次の行のとおりで、優先度 20 はより低い優先度のどのレコードにも負け、クライアントは指定された宛先のポート 8443 に接続します。

_vpn._tcp.gw.example. 600 IN SRV 20 10 8443 edge2.gw.example.

宛先も存在していなければならない

名前が解決する宛先は、応答するサービスと同じではありません。宛先のアドレスレコードを確認し、次に公開したポートとプロトコルで何かが待ち受けているかを確認してください。UDP のみの待ち受けを指す TCP レコードは、どれだけゾーンを編集しても直らない不一致です。宛先が流動的な間は TTL を短くし、名前が動かなくなったら長くしてください。

発見を実装しているクライアントでも、レコードをどこまで尊重するかはさまざまです。優先度だけを使うもの、重みを助言として扱うもの、ポートを無視して既定値を仮定するものもあります。そうした違いは、そうしなければレゾルバの不具合に見える挙動を説明してくれるのだから、ラベルの隣のメモに書くべきです。

発見は認証ではない

SRV の応答はどこへ接続するかを示すだけで、到着後に誰を信頼するかについては何も語りません。他人が偽装できるレコードが信頼の判断にならないよう、クライアントの証明書検証とサーバー識別の確認はそのままの状態に保ってください。DNS の応答はキャッシュ可能で、ゾーンを管理する誰もが編集できるため、ポリシーを埋め込む場所としては不適切です。

発見に対応していないクライアントには、それが受け付けるプロファイルかゲートウェイ URL を配布し、どの製品がどの方式を使うかを記録してください。その記録があれば、次の管理者がレコードを追加してどこでも動くはずだと期待することを防げます。SRV の仕様は宛先の選択を説明しており、これを認可の仕組みとして読むことが、有用なレコードをセキュリティ上の前提に変えてしまう道です。意図をもって公開し、文書にラベル名を書き、クライアントこそがそれが意味を持つかを決める構成要素だと捉えてください。