'outlook.office365.com' resolving to incorrect alias in Sydney, Australia.

1,962 views
Skip to first unread message

misf...@gmail.com

unread,
Mar 11, 2016, 6:23:12 PM3/11/16
to public-dns-discuss
The organisation I work for has used Office 365 for mail for a year or so now. MS recently opened data centres in Sydney and Melbourne hosting Office 365 services. Since the migration of our mailboxes to the local Sydney DC we've noticed that latency is still high.  

After investigating I noticed that 'outlook.office365.com' resolves to 'outlook-apacsouth.office365.com' when using 8.8.8.8 or 8.8.4.4. We use both address as the external forwarders for our internal DNS servers. RTT is high to 'outlook-apacsouth.office365.com'  See lookup and trace below.

Address:  8.8.8.8

DNS request timed out.
    timeout was 2 seconds.
Non-authoritative answer:
Addresses:  2a01:111:f400:5224::2
          2a01:111:f400:2e4a::2
          2a01:111:f400:2f9f::2
          2a01:111:f400:a400::2
          2a01:111:f400:2e28::2
          2a01:111:f400:5223::2
          2a01:111:f400:b400::2
          2a01:111:f400:2e29::2
          2a01:111:f400:2e96::2
          2a01:111:f400:a02e::2
          40.96.13.194
          132.245.129.130
          132.245.57.194
          40.96.17.178
          132.245.254.146
          40.100.0.34
          40.96.3.210
          132.245.42.242
          132.245.64.82
          40.96.3.226
          lb.geo.office365.com


Tracing route to outlook-apacsouth.office365.com [132.245.42.242]
over a maximum of 30 hops:

  1     1 ms    <1 ms    <1 ms  192.168.1.1
  2    10 ms    10 ms     9 ms  10.204.192.1
  3     9 ms    14 ms    10 ms  58.160.11.2
  4    37 ms     8 ms     9 ms  58.160.15.226
  5    10 ms     8 ms     9 ms  203.50.12.106
  6    12 ms     9 ms    13 ms  203.50.11.96
  7    12 ms    14 ms    10 ms  203.50.11.95
  8    10 ms    16 ms    10 ms  139.130.58.222
  9    33 ms    22 ms    25 ms  104.44.225.239
 10    22 ms    21 ms    29 ms  104.44.226.40
 11    68 ms    71 ms    66 ms  104.44.226.38
 12   148 ms   142 ms   136 ms  104.44.225.114
 13   137 ms   135 ms   135 ms  104.44.226.169
 14   182 ms   183 ms   184 ms  104.44.225.241
 15     *        *        *     Request timed out.
 16     *        *        *     Request timed out.
 17     *        *        *     Request timed out.
 18     *        *        *     Request timed out.
 19   140 ms   141 ms   139 ms  132.245.42.242

Trace complete.

When using a different DNS server (202.177.197.1) 'outlook.office365.com' alias resolves to 'outlook-au.office365.com' which is the correct alias for the Australian Office 365 instances.

Address:  202.177.197.1

Non-authoritative answer:
Addresses:  2a01:111:f400:580f::2
          2a01:111:f400:5901::2
          2a01:111:f400:7089::2
          2a01:111:f400:5180::2
          2a01:111:f400:580c::2
          2a01:111:f400:5c00::2
          2a01:111:f400:7088::2
          2a01:111:f400:5800::2
          132.245.163.178
          132.245.164.242
          132.245.163.66
          132.245.165.146
          132.245.164.226
          132.245.164.34
          132.245.165.130
          132.245.162.162
          lb.geo.office365.com

RTT times to 'outlook-au.office365.com' are much lower. See below.

C:\>tracert -d outlook.office365.com

Tracing route to outlook-au.office365.com [132.245.165.130]
over a maximum of 30 hops:

  1     1 ms    <1 ms    <1 ms  192.168.160.5
  2    <1 ms    <1 ms    <1 ms  192.168.160.10
  3    <1 ms    <1 ms    <1 ms  180.189.25.153
  4    <1 ms    <1 ms    <1 ms  27.111.240.144
  5    <1 ms    <1 ms    <1 ms  202.167.228.36
  6     1 ms     1 ms     1 ms  104.44.225.233
  7     *        *        *     Request timed out.
  8     *        *        *     Request timed out.
  9     1 ms    <1 ms    <1 ms  132.245.165.130

Trace complete.

C:\>

Can this please be resolved?

Regard,
Simon.


Alexander Dupuy

unread,
Mar 11, 2016, 6:40:16 PM3/11/16
to misf...@gmail.com, public-dns-discuss
Unfortunately, there is nothing that we can do within Google to resolve your problem (short of opening a data center in Australia).  The fundamental problem is that Microsoft's nameservers are not using the EDNS Client Subnet (ECS) extension to geo-locate based on your original IP address, but rather are basing their reply on the GeoIP location of the client that is querying them. In your case, the nearest Google Public DNS location (https://developers.google.com/speed/public-dns/faq#support) is in Singapore, which is why you are getting a CNAME to outlook-apacsouth.

Microsoft's lack of support for ECS is a bit unusual among the major CDN/Cloud providers - Akamai, AWS Route 53, and many other services have supported ECS for quite some time. If ECS gets promoted from Internet-Draft to RFC, I would guess that Microsoft will add support for it, but until that happens, I wouldn't hold my breath (I would love to be proved wrong, though).

@alex

Simon Dempsey

unread,
Mar 12, 2016, 6:33:54 AM3/12/16
to public-dns-discuss, misf...@gmail.com
Thanks for the explanation Alex. It really is quite interesting that MS are not supporting this feature, or even more importantly are not informing their customers of the potential issue.Once we were advised that our mail tenancy was now local, it seemed even less responsive. 

Thanks again.
Simon.

maste...@gmail.com

unread,
Jul 15, 2016, 2:08:01 PM7/15/16
to public-dns-discuss, misf...@gmail.com
Hi Mate, 

Not sure if you have fixed this issue but I recently ran into the same issue. Turns out at some stage my Windows server DNS cached the outlook-apacsouth.office365.com for outlook.office365.com. I flushed the DNS cache and it resolved the issue. 

Emil

pikeits...@gmail.com

unread,
Jan 8, 2017, 11:34:40 AM1/8/17
to public-dns-discuss
This issue still exists. I am trying 8.8.8.8/8.8.4.4 in place of Telstra Business DNS servers due to the filtering but it creates issues with Facebook and O365 going overseas.

My current fix is to send office365.com/facebook.com/fbcdn.net to a Telstra DNS resolver and everything else to Google DNS - but it would be better if everything could go to Google DNS.

Alex Dupuy

unread,
Jan 11, 2017, 10:37:33 AM1/11/17
to public-dns-discuss, pikeits...@gmail.com
On Sunday, January 8, 2017 at 11:34:40 AM UTC-5, pikeitservices wrote:
This issue still exists. I am trying 8.8.8.8/8.8.4.4 in place of Telstra Business DNS servers due to the filtering but it creates issues with Facebook and O365 going overseas.

My current fix is to send office365.com/facebook.com/fbcdn.net to a Telstra DNS resolver and everything else to Google DNS - but it would be better if everything could go to Google DNS.


Until Microsoft or Facebook support EDNS Client Subnet (ECS), or Google opens a data center in Australia, there is nothing we can do.

I'm not too optimistic about Microsoft or Facebook, but there is some good news on the Google side: https://cloud.google.com/about/locations/

Please be aware those are planned Cloud locations, there is no commitment to providing recursive to authoritative DNS egress from any of those locations (although Singapore [SIN] is already a Google Public DNS egress point—see https://developers.google.com/speed/public-dns/faq#locations, which will soon add Northern Virginia [IAD]). Note that the presence of a location on the list merely indicates that Google Public DNS could use it, not that it will; Dublin [DUB] on that list being one that is currently unused.

At any rate, there is some light at the end of the tunnel, and hope that Google may be able to improve the experience of Google Public DNS users in Australia by the end of the year, possibly sooner.

pikeits...@gmail.com

unread,
Jan 11, 2017, 10:49:53 AM1/11/17
to public-dns-discuss, pikeits...@gmail.com
Hi Alex
Thanks for the reply. I have opened a thread on MS support forums about EDNS Client Subnet:


I'm not bothering with Facebook - I doubt they would be interested. O365 is a different story as I pay for that hence why I am going down that path.

pikeits...@gmail.com

unread,
Jun 29, 2017, 1:54:21 PM6/29/17
to public-dns-discuss, pikeits...@gmail.com
Google is now listing subnets for Sydney on the DNS locations page:

2404:6800:4006::/48 syd 

Looks like they are not being used for queries yet. Any idea on when that will change?

Once queries are done from Sydney I will probably set my laptop to use Google DNS so I have unfiltered internet regardless of what internet connection I am using.

Alex Dupuy

unread,
Jul 1, 2017, 10:27:29 AM7/1/17
to public-dns-discuss, pikeits...@gmail.com
Hi Chris,

You wrote:
Google is now listing subnets for Sydney on the DNS locations page:

Looks like they are not being used for queries yet. Any idea on when that will change?

I previously wrote: 
I'm not too optimistic about Microsoft or Facebook, but there is some good news on the Google side: https://cloud.google.com/about/locations/

Please be aware those are planned Cloud locations, there is no commitment to providing recursive to authoritative DNS egress from any of those locations (although Singapore [SIN] is already a Google Public DNS egress point—see https://developers.google.com/speed/public-dns/faq#locations, which will soon add Northern Virginia [IAD]). Note that the presence of a location on the list merely indicates that Google Public DNS could use it, not that it will; Dublin [DUB] on that list being one that is currently unused.

We still don't have any specific plan to use these locations for Google Public DNS, but we are looking into the possibilities.

As this is a Google Cloud location, the first priority would be to use them for DNS resolution for customer Cloud applications and services, but we might be able to use them for Google Public DNS for whitelisted domains that do not support ECS, but do return geo-located responses, such as Microsoft's domains, and possibly a few high-traffic domains hosted on Azure DNS.

We would announce this when and if we enable such functionality.

pikeits...@gmail.com

unread,
Jul 18, 2017, 10:39:08 AM7/18/17
to public-dns-discuss
On Sunday, July 2, 2017 at 12:27:29 AM UTC+10, Alex Dupuy wrote:

We still don't have any specific plan to use these locations for Google Public DNS, but we are looking into the possibilities.

As this is a Google Cloud location, the first priority would be to use them for DNS resolution for customer Cloud applications and services, but we might be able to use them for Google Public DNS for whitelisted domains that do not support ECS, but do return geo-located responses, such as Microsoft's domains, and possibly a few high-traffic domains hosted on Azure DNS.

Hi Alex

Would be great if all queries done in AU can come out in Sydney - might get response times down to similar to ISP DNS:

For comparison:

;; ANSWER SECTION:
www.google.com.au.      276     IN      A       216.58.203.99
;; Query time: 152 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)

ISP DNS:

;; ANSWER SECTION:
www.google.com.au.      219     IN      A       216.58.196.227
;; Query time: 37 msec
;; SERVER: 139.130.4.4#53(139.130.4.4)


I know its free and I can't expect everything - just would be nice to have a dual stack DNSSEC compatible resolver that is fast here (plus having Microsoft/Facebook returning local results is needed).

I currently am using OpenDNS (which is not dual stack and doesn't have DNSSEC) and would like to switch my whole network to Google Public DNS. OpenDNS does all queries from Sydney for me.

Reply all
Reply to author
Forward
0 new messages