Se desideri perfetta segretezza avanzata , devi negoziare una chiave di sessione separata per ogni connessione (o gruppo di breve durata) di connessioni, a seconda dell'implementazione). Non è possibile negoziare una chiave di sessione effimera con un server dei nomi DNS "stupido" (infatti, il protocollo DNS non fornisce nemmeno le primitive necessarie senza un sacco di piegature e mutilazioni). Inoltre, anche supponendo che il server dei nomi DNS stia in qualche modo negoziando una chiave di sessione con l'utente finale, tale chiave deve ancora essere propagata al server dei contenuti effettivo per eseguire la terminazione TLS. Le chiavi effimere sono pensate per essere effimere; non dovrebbero lasciare la RAM, per non parlare di attraversare la rete in questo modo.
I round trip di keying sono inevitabili, a meno che tu non sia disposto a rinunciare alla segretezza. Rinunciare alla segretezza è gravemente indesiderabile, date le rivelazioni di Snowden (che mostravano tra l'altro che la NSA aveva una pratica effettiva di immagazzinare comunicazioni crittografate nella speranza di decifrarle alla fine) e la probabilità di comportamenti simili da parte di altri avversari.
Questo ci lascia solo con il salvataggio del certificato. Ma la realtà è che servire un certificato (o qualsiasi file abbastanza grande) su TCP (il livello di trasporto utilizzato da HTTP (S)) è probabilmente più veloce ed efficiente rispetto a servire su UDP (il trasporto utilizzato dal DNS). UDP richiede all'applicazione di re-inviare manualmente i blocchi persi e di correggere manualmente il riordino o la duplicazione dei pacchetti. UDP richiede inoltre all'applicazione di suddividere manualmente i file in pacchetti (che potrebbero dover essere estremamente piccoli a seconda della rete) e rimontarli. TCP esegue tutte queste cose automaticamente e le tipiche implementazioni TCP sono strongmente ottimizzate per il trasferimento di file (ad esempio, TCP ridimensiona automaticamente i pacchetti per adattarsi al meglio al congestionamento del collegamento di rete sottostante). UDP ha ancora senso per trasferimenti best-effort di messaggi molto brevi come le query DNS, ma il trasferimento di un intero certificato firmato sarebbe probabilmente più lento su DNS rispetto a HTTP / HTTPS.
Naturalmente, c'è anche il problema del caching e dell'indirizzamento indiretto. È estremamente comune per gli utenti comunicare con nameserver DNS non autorevoli (ad esempio, quelli forniti dal proprio ISP). In teoria, questi nameserver dovrebbero restituire gli stessi risultati delle loro autorevoli controparti, o interrogandoli direttamente ( in modo ricorsivo se necessario) o memorizzando nella cache i risultati delle query precedenti fino a un time-to-live (TTL) configurabile. In pratica, spesso si discostano dallo standard, ad esempio in uno o in tutti questi modi:
- Dirottamento di NXDOMAIN (restituendo un indirizzo IP "falso" invece di un errore per ricerche di domini inesistenti, che di solito portano all'utente a visualizzare annunci vagamente correlati al nome di dominio).
- Non rispettando il TTL (memorizzazione nella cache per un periodo di tempo superiore a quello previsto)
- Ignorare, rilasciare o pubblicare errori per richieste che non sono comunemente emesse da normali browser Web (es. richieste di record TXT ).
- Il supporto e l'uso effettivo di DNSSEC varia sostanzialmente per ISP e per regione .
È difficile mettere in pratica qualsiasi "furbo DNS" quando metà dello standard non è implementato correttamente da una parte sostanziale dei tuoi clienti.