Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Unpredictable DNS results with Office365

Hello,

We are seeing unpredictable results with the returned records for DNS (in particular from 64.6.65.6), while it still happens with 64.6.64.6 too.

Expected behaviour is that a client would request outlook.office365.com and get the nearest geographical Microsoft datacentre returned, for instance, I would expect to get outlook-emeaeast.office365.com returned (as a CNAME).
Runnning 100 nslookups, I see that suddenly outlook-namnortheast2.office365.com would return (North America, north).

Then, it may return to emea again, but it seems very indecisive about where to send me...

I also tested this from outside Europe, same dns request to outlook.office365.com via a server I have over in New York, and also from a server just outside London - they all provide unexpected results.

When testing with google anycast dns (8.8.8.8) the behaviour is not present - i.e it gives solid and predictable answers.
Microsoft said that everything was ok on their end. Without your LDNS source address, it's pretty hard to know how they determine what dns record they will return.

I ran a solid ping, and it provided stable results (31ms) suggesting that the anycast address responds from the same location every time.

Mtr to 64.6.65.6
Host Loss% Snt Last Avg Best Wrst StDev
5. ae9-0.ffm2nqp1.de.ip.tdc.net 0.0% 95 25.8 27.1 25.6 57.6 4.7
6. xe-1-1-0.r1.bb-fo.fra1.vrsn.net 0.0% 95 26.2 26.7 25.8 54.0 3.0
7. po3.r1.edge-fo.fra1.vrsn.net 0.0% 95 28.1 27.0 26.0 29.4 0.6
8. host-167.fra1.verisign.com 0.0% 95 56.4 28.1 25.9 125.5 10.7
bu-ether1.r2.edge-fo.fra1.verisign.com
9. recpubns2.nstld.net 0.0% 95 26.3 26.5 25.6 35.2 1.0


Here is an mtr of the connection to 64.6.64.6
Host Loss% Snt Last Avg Best Wrst StDev
5. ae9-0.ffm2nqp1.de.ip.tdc.net 0.0% 96 56.2 26.9 25.6 56.2 4.3
6. xe-1-1-0.r1.bb-fo.fra1.vrsn.net 0.0% 95 26.1 32.7 25.9 99.7 18.8
7. xe-7-1-0.r1.bb-fo.ams1.vrsn.net 0.0% 95 26.9 26.5 25.4 36.2 1.3
8. xe-1-2-0.r1.bb-fo.lon3.vrsn.net 0.0% 95 49.0 32.4 30.3 80.7 6.6
9. ae3.r1.edge-fo.lon3.vrsn.net 0.0% 95 30.9 31.0 30.2 52.9 2.6
10. 0.ae0.r2.edge-fo.lon3.verisign.com 0.0% 95 30.4 33.0 30.1 110.3 8.7
11. recpubns1.nstld.net 0.0% 95 30.5 30.6 30.2 33.4 0.5



Can you please look into this?

Cheers,
Simon.

Comments

  • Hello Simon, thank you for your feedback. We are reviewing further and should have an update for you soon.
  • Thank you. Let me know if I can troubleshoot some more :)
  • Hello Simon, thank you for your patience. Due to the length of the content provided in my results, I sent you an e-mail with those details. Please review those details and let us know if you are still receiving inconsistent results using a DIG request.
  • Hello, and thank you. I sent lengthy email in return, which still gives unpredictable results.
    It seems less of a problem when querying dns servers in the US than in London, not sure if this is related to those servers or MS' attempt to resolve the location of the querying LDNS.
    Your continuing efforts are much appreciated.

    Simon
  • Simon, thanks for your continued patience as we are still reviewing the data you provided.
  • After further review we are not seeing abnormal behavior from our recursive server. The routing and different geographic responses may be a result of configuration setting at the destination which determines where queries are coming in from and as a result, determines where to respond from.
Sign In or Register to comment.