SRV记录是DNS体系中一个常被忽视但非常实用的记录类型。普通的A记录只能回答“这个域名对应的IP是多少”，而SRV记录可以回答一个更具体的问题：“我要访问某种服务，应该去哪台机器的哪个端口找”。这种能力使得SRV记录成为服务发现领域最古老也最稳定的方案之一，广泛应用于Active Directory域环境、SIP语音通信、XMPP即时通讯以及各类游戏服务器自动寻址。
SRV记录的基本结构与字段含义
一条标准的SRV记录格式如下：_服务名._协议名.域名. IN SRV 优先级 权重 端口 目标主机。其中服务名和协议名以下划线开头，这是RFC 2782的规定，例如_sip._tcp.ippipp.com表示在ippipp.com域中通过TCP协议提供SIP服务。这种命名方式可以避免与普通主机名冲突。
优先级（Priority）和权重（Weight）是两个容易混淆的字段。优先级类似MX记录中的优先级，数值越小越优先，客户端应当先尝试优先级数值最小的目标，只有当它不可用时才转向更高数值的目标。而权重只在同一优先级的多条记录之间生效，用于做负载分担。例如同一优先级下有两条记录，权重分别为60和40，理论上大约60%的请求会流向第一条记录对应的主机。
端口字段让SRV记录具备了A记录无法企及的能力：直接告诉客户端服务监听在哪个端口。目标主机字段则必须是一个已存在的A记录或AAAA记录所对应的域名，不能直接写IP地址，这是配置时最常见的错误之一。如果目标主机本身没有对应的A记录，整个SRV解析链条就会断裂。
常见平台的配置方法
在BIND服务器上配置SRV记录需要编辑区域文件。假设我们要为内部服务db-proxy注册一个SRV记录，端口为6379，可以在区域文件中添加如下内容：
; 区域文件片段：db.ippipp.com.zone $ORIGIN db.ippipp.com. _primary._tcp IN SRV 10 60 6379 node1.db.ippipp.com. _primary._tcp IN SRV 10 40 6379 node2.db.ippipp.com. _backup._tcp IN SRV 20 0 6379 node3.db.ippipp.com. ; 目标主机必须有对应的A记录 node1 IN A 192.168.10.11 node2 IN A 192.168.10.12 node3 IN A 192.168.10.13
上面的例子中，两条优先级为10的记录通过权重60比40分担主流量，而优先级20的node3作为备用，只有当node1和node2都失败时才会被使用。修改区域文件后记得执行rndc reload或重启named服务让配置生效，并检查SOA记录中的序列号是否已经递增，否则从服务器不会同步更新。
在Windows Server的DNS管理器中，操作路径是：打开DNS管理器，展开正向查找区域，右键点击目标域名，选择“其他新记录”，在弹出的对话框中选择“服务位置(SRV)”，然后依次填入服务名、协议、端口号、提供服务的主机、优先级和权重。域控制器自动注册的Kerberos相关SRV记录（如_kerberos._tcp）就是通过这种方式生成的，这也是域加入和身份认证能正常工作的基础。
使用云服务商DNS（例如阿里云、腾讯云或Cloudflare）时，添加SRV记录通常在控制台的解析设置页面完成。需要注意云平台的记录值格式一般是“优先级 权重 端口 目标主机”四段以空格分隔，主机记录填写的是“_服务名._协议名”部分，不要重复带上主域名，否则会形成错误的多级域名导致解析失败。
验证解析与排查常见问题
配置完成后必须验证。Linux和macOS下推荐使用dig命令，查询语法为dig SRV _primary._tcp.db.ippipp.com，返回结果中ANSWER SECTION会列出所有匹配的SRV记录及其字段。Windows下可以用nslookup，进入交互模式后执行以下命令：
# Windows nslookup 交互模式 nslookup set type=SRV _primary._tcp.db.ippipp.com # 输出示例： # _primary._tcp.db.ippipp.com SRV service location: # priority = 10, weight = 60, port = 6379 # svr hostname = node1.db.ippipp.com
排查问题时首先确认目标主机的A记录是否存在，可以单独执行set type=A查询node1.db.ippipp.com。其次检查服务名和协议名是否严格以下划线开头且协议为小写的tcp或udp。如果客户端查询返回NXDOMAIN，多半是主机记录部分写错了层级；如果返回了记录但客户端连不上服务，则要检查端口字段是否与服务实际监听端口一致，以及目标主机防火墙是否放行。
SRV记录做服务发现的优缺点分析
SRV记录最大的优势是零依赖、零额外组件。它不需要部署Consul、etcd或ZooKeeper这样的注册中心，只要环境里有DNS就能工作，而且所有主流操作系统和编程语言的DNS解析库都原生支持SRV查询。对于变更频率不高的内部服务，用SRV记录做服务发现几乎是成本最低的方案，DNS的分层缓存机制也天然具备一定的抗压能力。
但它的局限同样明显。首先是DNS缓存的TTL机制导致服务下线或扩容后，客户端可能长时间持有过期记录，无法实现秒级的健康感知；其次是SRV记录本身不包含健康检查语义，目标主机宕机后记录依然存在，客户端只能靠自己重试下一个目标。再者，许多常见的客户端库（例如HTTP的多数SDK）默认并不查询SRV记录，只解析A记录，这意味着采用SRV方案需要应用侧显式适配。因此在动态性要求高、需要健康检查和自动摘除故障节点的微服务场景，注册中心类方案更合适；而在配置相对稳定、追求简单可靠的场景，SRV记录依然是值得优先考虑的经典选择。
综合来看，理解SRV记录的优先级与权重语义、保证目标主机A记录完整、并通过dig或nslookup严格验证，是配置成功的三个关键点。掌握这些之后，无论是搭建域环境还是为内部服务做轻量级寻址，SRV记录都能提供可靠的支撑。