Hi All One of the customers of a recursive service we operate has reported issues with their users accessing Office 365. Their internal investigation have indicated that the problem probably lies with resolving outlook.live.com against our service.
They have reported that when their local resolvers query that domain, the answer they get back varies. So they are sometimes getting this cname chain: ;; ANSWER SECTION: outlook.live.com. 141 IN CNAME live.ms-acdc.office.com. live.ms-acdc.office.com. 1729 IN CNAME outlook.ha.office365.com. outlook.ha.office365.com. 41 IN CNAME outlook.ms-acdc.office.com. outlook.ms-acdc.office.com. 21 IN CNAME LHR-efz.Ms-acDC.office.com. LHR-efz.ms-acdc.office.com. 36 IN CNAME outlook-fs.office.com. outlook-fs.office.com. 14 IN CNAME outlook-exo.trafficmanager.net. outlook-exo.trafficmanager.net. 28 IN CNAME lhr-mvp.trafficmanager.net. lhr-mvp.trafficmanager.net. 35 IN A 52.97.165.146 lhr-mvp.trafficmanager.net. 35 IN A 52.97.133.178 lhr-mvp.trafficmanager.net. 35 IN A 52.97.146.162 lhr-mvp.trafficmanager.net. 35 IN A 52.97.179.226 lhr-mvp.trafficmanager.net. 35 IN A 52.97.146.146 lhr-mvp.trafficmanager.net. 35 IN A 40.100.174.18 lhr-mvp.trafficmanager.net. 35 IN A 40.100.174.210 lhr-mvp.trafficmanager.net. 35 IN A 40.100.174.34 In the above output, the qname LHR-efz.ms-acdc.office.com (5th in the chain) is a CNAME. However, sometimes it is an A rrset: ;; ANSWER SECTION: outlook.live.com. 32 IN CNAME live.ms-acdc.office.com. live.ms-acdc.office.com. 1727 IN CNAME outlook.ha.office365.com. outlook.ha.office365.com. 39 IN CNAME outlook.ms-acdc.office.com. outlook.ms-acdc.office.com. 19 IN CNAME LHR-efz.ms-acdc.office.com. LHR-efz.ms-acdc.office.com. 1 IN A 52.97.146.162 LHR-efz.ms-acdc.office.com. 1 IN A 52.97.129.66 LHR-efz.ms-acdc.office.com. 1 IN A 40.100.174.226 LHR-efz.ms-acdc.office.com. 1 IN A 52.97.146.194 It’s not unusual for a GSLB to reply with different IPs every time, but I have not seen it before where you sometimes get a CNAME and sometimes A/AAAA. I’m not totally sure why this would be problematic, but one theory that we are tossing around is that the customer’s caching resolvers are attempting to prefetch the LHR-efz.ms-acdc.office.com record, receiving a NODATA response and therefore responding to the client with NXDOMAIN. I am wondering what people’s thoughts are on whether this theory has merit? I was previously able to replicate the issue up until an hour or two ago, now it is responding consistently with an A rrset, so it’s possible that it has gone away. Thanks, Paul Harris Senior DNS and Network Engineer [Nominet] Website<http://www.nominet.uk/> | Twitter<https://twitter.com/Nominet> | Facebook<https://www.facebook.com/nominet/> DD: +44 (0)1865 981759 E: [email protected]<mailto:[email protected]> Minerva House, Edmund Halley Road, Oxford Science Park, Oxford, OX4 4DQ, United Kingdom This message is intended exclusively for the individual(s) to whom it is addressed and may contain information that is privileged, or confidential. If you are not the addressee, you must not read, use or disclose the contents of this e-mail. If you receive this e-mail in error, please advise us immediately and delete the e-mail. Nominet UK has taken every reasonable precaution to ensure that any attachment to this e-mail has been swept for viruses. However, Nominet cannot accept liability for any damage sustained as a result of software viruses and would advise that you carry out your own virus checks before opening any attachment.
_______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations
