Confronto dei protocolli DNS crittografati: DoT, DoH, DoQ

Glossario rapido

• Plain DNS: DNS in chiaro, utilizza UDP/53 come predefinito, usa TCP/53 quando necessario (es. risposta troncata, trasferimento di zona, ecc.).
• DoT: DNS over TLS, utilizza TCP sopra TLS, porta predefinita 853 (RFC 7858/8310).
• DoH: DNS over HTTPS, basato su HTTPS (HTTP/2 o HTTP/3), porta predefinita 443 (RFC 8484).
• DoQ: DNS over QUIC, basato su QUIC + TLS 1.3, porta predefinita UDP/853 (RFC 9250, assegnata da IANA su 853/udp).

Relazioni a livelli (modello TCP/IP semplificato)

• Livello Applicazione: HTTP, HTTPS, DNS (DoH è un incapsulamento nel livello applicativo HTTPS)
• Livello di Sicurezza: TLS (fornisce crittografia per TCP o QUIC)
• Livello di Trasporto: TCP, UDP, QUIC
• Livello di Rete: IP
• Livello di Collegamento: Ethernet, ecc.
• Livello Fisico: Cavo in rame / Fibra / Wireless, ecc.

Punti chiave

• Plain DNS opera sopra UDP/TCP senza crittografia.
• DoT = TCP + TLS + DNS (porta dedicata 853).
• DoH = TCP/QUIC + TLS + HTTP(S) + DNS (passa attraverso la 443, condivide la porta con l’HTTPS normale).
• DoQ = QUIC + TLS 1.3 + DNS (porta dedicata UDP/853).

graph TB
    subgraph Livello Applicazione
        A[HTTP]
        A2[HTTPS]
        C[DNS]
        D[DoH DNS over HTTPS]
    end

    subgraph Livello di Sicurezza
        E[TLS]
    end

    subgraph Livello di Trasporto
        F[TCP]
        G[UDP]
        H[QUIC]
    end

    subgraph Livello di Rete
        I[IP]
    end

    subgraph Livello di Collegamento
        J[Ethernet]
    end

    subgraph Livello Fisico
        K[Cavo in rame/Fibra/Wireless]
    end

    A2 --> F
    A2 --> H
    A --> F
    C --> F
    C --> G
    D --> A2
    E --> F
    E --> H
    F --> I
    G --> I
    H --> I
    I --> J
    J --> K

    style D fill:#e1f5fe
    style E fill:#fff3e0

Concetti base e correzioni

• Plain DNS utilizza UDP/53 per impostazione predefinita e passa a TCP/53 quando riscontra una risposta troncata (bit TC) o necessita di un trasporto affidabile.
• DoT stabilisce un tunnel TLS su TCP per trasmettere i pacchetti DNS, porta predefinita 853; può riutilizzare connessioni persistenti per ridurre l’overhead dell’handshake.
• DoH tratta il DNS come una risorsa HTTPS (application/dns-message), solitamente utilizzando HTTP/2 o HTTP/3, porta 443, rendendolo facile da confondere con l’HTTPS normale.
• DoQ utilizza direttamente QUIC (basato su UDP) per trasportare il DNS, offrendo i vantaggi di bassa latenza e di evitare l’head-of-line blocking, ma la copertura dell’ecosistema è ancora in crescita.
• Conclusioni generiche come “QUIC è sempre X% più veloce di TCP” non sono accurate; le prestazioni effettive dipendono dalle condizioni di rete (perdita di pacchetti, jitter, RTT), se la connessione è riutilizzabile, dai dettagli di implementazione e dalla distribuzione lato server.
• DoH non è intrinsecamente “più lento/più veloce perché mette il DNS in HTTP”; le prestazioni dipendono dal riutilizzo della connessione, dalla qualità della rete e dall’implementazione; in molti casi DoH/3 offre un’esperienza simile o addirittura migliore rispetto a DoT.
• DoT può utilizzare SNI per verificare il nome host del certificato; DoH si basa sulla convalida standard dei certificati HTTPS e sulla corrispondenza del nome host.
• Il DNS crittografato può prevenire solo l’intercettazione e la manomissione sul percorso, non equivale a “anonimato completo”. I resolver potrebbero comunque registrare le query; scegliere provider affidabili e consultare le politiche sulla privacy.

graph TD
    subgraph Famiglia DNS
        A[Plain DNS UDP/TCP + DNS]

        subgraph DNS Crittografato
            B[DoT TCP + TLS + DNS]
            C[DoH HTTP/2,3 + TLS + DNS]
            D[DoQ QUIC + TLS 1.3 + DNS]
        end

        subgraph Trasporto di base
            E[TCP]
            F[UDP]
            G[QUIC]
        end
    end

    A --> B
    A --> C
    A --> D

    B --> E
    C --> E
    C --> G
    D --> G
    A --> F

    style A fill:#f3e5f5
    style B fill:#e8f5e8
    style C fill:#e3f2fd
    style D fill:#fff3e0

Panoramica del confronto

Prestazioni e latenza

• Riutilizzo della connessione: DoT/DoH/DoQ possono tutti riutilizzare connessioni persistenti per ridurre i costi dell’handshake; DoH/2, DoH/3 e DoQ supportano anche il multiplexing delle richieste su una singola connessione.
• Head-of-line blocking: TCP soffre del problema di “head-of-line blocking” a livello applicativo; HTTP/2 allevia il problema tramite multiplexing su TCP ma è ancora influenzato dalla perdita di pacchetti TCP, QUIC (DoH/3, DoQ) evita l’head-of-line blocking a livello di trasporto, risultando più amichevole per reti con elevata perdita di pacchetti o mobili.
• Latenza del primo pacchetto: Alla prima connessione DoT richiede l’handshake TCP+TLS; simile per DoH/2; DoH/3/DoQ basati su QUIC sono più veloci nella riconnessione e nella migrazione. Sotto carico prolungato, le differenze dipendono maggiormente dall’implementazione e dalle condizioni di rete.
• Raggiungibilità: DoH utilizza la porta 443, la più difficile da bloccare con semplici blocchi delle porte; DoT utilizza la porta 853, spesso bloccata indiscriminatamente; DoQ utilizza la porta 853/UDP, che attualmente potrebbe anche essere bloccata o non aperta.

Supporto client e di sistema

• Browser: La famiglia Chromium e Firefox hanno DoH integrato come predefinito (possono aggiornare automaticamente a resolver che supportano DoH o utilizzare provider di liste integrate).
• Windows: Windows 11 supporta nativamente DoH.
• Android: Android 9+ offre “DNS privato” (DoT a livello di sistema). La copertura del DoH a livello di sistema dipende dalla versione/produttore.
• Piattaforme Apple: iOS 14+/macOS 11+ supportano DoT e DoH tramite profili di configurazione o NetworkExtension.

Consigli sulla distribuzione e scelta

• Rete convenzionale/restrittiva (es. Wi-Fi pubblico, necessità di superare semplici blocchi): Priorità a DoH (porta 443), abilitare HTTP/3 se possibile.
• Uscita unificata a livello di sistema (router, gateway, DNS privato Android): Priorità a DoT (853), se la rete lo consente, aggiungere DoH come fallback.
• Elevata perdita di pacchetti/rete mobile: Priorità a DoH/3 o DoQ con supporto QUIC (dipende dal supporto del resolver e del client).
• Scenari aziendali/conformità: Selezionare in base alla politica (DoH può integrarsi con l’infrastruttura HTTPS esistente; DoT facilita la separazione del piano di controllo DNS).

Riepilogo

• Prima scelta DoH (443, forte penetrazione), abilitare HTTP/3 se disponibile.
• Se è necessaria un’unificazione a livello di sistema: Priorità a DoT (853) + connessioni persistenti, con fallback a DoH (443) se necessario.
• Se sia il resolver che il client lo supportano: Provare DoQ (l’esperienza sulle reti mobili è spesso migliore).

Standard di riferimento

• RFC 7858, RFC 8310 (DNS over TLS)
• RFC 8484 (DNS over HTTPS)
• RFC 9250 (DNS over QUIC)

Servizi DNS consigliati

• NullPrivate DNS: https://www.nullprivate.com supporta DoT, DoH (supporta HTTP3), supporto nativo per il blocco delle pubblicità e il routing del traffico.
• Versione self-hosted: https://github.com/NullPrivate/NullPrivate

• ←Precedente
• Successivo→