核心DNS配置疑问解答 #

你的理解完全正确——子域名要使用独立的权威DNS服务器，必须在父域名的权威DNS服务器上配置对应的NS记录，这是DNS层级解析的核心规则：

当客户端需要解析subdomain.example.com的NS记录时，会按递归流程先找到example.com的权威服务器（比如ns1.example.com），然后向它请求subdomain.example.com的NS记录。如果父权威服务器没有这条记录，递归解析流程就会中断，客户端无法获知子域名的权威服务器地址，最终导致解析失败。

你观察到的现象：公共DNS（如CloudFlare 1.1.1.1）能解析子域名，但直接查询父权威服务器却得不到子域名的NS记录，这完全符合配置异常的表现——公共DNS因为缓存量大、缓存周期长，可能还留存着之前正确的NS记录；而当缓存过期后，新的递归查询就会因为父服务器的配置缺失而失败。

针对Dynamics 365访问问题的根因分析 #

你遇到的DNS_PROBE_FINISHED_NXDOMAIN间歇性错误，根源就是微软的DNS配置不符合规范：

1. 正常递归解析流程中，公司内部DNS或ISP DNS服务器会向dynamics.com的权威服务器查询operations.dynamics.com的NS记录，但因为该服务器没有配置这条记录，递归流程中断，返回NXDOMAIN；
2. 问题会自行恢复，是因为部分递归DNS服务器还缓存着之前的正确NS记录，或者微软临时修复了配置（后续可能再次出现疏漏）；
3. 直接查询子域名的权威服务器能成功，是因为你已经手动指定了正确的服务器地址，但正常的递归解析无法自动获取这个地址。

建议的处理方案 #

1. 精准提交微软支持工单：避开Dynamics应用支持团队，直接通过Azure DNS或微软基础设施支持渠道提交问题，明确说明operations.dynamics.com及其子域名的NS记录未在父域名权威服务器上配置，导致递归解析失败，并附上你收集的查询截图作为证据；
2. 临时缓解措施：如果公司内部DNS支持自定义记录，可以手动添加EXAMPLE.operations.dynamics.com和EXAMPLE.sandbox.operations.dynamics.com的NS记录或A/AAAA记录，让内部DNS直接指向正确的权威服务器，跳过有问题的递归查询环节；
3. 持续监控解析状态：用DNS工具（如dig、nslookup脚本）定期检查域名解析情况，记录失败时的完整递归流程，为微软提供更具体的诊断数据。

备注：内容来源于stack exchange，提问作者JohnLBevan