> From: Ken A <[email protected]> > What is keeping nameserver vendors from building this into servers?
> > <http://www.opendns.com/technology/dnscrypt/> > > <http://dnscrypt.org/> > > <https://github.com/Cofyc/dnscrypt-wrapper> Preventing men in the middle raises key distribution questions, so I went looking for answers. https://github.com/jedisct1/dnscrypt-proxy/blob/master/TECHNOTES says The following information has to be provided to the proxy: - The provider name (defaults to 2.dnscrypt-cert.opendns.com.) - The provider public key (defaults to the current one for OpenDNS). ... The proxy doesn't cache replies. Neither does it perform any DNSSEC validation yet. This is better handled by a separate process or by linking libunbound. That makes the proxy+stub resolver and all of its implicit practical problems sound a lot like a stub resolver with a copy of the root DNSSEC key doing its own DNSSEC validation. I see commercial advantages in this mechanism to OpenDNS in locking in customers. (I intend no offense to OpenDNS. Every business does and should look for ways to retain customers.) I don't understand why DNSCrypt is better than stub resolvers that do DNSSEC validation. Vernon Schryver [email protected] _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
