Geekzone: technology news, blogs, forums
Guest
Welcome Guest.
You haven't logged in yet. If you don't have an account you can register now.

mdf



1829 posts

Uber Geek
+1 received by user: 522

Trusted
Subscriber

Topic # 238241 8-Jul-2018 14:06
Send private message quote this post

I've been using quad9 for a while but want to compare that against Vodafone's DNS servers (FibreX in Wellington). For a long time I've used:

 

203.97.78.43 and 203.97.78.44

 

But this page on Vodafone's site seems to suggest the following:

 

203.109.191.1 and 203.118.191.1

 

I'm experimenting with pi-hole / dnsmasq filtering so hopefully don't need quad9, cleanbrowsing etc. to do the filtering for me.

 

 


Create new topic
108 posts

Master Geek
+1 received by user: 47

Trusted
Vodafone NZ

  Reply # 2051504 8-Jul-2018 14:28
Send private message quote this post

203.109.191.1 and 203.118.191.1 are the current addresses. Any old addresses are pointed to the new servers (or will be if not already), so it shouldn't really matter. Just testing on my connection now it's marginally quicker to the new ones.

 

Tried Cloudflare's servers?


mdf



1829 posts

Uber Geek
+1 received by user: 522

Trusted
Subscriber

  Reply # 2051525 8-Jul-2018 15:34
Send private message quote this post

gaddman:

 

203.109.191.1 and 203.118.191.1 are the current addresses. Any old addresses are pointed to the new servers (or will be if not already), so it shouldn't really matter. Just testing on my connection now it's marginally quicker to the new ones.

 

Tried Cloudflare's servers?

 

 

Briefly. I'm trying to start understanding more about networking stuff, but it's slow going (breaking the internet makes it hard to google instructions to fix the internet...). 

 

Is is still true that (or was it ever true that) larger high-demand stuff is cached on network; using your ISP's DNS servers therefore will fire you off to the local cache rather than having to get it from an international server?


108 posts

Master Geek
+1 received by user: 47

Trusted
Vodafone NZ

  Reply # 2051536 8-Jul-2018 15:55
One person supports this post
Send private message quote this post

That high demand stuff used to be in ISP-managed caches, now it comes from 3rd party Content Delivery Networks (CDNs, eg Cloudflare, Akamai, Facebook), which are often hosted inside the ISP network. Same goes for YouTube content - bigger NZ ISPs will have Google caches in their network. Using a 3rd party DNS can mean that you end up going to Australia or the US for the same content you could have got locally. Depends on the content though - Google would have a pretty good idea where you are, regardless of what DNS you use, so they may still route you to the nearest cache.

 

You'd have to look at the IP addresses you're hitting to know for sure. Capture and analyse with Wireshark, or for YouTube you can view the "Stats for nerds", grab the Host parameter (eg r3---sn-8vq54voxo1-53as) and look it up by appending googlevideo.com.

 

If you're experimenting you might find it easier to change DNS settings on your PC, rather than the router. Then you can still use a smartphone to troubleshoot.


394 posts

Ultimate Geek
+1 received by user: 110


  Reply # 2051628 8-Jul-2018 18:39
One person supports this post
Send private message quote this post

If you're not quite sure what you're doing (which your second post in this thread suggest) just use whatever the ISP suggests via PPP/DHCP. I have yet to come across any situation where using the ISP provided DNS is not ideal. Do yourself a favor and use the ISP provided DNS—it will be faster and more accurate (in terms of pointing you toward the nearest CDN caches). There really is no benefit to using Cloudflare, Quad9, etc.


Meow
7528 posts

Uber Geek
+1 received by user: 3641

Moderator
Trusted
Lifetime subscriber

  Reply # 2051644 8-Jul-2018 19:18
One person supports this post
Send private message quote this post

KiwiSurfer:

 

If you're not quite sure what you're doing (which your second post in this thread suggest) just use whatever the ISP suggests via PPP/DHCP. I have yet to come across any situation where using the ISP provided DNS is not ideal. Do yourself a favor and use the ISP provided DNS—it will be faster and more accurate (in terms of pointing you toward the nearest CDN caches). There really is no benefit to using Cloudflare, Quad9, etc.

 

There is - DNS over HTTPS (or DoH) of which I use ;)





108 posts

Master Geek
+1 received by user: 47

Trusted
Vodafone NZ

  Reply # 2051709 8-Jul-2018 20:40
Send private message quote this post

KiwiSurfer:

 

If you're not quite sure what you're doing (which your second post in this thread suggest) just use whatever the ISP suggests via PPP/DHCP. I have yet to come across any situation where using the ISP provided DNS is not ideal. Do yourself a favor and use the ISP provided DNS—it will be faster and more accurate (in terms of pointing you toward the nearest CDN caches). There really is no benefit to using Cloudflare, Quad9, etc.

 

 

Yeah, aside from the content routing, just the speed of your ISP DNS is probably better. Vodafone has them in AKL, WLG, and CHC, so there's always one reasonably close. Whereas Cloudflare is AKL only, so the further you are from there the slower your DNS responses (and Google is coming from Sydney). DNS caching helps of course, which both your PC and your router are doing, so it'll depend on your internet habits and setup how much difference this actually makes*. There are definitely reasons to use alternative DNS servers, but I wouldn't count speed amongst them. In saying that, I was just doing some testing and realised I've been using DoH to Cloudflare's servers for the last month - haven't noticed any change (but I am in AKL, so latency is about the same as Voda DNS).

 

 

 

 * even if there is a measurable difference, say 10-20 milliseconds, I'd be surprised if you actually noticed it


3 posts

Wannabe Geek
+1 received by user: 5


  Reply # 2051921 9-Jul-2018 12:36
4 people support this post
Send private message quote this post

Quad9 is operational in Auckland and Wellington, though Christchurch isn't yet turned up.

 

 

I'm on Quad9's board of directors, so I can speak to the reasons why you might want to consider using Quad9 rather than Vodafone or some of the other alternatives.  The principal points of comparison would be privacy, security, and performance.  

 

From a privacy standpoint, Quad9 (and the TWNIC quad-101, which I can't speak for, but can relate what they say publicly) do not collect user data. Which means that they're not only not selling it, they're also not subject to data breaches. Those are the only two that don't collect user data.  A few others say they don't in their marketing materials, but contradict that in their privacy policy.  Most telcos which offer a recursive resolver actually outsource the operation of it to one of a couple of monetization firms, which then cut them in on a share of the profit of selling your click-trail to data-brokers.  I can't speak to what Vodafone does, but I'd be very surprised if they were not doing what the others do.  Beyond not collecting data, Quad9 offers link encryption, QNAME minimization, and optionally blocks EDNS Client Subnet, all of which also serve to protect privacy.  A few of the other recursive resolvers are starting to follow our lead in offering those features as well, though none of the others offer all of those features.

 

From a security standpoint, Quad9 and Cisco Umbrella (OpenDNS) provide optional malware filtering, while most of the others do not (a few have filtering which has proven ineffective in independent reviews).  Again, I'd be very surprised if Vodafone offers any security protections in their recursive resolver.  If they were, they'd be talking about it loudly.

 

From a performance standpoint, you'll need to test from your location, but there are several components to the latency you'll experience: round-trip travel time from you to the recursive resolver, cache-hit versus cache-miss once you get there (which depends on the size of the user population querying that resolver), and latency from the resolver to the authoritative servers.  Quad9 is better than any of the other global recursive resolvers on distribution of nodes (about 180 locations right now) but that may not make as much of a difference to any specific user relative to one that's inside their own ISP (if the ISP hasn't outsourced it to a "cloud" provider)...  Where Quad9 really shines is it's the only one that's back-to-back with most of the authoritative TLD nameservers.  Again, less of a win in New Zealand specifically, which is one of the few countries that PCH isn't authoritative for, but if you were trying to reach .AU domains, for instance, they'd be right there, a few microseconds away from the recursive resolver.

 

                -Bill Woodcock


394 posts

Ultimate Geek
+1 received by user: 110


  Reply # 2052126 9-Jul-2018 17:03
One person supports this post
Send private message quote this post

Thank you Bill for your very informative post.


3 posts

Wannabe Geek
+1 received by user: 5


  Reply # 2052127 9-Jul-2018 17:08
One person supports this post
Send private message quote this post

Happy to help any way I can.

 

And to be clear, I'm not meaning to be hard on Vodafone, I'm certainly not suggesting they're doing anything that other carriers aren't, and it's quite possible that their privacy practices are better than those of other carriers; I honestly don't have any information or opinion on that.

 

Quad9 was put together largely to address the privacy problem, which exists to different degrees for different folks.  Riding on top of PCH's network gets it some performance and security benefits as well, but those aren't unique.  

 

If there are any other questions I can answer about it, I'm happy to do so.

 

Thanks,

 

                -Bill


mdf



1829 posts

Uber Geek
+1 received by user: 522

Trusted
Subscriber

  Reply # 2052206 9-Jul-2018 19:33
One person supports this post
Send private message quote this post

So my results using the GRC tool show the "old" Vodafone DNS servers with a marginal edge over the "new" Vodafone servers and Quad9. Then a small gap to Cloudflare's 1.1.1.1, then a bigger gap to Google, and CleanBrowsing.org (which the kids are required to use at this stage). CleanBrowsing.org's backup was well behind everything else.

 

 

Final benchmark results, sorted by nameserver performance:
(average cached name retrieval speed, fastest to slowest)

 

203. 97. 78. 43 | Min | Avg | Max |Std.Dev|Reliab%|
----------------+-------+-------+-------+-------+-------+
- Cached Name | 0.007 | 0.009 | 0.014 | 0.001 | 100.0 |
- Uncached Name | 0.008 | 0.158 | 0.286 | 0.075 | 100.0 |
- DotCom Lookup | 0.042 | 0.151 | 0.169 | 0.034 | 100.0 |
---<-------->---+-------+-------+-------+-------+-------+
ns1.telstraclear.net
CLIX-NZ TelstraClear Ltd, NZ

 


203. 97. 78. 44 | Min | Avg | Max |Std.Dev|Reliab%|
----------------+-------+-------+-------+-------+-------+
- Cached Name | 0.007 | 0.009 | 0.012 | 0.001 | 100.0 |
- Uncached Name | 0.010 | 0.166 | 0.299 | 0.074 | 100.0 |
- DotCom Lookup | 0.042 | 0.153 | 0.204 | 0.040 | 100.0 |
---<-------->---+-------+-------+-------+-------+-------+
ns2.telstraclear.net
CLIX-NZ TelstraClear Ltd, NZ

 


203.118.191. 1 | Min | Avg | Max |Std.Dev|Reliab%|
----------------+-------+-------+-------+-------+-------+
+ Cached Name | 0.008 | 0.010 | 0.014 | 0.001 | 100.0 |
+ Uncached Name | 0.008 | 0.160 | 0.302 | 0.075 | 100.0 |
+ DotCom Lookup | 0.041 | 0.158 | 0.209 | 0.032 | 100.0 |
---<-------->---+-------+-------+-------+-------+-------+
rdns2.ihug.net
VODAFONE-TRANSIT-AS Vodafone NZ Ltd., NZ

 


203.109.191. 1 | Min | Avg | Max |Std.Dev|Reliab%|
----------------+-------+-------+-------+-------+-------+
+ Cached Name | 0.008 | 0.010 | 0.014 | 0.001 | 100.0 |
+ Uncached Name | 0.009 | 0.167 | 0.295 | 0.071 | 100.0 |
+ DotCom Lookup | 0.043 | 0.145 | 0.173 | 0.043 | 100.0 |
---<-------->---+-------+-------+-------+-------+-------+
rdns1.ihug.net
VODAFONE-TRANSIT-AS Vodafone NZ Ltd., NZ

 


9. 9. 9. 9 | Min | Avg | Max |Std.Dev|Reliab%|
----------------+-------+-------+-------+-------+-------+
- Cached Name | 0.009 | 0.011 | 0.018 | 0.002 | 100.0 |
- Uncached Name | 0.011 | 0.224 | 0.585 | 0.118 | 100.0 |
- DotCom Lookup | 0.149 | 0.188 | 0.357 | 0.060 | 100.0 |
---<-------->---+-------+-------+-------+-------+-------+
dns.quad9.net
QUAD9-AS-1 - Quad9, US

 


149.112.112.112 | Min | Avg | Max |Std.Dev|Reliab%|
----------------+-------+-------+-------+-------+-------+
- Cached Name | 0.009 | 0.012 | 0.018 | 0.002 | 100.0 |
- Uncached Name | 0.043 | 0.205 | 0.595 | 0.120 | 100.0 |
- DotCom Lookup | 0.149 | 0.178 | 0.410 | 0.058 | 100.0 |
---<-------->---+-------+-------+-------+-------+-------+
rpz-public-resolver1.rrdns.pch.net
QUAD9-AS-1 - Quad9, US

 


1. 1. 1. 1 | Min | Avg | Max |Std.Dev|Reliab%|
----------------+-------+-------+-------+-------+-------+
- Cached Name | 0.017 | 0.019 | 0.025 | 0.002 | 100.0 |
- Uncached Name | 0.023 | 0.149 | 0.314 | 0.083 | 100.0 |
- DotCom Lookup | 0.168 | 0.178 | 0.204 | 0.011 | 100.0 |
---<-------->---+-------+-------+-------+-------+-------+
1dot1dot1dot1.cloudflare-dns.com
CLOUDFLARENET - Cloudflare, Inc., US

 


185.228.168.168 | Min | Avg | Max |Std.Dev|Reliab%|
----------------+-------+-------+-------+-------+-------+
- Cached Name | 0.041 | 0.043 | 0.047 | 0.001 | 100.0 |
- Uncached Name | 0.043 | 0.198 | 0.391 | 0.104 | 100.0 |
- DotCom Lookup | 0.047 | 0.051 | 0.056 | 0.002 | 100.0 |
---<-------->---+-------+-------+-------+-------+-------+
family-filter-dns.cleanbrowsing.org
CIDNOC, IE

 


8. 8. 4. 4 | Min | Avg | Max |Std.Dev|Reliab%|
----------------+-------+-------+-------+-------+-------+
- Cached Name | 0.042 | 0.044 | 0.048 | 0.001 | 100.0 |
- Uncached Name | 0.173 | 0.234 | 0.426 | 0.072 | 100.0 |
- DotCom Lookup | 0.221 | 0.327 | 0.437 | 0.065 | 100.0 |
---<-------->---+-------+-------+-------+-------+-------+
google-public-dns-b.google.com
GOOGLE - Google LLC, US

 


8. 8. 8. 8 | Min | Avg | Max |Std.Dev|Reliab%|
----------------+-------+-------+-------+-------+-------+
- Cached Name | 0.042 | 0.044 | 0.048 | 0.001 | 100.0 |
- Uncached Name | 0.171 | 0.237 | 0.465 | 0.084 | 100.0 |
- DotCom Lookup | 0.222 | 0.330 | 0.436 | 0.061 | 100.0 |
---<-------->---+-------+-------+-------+-------+-------+
google-public-dns-a.google.com
GOOGLE - Google LLC, US

 


185.228.169.168 | Min | Avg | Max |Std.Dev|Reliab%|
----------------+-------+-------+-------+-------+-------+
- Cached Name | 0.141 | 0.144 | 0.150 | 0.002 | 100.0 |
- Uncached Name | 0.143 | 0.206 | 0.593 | 0.095 | 100.0 |
- DotCom Lookup | 0.146 | 0.149 | 0.153 | 0.002 | 100.0 |
---<-------->---+-------+-------+-------+-------+-------+
··· no official Internet DNS name ···
CIDNOC, IE

 


UTC: 2018-07-09, from 07:25:08 to 07:25:57, for 00:49.179

 

Interpreting your benchmark results above:

 

The following guide is only intended as a quick
"get you going" reference and reminder.

 

To obtain a working understanding of this program's operation, and to familiarize yourself with its many features, please see the main DNS Benchmark web page by clicking on the "Goto DNS Page" button below.

 

Referring to this sample:

 

64. 81.159. 2 | Min | Avg | Max |Std.Dev|Reliab%
----------------+-------+-------+-------+-------+-------
- Cached Name | 0.001 | 0.001 | 0.001 | 0.000 | 100.0
- Uncached Name | 0.021 | 0.033 | 0.045 | 0.016 | 100.0
- DotCom Lookup | 0.021 | 0.022 | 0.022 | 0.001 | 100.0
---<O-OO---->---+-------+-------+-------+-------+-------
dns.chi1.speakeasy.net
Speakeasy

 

The Benchmark creates a table similar to the one above for each DNS resolver (nameserver) tested. The top line specifies the IP address of the nameserver for this table.

 

The first three numeric columns provide the minimum, average, and maximum query-response times in seconds. Note that these timings incorporate all network delays from the querying computer, across the Internet, to the nameserver, the nameserver's own processing, and the return of the reply. Since the numbers contain three decimal digits of accuracy, the overall resolution of the timing is thousandths of a second, or milliseconds.

 

The fourth numeric column shows the "standard deviation" of the collected query-response times which is a common statistical measure of the spread of the values - a smaller standard deviation means more consistency and less spread.

 

The fifth and last numeric column shows the reliability of the tested nameserver's replies to queries. Since lost, dropped, or ignored queries introduce a significant lookup delay (typically a full second or more each) a nameserver's reliability is an important consideration.

 

The labels of the middle three lines are colored red, green, and blue to match their respective bars on the response time bar chart.

 

The "Cached Name" line presents the timings for queries that are answered from the server's own local name cache without requiring it to forward the query to other name servers. Since the name caches of active public nameservers will always be full of the IPs of common domains, the vast majority of queries will be cached. Therefore, the Benchmark gives this timing the highest weight.

 

The "Uncached Name" line presents the timings for queries which could not be answered from the server's local cache and required it to ask another name server for the data. Specifically, this measures the time required to resolve the IP addresses of the Internet's 30 most popular web sites. The Benchmark gives this timing the second highest weight.

 

The "DotCom Lookup" line presents the timings for the resolution of dot com nameserver IP addresses. This differs from the Cached and Uncached tests above, since they measure the time required to determine a dot com's IP, whereas the DotCom Lookup measures the time required to resolve the IP of a dot com's nameserver, from which a dot com's IP would then be resolved. This test presents a measure of how well the DNS server being tested is connected to the dot com nameservers.

 

The lower border of the table contains a set of eight indicators (O and -) representing non-routable networks whose IP addresses are actively blocked by the resolver to protect its users from DNS rebinding attacks: <O-OO---->. The "O" character indicates that blocking is occurring for the corresponding network, whereas the "-" character indicates that non-routable IP addresses are being resolved and rebinding protection is not present. The first four symbols represent the four IPv4 networks beginning with 10., 127., 172., and 192. respectively, and the second four symbols are the same networks but for IPv6.

 

The final two lines at the bottom of each chart duplicate the information from the Name and Owner tabs on the Nameserver page:

 

dns.chi1.speakeasy.net
Speakeasy

 

The first line displays the "Reverse DNS" name of the server, if any. (This is the name looked up by the nameserver's IP address.) The second line displays the Ownership information, if any, of the network containing the nameserver

 

The final line of the automatically generated chart is a timestamp that shows the date and time of the start, completion, and total elapsed time of the benchmark:

 

UTC: 2009-07-15 from 16:41:50 to 16:44:59 for 03:08.703

 

All times are given in Universal Coordinated Time (UTC) which is equivalent to GMT. In the sample shown above, the entire benchmark required 3 minutes, 8.703 seconds to run to completion.

 

All, or a marked portion, of the Tabular Data results on this page may be copied to the Windows' clipboard or saved to a file for safe keeping, sharing, or later comparison.
• • •

 

 

Take this with a grain of salt. I really don't know what I'm doing. This was on a Win 10 PC, ethernet connection, nothing else obvious running or using the network (but I didn't go around unplugging everything else either).

 

EDIT: fixing whitespace on the image


3 posts

Wannabe Geek
+1 received by user: 5


  Reply # 2052211 9-Jul-2018 19:41
Send private message quote this post

Do you have IPv6 connectivity?  If so, would you mind posting IPv4 and IPv6 traceroutes?  Always interesting to see how direct a path you have.


108 posts

Master Geek
+1 received by user: 47

Trusted
Vodafone NZ

  Reply # 2052247 9-Jul-2018 20:29
One person supports this post
Send private message quote this post

Hi Bill,

 

Thanks for the post, really good info there, and as you've pointed out - performance is more than just ICMP latency to the resolver. But on that topic, here are v6 traces from AKL, WLG & CHC.

 

 

Auckland:

 

HOST:         Loss% Snt Last Avg Best Wrst StDev
1.|-- 2407:7000:819f:----- 0.0% 5 1.3 1.2 0.9 1.3 0.0
2.|-- 2407:7000::1407 0.0% 5 5.7 4.6 3.1 6.2 1.2
3.|-- ??? 100.0 5 0.0 0.0 0.0 0.0 0.0
4.|-- 2001:7fa:11:4:0:251c:0:1 0.0% 5 31.3 30.3 28.2 31.3 1.1
5.|-- 2001:7fa:11:4:0:2a:0:1 60.0% 5 154.7 93.2 31.7 154.7 87.0
6.|-- 2620:fe::fe 0.0% 5 30.0 29.3 27.4 30.9 1.0

 

Wellington:

 

HOST:         Loss% Snt Last Avg Best Wrst StDev
1.|-- 2407:7000:841b:----- 0.0% 5 0.9 1.2 0.9 2.1 0.0
2.|-- lo20.bng1-twn-wlg.vf.net.nz 0.0% 5 3.2 7.3 3.2 19.1 6.7
3.|-- ??? 100.0 5 0.0 0.0 0.0 0.0 0.0
4.|-- 2001:7fa:11:4:0:251c:0:1 0.0% 5 37.2 36.5 34.9 38.3 1.1
5.|-- 2001:7fa:11:4:0:2a:0:1 80.0% 5 35.8 35.8 35.8 35.8 0.0
6.|-- dns.quad9.net 0.0% 5 34.8 38.3 34.4 44.5 4.1

 

Christchurch:

 

HOST:          Loss% Snt Last Avg Best Wrst StDev
1.|-- 2407:7000:818c:----- 0.0% 5 0.9 1.0 0.9 1.2 0.0
2.|-- 2407:7000::1407 0.0% 5 13.2 20.5 3.5 45.4 17.4
3.|-- ??? 100.0 5 0.0 0.0 0.0 0.0 0.0
4.|-- 2001:7fa:11:4:0:251c:0:1 0.0% 5 33.6 32.7 26.8 39.1 5.7
5.|-- 2001:7fa:11:4:0:2a:0:1 0.0% 5 29.0 29.1 29.0 29.3 0.0
6.|-- 2620:fe::fe 0.0% 5 27.3 27.4 27.3 27.5 0.0

 

Could be improved, I'll PM you my email and will take a look later this week if it's something on our side. For v4 the path is good - through APE or WIX, whichever is nearest.


Create new topic

Twitter »

Follow us to receive Twitter updates when new discussions are posted in our forums:



Follow us to receive Twitter updates when news items and blogs are posted in our frontpage:



Follow us to receive Twitter updates when tech item prices are listed in our price comparison site:





News »

Hawaiki Transpacific cable ready-for-service
Posted 20-Jul-2018 11:29


Microsoft Dynamics 365 Business Central launches
Posted 10-Jul-2018 10:40


Spark completes first milestone in voice platform upgrade
Posted 10-Jul-2018 09:36


Microsoft ices heated developers
Posted 6-Jul-2018 20:16


PB Technologies charged for its extended warranties and warned for bait advertising
Posted 3-Jul-2018 15:45


Almost 20,000 people claim credits from Spark
Posted 29-Jun-2018 10:40


Cove sells NZ's first insurance policy via chatbot
Posted 25-Jun-2018 10:04


N4L helping TAKA Trust bridge the digital divide for Lower Hutt students
Posted 18-Jun-2018 13:08


Winners Announced for 2018 CIO Awards
Posted 18-Jun-2018 13:03


Logitech Rally sets new standard for USB-connected video conference cameras
Posted 18-Jun-2018 09:27


Russell Stanners steps down as Vodafone NZ CEO
Posted 12-Jun-2018 09:13


Intergen recognised as 2018 Microsoft Country Partner of the Year for New Zealand
Posted 12-Jun-2018 08:00


Finalists Announced For Microsoft NZ Partner Awards
Posted 6-Jun-2018 15:12


Vocus Group and Vodafone announce joint venture to accelerate fibre innovation
Posted 5-Jun-2018 10:52


Kogan.com to launch Kogan Mobile in New Zealand
Posted 4-Jun-2018 14:34



Geekzone Live »

Try automatic live updates from Geekzone directly in your browser, without refreshing the page, with Geekzone Live now.



Are you subscribed to our RSS feed? You can download the latest headlines and summaries from our stories directly to your computer or smartphone by using a feed reader.

Alternatively, you can receive a daily email with Geekzone updates.