我卡住了。 在美国最近的ISP法律变化之后，我试图利用DNSCrypt。 这是我的设置：
为了testing，我只是想用DNSCrypt来使用OpenDNSparsing器。 我的目标是最终将我的stream量发送到我使用的VPS，然后转发到我想要的DNS服务器。 本地BIND服务器也能够响应内部DNS的查询，这一点很重要。 我有一个区域，我需要能够在内部解决。
我正在执行以下命令来启动dnscrypt-proxy：
dnscrypt-proxy -R cisco -a 127.0.1.2 -d -L /usr/share/dnscrypt-proxy/dnscrypt-resolvers.csv -l /var/log/dnscrypt-proxy -m 6 -p /var/run/dnscrypt-proxy （cisco是在兼容的parsing器列表中预先定义的，这是OpenDNS服务器）。
我可以testing，这与以下命令一起工作：
dig @127.0.1.2 serverfault.com
它返回一个适当的查询。
然后我用127.0.1.2的转发器configurationBIND，这是停止工作的地方。 如果我现在对127.0.0.1运行一个dig命令，我得到一个SERVFAIL错误，但对127.0.1.2挖掘仍然工作。
除此之外，从我的路由器执行pcap会显示大量通过端口53（而不是dnscrypt使用的443）到各个根服务器的出站DNS查询。
所以最终：
forward only;尝试configurationforward only;和recursion no;但似乎不工作）？ recursion no不是你想要的，因为转发本质上被认为是recursion的一个特例。
与forwarders定义和forward only BIND应发送所有recursion查询到您的转发器。
也就是说， options的以下内容应该起作用：
recursion yes; forwarders { 127.0.1.2; }; forward only;
关于SERVFAIL错误，请检查BIND日志以查看实际正在进行的操作。 named-checkconf -zj也可能用于validationconfiguration本身。
这就是说，我确实有一个想法可以解释这个问题。
如果您必须使用OpenDNS，请确保您在BIND中禁用DNSSECvalidation，因为OpenDNS服务与DNSSEC不兼容。
检查（更改）DNS数据的想法基本上与validationDNS数据的真实性不一致，所以我不认为这会改变。