问题背景
以下域名均为虚构，仅用作示例
在一次线上事故中，出现了子业务域名a.example.com无法解析到A记录的情况，同时其他子域名服务正常。
配置如下:
- G为
example.com的域名注册商 - Q为
example.com的主域名服务商 - D为
a.example.com的子域名服务商 - Q的NS记录为
ns.domain1.com - D的NS记录为
ns.domain2.com - 在G的系统中给主域名
example.com配置了NS记录，指向ns.domain1.com - 在Q的系统中给子域名
a.example.com配置了NS记录，指向ns.domain2.com - 在D的系统中给子域名
a.example.com配置了A记录，指向最终解析的IP
错误排查
按照解析顺序一步一步进行查看。首先使用以下dig命令判断子域名的NS记录是否正常
|
1 2 |
dig a.example.com ns |
结果发现没有任何返回!
所以这里断定问题出在服务商Q没有正常的解析子域名a.example.com的NS记录。于是反馈问题给服务商Q，进行排查。但是耗费了大量时间仍然没有找到原因之后，突然发现服务商D的业务状态是有问题的，但依旧没有往这方面想。
正确解决
又过了一段时间，终于有一个Q服务商的工程师给出了截图，表明dig a.example.com返回了正确的NS记录，实际是因为服务商D没有正常解析A记录。于是联系D服务商后，问题解决。
事后分析
这件事情没有快速顺利的解决，在于通过子域名NS记录解析失败就判定是主域名服务商的问题，从而找错了方向。实际上就算主域名服务商正确解析了子域名的NS记录，通过dig或nslookup一类的工具，如果只添加上NS参数，也是不能正确判断其状态的。
这就引出了一个问题，如何正确的判定子域名是否正确解析NS记录。
通过搜索，得到了一个比较有说服力的答案。DNS服务器分为权威服务器和转发服务器，访问到转发服务器有很大概率不能得到正确的NS记录结果。所以如果要得到正确的子域名NS记录，一定要访问配置了权威服务器。
在上面的例子中，D服务商的权威服务器就是ns.domain1.com。所以运行以下命令
|
1 2 |
dig +norec @ns.domain1.com a.example.com ns |
这样直接询问权威服务器，就能得到正确的NS解析结果，判定服务商是否正常工作。其实其他记录也一样，因为DNS是一个巨大的缓存系统，访问权威服务器是最直接的检验服务配置是否生效的办法，同样的方法可以检测A记录, CNAME记录等。