Se DNSSEC è così discutibile, perché è in anticipo rispetto a DNSCurve in adozione?

C'è un problema:

DNSCurve è più simile a TLS per i server DNS, rispetto a DNSSEC, che è record firmati . DNSCurve utilizza la crittografia point-to-point per proteggere le comunicazioni, mentre DNSSEC utilizza le firme precalcolate per garantire l'accuratezza dei record forniti.

Quindi possiamo riassumerlo in questo modo:
DNSSEC : risultati accurati
DNSCurve : traffico crittografato

In teoria è possibile utilizzare la crittografia del traffico per garantire la precisione, come fa TLS per i siti Web. Tranne che non è proprio la crittografia che garantisce la tua precisione, è l' autenticazione fornita attraverso l'infrastruttura PKI. E c'è una serie di problemi critici con il DNKurve PKI di base.

Il primo problema qui è che con DNSCurve, ogni server DNS coinvolto necessita di una chiave privata , e poiché la firma della chiave è codificata nell'indirizzo del resolver, quindi nel caso di server DNS anycast ogni server ha bisogno della stessa chiave privata . Ma anche se usano chiavi diverse, ti stai ancora affidando alla sicurezza locale dove è installato il server DNS. Se il server è installato da qualche parte in modo ostile, i risultati possono essere compromessi. Questo non è vero con DNSSEC.

ICANN ha dichiarato che, nel caso dei server della zona radice DNS, DNSCurve non verrà implementato, mai. Molti server di root operano in posizioni meno affidabili e il potenziale di abuso da parte dei governi locali sarebbe enorme. Questo è esattamente il motivo per cui DNSSEC è stato progettato in modo tale che la firma avvenga fuori dal server DNS. Il DNS si basa su una vasta rete di server che potrebbe non essere affidabile, quindi DNSSEC è stato progettato in modo tale che il trust si basi esclusivamente sulle informazioni che servono, non sull'onestà dell'operatore.

Il secondo problema è che DNSCurve protegge la chiave pubblica codificandola nel nome del resolver. Ma DNSSEC non firma il nome del resolver. Ciò significa che DNSSEC (che è implementato nella zona radice) non può essere utilizzato come trust trust per DNSCurve, perché l'unica cosa che DNSCurve richiede di essere accurata è in effetti la stessa cosa per cui DNSSEC non può assicurati la precisione.

Quindi essenzialmente DNSCurve è praticamente un antipasto. Sebbene possa essere usato per garantire la sicurezza della tua comunicazione con un singolo risolutore DNS, attualmente non c'è modo di ancorare globalmente la tua fiducia in un modo che possa garantire l'accuratezza dei risultati che ottieni.

A meno che DNSCurve sia stato riprogettato per consentire la distribuzione delle chiavi attendibili, dovrà rimanere uno strumento di sicurezza lato client piuttosto che uno strumento per garantire l'autenticità dei record DNS.

Dato che DNSCurve è relativamente nuovo ed è stato sviluppato in gran parte da djb in isolamento, presumibilmente questi problemi di show-stopping sono stati semplici sviste da parte sua e potrebbero essere risolti in una data futura. Sebbene abbia tenuto conto del dott. Bernstein del mantenimento delle sue invenzioni, non terrei il respiro.

Il motivo principale è che DNSSEC era già stato adottato dai principali server root quando DNSCurve è uscito. Inoltre non affrontano gli stessi problemi, si sovrappongono su alcuni punti ma si differenziano sugli altri. Potrebbero benissimo essere usati insieme.

Si noti che abbiamo avuto una domanda DNSSec (Comcast) vs DNSCurve (OpenDNS) che descrive molto bene le differenze:

First of all, DNSSEC does NOT sign your queries. Rather DNSSEC allows a zone (such as a domain) to be signed by its owner, and allows a resolver (for instance, Comcast's DNS servers) to verify the signature, and therefore be sure that the zone data it gets is authentic. It protects the resolver from receiving bad data, but does nothing to prevent MITM or snooping between you and the resolver.

DNSCurve on the other hand encrypts communications between recursive resolvers and authoritative servers and allows authoritative servers to sign their data against forgery, but does nothing to protect an end-user client from a bad recursive resolver. OpenDNS's DNSCrypt solution is based on the same technology as DNSCurve, but protects the last-mile between a trusted 3rd party recursive resolver like OpenDNS and the end-client.

As for which is more secure, neither is. They are both secure, however the security is applied in different areas. In either case you are picking which aspect of DNS security is more important, rather than which security tool is stronger.