MSFT reverse IP failure?

Hank Nussbacher hank at efes.iucc.ac.il
Tue Feb 27 07:38:10 UTC 2018


On 27/02/2018 01:25, Christian Kuhtz via NANOG wrote:

|

13.67.59.89/32 should reverse to |

testconnectivity.microsoft.com

|

|

https://support.office.com/en-us/article/office-365-urls-and-ip-address-ranges-8548a211-3fe7-47cb-abb1-355ea5aa88a2


	

*Optional:* Remote Connectivity Analyzer
<https://testconnectivity.microsoft.com/> - Initiate connectivity tests.

	|

testconnectivity.microsoft.com

| 	

no

	|

13.67.59.89/32
40.69.150.142/32
40.85.91.8/32
104.211.54.99/32
104.211.54.134/32

| 	

TCP 80 & 443


-Hank

> Ken,
>
> A little difficult to say what this without knowing what 13.67.59.89 actually is.   If this is an Azure deployment, ReverseFqdn needs to be populated on the Public IP address resource.  Please take a look here https://docs.microsoft.com/en-us/azure/dns/dns-reverse-dns-for-azure-services
>
> Thanks,
> Christian
>
>
> -----Original Message-----
> From: NANOG <nanog-bounces at nanog.org> On Behalf Of Ken Chase
> Sent: Monday, February 26, 2018 1:31 PM
> To: nanog at nanog.org
> Subject: Re: MSFT reverse IP failure?
>
> Having a client doing a test from the MSFT exchange tools site, which is failing.
>
> NOQUEUE: reject: RCPT from unknown[13.67.59.89]: 450 4.7.1 Client host rejected: cannot find your reverse hostname, [13.67.59.89];
>
> NetRange:       13.64.0.0 - 13.107.255.255
> CIDR:           13.96.0.0/13, 13.104.0.0/14, 13.64.0.0/11
> NetName:        MSFT
>
> A bit of an oversight?
>
> /kc





More information about the NANOG mailing list