One of the most talked-about topics online today is privacy and security.. Even in casual contexts like social media, we see growing awareness. Take Instagram, for instance: imagine a post from a small page with fewer than a thousand followers. The post has a random stranger for less than split second. Yet If you scroll through comment section, you could see at least 50% of the comments ask the admin to blur the face. Especially when the person happens to be a woman.
It feels great to see such cultural shift where people want more privacy and anonymity. But while most people care about the privacy in platforms they use, they often forget about the root of the network. Yes, our own home / personal internet and the service provider. We trust them completely to provide us secure, reliable internet, but doing so could be a grave mistake.
How?
Because the answer really lies in the design of Internet and its evolution (Plus, How some business used it for their advantage)
How does your device know which site to load?
Ever thought of what happens when you type google.com and press enter/return or click go?
If you know the answer, you can skip this paragraph.
When you enter google.com and hit Enter, the first thing your device does is check if it already knows the IP address — maybe it’s stored in the local cache (browser, OS, or router). if not, request will be forwarded to local ISP’s DNS server — the resolver.
If the ISP’s DNS resolver doesn’t have the IP address, it begins a process called recursive DNS resolution, which looks like this:
- Root DNS Server – The resolver asks the root server: “Hey, where do I find .com domains?”
- TLD DNS Server – The root replies with the IP address of the .com top-level domain (TLD) name server.
- Authoritative DNS Server – The resolver then asks the TLD server, “Where can I find google.com?”
- The TLD responds with the IP address of Google’s authoritative DNS server.
- Finally, the resolver asks Google’s server for the IP address of google.com, and it returns the answer.
Now that your resolver has the IP, it passes it back to your device — and your browser opens a connection to that IP address.
Sounds clean, right?
Well, here’s the problem:
This entire DNS lookup process can be watched, logged, and even manipulated by your ISP or anyone in between. Because every request happens over plain text.
Traditionally the DNS lookup happens over UDP protocol. Which is light weight and superfast. UDP doesn’t establish a connection. It just sends a packet.
example:
Query: What is the address of google.com ?
Answer: Some IP address.
Because UDP doesn’t involve a handshake or encryption, DNS queries over UDP are completely visible to anyone watching the network — especially your ISP, public Wi-Fi providers, or malicious actors on the same network.
Infact:
- They can see what websites you look up, even if you don’t visit them.
- They can log your queries and use them for tracking, analytics, or targeted ads.
- They can even block or hijack queries, redirecting you to fake or filtered results.
Solution to the most of these problems are pretty simple
DoH (DNS over HTTPS)
Why It’s One of the Most Important Upgrades for Your Internet Privacy?
DNS over HTTPS is a protocol that encrypts your DNS queries using the HTTPS protocol (the same encryption used for secure websites). Instead of sending DNS requests in plain text, your browser or operating system sends them as encrypted HTTPS requests, usually to a DNS resolver like Cloudflare (1.1.1.1), Google (8.8.8.8), or NextDNS.
📦 In simple terms:
DoH wraps your DNS query in a secure HTTPS packet, making it invisible to eavesdroppers.
⚙️ How Does It Work?
Instead of using a traditional DNS resolver over port 53, your browser sends a POST or GET request over HTTPS (port 443) to a DoH-compatible DNS server.
Example flow:
- You type reddit.com in your browser.
- The browser checks its cache — if not found, it sends a DoH request to https://cloudflare-dns.com/dns-query.
- The DoH resolver decrypts the request and responds with the IP address for reddit.com.
- The browser connects to that IP — and now you’re browsing securely.
Because it’s HTTPS traffic, your DNS queries look like regular web traffic, blending in with everything else.
There is another better option : DoT
At a glance, DoT (DNS over TLS) and HTTPS (Hypertext Transfer Protocol Secure) may seem similar — both use TLS encryption to secure data in transit. But under the hood, they solve very different problems in the internet stack.
DoT is Often Network-Wide, While DoH is Usually Device-Specific
One key practical difference between DoT (DNS over TLS) and DoH (DNS over HTTPS) is where and how they’re typically implemented:
| Feature | DoT | DoH |
|---|---|---|
| Typical Scope | 🛜 Network-wide (router, OS-level) | 📱 Device/app-specific (browser, app) |
| Runs on | Port 853 (dedicated DNS over TLS) | Port 443 (standard HTTPS) |
| Best used for | Enforcing DNS privacy on all devices in a network | Per-device privacy & censorship bypass |
| Easier to block | ✅ Yes (easy to detect by port) | ❌ No (blends in with HTTPS traffic) |
| Common use cases | Routers, Android Private DNS, Linux systems | Firefox, Chrome, mobile apps |
You might have already thought of way to protect yourself. There is another Last Mile of Internet Privacy That Few People Know About.
ECH (Encrypted Client Hello)
You’ve encrypted your DNS with DoT or DoH. Your connection to websites is secured with HTTPS. So, you’re fully private now… right?
Not quite.
There’s one last leak in the privacy chain — and it happens before the encrypted connection even begins. It’s called the Client Hello, and it reveals more than you think.
What is Client Hello?
When you visit a secure website (https://example.com), your browser first initiates a TLS handshake — the process that sets up encryption between your device and the website’s server.
One of the first steps in that handshake is the Client Hello message. It includes:
- Supported TLS versions and cipher suites
- The Server Name Indication (SNI) – the actual domain name you’re trying to connect to
🔓 The problem: The SNI is sent in plain text — even over HTTPS.
That means anyone on the path (like your ISP, network admin, or a censoring government) can see which website you’re visiting, even if they can’t see the page contents.
Enter ECH: Encrypted Client Hello
ECH (Encrypted Client Hello) is an extension to TLS 1.3 that encrypts the entire Client Hello, including the SNI.
📦 Think of ECH as sealing the envelope before you even say who the letter is for.
With ECH enabled, the name of the website you’re visiting is no longer visible to your ISP, employer, or network firewall.
Who Supports ECH?
As of mid-2025, ECH is still rolling out across browsers, operating systems, and CDNs.
✅ Browsers that support ECH:
- Firefox (v118+) – With settings enabled
- Chrome / Chromium (v117+) – With system and DNS support
- Brave / Edge – Based on Chromium, gaining support
✅ DNS Providers that support ECH:
To use ECH, you must resolve domains using a DNS provider that publishes ECH keys via HTTPS records, such as:
- Cloudflare (1.1.1.1)
- NextDNS
ECH only works when used with encrypted DNS (DoH/DoT) — so that the SNI encryption key can be discovered securely.
How to Enable ECH
🔧 Firefox:
- Go to about:config
- Search for network.dns.echconfig.enabled and set to true
- Also enable network.dns.http3.echconfig.enabled and network.security.esni.enabled
🔧 Chrome:
ECH support is rolled into Chrome’s use of the OS resolver and DNS-over-HTTPS. It’s auto-enabled when:
- The server you’re connecting to supports ECH (e.g., Cloudflare-hosted websites)
- You’re using DoH with a supporting resolver
The Bigger Problem: BGP and the Internet’s Fragile Backbone
So far, we’ve talked about DNS and how unencrypted queries can leak your browsing habits to ISPs or attackers. But there’s another, deeper layer of the internet’s infrastructure that’s even more opaque to end users — and just as vulnerable: The name is BGP or Border Gateway Protocol.
BGP is literally the postal service of the internet. It tells routers across the world how to reach different IP address blocks. ISPs, data centers, and large corporations use BGP to announce which IP ranges they control — and routers use that information to build the best path to deliver data across the internet.
But here’s the problem:
BGP was never designed with security in mind.
There’s no built-in verification or checks to make sure that an ISP announcing ownership of an IP range is actually authorized to do so.
What can go wrong?
A lot.
- BGP Hijacking: A malicious or misconfigured network can announce ownership of IP ranges it doesn’t control. This reroutes traffic through unintended paths — sometimes for spying, sometimes by accident.
- Traffic Interception: In 2018, traffic to major companies (like Google, Amazon, and Facebook) was briefly hijacked and rerouted through suspicious ASes (Autonomous Systems) in countries like Russia and China.
- Outages: A bad BGP route can cause parts of the internet to become inaccessible — and it happens more often than you’d expect.
Why isn’t it fixed?
Because deploying BGP safety mechanisms like RPKI (Resource Public Key Infrastructure) requires global coordination, effort, and incentives. Sadly, many ISPs — especially smaller or regional ones — still haven’t adopted them.
That means your traffic could still be vulnerable to interception or misrouting, even if you’re using encrypted DNS or HTTPS.
Final Thoughts
ECH is the future of web privacy.
It seals the last leak in the HTTPS handshake and protects your intent from being visible — even before the page loads.
When combined with:
- ✅ DNS over HTTPS (DoH) or DNS over TLS (DoT)
- ✅ HTTPS
- ✅ A trusted DNS resolver like Cloudflare or NextDNS
You’re as close as possible to true privacy on today’s internet — no VPN required provided that your ISP is BGP safe. Which you can always check with the url : https://isbgpsafeyet.com/
Want to configure the browser / network to make it more private? Stay tuned.!