COMODO Primary SECURE DNS encounters a excessive REQUEST TIMED OUT resulting to a serious poor internet connection problem! here in our local area (Quezon City, Philippines)
:THNK :THNK :THNK
:THNK :THNK :THNK
:THNK :THNK :THNK
This is concerning…
[attachment deleted by admin]
Did anyone help you with this yet? ???
What response do yo get if you ping the UltraDNS (who manage Comodos DNS) servers:
156.154.70.1
156.154.71.1
Or Google Public DNS:
8.8.8.8
8.8.4.4
OpenDNS:
208.67.222.222
208.67.220.220
Nope… I didn’t got any help on this… a Comodo Equipment failure is more possible cause of Comodo DNS RTO.
(:KWL) (:KWL) (:KWL)
(:KWL) (:KWL) (:KWL)
(:KWL) (:KWL) (:KWL)
The servers are not Comodos, they’re Newstar/UltraDNS…
ah… I see!
so why it is named COMODO DNS by the way?
:THNK :THNK :THNK
:THNK :THNK :THNK
:THNK :THNK :THNK
Because Comodo rents capacity with Neustar DNS to make their own product.
So do you have guys idea on where these NEUSTAR DNS location or strategically positioned?
:THNK :THNK :THNK
:THNK :THNK :THNK
:THNK :THNK :THNK
Here
[attachment deleted by admin]
Anycast anywhere 
Anycast, anytime, anywhwere… sounds like a commercial for a certain alcoholic beverage…
Thanks!
Know I know why COMODO DNS encounters RTO because of a SECONDARY PARTY Equipment (NEUSTAR) and therefor confirmed my belief that maybe using comodo dns makes your browsing safe, opens website even an intermittent connection is acquired but. . . not for a faster internet experienced.
:BNC :BNC :BNC
:BNC :BNC :BNC
:BNC :BNC :BNC
I’ve tried all the third-party DNS services and in test after test they all come-up seriously slower than my ISP. Something to do with where I live, unfortunately. I also can’t say I’m terribly interested in being ‘nannied’ everywhere I go. Still, it’s good for some.
I’m not sure I fully understand your comment…
A fast DNS resolver is key for fast loading of pages, as the average page loads data from several domains your system needs to query for a bunch of A records before it can start to compile the page. So having 10 queries for 10ms is better then having 10 queries of 200ms
Downloading a single file after the DNS query Secure DNS can’t influence because the query is already done, download speed is now depending on slowest link and quality of the connections between client and server.
Secure DNS only ‘redirects’ the A record of a query if it finds the requested domain suspicious, therefore you end up on a Secure DNS landing page telling you it’s probably malicious, this doesn’t happen on a “clean” DNS request.
If you like to see which DNS servers have which responses then here is a tool to test queries.
http://www.grc.com/dns/benchmark.htm
Yes that’s correct but before using any 2nd party DNS, it’s better to have a PING TEST of your ISP’s DNS and 2nd Party DNS at least 24-hours both for you to decide base on ping results that you may have.
to be honest, I actually promote COMODO DNS in the largest Broadband Company here but when I ask for there test results, it actually failed to there passing ping results. but they and I believed that it is possible to have a safer internet browsing with COmodo DNS. Also, ISP DNS has a lower ping results than any 2nd party DNS that’s why you can actually feel that DNS RESOLVER of Comodo DNS if… you experience an Intermittent connection. but even you only have a clean 500-kbps with a large throughput broadband like WiMAX or LTE connection, you do not need that DNS RESOLVER. . .
so any idea’s or trivia’s why COMODO DNS encounters excessive TRO?
:SMLR :SMLR :SMLR
:SMLR :SMLR :SMLR
:SMLR :SMLR :SMLR
Based on the trace route your traffic has to cross the Pasific over to San Jose to go to the closest Secure DNS server for your location it’s already over 200ms when it reaches the peer network from Level3 and then it still has to go to the closest Neustar link.
Can you also post a trace route from the faster responding host? It will be interesting to see which route that one takes, I guess a different route then the image posted above.
An other thing that is in play here is DNS is mostly based on UDP traffic and that’s fire-and-forget, it will send a query and if the packet get’s dropped along the line your PC has to time-out first and will then resend a request after x ms, the more queries get lost the longer it will take to resolve.
At this moment, COMODO DNS is CLEAN with no RTO during this Trace Route test (See attached S-Shoots)
because I can’t afford to do a Ping and Trace Route for another 24 hours… As you can see, my ISP’s DNS has only 9 to 10 hops before it reach the internet compare to 17 to 20 hops of Comodo DNS that’s why sometimes comodo dns encounters RTO due to the fact that the SERVERS, SWITCH and ROUTER of NEUSTAR is far (Hongkong if I’m right)
:THNK :THNK :THNK
:THNK :THNK :THNK
:THNK :THNK :THNK
[attachment deleted by admin]
As you can see in the trace the traffic is taking completely different routes and peering partners to reach it’s destination, now it’s routed over Alter.net instead of Level3, so this also influences the response time and reliability of the end host, the 70.22 is resolved in San Jose, the 71.22 seems to route to Hongkong indeed.
In general your ISP DNS will always be closer to you then external DNS providers, which doesn’t mean by definition that it’s more reliable, it can be close and ping fast, but that doesn’t have to mean it resolves quick and correct.
Test from my side of the globe:
ping for icmp round-trip
Reply from 156.154.70.22: bytes=32 time=28ms TTL=51
Reply from 156.154.70.22: bytes=32 time=28ms TTL=51
Reply from 156.154.70.22: bytes=32 time=28ms TTL=51
Reply from 156.154.70.22: bytes=32 time=28ms TTL=51
Reply from 156.154.70.22: bytes=32 time=28ms TTL=51
Ping statistics for 156.154.70.22:
Packets: Sent = 53, Received = 53, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 26ms, Maximum = 29ms, Average = 27ms
TCPing to the DNS servers port 53, this means the time it takes to complete a connection setup to the DNS server.
Probing 156.154.70.22:53/tcp - Port is open - time=29.100ms
Probing 156.154.70.22:53/tcp - Port is open - time=29.410ms
Probing 156.154.70.22:53/tcp - Port is open - time=29.318ms
Probing 156.154.70.22:53/tcp - Port is open - time=28.580ms
Probing 156.154.70.22:53/tcp - Port is open - time=29.085ms
Probing 156.154.70.22:53/tcp - Port is open - time=30.313ms
Control-C
Ping statistics for 156.154.70.22:53
26 probes sent.
26 successful, 0 failed.
Approximate trip times in milli-seconds:
Minimum = 28.580ms, Maximum = 44.633ms, Average = 31.596ms
which shows the time it takes to build a TCP connection (3-way handshake).
My trace route shows the 70.22 is located in London and the 71.22 is Amsterdam, it’s also faster ~20ms as it doesn’t have to cross the sea. So in my case the 71.22 would be the optimal primary DNS server to chose.
therefor Comodo should be careful in using this statement:
“Faster - Comodo uses strategically placed nodes are located at the most optimal intersections of the Internet. Unlike most DNS providers, the Comodo our request routing technology means that no matter where you are located in the world, your DNS requests are answered by the closest available set of servers, resulting in information becoming available faster and more reliably than ever before.”
for the reasons of NOT all internet users are NEAR those strategically positioned DNS Servers…
:THNK :THNK :THNK
:THNK :THNK :THNK
:THNK :THNK :THNK