search

dns-sb / dns.sb

https://dns.sb/
MIT License
111 stars 9 forks source link

The use of Level3 nodes in routing. #6

Closed SC1040-TS2 closed 1 year ago

SC1040-TS2 commented 2 years ago

Greetings. In attempting to figure out why DNS.sb addresses seemed to have high overhead as reported by Steve Gibson's DNS Speed Benchmark tool (https://www.grc.com/dns/benchmark.htm), running a TraceRT command to the DNS addresses revealed that the routing setup it uses prefers resolving over Level3 infrastructure.

This may have made sense years ago, but ever since the CenturyLink acquisition of Level3, it does not due to the ISP now directly controlling and using it. To make matters worse, the Gibson benchmarking software also reports that all Level3 DNS addresses that are pinged by the software or added to it do not simply return errors if a bad domain name tries to be resolved over them, but instead redirect the request to another page that CenturyLink or otherwise operates. DNS.sb itself does not resort to such interception methods, but CenturyLink may certainly try to intercept them, inducing latency and overhead in the process.

This sort of intercepting and redirection of requests now being done through Level3 goes against the original ethos of DNS.sb being privacy-minded. With this in mind, it is strongly advised to reconfigure DNS.sb's routing methods to no longer prefer or even consider Level3 infrastructure if possible.

Showfom commented 2 years ago

Sorry, but what do you mean? We can't control the routing with Lumen (Level 3)

SC1040-TS2 commented 2 years ago

Sorry, but what do you mean? We can't control the routing with Lumen (Level 3)

Greetings, apologies for the confusion.

Here is a more relevant and coherent issue raising.

When using the aforementioned DNS Benchmarking tool, the current DNS.SB addresses report a high latency compared to other providers. Upon using TraceRT to figure out why, it was found that the route suffers a 60ms-70ms latency increase as soon as it hops to the Level3.net San Jose node over IPv4, and 60ms increases over IPv6, perhaps expectedly. This may not be ideal for users looking to do very time-sensitive things, such as game on the service.

In hindsight and further testing, this latency problem may be a limitation of exclusively relying on Lumen's Level3.net infrastructure, as other DNS providers such as CloudFlare will try to keep latency down by routing over different infrastructure, such as its own or a user's ISP's servers.

Showfom commented 2 years ago

This is because in US, we only have one location in San Jose.

Please use DoH service with CDN instead, it's located in Chicago

https://doh.dns.sb/dns-query