Cloudflare DNS unaware of a host?

#1

I use voip.ms as my voip provider and Zoiper Biz as my softphone. I had Zoiper configured to access the chicago2.voip.ms server and that had been working fine for years. Recently, I configured my router to use the 1.1.1.1 DNS server and forced my computer to get DNS entries from the router. This has not led to any rpoblems, until yesterday…

When I tried placing a call, I got a SIP 503 - DNS timeout error. I reached out to voip.ms and they suggested using the IP address, instead of the domain, and that worked. Strangely, I was able to successfully ping the server from my computer. I posed this question to Zoiper and they responded: This error and the fact that you can connect to the server by IP address indicates that the cloudflare’s DNS server is not aware of the domain which you are using. There could be many different reasons for that. However I can only suggest that you either use the IP address or return the standard DNS server of your ISP.

I am not sure who to believe at this point. While I can make calls, I would like to understand the cause of the problem in case something like this crops up again. Any ideas/suggestions?

Thanks!

#2

Which IP address is the one working?

#3

sandro - thank you for taking time to reply, but I am not sure that I understand your question. Within Zoiper->Preferences, where the provider is defined, when I enter chicago2.voip.ms, then I get the DNS timeout error; however, when I enter 208.100.39.53, then the calls are completed.

Note that I was able to successfully ping the server from my computer when I tried ping chicago2.voip.ms (and the reply shows the IP address shown above).

#4

Thats the same IP address Cloudflare is resolving.

Can you open a command line and type ping chicago2.voip.ms and nslookup chicago2.voip.ms and post the output here?

#5

Good suggestion - hadn’t thought to try nslookup!

C:\Users\Gerry>ping chicago2.voip.ms
Pinging chicago2.voip.ms [208.100.39.53] with 32 bytes of data:
Reply from 208.100.39.53: bytes=32 time=20ms TTL=56
Reply from 208.100.39.53: bytes=32 time=19ms TTL=56

C:\Users\Gerry>nslookup chicago2.voip.ms
DNS request timed out.
timeout was 2 seconds.
Server: UnKnown
Address: 192.168.73.1

Non-authoritative answer:
Name: chicago2.voip.ms
Address: 208.100.39.53

The problem seems to be on my end - wonder what’s going wrong…

#6

Do you have Cloudflare currently configured as system resolver?

You can try additionally nslookup chicago2.voip.ms 1.1.1.1. What does that give you?

#7

In case you ask:

From my router:
Status: Connected
IP Address: xx.xx.xx.xx
Subnet Mask: 255.255.252.0
Default Gateway: xx.xx.xx.xx
Primary DNS: 1.1.1.1
Secondary DNS: 208.67.222.222

From my computer:

C:\Users\Gerry>ipconfig /all

Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Realtek PCIe GBE Family Controller
Physical Address. . . . . . . . . : xx-xx-xx-xx-xx-xx
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IPv4 Address. . . . . . . . . . . : 192.168.xx.8(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Lease Obtained. . . . . . . . . . : Thursday, 03 January, 2019 5:39:08 PM
Lease Expires . . . . . . . . . . : Sunday, 16 February, 2155 7:41:16 PM
Default Gateway . . . . . . . . . : 192.168.xx.1
DHCP Server . . . . . . . . . . . : 192.168.xx.1
DNS Servers . . . . . . . . . . . : 192.168.xx.1
NetBIOS over Tcpip. . . . . . . . : Enabled

Both the router and computer have been recently rebooted.

#8

C:\Users\Gerry> nslookup chicago2.voip.ms 1.1.1.1
Server: one.one.one.one
Address: 1.1.1.1

Non-authoritative answer:
Name: chicago2.voip.ms
Address: 208.100.39.53

No - I have pointed my computer to my router, i.e., my router is my resolver. Seems odd that I would need to configure the DNS entries in two places (router and computer)…

#9

Well, you seem to be able to resolve that host just fine. So I’d assume the application should be fine too.

#10

I appreciate your help

#11

Does the application show any error when you try to connect via the hostname?

#12

Via hostname, I get the DNS timeout error; via IP address, it works just fine.

#13

Could you also run nslookup chicago2.voip.ms 208.67.222.222?

#14

Many routers out there just have a completely broken DNS forwarder; I have no idea where do they get them, given that there are some very good ones used in the opensource world;

Anyway - I have my own rule for like 20 years now: Never use your router as a DNS server if you don’t want to waste your time randomly.

If you can, have your router set the external DNS servers (like 1.1.1.1 or 8.8.8.8) in its’ DHCP responses. If that is not possible (they must act as a proxy and give their own IP as the DNS server), just hard code the external IPs in your NIC configuration (or resolv.conf if you use a better OS…) for “DNS Servers” and leave just the “Obtain IP” on DHCP.

#15

I am not sure I’d blame the router just yet. The host did resolve fine earlier. Maybe there is an issue with OpenDNS.

Also, the “better OS” remark? Come on :wink:

#16

The part of “resolve fine earlier” and stopped working out of the blue, is exactly the “broken forwarders” I was referring. He already gave an nslookup that shows that going to 1.1.1.1 directly from his PC, resolved chicago2.voip.ms fine ( = no timeout) when it didn’t go through his router’s DNS proxy - which is exactly the symptom I know…

Yeah, it is a better OS. :slight_smile: This is why anyone who wants to provide a stable service on the Internet, will use it, and not the other one, which has “some” issues, many of them specifically in the networking domain.

#17

All resolve attempts worked so far, you cant blame the router at this point.

As for the operating system, these discussions are usually pointless and I do not intend to start one now but the remark itself was unnecessary.

#18

You must have missed this part…

They’re indeed pointless, it’s called a sense of humor… if you didn’t intend to start one you could just ignore it.

#19

It did resolve, it seems the first attempt failed and that might even point to Cloudflare.

The problem seems to be rather consistent, hence my question to post the other lookup to check whethe OpenDNS might time out.

I am afraid these remarks were not funny back in their time in the 90s, nor are they now. Anyhow, we dont need to get more offtopic.

#20

But you requested to do it with nslookup directly to OpenDNS (which already worked without timeout to Cloudflare as well!) - so how will it prove anything? Not that replacing the DNS proxy’s forwarder address to OpenDNS prove anything - those broken resolvers just choke on certain type of DNS responses - which one server might return (at no fault for them), and the other might not. And it depends on the mood of the resolver on top of that. See, that’s why they’re a problem. Also since the 90’s.