Changing the domain name resolver on your Jetson can significantly increase how fast many web resources load. Looky here:
This is a little different article than we usually do here. Watch the video for a walk through on how to change network settings for using a custom domain name resolver. It’s straightforward once you know the lingo.
I am blessed. One of my gifts is that I can delve deep into a technical subject, and then forget everything I learned in about a year. Whenever I open up a dialog that controls networking, a flood of memories come back. The memories remind me that I’ve never seen such a mess of acronyms and numbers in my whole life. Or at least the last time I saw the network dialogs.
When you do a deep dive into networking, no particular part seems difficult. At its core, we’re just assigning the network identity of the device. We’re also specifying how the device interacts with other devices on the network. We want to make sure it “plays well with others”.
Now bits and pieces of networking peek out regularly. Most developers see IP addresses on a daily basis. We’re aware that there may be local networks, and then external networks like the Internet. In the back of our minds we know that computers speak in IP addresses. We know that we can type in our browser domain names, like jetsonhacks.com. The “web browser” will then translate the domain name into an IP address and fetch the page from that web server.
Domain Name System
Conceptually the domain name system is simple. Take the registered name of a server, and translate it to an IP address. There’s a whole ecosystem to take care of this. People register their servers with a Domain Name Registrar. The Domain Name Registrar makes this information available to what is called a Domain Name Resolver. The resolver aggregates the information for the registrars (there are many registrars) and then makes that available to its users.
Of course, that’s just the concept. The Domain Name System is an integral part of the backbone of the Internet. As such, there are very many factors to take into consideration. Modern webpages can reference many different domains, each of which require a lookup. Therefore the speed of the lookup is a very important factor on how fast the web page loads. Latency is a big deal.
To get speed, DNS Resolvers cache a large amount of the web addresses. However if a query results in a cache miss, then the actual time to resolve the address may be quite long. The resolver may have to query several different places to gather the information. These places may not be close geographically, or may suffer from slow access to the information.
You can read the Google Public DNS Performance Benefits page to get a feel for how you have to handle the problem. Remember that you most likely need world wide coverage, and the ability to fend off denial of service attacks and other security issues. This is big boy stuff.
Internet Service Providers
Most Internet Service Providers (ISPs) have their own Domain Name Resolver. They do this for several reason. The most obvious of which is to easily track which website users are browsing. This is useful information for a variety of reasons. There’s advertising as an example. The advantage to the user is that they don’t have to do any setup, everything just works.
However, if you have a targeted service ISP such as a cable provider, the web address cache may be relatively small in comparison to some of the larger DNS Resolvers. Which means that even if you have a fast connection, web pages may load slowly if you go to less travelled areas of the web.
Why is this Important?
This is important because if affects me directly. I’m writing this so that I can remember it in the future, and hope you might find it useful too.
Here’s a little story. I was trying to use Docker to pull some machine learning images from the NVIDIA NGC website. But the connection kept timing out. After checking, I knew that I had a good Internet connection (I could ping Google).
I remembered that Github was having some issues a while back. So I cloned a repository from the JetsonHacks Github account. 15 seconds ticked by before the clone began. Time to ping github.com. Yepper, 15 seconds before it starts echoing. I’ve been through this dance often enough to know that there was an issue with the DNS resolver. If I was a newbie I would use strace to find the culprit, as shown in the video. I was pleased to find that ChatGPT is very helpful in explaining strace output.
Then it hit me. The router was recently swapped out for a newer, better, faster one. Personally I couldn’t tell any difference, but the cable company assured me that I would be a better person after installing it. It so happened that Github was having connectivity issues the day of the new router installation. Therefore I didn’t feel a little spidey-sense that something was wrong.
My previous router was a dear, close friend. I had taken the time to set it up exactly as a noble router should be. This includes setting it to point to an appropriate public DNS Resolver. We had fun over the years, connecting to the DNS Resolvers at Cloudflare, Quad9 and Google. I could hook up all of my machines to the router, and it would merrily give me back IP addresses as fast as anything on the planet. Good times!
Yeah, but …
It makes sense for me to set the router like that because of the way I develop for the Jetsons. For each of the JetsonHacks videos, I flash a new system several times. This covers development, and the inevitable “starting with a new system” journey. Setting up a new connection each time is impractical. You may want to setup each of your devices individually. You probably want to do this with your phone in any case.
What I found surprising is the number of things that were outright broken once I was using the cable ISP DNS Resolver. There were all sorts of errors that upon reflection are just poor programming.
I’m no stranger to poor programming, I contribute regularly to the cause. But not dealing with really fundamental errors like a network connection time out? Inexcusable. At the very least tell the user there’s a connection issue.
Instead I was receiving errors like “Invalid Password” and “there is no information associated with this account”. I know that there’s a pretty low bar for programming now, but come on.
Just to let you know, I’ve put the current router on probation. Maybe over time we can become friends, but right now I’m rather wary. I have placed a label of shame on it that says “Set the DNS!” so that when its time comes, I’ll remember to setup the replacement. Hopefully we’ll generate some fond memories before that time.
Just so you’re aware, some ISPs block using a custom DNS resolver. I hope it’s not yours.