跳到主要内容

3. 域管理员建议 (Domain Administrator Advice)

3.1 向后兼容性考量 (Backward Compatibility Considerations)​

期望每个人在第一个服务器发布 SRV RR 时更新其客户端应用程序是徒劳的 (即使是可取的)。因此 SRV 必须与现有协议的地址记录查找共存, DNS 管理员应尝试提供地址记录以支持旧客户端。

3.2 配置策略 (Configuration Strategies)​

3.2.1 多主机分布式服务 (Multi-Host Distributed Services)​

当单个域的服务分布在多个主机上时, 似乎建议在与 SRV RR 相同的 DNS 节点上有一个地址记录列表, 列出 Telnet、NNTP 和其他可能与此名称一起使用的协议的合理 (如果可能不是最优的) 备用主机。

注意: 某些程序只尝试从例如 gethostbyname() 返回的第一个地址, 我们不知道这种行为有多普遍。

3.2.2 单一服务, 多台主机 (Single Service, Multiple Hosts)​

当一个服务由多台主机提供时, 可以:

  • 为所有主机提供地址记录 (在这种情况下, 轮询机制 (如果可用) 将平均分配负载)
  • 只为一台主机提供地址记录 (可能是最快的那台)

3.2.3 备份服务器 (Backup Servers)​

如果主机仅在主服务器关闭时提供服务, 则可能不应该在地址记录中列出它。

3.2.4 备份记录的端口要求 (Port Requirements for Backup Records)​

强制要求: 备份地址记录引用的主机必须 (MUST) 使用已分配号码中为该服务指定的端口号。

3.2.5 未来协议设计 (Future Protocol Design)​

未来协议的设计者, 如果"辅助服务器"不有用 (或没有意义), 可以选择不使用 SRV 对辅助服务器的支持。此类协议的客户端可以使用或忽略优先级高于域的最低优先级 RR 的 SRV RR。

3.3 DNS 回复大小限制 (DNS Reply Size Limitations)​

3.3.1 实际限制 (Practical Limit)​

目前 DNS 回复有 512 字节的实际限制。在所有解析器都能处理更大响应之前, 强烈建议域管理员将其 SRV 回复保持在 512 字节以下。

3.3.2 大小估算 (Size Estimation)​

回复数据包组成:

  • 30 字节: 一般开销
  • 可变: 服务名称 (例如 "_ldap._tcp.example.com")
  • 20 字节 + 目标名称: 每个 SRV RR
  • 15 字节 + NS 名称: 权威部分中的每个 NS RR
  • 约 20 字节: 附加数据部分中的每个 A RR

此大小估算非常粗略, 但不应低估实际答案大小太多。

提示: 如果答案可能接近限制, 使用 DNS 查询工具 (例如 "dig") 查看实际答案是个好主意。

标签：
最后于 更新