我最近在我们的公共 DNS 中创建了以下 CNAME 记录，以允许我们的 Office 2010 客户端自动为 Office 365 配置自身（即我们可以使用自动发现）。
Domain: autodiscover.(ourdomain).com
Target: autodiscover.outlook.com
不幸的是，经过超过 48 小时的 DNS 解析（时间足够多了）后，我们仍然无法使用自动发现。
NSLOOKUP 显示“autodiscover.(ourdomain).com”解析为“(ourdomain).com”，而不是“autodiscover.outlook.com”。指向“lync.com”的其他 CNAME 记录也发生同样的情况。
NSLOOKUP 似乎将我的三个新 CNAME 记录解析回我们域的根目录，而不是指定的 Microsoft 服务器。如果 CNAME 记录不存在，这正是我所期望看到的（因为我们的通配符 CNAME 记录将处理无法识别的子域）。
如果这些特定子域名有 CNAME 记录，那么为什么通配符记录会处理这些请求做存在吗？只有红色突出显示的三条 CNAME 记录似乎被通配符记录覆盖。其他记录工作正常。
看起来这更像是一个一般的 DNS 问题，而不是 Office 365 问题。
答案1
我的托管服务提供商花了大约 2 分钟才发现该问题。
事实证明我忘记在目标和目标主机名末尾添加句点。
问题解决了！
“问题是每个主机名末尾的左侧和右侧都缺少句点“。”。
如果您没有在末尾输入句点，DNS 会将其转换为，例如：
“sip.(yourdomain).ca” 在 DNS 中变成“sip.(yourdomain).ca.(yourdomain).ca”。
但是如果您有“sip.(yourdomain).ca.”（带有句点），它会正确将其识别为“sip.(yourdomain).ca”。
请记住对右侧的 Lync 和其他主机名也执行此操作。
请不要在 IP 地址中添加“.”句点。这些 IP 地址不需要句点，如果添加，将会导致问题。“
这就解释了。通配符（将 NSLOOKUP 查询定向到我们域的根目录）被应用是因为子域“autodiscover.(ourdomain).ca。（我们的域名）.ca“是我的 CNAME 记录被解释的方式 - 所以它与“autodiscover.(ourdomain).ca”的 NSLOOKUP 查询不匹配。
最后，我意识到我实际上可以从左侧列中删除域的根，只要我不添加句点，它就会自动添加。（或者，我可以将域的根保留在那里并添加一个句点 - 但我是一个极简主义者。）
这就是我最终使用的方法，现在 NSLOOKUP 中的所有内容都可以正确解析：
句号仅用在右侧。