Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

DNS Performance compared: CloudFlare 1.1.1.1 x Google 8.8.8.8 x Quad9 x OpenDNS

medium.com

Post reply on HN
Print view View original

91–100 of 364 posts

Re: DNS Performance compared: CloudFlare 1.1.1.1 x Google 8.8.8.8 x Quad9 x OpenDNS

#91

Post by brightball »

anilgulecha wrote: post #2

I think we'll start seeing the standard configuration of 1.1.1.1,8.8.8.8 everywhere. Google/Cloudflare tackled the UX of free DNS spectacularly with these gold IP addresses. It's the primary reason I use them instead of OpenDNS, which was an earlier player in this space.

OpenDNS still has a lot of value beyond just free DNS service though. When I was very active in dealing with phishing, we found that OpenDNS flagged phishing sites about 4 times faster than any other DNS provider, which I assume is because of PhishTank. It's the primary reason I recommend it to my parents.

Between that and some of the content filtering options you can get with the paid plan, I find that it's a very full-featured option for homes with young kids. I'm pretty sure you get to control the logs on the paid plan too. Need to double check.

Re: DNS Performance compared: CloudFlare 1.1.1.1 x Google 8.8.8.8 x Quad9 x OpenDNS

#93

Post by beardicus »

lucb1e wrote: post #56

Which ISPs are so bad that you want to use external services, which are further in distance than your ISP, for speed? When I test with my ISP, they beat all of these services (both IPv4 and IPv6). They're simply closer to me in terms of hops. My router is another story though. The Fritzbox (>200eur router) adds 6ms of latency, and that's what is advertised over DHCP. (Might still be fine, since cached queries are fas…

Queries to my local Spectrum DNS service are 4 times slower than 1.1.1.1, and they redirect you to stupid search pages instead of `NXDOMAIN`. I switched the whole network over this morning.

Re: DNS Performance compared: CloudFlare 1.1.1.1 x Google 8.8.8.8 x Quad9 x OpenDNS

#94

Post by jeremejevs »

Daviey wrote: post #29
jamra wrote: post #24

Earlier quoted context omitted.

But your DNS will have to query other DNS providers so if you’re the only one using it, it won’t be private.

There is 2 main different ways, one which does what you say - the other i'd say is pretty much OK. If your local DNS server is merely querying an upstream resolver (like 1.1.1.1 / 8.8.8.8) on your behalf, then yes - it is no different. If however, you query the root nameservers for the glue record for a domain and query the domain's own nameservers directly, then it is pretty good... As you are neither querying your…

> only the domain nameserver owner knows what queries you made (and you are probably hitting that domain in a moment anyway!)

But these are different people, with different incentives. The NS owner may be logging everything, without the domain owner's knowledge, and the NS owner won't even be in the wrong, because they likely made no promise to not log.

With a single resolver, I can verify that they're trustworthy enough [for me], just once, and direct all my traffic to it. Cloudflare's "We committed to never writing the querying IP addresses to disk and wiping all logs within 24 hours" is something, I imagine, they very much wouldn't want to be caught violating or changing their mind about later.

In the meanwhile, with the root NS method, I can only hope that my queries will get lost in the "noise". And I'm putting noise in quotation marks because there isn't much diversity in the name server ownership: 75% of Alexa top 1M domains are hosted at Cloudflare, GoDaddy and Amazon. [0]

[0] https://www.datanyze.com/market-share/dns/Alexa%20top%201M/

Re: DNS Performance compared: CloudFlare 1.1.1.1 x Google 8.8.8.8 x Quad9 x OpenDNS

#95

Post by jsjohnst »

userbinator wrote: post #46

I wonder how well 4.2.2.x compares... Then again, a few ms of difference is unlikely to make any noticeable effect in real-world use cases where clients already have local DNS caching and the bulk of the time is data transfer, not DNS lookups.

> the bulk of the time is data transfer, not DNS lookups

You’d be surprised.

Re: DNS Performance compared: CloudFlare 1.1.1.1 x Google 8.8.8.8 x Quad9 x OpenDNS

#96

Post by halayli »

jsjohnst wrote: post #83
halayli wrote: post #73

This tests the performance / distance between vps data centers and the dns server's data centers. imho it's better to have a test web page that consumers visit and establishes a tcp connection to those dns services and estimate the rtt of a single packet from the time it took to establish the connection, or test via the https interface for services that support it.

While I whole-heartedly agree with your objection, I question the solution. How do you get high accuracy timing of DNS resolution in JavaScript inside the browser?

It's an estimate of rtt + dns resolution.

The challenge in providing a good dns service is more about having nodes closer to the user than the dns resolution step itself because that in theory is almost constant for cached responses (it's usually in the microseconds) and when it's not cached the response time is really dependent on recursive querying of other dns servers. So the dns resolution can me estimated by measuring it from a data center manually and subtracting the rtt and use that as a constant.

To estimate the rtt, you can do an xhr request and grab the connectStart and connectEnd using window.performance API keeping in mind it takes 3 rtt to do the handshake. Note that the request will fail for services that don't provide https support but that's ok because we just want to measure connect.

The reason cloudflare has a better performance is most likely because they have better coverage and not because their servers are faster. Faster servers are a small factor in the final response time.

For services that provide https support you can accurately measure the connect and response time of the XHR request using window.performance interface and subtract the dns resolution of the request. Also if you do the request twice, the second time is likely to have a dns and connect time = 0.

Re: DNS Performance compared: CloudFlare 1.1.1.1 x Google 8.8.8.8 x Quad9 x OpenDNS

#97

Post by Isomer »

jeremejevs wrote: post #94
Daviey wrote: post #29

Earlier quoted context omitted.

There is 2 main different ways, one which does what you say - the other i'd say is pretty much OK. If your local DNS server is merely querying an upstream resolver (like 1.1.1.1 / 8.8.8.8) on your behalf, then yes - it is no different. If however, you query the root nameservers for the glue record for a domain and query the domain's own nameservers directly, then it is pretty good... As you are neither querying your…

> only the domain nameserver owner knows what queries you made (and you are probably hitting that domain in a moment anyway!) But these are different people, with different incentives. The NS owner may be logging everything, without the domain owner's knowledge, and the NS owner won't even be in the wrong, because they likely made no promise to not log. With a single resolver, I can verify that they're trustworthy en…

With QNAME minimalisation, RFC7129 (Authenticated denial of existence) and RFC8020 (NXDOMAIN: There really is nothing underneath), you should be sending almost nothing to the root servers of use.

QNAME minimalisation will only send .com to the root for them to give you the referral.

and RFC7129/RFC8020 mean that when you get a NXDOMAIN back from the root, you'll cache it and never try again for a large swath of possible names.

Re: DNS Performance compared: CloudFlare 1.1.1.1 x Google 8.8.8.8 x Quad9 x OpenDNS

#98

Post by falcolas »

jsjohnst wrote: post #83
halayli wrote: post #73

This tests the performance / distance between vps data centers and the dns server's data centers. imho it's better to have a test web page that consumers visit and establishes a tcp connection to those dns services and estimate the rtt of a single packet from the time it took to establish the connection, or test via the https interface for services that support it.

While I whole-heartedly agree with your objection, I question the solution. How do you get high accuracy timing of DNS resolution in JavaScript inside the browser?

Not a JavaScript developer, but if they can do timings fine enough to run Meltdown attacks in JS, I think they can safely and accurately measure network timings.

Re: DNS Performance compared: CloudFlare 1.1.1.1 x Google 8.8.8.8 x Quad9 x OpenDNS

#99

Post by jsjohnst »

falcolas wrote: post #98
jsjohnst wrote: post #83

Earlier quoted context omitted.

While I whole-heartedly agree with your objection, I question the solution. How do you get high accuracy timing of DNS resolution in JavaScript inside the browser?

Not a JavaScript developer, but if they can do timings fine enough to run Meltdown attacks in JS, I think they can safely and accurately measure network timings.

Timing in general isn’t the issue here, there isn’t a way to my knowledge to get just the DNS portion (specifically across an arbitrary set of DNS providers) of the network timing in JS. Just like there isn’t a way to test the timing of a single packet really either.

Re: DNS Performance compared: CloudFlare 1.1.1.1 x Google 8.8.8.8 x Quad9 x OpenDNS

#100

Post by Isomer »

jsjohnst wrote: post #83
halayli wrote: post #73

This tests the performance / distance between vps data centers and the dns server's data centers. imho it's better to have a test web page that consumers visit and establishes a tcp connection to those dns services and estimate the rtt of a single packet from the time it took to establish the connection, or test via the https interface for services that support it.

While I whole-heartedly agree with your objection, I question the solution. How do you get high accuracy timing of DNS resolution in JavaScript inside the browser?

Using the Resource Timing API: https://www.w3.org/TR/resource-timing/#dom-performanceresour...

This allows you to get accurate timings for every resource the page loaded, including the timeline of DNS request/response for that resource.

Post reply on HN