What is DNS and why you need your own local DNS?

Whenever it comes to a discussion regarding DNS, I would like to initiate it with this famous Haiku.

Explanation: You may think that the network issue was due to something serious, unlike DNS. You may be absolutely convinced that it’s not due to DNS. But after debugging the issue for an hour, you will finally come to the conclusion that it was indeed due to DNS.

What exactly is DNS?

As there are various blogs on the internet which goes on detail about what DNS is, I will oversimplify DNS with a single line; it’s a phone directory for the internet.

Some of you younger folks might not know what a phone directory is. It was a book which contained a list of people and businesses in your city, and their corresponding phone numbers (Privacy issues were non-existent in the ’80s). So instead of remembering the phone numbers (or IP addresses in this case) of a hundred people, you just remember their names (website name), and using the book, you can find their phone numbers.

So this is how DNS works

• Browser: Hi! I need the IP address of the website https://duckduckgo.com
• DNS: Here you go, this is the IP -> x.x.x.x
• Browser: Thanks! Hey router, take me to the IP address x.x.x.x
• Router: Yes, right away!

DNS is one of the oldest distributed architecture running across the world. As a homelabber, that’s all that you need to know about DNS, for now.

Useful commands/websites for debugging DNS issues

As someone using DNS as an end-user, there is not an extensive list of commands for DNS. These are what I prefer to use when diagnosing DNS issues.

dig <URL>

• Returns the resolved IP address of the URL
• You can find the latency of the DNS server

dig <URL> @<DNS SERVER>

• Returns the resolved IP address from the specified DNS server

host <URL> or host <IP>

A simpler dig command, but it also does reverse DNS lookup, i.e., you can find out the domain name, if any, of a given IP address. It can be useful in certain scenarios.

• host server.lan gives the IP address of server.lan
• host 192.168.10.1 gives the domain name associated with the IP

bash.ws or dnsleaktest

It’s possible that your DNS resolution is done by someone other than the resolvers mentioned in your router (See DNS hijacking), or you have simply misconfigured your DNS settings. There could be a forgotten application on your network which has hard-coded DNS resolvers mentioned inside its OS. In such cases, a DNS leak-test is useful. You can use any of these two websites to identify exactly who is resolving your DNS requests.

If you want to do perform the same test on a headless server, use this Github repo.

The Fun Part: Setting local DNS entries

I sometimes get annoyed typing the IP address every time when accessing my self-hosted services. So why not just give the services a name using local DNS entries? This can be done via several ways, each with their own set of advantages. Here are a couple of approaches

At the host machine (Simplest)

Edit the file /etc/hosts and append your DNS mappings

192.168.10.1  server.lan
192.168.10.2  desktop.lan

Pros

• You edit a single file and do not need to mess with network settings

Cons

• Only works on a machine by machine basis; not scalable.
• Will not work on Android/iOS device since /etc/hosts is on the root partition

Note: Don’t modify the existing entries unless you know what you are doing

At your router

Pros

• You can use your local DNS entries across your entire network

Pros

• Highly dependant on your router

Some routers allow adding DNS entries, some don’t. If you want to proceed with this approach, there are a couple of options

1. Unlock your router (Some commercial routers allow it)
2. Buy a router which has a better firmware support (Asus Merlin firmware)
3. Flash your router with an open-source firmware, such as OpenWRT
4. Build your own firewall using OPNSense

Each of these options are their own separate chapter. If you have the time and patience, you can do it. However, the one I would recommend which I feel is a good middle ground and would give you a lot of flexibility, is…

Deploy your own DNS server

This is probably the best option as a budding homelabber

Pros

• No need to modify your router
• Lot’s of options unlocked by using something like Pihole or Technitium
  • Use Technitium only if you truly care about DNS
• Perform DNS level blocking (Ad-blocking)
• Use custom domain names which works across your home network
  • Create a DNS entry once, use the domain on all your devices
• Ability to use dnsmasq, which is very useful when using a reverse proxy

Cons

• Your internet connection depends on the uptime of your DNS service, i.e., your server
• Can seem a bit complicated initially

Deployment (Of Pihole)

You can check the excellent resource on how to setup Pihole using Docker here.

• Use the Pihole image
• Deploy it on your server
• In your router’s IP configuration section, point to your Pihole IP

The process remains the same, irrespective of which DNS service you use.

Advanced topics - Deploying your own encrypted DNS forwarder

This is one aspect of DNS which interests me; encrypted DNS. It’s mainly because I have been trying to safeguard my privacy in recent times. DNS request have historically been unencrypted, thus, ISPs or other middleboxes can easily keep track of who is visiting what website and can create a profile of each user. I may go into detail regarding this topic in another blog.

Recently (like in the last 2 decades), we have encrypted DNS services like DNSSEC. This has sprawled into several other options such as

• DNS-over-HTTPS (DoH)
• DNS-over-TLS (DoT)
• DNS-over-QUIC (DoQ)
• DNScrypt

Each of them have their own philosophy regarding how to encrypt, what transport protocol to use, and where to route it. I will suggest the reader to explore this on their own.