Issue with Reverse DNS Lookup only with OpenDNS

[Rafael_Riera]

Hello OpenDNS Community,

We are encountering a problem where reverse DNS (PTR) lookups for one of our IP addresses succeed on most DNS servers but consistently fail when using OpenDNS resolvers. Specifically, the PTR record resolves correctly on standard DNS servers but returns an NXDOMAIN error when queried through OpenDNS.

We have confirmed that the PTR and corresponding A records are correctly configured and fully consistent.

Has anyone experienced similar issues or could offer insight into why OpenDNS resolvers might fail to resolve certain reverse DNS entries even though they appear properly set up?

Thanks in advance for any guidance or suggestions.

Best Regards

[reham1]

Hello, 

Try refreshing the cache on your domain at (cachecheck.opendns.com).

[Rafael_Riera]

Hi Reham

I have refreshed the domain in cachecheck.opendns.com. But the problem is the same:

In opendns:

PS C:\Users\rriera> nslookup.exe 62.37.182.181 208.67.222.222
Servidor: dns.sse.cisco.com
Address: 208.67.222.222

*** dns.sse.cisco.com no encuentra 62.37.182.181: Non-existent domain

In google dns
PS C:\Users\rriera> nslookup.exe 62.37.182.181 8.8.8.8
Servidor: dns.google
Address: 8.8.8.8

Nombre: mail6.divinaseguros.com
Address: 62.37.182.181

Thanks in advance for your answer

[reham1]

Hello,

Please specify the exact domain address you are having this problem with. 

Your reply is appreciated

[Bryan Byles]

I went to the dashboard https://dashboard.opendns.com/ and "Never Blocked" divinaseguros.com in order for it to come up on my OpenDNS PC.
Apologies in advance for Google Translate:
Fui al panel de control https://dashboard.opendns.com/ y aparecía "Nunca bloqueado" divinaseguros.com para que apareciera en mi PC con OpenDNS.

[reham1]

Hello,

The results of a dig test  (excerpt shown below) on the domain show that whether a DNS resolver is not used or when Google and OpenDNS are used the IP address returned is 40.122.36.65

; <<>> DiG 9.10.6 <<>> divinaseguros.com

divinaseguros.com. 0 IN A 40.122.36.65

—————————————

; <<>> DiG 9.10.6 <<>> divinaseguros.com @8.8.8.8

divinaseguros.com. 5 IN A 40.122.36.65

——————————————————

; <<>> DiG 9.10.6 <<>> divinaseguros.com @208.67.222.222

divinaseguros.com. 5 IN A 40.122.36.65

—————————————————— 

; <<>> DiG 9.10.6 <<>> divinaseguros.com @208.67.220.220;

divinaseguros.com. 5 IN A 40.122.36.65

[Bryan Byles]

Per cachecheck.opendns.com for divinaseguros.com
South America, North America, Europe, Australia, Asia and Africa all point to 40.122.36.65 (Organization: Microsoft Corporation (MSFT))
If you manage this domain, contact your DNS host and report the problem.
https://dnschecker.org/#A/divinaseguros.com says the same as the Cachecheck above.(40.122.36.65)
I concur with your findings using DiG 9.16.23-RH from Oracle Linux on WSL.
https://www.whois.com/whois/62.37.182.181
https://www.whois.com/whois/divinaseguros.com 
I concur with the following:

PS C:\Users\ZZ> nslookup.exe 62.37.182.181 8.8.8.8
Server: dns.google
Address: 8.8.8.8

Name: mail6.divinaseguros.com
Address: 62.37.182.181

PS C:\Users\ZZ> nslookup.exe 62.37.182.181 208.67.222.222
Server: dns.sse.cisco.com
Address: 208.67.222.222

*** dns.sse.cisco.com can't find 62.37.182.181: Non-existent domain

[Rafael_Riera]

Hi Bryan and Reham. Thanks for your responses.

But I don't understand what the problem is with  that the domain register for divinaseguros.com which is 40.122.36.65 (azure) and the register for mail6.divinaseguros.com  is 62.37.182.181.

We have open a case with the internet provider for reverse domain for the ip 62.37.182.181 and it is ok.

Yes,  the problem that we have is that:

PS C:\Users\ZZ> nslookup.exe 62.37.182.181 8.8.8.8
Server: dns.google
Address: 8.8.8.8

Name: mail6.divinaseguros.com
Address: 62.37.182.181

PS C:\Users\ZZ> nslookup.exe 62.37.182.181 208.67.222.222
Server: dns.sse.cisco.com
Address: 208.67.222.222

*** dns.sse.cisco.com can't find 62.37.182.181: Non-existent domain

And we have problem with email servers that use openDNS , because they can´t resolve de reverse register.

Thanks for your time.