0

I recently created the following CNAME record in our public DNS in order to allow our Office 2010 clients to automatically configure themselves for Office 365 (i.e. so we can use autodiscover).

Domain: autodiscover.(ourdomain).com
Target: autodiscover.outlook.com

Unfortunately, after allowing over 48 hours for DNS to resolve (more than enough time) we still cannot use autodiscover.

NSLOOKUP reveals that "autodiscover.(ourdomain).com" resolves to "(ourdomain).com", rather than "autodiscover.outlook.com". The same happens with the other CNAME records pointing to "lync.com".

enter image description here

NSLOOKUP seems to resolve my three new CNAME records back to the root of our domain rather than to the Microsoft servers specified. This is exactly what I would expect to see if the CNAME records did not exist (as our wildcard CNAME record would then handle the unrecognized subdomains).

Why is the wildcard record apparently handling these requests if CNAME records for these specific subdomains do exist? Only the three CNAME records highlighted in red seem to be overridden by the wildcard record. The others are working correctly.

It seems this is more of a general DNS question than an Office 365 one.

  • The autodiscover record looks precisely the same as the other records like mail, pop3, and so on. Are you sure this is the live set of DNS records? – David Schwartz Apr 3 '14 at 23:31
  • This is definitely the live set of DNS records. These records aren't precisely the same as far as I can see as both the source and destination hosts in the CNAME records are different. All CNAME records pointing to Zenutech correctly resolve in NSLOOKUP. All new CNAME records pointing to Microsoft servers ("outlook.com" and "lync.com") fail to resolve properly - the wildcard CNAME record seems to be applied instead as they resolve to the root of our domain. I can't see why the new CNAME records are effectively being ignored. – Austin ''Danger'' Powers Apr 4 '14 at 0:15
  • Have you seen this: help.outlook.com/en-us/140/cc950655.aspx – joeqwerty Apr 4 '14 at 0:30
  • Yes. It shows which CNAME record to create for autodiscover. I have created the record correctly (fourth line from bottom). For some reason is being ignored in favor of the wildcard CNAME record at the bottom of the list. I have even had a Microsoft Office 365 support technician remotely connect to my PC and check the records himself to verify they were correct. The problem seems to be with our DNS somewhere but everything else works fine (including our other CNAME records). – Austin ''Danger'' Powers Apr 4 '14 at 0:36
5

My hosting provider took about 2 minutes to spot the problem.

Turns out I had forgotten to add periods to the end of the target and destination hostnames.

Problem solved!

"The issue is that you are missing a period "." at the end of each hostname, on both the left side and on the right hand side.

When you don't enter a period at the end, DNS translates that into, for example:

"sip.(yourdomain).ca" becomes "sip.(yourdomain).ca.(yourdomain).ca" in DNS.

But if you had "sip.(yourdomain).ca." (with the period), it would recognize it as "sip.(yourdomain).ca" correctly.

Remember to do it for the Lync and other hostnames on the right hand side as well.

Please do not add "." periods to IP addresses. Those don't need the period and will cause an issue if added to them."

So that explains it. The wildcard (which directed NSLOOKUP queries to the root of our domain) was being applied because the subdomain "autodiscover.(ourdomain).ca.(ourdomain).ca" was how my CNAME record was being interpreted - so it did not match the NSLOOKUP query for "autodiscover.(ourdomain).ca".

In the end, I realized I could actually delete the root of the domain from the left hand column and it would automatically be added as long as I didn't append a period. (Alternatively, I could have left the root of the domain in there and appended a period - but I'm a minimalist.)

This is what I ended up using and everything is now resolving properly in NSLOOKUP:

enter image description here

Periods only used on the right hand side.

  • Interesting. The problem with most web based DNS control panels is that everyone seems to have a different layout, field names, field requirements, etc. – joeqwerty Apr 4 '14 at 4:13
  • 1
    Those pesky trailing dots are so important. – milli Apr 8 '14 at 9:42

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.