Community

« Back to Windows version

No DNS entry for id.remoteutilities.com

Page:

Go to last message

Links used in this discussion

Paul Durham, User (Posts: 6)

Sep 10, 2020 2:33:56 pm EDT

Support level: Free or trial

I am trying to set up an Internet-ID Connection based host but connectivity to it fails. Both host & client are currently on the same network and I am able to successfully connect to the host via a direct connection. Both PC's and Windows 10 Professional x64 and have ESET Internet Security enabled. I have created a rule in ESET's firewall to allow ports 5655 & 443 in both directions for TCP & UDP. The host's Internet-ID Connection status indicates "Connection not available" even though it has an ID & both the ID Server & Port are set to the defaults.

I suspect the problem is that id.remoteutilities.com does not resolve on either PC, and from the documentation this is required for an Internet-ID Connection to function. Interestingly, https://www.remoteutilities.com does resolve successfully as do any other common DNS entries like https://www.microsoft.com. Has something happened to the DNS record for id.remoteutilities.com?

Viewer version 6.10.10.0
Host version 6.10.10.0

Pauline, Support (Posts: 2775)

Sep 10, 2020 5:16:43 pm EDT

Hello Paul,

Thank you for your message.

Our servers are up and running and there haven't been any downtimes long ago. id.remoteutilities.com is our public ID servers' DNS name that is used for Internet-ID connections.
As you've noticed, this might point to some issues with DNS resolution on any sides of the connection or, perhaps, access to our servers was blacklisted mistakenly on the ISP level.

Could you please try flushing the DNS cache by executing the following command in the command-line interface:

ipconfig /flushdns

In addition, please try setting your DNS servers to Google Public DNS servers instead of your ISPs in your TCP/IP properties and see if this helps to resolve the issue.

Hope that helps.

Paul Durham, User (Posts: 6)

Sep 11, 2020 7:39:32 am EDT

Support level: Free or trial

Hello Polina,

Flushing the DNS cache didn't help. However, if I do an nslookup using a Google DNS server the address does resolve (see below), so you have me pointed in the right direction - thank you!

C:\Users\ABCDEFG>nslookup
Default Server: home
Address: 192.168.1.1

> id.remoteutilities.com
Server: home
Address: 192.168.1.1

Non-authoritative answer:
Name: id.remoteutilities.com
Addresses: ::
0.0.0.0

> id.remoteutilities.com 8.8.8.8
Server: [8.8.8.8]
Address: 8.8.8.8

Non-authoritative answer:
Name: id.remoteutilities.com
Address: 108.163.130.184

My router is using Quad9 (9.9.9.9) and Cloudflare (1.1.1.2) as its resolvers. I am not sure if the issue is with these DNS resolvers or with my ISP. I have opened a support ticket with my ISP to investigate.

Thank you again.

Paul Durham, User (Posts: 6)

Sep 11, 2020 8:12:58 am EDT

Support level: Free or trial

Hello Polina,

It turns out that Quad9 9.9.9.9 (DNS with malicious domain blocking) and Cloudflare 1.1.1.2 (DNS with malware blocking) both refuse to resolve id.remoteutilities.com because they flag this as a malicious domain. Their unfiltered DNS services (9.9.9.10 & 1.1.1.1) resolve id.remoteutilities.com correctly.

Why are both these companies treating id.remoteutilities.com as a malicious domain? Since they are both among the largest DNS resolvers in the world I am sure it is in your company's interest to investigate & resolve this issue. Any any what they have detected that is casing them to treat your domain as malicious?

Thank you,
Paul.

Pauline, Support (Posts: 2775)

Sep 11, 2020 3:41:57 pm EDT

Hello Paul,

I'm glad to hear we were able to help and thank you for bringing this issue to our attention.

We've contacted both CloudFlare and Quad9 and requested them to whitelist id.remoteutilities.com and reported the issue to our development department as well. Hopefully, this would be resolved soon.

It would be very helpful if you could contact them as well, as their customer, and report on the issue. We believe they would take reports from their customers into consideration much faster.

Please let us know if you have more questions.

Paul Durham, User (Posts: 6)

Sep 11, 2020 6:32:33 pm EDT

Support level: Free or trial

Hello Polina.

I will gladly submit a request to both DNS providers to whitelist your domain. Why do you believe they blacklisted it in the first place? Is there anything about RemoteUtilities that would have concerned them?

Thank you,
Paul.

john Randal, User (Posts: 120)

Sep 12, 2020 5:48:53 pm EDT

Support level: Mini

nevermind

Edited:john Randal - Sep 12, 2020 5:49:42 pm EDT

Paul Durham, User (Posts: 6)

Sep 13, 2020 10:04:33 am EDT

Support level: Free or trial

@john Randal, I don't understand you comment.

Pauline, Support (Posts: 2775)

Sep 14, 2020 4:08:34 pm EDT

Hello Paul,

Thank you for your concern.

We have already submitted false positives to both CloudFlare and Quad9. Quad9 has already checked and let us know that they're not currently blocking any of our domains, including id.remoteutilities.com. It's also possible to check if they're blocking any domains on this page.
As for the CloudFlare - we're still waiting for their reply, hopefully, your submitted report will help to bring their attention to this issue faster.
Unfortunately, it's hard to tell what might be the exact reason for them to blacklist our server's DNS name. Perhaps, it was done by mistake.
I don't think that there's anything wrong with Remote Utilities that might have concerned them - all traffic that Remote Utilities sends over the network is encrypted. In addition, encryption is always on by default and cannot be disabled by the user. For more information please see our Security page.

I will get back to you with an update on this as soon as we receive any reply from the CloudFlare.

Paul Durham, User (Posts: 6)

Sep 21, 2020 7:10:59 am EDT

Support level: Free or trial

Hello Polina,

Have you had feedback from CloudFlare?

Submit a reply

Page:

Go to last message

^* Website time zone: America/New_York (UTC -4)