This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

DNS

  • _index

1 - DoT vs DoH vs DoQ

DoT

DNS over TLS (DoT) is a DNS encryption protocol based on TLS. TLS 1.2 requires at least four round-trips, TLS 1.3 requires at least three round-trips, while DNS requests only need one round-trip.

Timeline
  ↓
  ┌───────────────────────────────────────────────────────────────────────┐
  │                          Client                                       Server
  │                                                                        │
  │  Client sends SYN segment                                              │
  │  ────────────────────────────────────────────────────────────────────▶│
  │  SYN = 1, Seq = x                                                     │
  │                                                                        │
  │  ←─────────────────────────────────────────────────────────────────────│
  │  Server responds with SYN-ACK segment                                 │
  │  SYN = 1, ACK = 1, Seq = y, Ack = x + 1                               │
  │                                                                        │
  │  Client sends ACK segment                                              │
  │  ────────────────────────────────────────────────────────────────────▶│
  │  ACK = 1, Seq = x + 1, Ack = y + 1                                    │
  │                                                                        │
  │  TCP connection established                                           │
  │  Client sends ClientHello                                              │
  │  ────────────────────────────────────────────────────────────────────▶│
  │                                                                        │
  │  ←─────────────────────────────────────────────────────────────────────│
  │  Server responds with ServerHello                                     │
  │  Server sends certificate chain                                       │
  │                                                                        │
  │  Client sends key exchange message                                    │
  │  ────────────────────────────────────────────────────────────────────▶│
  │                                                                        │
  │  Server sends key exchange message                                    │
  │  ←─────────────────────────────────────────────────────────────────────│
  │                                                                        │
  │  Client sends Finished                                                 │
  │  ────────────────────────────────────────────────────────────────────▶│
  │                                                                        │
  │  Server sends Finished                                                 │
  │  ←─────────────────────────────────────────────────────────────────────│
  │                                                                        │
  │  TLS handshake completed                                              │
  │  Client sends DNS query                                                │
  │  ────────────────────────────────────────────────────────────────────▶│
  │                                                                        │
  │  ←─────────────────────────────────────────────────────────────────────│
  │  Server responds with DNS query                                       │
  │                                                                        │
  └───────────────────────────────────────────────────────────────────────┘

TLS 1.2 handshake requires at least two round-trip times (RTT): client sends ClientHello, server replies with ServerHello and certificates, then client sends ClientKeyExchange and ChangeCipherSpec, finally server sends Finished. TLS 1.3 simplifies the handshake to one round-trip (1-RTT). When sending ClientHello, client can include key share information (ClientKeyShare), server also includes key share information in ServerHello response, completing key negotiation and handshake within the first round-trip.

DoH

DNS over HTTPS (DoH) is a DNS encryption protocol based on HTTPS. HTTPS, being TCP-based, requires at least three round-trips to establish a connection while DNS requests only need one round-trip. Therefore, DoH is the slowest among the three encrypted DNS protocols.

Compared to DoT, DoH has higher protocol overhead due to additional HTTP protocol headers, making it slightly slower than DoT. Other aspects are similar to DoT.

DoQ

DNS over QUIC (DoQ) is a DNS encryption protocol based on QUIC. QUIC, being UDP-based, requires two round-trips to establish a connection while DNS requests only need one round-trip. Therefore, DoQ is the fastest among the three encrypted DNS protocols.

Timeline
  ↓
  ┌───────────────────────────────────────────────────────────────────────┐
  │                         Client                                      Server
  │                                                                        │
  │  Client sends Initial Packet                                          │
  │  Contains: QUIC version, Connection ID, encrypted handshake message   │
  │  (ClientHello), possibly application-layer data                       │
  │  ────────────────────────────────────────────────────────────────────▶│
  │                                                                        │
  │                                                                        │
  │  ←─────────────────────────────────────────────────────────────────────│
  │  Server responds with Initial Packet                                  │
  │  Contains: encrypted handshake message (ServerHello, Certificate,     │
  │  ServerKeyExchange etc.)                                                │
  │  May contain confirmation or rejection of client's 0-RTT data         │
  │                                                                        │
  │  Client sends encrypted handshake message (EndOfEarlyData, Finished)  │
  │  ────────────────────────────────────────────────────────────────────▶│
  │                                                                        │
  │  Server sends encrypted handshake message (Finished)                  │
  │  ←─────────────────────────────────────────────────────────────────────│
  │                                                                        │
  │  Handshake completed                                                  │
  │  Connection established                                               │
  │  Data transmission begins                                             │
  │  ────────────────────────────────────────────────────────────────────▶│
  │  ←─────────────────────────────────────────────────────────────────────│
  │  Data transmission                                                    │
  │  Data transmission                                                    │
  │  Data transmission                                                    │
  └───────────────────────────────────────────────────────────────────────┘

QUIC uses TLS 1.3 or higher to secure connections. The encrypted handshake process resembles traditional TLS handshake but is conducted through QUIC’s packet format, allowing data transmission to start simultaneously with handshake. If a client has previously established a QUIC connection with the server, it can immediately send application-layer data in new connection attempts without waiting for server response. This mechanism, called 0-RTT, can significantly reduce interaction latency. However, 0-RTT data might be rejected by servers due to replay attack risks.

QUIC’s design objectives include faster connection establishment and better congestion control compared to TCP, while maintaining compatibility with existing network infrastructure. Through these mechanisms, QUIC achieves fast handshake during first connection and utilizes 0-RTT for reduced latency in subsequent connections.

Conclusion

In stable network environments, DoQ theoretically offers the fastest speed thanks to its UDP and TLS 1.3 foundation. However, in actual networks, UDP’s connectionless nature may lead to random packet drops by ISPs during heavy traffic, causing connection instability. DoT is slightly slower than DoQ but offers more stable TCP-based connections. DoH is slower due to its HTTP-based protocol, but provides richer backend functionality. Choose the appropriate encrypted DNS protocol based on your network environment and requirements.

Reference

2 - Fastest DNS

Ordinary users typically measure ping response speed of plaintext DNS IP addresses, but this rarely reflects actual server connection performance. Modern DNS requires encrypted DNS protocols to ensure service integrity against hijacking.

From client to destination, traffic usually passes through 5-8 network devices. Any of these can hijack UDP:53 requests through simple commands. Never rely on plaintext DNS, especially in enterprise environments where hijacking is nearly inevitable.

Example hijacking command: sudo iptables -t nat -A PREROUTING -p udp --dport 53 -j DNAT --to-destination 1.1.1.1:53

Hijacking setup is trivial. Enterprise internal DNS speeds often stay under single-digit milliseconds while home networks typically see sub-1ms latency. Whatever plaintext DNS you configure, responses ultimately come from local DNS services.

Now discussing encrypted DNS speeds. Three common protocols: DNS over TLS (DoT), DNS over HTTP (DoH), and DNS over QUIC (DoQ).

Theoretical comparison:

  • Fastest: DoQ. QUIC (UDP-based) requires 1 round-trip (RTT) for connection + 1 RTT for DNS request
  • DoT: TLS 1.2 needs 4 RTT, TLS 1.3 needs 3 RTT connection + 1 RTT DNS request
  • DoH: HTTPS requires ≥4 RTT connection + HTTP overhead makes it slower than DoT
  • Traditional UDP:53: 0 RTT connection + 1 RTT

Encrypted DNS requires 2-4x longer for initial requests, but matches plaintext DNS speed once connected (ignoring connection timeouts).

Network reality: ISPs randomly drop UDP packets during congestion. TCP’s retransmission mechanism prevents this, making TCP DNS more stable during peak hours.

Connection time alone won’t significantly improve browsing experience. Proper DNS parameter configuration often yields better results than server selection.

Internet access involves two steps: domain IP lookup followed by direct IP communication. Local DNS cache checks happen first - cache queries take nanoseconds. TTL (Time to Live) controls cache duration. For example, TTL=600 keeps records valid 10 minutes. Many enterprises set TTL=10 (10 seconds).

Self-hosted DNS servers can modify TTL values. Services like www.adguardprivate.com allow DNS customization with extended TTL to reduce queries and improve browsing.

This article only discusses connection speed - DNS services offer many other performance-affecting features.