Does your DNS server route you through the most optimal routes?

[RMerlin]

One of the reasons why I generally recommend to stick to your ISP's DNS server (unless requiring special filtering services) is that your ISP DNS is almost guaranteed to point you at the closest location when you try to access a site that's behind a CDN.

For testing this, www.google.com is great, because the reverse lookup of their servers seem to contain the international airport code in their hostname, telling you the location of that datacenter.

Here's a few examples. I am located in Montreal.

1) With ISP's DNS

merlin@ubuntu-dev:~$ dig www.google.com +short
172.217.13.196
merlin@ubuntu-dev:~$ host 172.217.13.196
196.13.217.172.in-addr.arpa domain name pointer yul03s05-in-f4.1e100.net.

YUL = Montreal.


2) With Quad 9

merlin@ubuntu-dev:~$ dig www.google.com @9.9.9.9 +short
172.217.2.100
merlin@ubuntu-dev:~$ host 172.217.2.100
100.2.217.172.in-addr.arpa domain name pointer iad23s72-in-f4.1e100.net.
100.2.217.172.in-addr.arpa domain name pointer yyz10s05-in-f4.1e100.net.

YYZ = Toronto (Rush fans will recognize this one )
IAD = Washington DC (Washington Dulles International Airport)

Which is a bit odd. First one is very close to me, the second one would be a good bit further away.

Cloudflare seems to be more random - sometimes they properly point me at a Montreal location, sometimes at a slightly farther away New York server.

EDIT:
You can make it a one-liner, like this (in this example I test using Yandex):

merlin@ubuntu-dev:~$ host $(dig www.google.com @77.88.8.8 +short | tail -n 1)
105.222.194.173.in-addr.arpa domain name pointer lo-in-f105.1e100.net.

(not sure what LI would stand for. I had someone in Russia try, and they get LM instead. Different naming scheme in Europe?)



So when picking up a third party DNS, I recommend doing this little test to see how optimal their routing will be for your specific location.

 

[ColinTaylor]

EDIT:
You can make it a one-liner, like this (in this example I test using Yandex):

merlin@ubuntu-dev:~$ host $(dig www.google.com @77.88.8.8 +short | tail -n 1)
105.222.194.173.in-addr.arpa domain name pointer lo-in-f105.1e100.net.

(not sure what LI would stand for. I had someone in Russia try, and they get LM instead. Different naming scheme in Europe?)

"LI" isn't in the output you posted. But it looks like the names are being cycled through by that provider:

root@nuc:~# host $(dig www.google.com @77.88.8.8 +short | tail -n 1)
105.163.233.64.in-addr.arpa domain name pointer lj-in-f105.1e100.net.
root@nuc:~# host $(dig www.google.com @77.88.8.8 +short | tail -n 1)
99.161.233.64.in-addr.arpa domain name pointer lh-in-f99.1e100.net.
root@nuc:~# host $(dig www.google.com @77.88.8.8 +short | tail -n 1)
106.161.233.64.in-addr.arpa domain name pointer lh-in-f106.1e100.net.
root@nuc:~# host $(dig www.google.com @77.88.8.8 +short | tail -n 1)
106.222.194.173.in-addr.arpa domain name pointer lo-in-f106.1e100.net.
root@nuc:~# host $(dig www.google.com @77.88.8.8 +short | tail -n 1)
99.162.233.64.in-addr.arpa domain name pointer li-in-f99.1e100.net.
root@nuc:~# host $(dig www.google.com @77.88.8.8 +short | tail -n 1)
105.165.233.64.in-addr.arpa domain name pointer lg-in-f105.1e100.net.
root@nuc:~# host $(dig www.google.com @77.88.8.8 +short | tail -n 1)
103.163.233.64.in-addr.arpa domain name pointer lj-in-f103.1e100.net.
root@nuc:~# host $(dig www.google.com @77.88.8.8 +short | tail -n 1)
103.73.194.173.in-addr.arpa domain name pointer lq-in-f103.1e100.net.
root@nuc:~# host $(dig www.google.com @77.88.8.8 +short | tail -n 1)
104.222.194.173.in-addr.arpa domain name pointer lo-in-f104.1e100.net.
root@nuc:~# host $(dig www.google.com @77.88.8.8 +short | tail -n 1)
104.165.233.64.in-addr.arpa domain name pointer lg-in-f104.1e100.net.
root@nuc:~# host $(dig www.google.com @77.88.8.8 +short | tail -n 1)
99.222.194.173.in-addr.arpa domain name pointer lo-in-f99.1e100.net.
root@nuc:~# host $(dig www.google.com @77.88.8.8 +short | tail -n 1)
103.165.233.64.in-addr.arpa domain name pointer lg-in-f103.1e100.net.
root@nuc:~# host $(dig www.google.com @77.88.8.8 +short | tail -n 1)
147.162.233.64.in-addr.arpa domain name pointer li-in-f147.1e100.net.
root@nuc:~# host $(dig www.google.com @77.88.8.8 +short | tail -n 1)
99.222.194.173.in-addr.arpa domain name pointer lo-in-f99.1e100.net.

 

[ColinTaylor]

My ISP and 1.1.1.1 consistently give me LHR addresses (i.e, London), but 9.9.9.9 gives me LHR + some foreign ones (Berlin, Milan, etc.)

EDIT: To clarify, 9.9.9.9 isn't returning multiple addresses it's just that the IP address has multiple aliases.

36.205.58.216.in-addr.arpa domain name pointer mil04s24-in-f36.1e100.net.
36.205.58.216.in-addr.arpa domain name pointer mil04s24-in-f4.1e100.net.
36.205.58.216.in-addr.arpa domain name pointer lhr48s23-in-f4.1e100.net.

 

[RMerlin]

Sorry, I meant LO.

 

[RMerlin]

My ISP and 1.1.1.1 consistently give me LHR addresses (i.e, London), but 9.9.9.9 gives me LHR + some foreign ones (Berlin, Milan, etc.)

That is odd. A bit like me where I get one close one, and one that's slightly further away. So I guess that means that performance (at least with Google) could vary between queries when using Quad 9.

 

[ColinTaylor]

That is odd. A bit like me where I get one close one, and one that's slightly further away. So I guess that means that performance (at least with Google) could vary between queries when using Quad 9.

See my updated post.

EDIT: To clarify, 9.9.9.9 isn't returning multiple addresses it's just that the IP address has multiple aliases.

36.205.58.216.in-addr.arpa domain name pointer mil04s24-in-f36.1e100.net.
36.205.58.216.in-addr.arpa domain name pointer mil04s24-in-f4.1e100.net.
36.205.58.216.in-addr.arpa domain name pointer lhr48s23-in-f4.1e100.net.

 

[dave14305]

This is also why I use the Quad9+EDNS server for lookups (9.9.9.11) to hopefully get more geographically relevant results. Mileage varies, of course.

 

[bbunge]

DNS should not have anything to do with routing your internet connection. However, the way your ISP configures Anycast does result in some varied DNS routings. Centurylink routes my Quad9 to Miami and Cloudflare to the Ashburn, VA center where Quad9 also has resolvers.

 

[dave14305]

DNS should not have anything to do with routing your internet connection. However, the way your ISP configures Anycast does result in some varied DNS routings. Centurylink routes my Quad9 to Miami and Cloudflare to the Ashburn, VA center where Quad9 also has resolvers.

DNS doesn't have anything to do with routing, per se, but it does have everything to do with which server IP you are attempting to route to. If your DNS server returns a geographically unfavorable IP, you will be routing farther than perhaps necessary. This is part of the reason for EDNS Client Subnet.
https://quad9.net/faq/#What_is_EDNS_Client-Subnet

 

[RMerlin]

See my updated post.

Yeah, I know it's Google that's having multiple hostnames for the same IP, it's just weird that only the response from Quad 9 gave me that. Other servers would give me different IPs (in round-robin) or one single IP with one single hostname.

 

[Deleted member 51572]

GRC DNS Benchmark utility can be used to rank your ISP DNS against 3rd-party DNS. My ISP's servers win every time, ranked in the top two; usually with OpenDNS and/or Google in third and fourth place, but I haven't run the benchmark in a while.

 

[RMerlin]

GRC DNS Benchmark utility can be used to rank your ISP DNS against 3rd-party DNS. My ISP's servers win every time, ranked in the top two; usually with OpenDNS and/or Google in third and fourth place, but I haven't run the benchmark in a while.

But wins at what specifically? Resolution time is mostly meaningless quite frankly. If it takes 10 ms to resolve a DNS query instead of 100 ms, but you end up having a 150 ms latency for every single connection to the resolved server address plus a lower throughput because that web server you got connected at is not optimal for your current location, you will get a much more visible performance impact.

 

[Deleted member 51572]

by my ISP wins, I simply mean that latency is significantly less compared 3rd-party DNS (as expected), and that my ISP's DNS resolves CDNs to nearby edge servers (often hosted by my ISP), further reducing latency.

what i'm saying is: "stick to your ISP's DNS server (unless requiring special filtering services) is that your ISP DNS is almost guaranteed to point you at the closest location when you try to access a site that's behind a CDN."

cheers

 

[coxhaus]

My ISP's DNS is the fastest but I use QUAD9, 9.9.9.9 as I like their filtering. I am in the USA and not running any VPNs so hitting wrong sites has not been an issue.

 

[RMerlin]

Ignore latency, it`s meaningless provided you are within reasonable delays. You will never see the difference between 10 ms and 100 ms while doing DNS lookups. Keep in mind that lookups gets cached at multiple level, so only the first request for a given domain may take that whole 100 ms - other reference will be instantaneous while the content is in your local cache.

 

[el pescador]

How can i test this?
CMD on windows? putty?

 

[ColinTaylor]

How can i test this?
CMD on windows? putty?

Use any client that has the dig and host commands.

 

[el pescador]

RMerlin. How do you get a list of the code which tell you the location?
YUL for example.

 

[ColinTaylor]

RMerlin. How do you get a list of the code which tell you the location?
YUL for example.

He said in post #1 that they are international airport codes, so Google.

For example: https://en.wikipedia.org/wiki/List_of_airports_by_IATA_airport_code:_Y

 

[RMerlin]

RMerlin. How do you get a list of the code which tell you the location?
YUL for example.

And I'm not sure if they use the same naming scheme for their European servers, or only in North America. So far at least the Russian servers were using a different naming.