Calcul 100% dans le Navigateur • Zéro Journal Serveur • Exécution Instantanée
Curious TechieBoîte à Outils
Networking & Infrastructure6 min ReadSide-by-Side Architectural Breakdown

DNS vs DNS over HTTPS (DoH)

Traditional cleartext UDP port 53 lookups vs encrypted HTTP/2 TLS lookups over port 443 — Deep technical analysis of trade-offs, architecture, performance, security postures, and engineering decision frameworks.

CT
Curious-Techie Engineering TeamAuteur Vérifié

Web Protocols & Security Architecture Research

Publié :
•
Mis à jour :
•6 min read
Spécification Faisant Foi :RFC 9110(IETF)
Revu par Curious-Techie Architecture Peer Review Group
Primary Question • Immediate Technical Contrast

DNS vs DNS over HTTPS (DoH)

•
Core Engineering Verdict

Use DNS over HTTPS (DoH) or DNS over TLS (DoT) to safeguard user browsing privacy, defeat ISP surveillance, and prevent DNS poisoning attacks.

Secondary Question • Architectural Definitions

What are Classic DNS and DoH?

Option ACleartext Protocol

Traditional DNS (RFC 1035)

The original decentralized naming system operating over cleartext UDP (and TCP) port 53 that resolves hostnames into IP addresses with zero cryptographic encryption.

Defining Trait: Cleartext & Easily Monitored — Visible to every router and ISP between the client and resolver.
Option BEncrypted Protocol

DNS over HTTPS (DoH / RFC 8484)

A protocol for performing remote Domain Name System resolution via the HTTPS protocol, encrypting queries and responses using standard TLS over port 443.

Defining Trait: Encrypted & Indistinguishable — Disguises DNS queries as standard HTTPS web traffic.

3. Side-by-Side Comparison Matrix

Feature / DimensionClassic DNSDoHAdvantage
Transport Encryption
DoH protects query confidentiality
None (Plaintext UDP/TCP)Strong TLS 1.3 encryptionDoH
Network Port
DoH blends into regular web traffic
Port 53 (Easily intercepted)Port 443 (Standard HTTPS)DoH
ISP / Wi-Fi Surveillance
ISP only sees the IP of the DoH resolver
Complete visibility into all domain lookupsHidden from local network and ISPDoH
DNS Hijacking & Spoofing
Guarantees the DNS answer came from trusted resolver
Vulnerable (Routers can spoof answers)Immune (Authenticated TLS connection)DoH
Query Latency
Traditional DNS has minimal setup overhead
Fast (1 RTT over UDP)Marginally slower initial handshake; fast with connection reuseClassic DNS
Enterprise Filtering Compatibility
Enterprises sometimes disable DoH to enforce security filters
Native (Enterprise firewalls easily filter port 53)Difficult (Bypasses local enterprise DNS policies)Classic DNS
Secondary Question • In-Depth Technical Analysis

How do Classic DNS and DoH differ technically?

01

Plaintext Exposure vs TLS Secrecy

Even if a website uses HTTPS, when you use traditional DNS, your computer asks your ISP’s resolver: "What is the IP of sensitive-health-site.com?" in plaintext over port 53. The ISP logs this request. With DoH, the query is encrypted inside TLS before leaving your machine.

Engineering Impact: DoH closes the biggest privacy loophole in modern web browsing.
02

Port 53 Blocking vs Port 443 Blending

Governments and hostile networks censor websites by intercepting or blocking UDP port 53 traffic. DoH uses standard port 443—the same port used by all web traffic. A network cannot block DoH without breaking all HTTPS web browsing.

Engineering Impact: DoH makes DNS censorship and selective domain throttling significantly more difficult.
03

Centralized Resolver Concentration

Traditional DNS automatically distributes queries to local ISP resolvers. DoH configurations often funnel hundreds of millions of users into a handful of mega-resolvers (Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9).

Engineering Impact: Shifts trust from thousands of ISPs to a few centralized tech conglomerates.
Decision Framework • Selection Criteria

When should you use Classic DNS vs DoH?

When to Use Classic DNS

Internal Corporate Networks with Active Directory

Corporate intranets rely on internal DNS servers to resolve local resources (e.g. intranet.corp.local).

Embedded / IoT Devices with Strict Memory Limits

Simple devices that cannot maintain TLS connection state or verify CA certificate chains.

When to Use DoH

Public Wi-Fi Networks (Coffee Shops, Airports, Hotels)

Prevents rogue routers and Wi-Fi sniffers from tracking your lookups or redirecting you to phishing portals.

Privacy-Conscious Web Browsers

Modern browsers (Firefox, Chrome) default to DoH to protect user privacy from ISP data monetization.

Bypassing Local DNS Censorship or ISP Throttling

Ensures queries reach uncensored resolvers without tampering.

Threat Modeling • Attack Vectors

What are the security differences between Classic DNS and DoH?

Traditional DNS is vulnerable to DNS cache poisoning, Kaminsky attacks, and transparent proxy hijacking. DoH provides authenticated, encrypted lookups, but centralizes browsing history with the chosen DoH provider.

Threat Vectors in Classic DNS
  • ×DNS Spoofing and Cache Poisoning returning malicious phishing IPs
  • ×Man-in-the-Middle ISP injection of warning or censorship pages
  • ×Passive surveillance logging every domain visited
Threat Vectors in DoH
  • ×Centralized profiling by mega DoH providers (Cloudflare, Google)
  • ×Circumvention of parental controls and corporate malware blocklists
Recommended Security Hardening
  • Choose privacy-focused DoH resolvers with certified no-logging policies (e.g., Quad9 9.9.9.9 or Mullvad).
  • Enable DNSSEC validation at the resolver level to guarantee authoritative zone signatures.
  • Pair DoH with Encrypted Client Hello (ECH) to prevent domain leakage during the TLS SNI handshake.
Benchmarks • Resource Utilization

Which performs better: Classic DNS or DoH?

Traditional DNS has lower initial latency because UDP requires no handshake. However, once a DoH HTTP/2 or HTTP/3 connection is established, pipelined queries resolve with near-identical speed.

Benchmark MetricClassic DNSDoH
Initial Query Latency1 RTT over UDP (~15–30ms)2–3 RTT (TCP + TLS setup, ~60–120ms)
Subsequent Query Latency1 RTT per lookup<1 RTT over persistent HTTP/2 connection
Packet Size~60 – 120 bytes~400 – 800 bytes (TLS overhead)

9. Side-by-Side Concrete Technical Examples

Traditional Plaintext DNS Query (dig CLI)bash
# Plaintext UDP port 53 query - visible to Wi-Fi sniffers
dig @8.8.8.8 curious-techie.com A +noall +answer

# Output:
# curious-techie.com.   300   IN   A   104.21.58.12
Explanation: Sends an unencrypted UDP datagram to 8.8.8.8 on port 53. Every router on the path can see the domain name and response.
DNS over HTTPS Query using curl (application/dns-json)bash
# Encrypted HTTPS query over port 443 with TLS 1.3
curl -H "accept: application/dns-json" \
  "https://cloudflare-dns.com/dns-query?name=curious-techie.com&type=A"

# Output (encrypted in transit):
# {"Status":0,"Answer":[{"name":"curious-techie.com","type":1,"TTL":300,"data":"104.21.58.12"}]}
Explanation: The query is wrapped in TLS encryption over port 443. The ISP sees only an HTTPS connection to cloudflare-dns.com, but cannot see what domain is being resolved.
Myths vs Reality • Technical Clarification

What are common misconceptions about Classic DNS vs DoH?

Myth / Fallacy
"DoH makes your internet browsing 100% anonymous."
Technical Reality

DoH only encrypts the DNS lookup. The destination IP address and Server Name Indication (SNI) are still visible to network observers unless Encrypted Client Hello (ECH) is also used.

Myth / Fallacy
"DoH and DNS over TLS (DoT) are the same thing."
Technical Reality

DoT uses a dedicated port (port 853) with raw TLS; network administrators can easily block port 853. DoH uses standard HTTPS port 443, making it impossible to block without blocking the entire web.

Final Verdict • Engineering Selection

Which should you choose: Classic DNS or DoH?

Enable DNS over HTTPS in your operating system or web browser to prevent ISP tracking and protect against rogue Wi-Fi DNS spoofing. Select an independent, zero-log resolver like Quad9 or Cloudflare.

Engineering Decision Rules
IF:Personal web browsing on public or home networks
→ USE:Enable DoH in browser or OS settings.
IF:Enterprise corporate network with internal compliance
→ USE:Use internal managed DNS; selectively disable public DoH.
IF:High-security zero-trust mobile setup
→ USE:Combine DoH with WireGuard VPN and Encrypted Client Hello (ECH).
Direct Technical Answers • Knowledge Base

Frequently Asked Questions About Classic DNS vs DoH

Q:What is the difference between DoH and DoT?

Direct Answer:DoH runs over port 443 (standard HTTPS); DoT (DNS over TLS) runs over dedicated port 853.

Because DoT uses port 853, firewalls can easily detect and block it. DoH blends into all other web traffic on port 443, making it censorship-resistant.

Q:Does DoH slow down web browsing?

Direct Answer:In practice, no. Browsers maintain a persistent HTTP/2 connection to the DoH resolver, resulting in sub-millisecond query multiplexing.

While the very first connection requires a TLS handshake, subsequent DNS lookups share the existing encrypted tunnel with zero setup overhead.

13. Related Client-Side Verification Tools

Inspect, test, and benchmark these technologies directly in your browser with 100% private client-side execution:

Companion Interactive Tool100% Client-Side Execution

Test & Verify with DNS Lookup

Query A, AAAA, MX, TXT, CNAME, NS, SOA, and CAA records via DNS-over-HTTPS.

Companion Interactive Tool100% Client-Side Execution

Test & Verify with WHOIS Lookup

Query domain registration, registrar info, and expiration dates via RDAP.

Companion Interactive Tool100% Client-Side Execution

Test & Verify with IP Address Checker

Detect your public IP address, ISP, ASN, and geographic location.

Authoritative Sourcing & Verification

References & Primary Sources

Every source below directly substantiates technical statements and protocol behaviors explained in Traditional DNS (RFC 1035) vs DNS over HTTPS (DoH / RFC 8484). Curious-Techie prioritizes official Internet standards (IETF RFCs, W3C Recommendations, WHATWG specifications) and established security bodies (OWASP, NIST). Zero sponsored or secondary links.

  1. [1]IETFPrimary SpecificationRFC 9110 • Core Architecture
    Verified Primary Source
    Technical Claim Supported:

    Foundational specification for the stateless client-server request-response architecture, standard status codes (1xx–5xx), and method safety and idempotency.

  2. [2]IETFPrimary SpecificationRFC 9112 • Section 3 & 6
    Verified Primary Source
    Technical Claim Supported:

    Defines ASCII wire protocol framing, chunked transfer encoding, and persistent connection Keep-Alive mechanics.

  3. [3]IETFPrimary SpecificationRFC 9113 • Section 4 & 5
    Verified Primary Source
    Technical Claim Supported:

    Standardizes binary framing, HPACK header compression, and bi-directional stream multiplexing over a single shared TCP connection.

  4. [4]IETFPrimary SpecificationRFC 9114 • Section 3 & 4
    Verified Primary Source
    Technical Claim Supported:

    Eliminates TCP head-of-line blocking by mapping HTTP streams directly over QUIC UDP transport connections with integrated TLS 1.3 encryption.