[dns-operations] DNSCrypt.

[Vernon Schryver]

> From: Ken A <ka at pacific.net>

> 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    vjs at rhyolite.com