[fChk]

So, to protect the identity of the sites we visit we have to deal with 4 different leaks:

• DNS name resolution: this leak is dealt with when using DoH (DNS over HTTPS on port 443) or DoT (DNS over TLS on port 853.)
  
• the TLS certificate message: this leak is suppressed when we use TLS v1.3, which encrypts the server certificate by default.
  
• the TLS Server Name Indication extension (SNI): the fix for this leak (i.e. the encryption of the the SNI field, hence “encrypted SNI” or ESNI) was dropped from the TLS v1.3 standard but still Mozilla & Cloudflare engineers are currently testing a use-case for it.
  
• the IP address of the server: this is a hard one to crack; no wonder, it's at the heart of the Internet mechanics. But on shared hosting and/or behind a CDN (like Cloudflare) and/or behind a VPN ..etc.. things get indeed a lot fuzzier.
  

In this post, I'll expand a bit on the DNS name resolution risks and what specific issues the use of DNSSEC and encrypted DNS (or secure DNS or DoH/DoT) address from an end-user(/client) perspective.

In upcoming threads, I'll deal with how these 3 technologies(/standards) are implemented server-side (ie, how DNSSEC is deployed for a given domain name, and how we can implement our own DoT/DoH servers.) But for now, in this post, we'll just address the DNS issues from a user's perspective in the Web context (as an example.)

The Importance the DNS:
The first thing a browser does when you want to visit a website is to perform a DNS lookup to get the IP address of the domain name you're about to visit. For this to succeed, the browser relies on the OS configured DNS server (which is normally set with your IPv4 connectivity stack.) For the 92% of the case it's the user's ISP DNS server; for the 5% it's the Corporate DNS servers and for the rest(/powerUsers) it's a public DNS resolver (be it OpenDNS, Quad9, Cloudflare's or Google's ..) [1] So, if this DNS lookup for whatever reason fails, well, you're stuck!... That's how DNS is critical for your daily web browsing routines (in fact, DNS is critical for anything using domain names on the Internet... and I'm sure this is trivial knowledge... but I'm building a logic here :-) So, bear with me, please.)

The Problem(s) with the DNS:
DNS queries and replies are transmitted in plain text over UDP or TCP, which make them an easy target for spoofing, surveillance, and filtering (DNS-based censorship) while in transit on the wire.

In other words, traditional DNS is just a disaster waiting to happen. It is plain-text,  easily monitored, easily blocked (port 53), easily redirected, easily forged (when without DNSSEC.)


DNSSEC to the Rescue:
Because securing the DNS is securing the Internet as a whole, the Domain Name System Security Extensions (DNSSEC) has been steadily developed and deployed over the past two decades (check the timeline here.)

At its core, DNSSEC is a technology that uses cryptographic signatures to make the DNS tamper-proof, protecting it against DNS hijacking. And to quote the Wikipedia page:

It is a set of extensions to DNS which provide to DNS clients (resolvers) cryptographic authentication of DNS data, authenticated denial of existence, and data integrity, but not availability or confidentiality.

So, please, remember that DNSSEC doesn't provide DNS data confidentiality(/privacy) but it's all about DNS data authentication and integrity (ie, you can be sure that the data you're getting is authentic and sound.)

Alas, for this assurance to happen, both the domain and the user's stub resolver have to DNSSEC-aware. Please review the wiki page for more on that. In here, I'll just point out that in Linux (I'm no longer a Windows user in production mode--and don't advice it) both Bind and Unbound are good options when it comes to DNSSEC support(/signature validation.) But, Use Bind only if you have local zones to manage; if not, use Unbound.

What about Privacy ?.. "encrypted DNS" to the Rescue:
To the joy of the Internet snoopers, secure DNS has been neglected for far too long; the party is over!.. DoH and DoT are here ( drum beat :-) )

For about 2 years or so (I was basically offline in that period, so I missed the whole beginnings), encrypted DNS is becoming a HOT topic on the Internet and rightly so; it's such a huge deal for the rest of us privacy-starved netizens, although, it's still work in progress that result on today's DoH and DoT.

DNS-over-HTTPS (DoH, port 443) and DNS-over-TLS (DoT, port 853), by encrypting the traffic between clients and resolvers, enhance users' privacy and complement Public DNS resolvers validation of DNSSEC to finally provide a real end-to-end authenticated DNS for DNSSEC-signed domains.

Now, I'll finish by presenting a rough overview of DoH and DoT and will leave all the technical details to my upcoming thread on 'Encrypted DNS'.

What is DoT?
DNS over TLS (DoT) is a proposed standard (rfc7858) from the IETF, that encrypts DNS traffic and send it via port 853 using the TLS protocol. Thus its sole goal is to increase user's privacy and security by preventing eavesdropping and tampering of the DNS data.

We'll deal more about DoT implementation in the adhoc thread; for now let's just summarize it by stating that DoT is encrypted, easily monitored (traffic-wise; port 853), easily blocked but not easily forged.


What is DoH?
DNS over HTTPS (DoH) is a new RFC (rfc8484) from the IETF, published in October 2018, that "gives web applications access to DNS information via existing browser APIs." And, by doing that, they are short-circuiting the Operating system hegemony/control over DNS functionality, thus creating another headache to the corporate security folks in their efforts to enforce
the corporation's policy in the work-place (I've read somewhere on the Web, someone calling Firefox a 'rogue application' for daring to implement DoH :-) .)

Anyway, DoH is encrypted, not easily monitored (it's mixed with standard HTTPS traffic; but see this post ), not easily blocked (same reason as before), not easily redirected and not easily forged.

This ends the overview of the DNS name resolution leakes and fixes. My next post here is about the TLS v1.3 and the ESNI.

Stay tuned!


----------
[1]-Those percentages aren't real obviously, but quite plausible :-)