6. 使用规则
6.1 客户端处理流程
支持 SRV 的客户端**应当（SHOULD）**使用以下流程来定位服务器列表并连接到首选服务器：
6.2 算法步骤
第 1 步：执行 SRV 查询
执行如下查询：
QNAME=_service._protocol.target
QCLASS=IN
QTYPE=SRV
第 2 步：检查响应
如果回复为 NOERROR、ANCOUNT>0，且回复中至少有一条 SRV RR 指定了所请求的服务与协议：
第 3 步：检查服务是否不可用
如果恰好只有一条 SRV RR，且其目标（Target）为 "."（根域），则中止。
第 4 步：构建候选列表
否则，针对所有此类 RR，构建一个 (优先级, 权重, 目标) 元组列表。
第 5 步：按优先级排序
按优先级对列表排序（数字最小者在前）。
第 6 步：创建有序列表
创建一个新的空列表。
对于每个不同的优先级层级：
- 只要该优先级层级仍有元素剩余
- 按照"SRV RR 格式"一节中关于权重的说明选中一个元素，并将其移至新列表的末尾
第 7 步：查询并连接
对于新列表中的每个元素：
- 查询该目标的 DNS 地址记录，或使用之前 SRV 响应"附加数据"段中找到的此类记录
- 对于每个找到的地址记录，尝试连接至
(协议, 地址, 服务)
第 8 步：回退到 A 记录
否则（如果没有 SRV 记录）：
执行如下查询：
QNAME=target
QCLASS=IN
QTYPE=A
对于每个找到的地址记录，尝试连接至 (协议, 地址, 服务)。
6.3 重要注意事项
6.3.1 端口号
禁止事项
端口号**不应（SHOULD NOT）**用来替代符号化的服务或协议名（原因与不允许使用变体名相同：应用程序将不得不执行两次或更多次查询）。
6.3.2 被截断的响应
如果 SRV 查询返回了被截断的响应，则应适用 [RFC 2181] 中描述的规则。
6.3.3 解析要求
强制要求
客户端**必须（MUST）**解析回复中的所有 RR。
6.3.4 附加数据段
如果"附加数据"段未包含全部 SRV RR 的地址记录，而客户端可能想要连接所涉及的目标主机，则客户端**必须（MUST）**查找相应的地址记录。
常见情形
当地址记录的 TTL 短于 SRV 或 NS RR 时，这种情况相当常见。
6.3.5 未来协议
未来的协议可被设计为使用 SRV RR 查询，作为客户端定位其服务器的手段。