跳到主要内容

6. 使用规则 (Usage Rules)

6.1 客户端处理程序 (Client Processing Procedure)​

支持 SRV 的客户端应该 (SHOULD) 使用此程序来定位服务器列表并连接到首选服务器:

6.2 算法步骤 (Algorithm Steps)​

步骤 1: 执行 SRV 查询​

查找:

QNAME=_service._protocol.target
QCLASS=IN
QTYPE=SRV

步骤 2: 检查响应​

如果回复是 NOERROR, ANCOUNT>0 并且回复中至少有一个 SRV RR 指定了请求的 Service 和 Protocol:

步骤 3: 检查服务不可用​

如果恰好有一个 SRV RR, 且其 Target 为 "." (根域), 则中止。

步骤 4: 构建候选列表​

否则, 对于所有此类 RR, 构建 (Priority, Weight, Target) 元组列表。

步骤 5: 按优先级排序​

按优先级对列表排序 (最低数字优先)。

步骤 6: 创建有序列表​

创建一个新的空列表。

对于每个不同的优先级:

  • 当此优先级仍有剩余元素时
    • 按照上面 "SRV RR 的格式" 部分中权重描述中指定的方式选择一个元素, 并将其移动到新列表的末尾

步骤 7: 查询并连接​

对于新列表中的每个元素:

  1. 查询 DNS 以获取 Target 的地址记录, 或使用在早期 SRV 响应的附加数据部分中找到的任何此类记录
  2. 对于找到的每个地址记录, 尝试连接到 (protocol, address, service)

步骤 8: 回退到 A 记录​

否则 (如果没有 SRV 记录):

查找:

QNAME=target
QCLASS=IN
QTYPE=A

对于找到的每个地址记录, 尝试连接到 (protocol, address, service)。

6.3 重要说明 (Important Notes)​

6.3.1 端口号 (Port Numbers)​

禁止: 端口号不应该 (SHOULD NOT) 用于代替符号服务或协议名称 (原因与不允许变体名称相同: 应用程序必须进行两次或更多次查找)。

6.3.2 截断响应 (Truncated Responses)​

如果 SRV 查询返回截断响应, 则应适用 [RFC 2181] 中描述的规则。

6.3.3 解析要求 (Parsing Requirements)​

强制: 客户端必须 (MUST) 解析回复中的所有 RR。

6.3.4 附加数据部分 (Additional Data Section)​

如果附加数据部分不包含所有 SRV RR 的地址记录, 且客户端可能想要连接到涉及的目标主机, 则客户端必须 (MUST) 查找地址记录。

注意: 当地址记录的 TTL 比 SRV 或 NS RR 短时, 这种情况经常发生。

6.3.5 未来协议 (Future Protocols)​

未来的协议可以设计为使用 SRV RR 查找作为客户端定位其服务器的方式。

标签：
最后于 更新