正文
问题引入
假设你现在有一个域名service.domain.com中, 在端口1000上跑了一个TCP服务, 现在用户使用客户端访问service.domain.com:1000即可访问你提供的服务.
为了减少用户的输入, 同时规避一些错误, 你使用SRV解析来关联了上述的服务到domain.com(_service._tcp.domain.com), 通过SRV关联端口的功能, 你成功的令用户只需要在配置中填入domain.com即可访问你的服务, 这个方案成功降低了用户输错端口号之类情况的概率.
为了加快用户访问服务的速度, 你使用若干不同服务商提供的若干个边缘计算或反向代理节点, 由于使用了不同的服务商提供的服务, 你得到的端口号五花八门, 得到的加速地区也不一定是单独的某个地区. 甚至有的服务商很大方的给你提供了全地区的BGP节点.
这时候你发现了第一个问题, 单个的SRV解析不能再满足你的需求了, 因为SRV记录一条只针对于一个加速节点, 在稍微了解后, 你了解到可以通过添加"多线解析"的方式来自动为不同区域的用户返回最近的节点, 对于同一个地区有多个节点的用户, 你还可以通过设置解析权重来达到负载均衡.
这时候你发现了一个严重的问题, 那就是通过SRV协议设置的服务不能被ping通, ping不认识SRV解析. 也就意味着如果某条线路出了问题你无法通过ping命令来定位具体出问题的线路.
解决思路与方案
在通过一番搜索后, 我了解到可以通过NSLOOKUP命令来获取当前计算机获取到的SRV解析信息.
nslookup
于是可以用下方命令来进行查询:
nslookup -type=SRV _service._tcp.domain.com
参考文章
SRV记录 - DNS学习笔记
nslookup(1) - Linux man page
验证是否已创建 SRV 域名系统 (DNS) 记录 - Windows Server | Microsoft Learn
nslookup详解(name server lookup)( 域名查询) - 范仁义 - 博客园
配置权重解析云解析服务 DNS用户指南智能线路解析华为云
I have been browsing online more than three hours today yet I never found any interesting article like yours It is pretty worth enough for me In my view if all website owners and bloggers made good content as you did the internet will be a lot more useful than ever before