Comparing DNS Over HTTPS and TLS: Key Concepts and Implementation

TL;DR

This article covers DNS over HTTPS (DoH) and DNS over TLS (DoT), detailing their key differences, implementation strategies, and impact on user security and privacy. It includes a comparison of how each protocol works, preferred use cases, and considerations for implementing them within authentication systems and login management solutions, offering developers a guide to choose the right protocol.

Introduction: The Need for Secure DNS

Okay, so why all this fuss about secure DNS? Well, think of it like this: you wouldn't send a postcard with your bank details, right?
Traditional DNS is kinda like that postcard—totally exposed.

Here's a quick breakdown of why this is a problem:

Privacy nightmare: Unencrypted DNS queries are basically broadcasting your browsing history to, well, everyone along the way. That's your isp, any malicious actor on the network, anyone who wants to know what you're doing. Really, not ideal.
Man-in-the-middle attacks: Because the data isn't protected, attackers can intercept your DNS requests and send you to a fake website. Think about the implications for e-commerce, finance, or even healthcare!
ISPs tracking you: Yeah, your isp can see all your unencrypted DNS queries, and they can use that info to track your online activity. And they do.
DNS Cache Poisoning: Attackers can tamper with DNS records, leading users to malicious sites even if they type the correct URL.
Lack of Authentication: There's no built-in way to verify that the DNS server you're talking to is the legitimate one.

So, what's the fix? Encrypt those DNS queries! That's where DNS over HTTPS (DoH) and DNS over TLS (DoT) come in.
They're like putting your DNS requests in a sealed envelope, so only the intended recipient can read them.

Now, we're gonna dive into how these protocols actually work, compare 'em, and figure out which one might be better for different situations. Stick around!

DNS Over TLS (DoT): Securing DNS at the Transport Layer

DNS over TLS, or DoT, encrypts those DNS queries, right? But how does it actually do that?

Well, DoT is like giving your DNS requests a VIP escort. It's pretty straightforward, actually:

TLS Encryption: It wraps your DNS queries in Transport Layer Security (TLS) encryption, keeping 'em safe from prying eyes. Think of it like sending a secure email instead of a postcard.
Dedicated Port 853: DoT uses a special port just for itself. This means it's easier to manage those encrypted DNS queries. It also means network administrators can more easily identify and manage this specific type of encrypted traffic, perhaps by prioritizing it or applying specific security policies.
Stops Eavesdropping: By encrypting your DNS traffic, DoT makes it way harder for attackers to listen in and mess with your requests; this way, you won't be redirected to malicious sites.

Implementing DoT isn't always a walk in the park, though.

Certificate Management: You will need to manage those TLS certificates.
Firewall Issues: Some firewalls might block DoT traffic, messing with yer connections.
Network Visibility: It can make it tricky to see what's going on in your network.

So, while DoT is pretty cool, there's stuff to think about before you jump in. Now, let's move on to the next step, where we get into DoH—DNS over HTTPS.

DNS Over HTTPS (DoH): Hiding DNS Traffic in HTTPS

Alright, so, DoH – DNS over HTTPS. Think of it like this; your DNS query is now hitching a ride inside an https connection. Sneaky, right? But how does it actually work?

Well, DoH is all about hiding in plain sight, like a DNS query wearing an invisibility cloak made of encryption. Here's the gist:

HTTPS Wrapper: DoH takes your DNS query and wraps it up nice and snug inside a standard HTTPS request. So, instead of shouting your intentions across the internet, you're whispering them in a secure tunnel.
Port 443 Hijack: It uses port 443, which is the same port used for regular https traffic. This makes it much harder to distinguish from normal web browsing, which is kinda the whole point.
Traffic Blending: Because it blends with all the other web traffic, it's tougher for network snoops to pick it out.

But it's not all sunshine and rainbows, you know? There are some things you need to consider before you go all-in on doh:

Filtering Bypass: Since it uses standard https, it can bypass some DNS-based filtering that organisations use for security or content control; this could be a problem for parental controls.
Latency Boost: There may be an increase in latency as compared to traditional DNS. This is because the DNS query has to go through the full HTTPS handshake and processing, which adds a few extra steps compared to a simple UDP DNS request.
Server Config: It needs an https server configuration, which adds complexity.

As Catchpoint mentions, this can be a win when privacy is your top concern. They note that DoH's ability to blend with regular web traffic makes it harder for adversaries to block or monitor DNS requests specifically, thereby enhancing user privacy.

So, DoH is a handy tool, but it's not a silver bullet. Next up, we'll get into some of the nitty-gritty implementation details.

Key Differences: DoT vs. DoH

Okay, so you're wondering what really sets DoT and DoH apart, huh? It's not just alphabet soup, I promise.

Think of it this way:

Protocol and Port: DoT uses TLS on a dedicated port (853), making it distinct and potentially easier for network administrators to manage or block. DoH, on the other hand, uses HTTPS on the standard port 443, blending in with regular web traffic.
Privacy vs. Manageability: DoH generally offers better privacy by hiding DNS traffic within encrypted web traffic, making it harder to detect and block. DoT, while secure, can be more easily identified by network administrators.
Performance: DoT is often considered slightly faster because it's a more direct, less complex connection than DoH, which has to go through the full HTTPS handshake. However, the difference is often negligible for most users.
Censorship Resistance: DoH's ability to blend with HTTPS traffic can make it more effective at bypassing censorship or network restrictions compared to DoT, which might be blocked if port 853 is restricted.

Choosing? It all boils down to whatcha need. Next up, we'll dive into implementation.

Implementation in Authentication and Login Systems

Alright, let's talk about how this stuff plays out in real life—specifically, when you're logging in somewhere. It's kinda vital, right?

Authentication workflows are getting safer: Imagine every time you log in, DoT/DoH shields those DNS queries. This means that even if an attacker intercepts network traffic, they won't be able to see which servers your device is trying to connect to for authentication purposes. Less chance of someone snooping and stealing your credentials, which is the whole point.
Attackers, begone! Seriously, intercepting login info? Not on our watch—these protocols makes it way harder to succeed with these attacks. For example, if a login process involves fetching configuration details or verifying identity through a DNS lookup, an attacker can't easily redirect you to a phishing site by manipulating that DNS response.
Security posture gets a boost: Using DoT/DoH bolsters the overall security of how you log into systems. It adds an extra layer of defense against common network-based attacks that target the initial stages of establishing a connection, like DNS spoofing or man-in-the-middle attacks during the authentication handshake.

Code Examples: Configuring DoT and DoH

Okay, so you're ready to see some code? Honestly, it's not always the most thrilling part, but it's where the rubber meets the road, ya know? Let's get into it.

Configuring DoT in systemd-resolved

On many Linux systems, systemd-resolved handles DNS. You'll need to edit its configuration file, typically located at /etc/systemd/resolved.conf.

Here's how you might set it up:

Edit the configuration file:
Open /etc/systemd/resolved.conf with your preferred text editor.

Specify DNS servers and enable DoT:
Uncomment and modify the [Resolve] section. You'll want to specify your DNS servers and tell systemd-resolved to use DoT.

[Resolve] DNS=1.1.1.1#cloudflare-dns.com 1.0.0.1#cloudflare-dns.com # You can add more servers here, separated by spaces. # The format is IP_ADDRESS#HOSTNAME. The hostname is used for TLS certificate verification. DNSOverTLS=yes Make sure this line is uncommented and set to 'yes' to enable DoT.

The # symbol separates the IP address from the hostname that systemd-resolved will use to verify the TLS certificate of the DNS server.

Restart the service:
After saving the file, restart systemd-resolved for the changes to take effect:
```
sudo systemctl restart systemd-resolved
```
Verify DoT Functionality:
You can check the status with resolvectl status. If everything's configured correctly, you should see indicators that DoT is active. While DNSSEC=yes is a good sign of DNS security, the key indicator for DoT is often found within the output related to your configured DNS servers, showing they are using TLS. Look for specific mentions of DoT being enabled for your active DNS servers.

Configuring DoH in Firefox

Configuring DoH in Firefox is pretty straightforward:

Open Firefox Preferences: Go to about:preferences#privacy.
Scroll to DNS over HTTPS: Find the "DNS over HTTPS" section.
Enable and Choose Provider:
- You can select a pre-configured provider from the dropdown menu.
- To use a custom provider, select "Custom" and enter the DoH endpoint URL. For example, for Cloudflare, you might use https://cloudflare-dns.com/dns-query.
Make sure the provider you choose actually supports DoH. A good way to verify is to check their official documentation or look for specific API endpoints designed for DoH queries.
Test DoH Functionality:
Use a site like Cloudflare's browser check to confirm DoH is working. This tool can help verify that your DNS queries are being encrypted and protected.

Now that we’ve seen some examples, let's move on to how services can streamline all this.

Conclusion: Choosing the Right Protocol for Your Needs

Alright, so we've gone deep into DoT and DoH; figuring out which one's "best" ain't simple, you know? It really depends on what you're prioritizin'.

For maximum privacy and blending in: DoH is often the go-to. It hides those DNS queries in regular https traffic, making it harder for anyone to specifically identify and monitor your DNS lookups.
For easier network management and distinct traffic: DoT might be preferred. Its use of a dedicated port (853) makes it clear to network administrators what's happening, which can be useful for policy enforcement or troubleshooting.
Consider performance: While DoT is often cited as being slightly faster due to less overhead, the difference is usually negligible for most users. Unless you're in a highly performance-sensitive environment, either protocol should be fine.
Think about your environment: On public Wi-Fi or in restrictive networks, DoH's ability to bypass censorship by masquerading as regular web traffic can be a significant advantage.

Ultimately, the "right" protocol is the one that fits your needs and infrastructure best. Don't be afraid to experiment, and stay secure, y'all.