通过阻止查询和响应来保护DNS [Dnscrypt问题]

Question

访问facebook.com时，您将查询s.update.fbsbx.com。s.update.fbsbx.com是s.agentanalytics.com的CNAME。目前，阻止s.agentanalytics.com的唯一方法是通过主机阻止s.update.fbsbx.com。Windows DNS客户端，甚至通配符阻塞解析器(如Dnscrypt )，也无法阻止CNAME回复的父域。

13:19:30 dnsmasq[1211]: query[A] s.update.fbsbx.com from 192.168.50.142
13:19:30 dnsmasq[1211]: forwarded s.update.fbsbx.com to 127.0.0.1
13:19:30 dnsmasq[1211]: reply s.update.fbsbx.com is 
13:19:30 dnsmasq[1211]: reply s.agentanalytics.com is
13:19:30 dnsmasq[1211]: reply agentanalytics.com is 52.20.233.11
13:19:30 dnsmasq[1211]: reply agentanalytics.com is 35.170.177.215
13:19:30 dnsmasq[1211]: reply agentanalytics.com is 34.235.44.232
13:19:30 dnsmasq[1211]: reply agentanalytics.com is 34.194.252.192
13:19:30 dnsmasq[1211]: reply agentanalytics.com is 18.206.130.128
13:19:30 dnsmasq[1211]: reply agentanalytics.com is 52.202.107.183
13:19:30 dnsmasq[1211]: reply agentanalytics.com is 18.209.97.44
13:19:30 dnsmasq[1211]: reply agentanalytics.com is 35.173.82.169
13:19:30 dnsmasq[1211]: reply agentanalytics.com is 23.22.178.204
13:19:30 dnsmasq[1211]: reply agentanalytics.com is 18.206.103.1

有时，有多个CNAMES在答复中揭示了它们实际隐藏的联系，例如：

13:55:28 dnsmasq[26607]: query[A] su.itunes.apple.com from 192.168.50.96
13:55:28 dnsmasq[26607]: forwarded su.itunes.apple.com to 127.0.0.1

13:55:29 dnsmasq[26607]: reply su.itunes.apple.com is 
13:55:29 dnsmasq[26607]: reply su-cdn.itunes-apple.com.akadns.net is 
13:55:29 dnsmasq[26607]: reply su-applak.itunes-apple.com.akadns.net is 
13:55:29 dnsmasq[26607]: reply su.itunes.apple.com.edgekey.net is 
13:55:29 dnsmasq[26607]: reply e673.dsce9.akamaiedge.net is 184.50.162.217

13:55:29 dnsmasq[26607]: query[A] xp.apple.com from 192.168.50.96
13:55:29 dnsmasq[26607]: forwarded xp.apple.com to 127.0.0.1
13:55:29 dnsmasq[26607]: reply xp.apple.com is 
13:55:29 dnsmasq[26607]: reply xp.itunes-apple.com.akadns.net is 
13:55:29 dnsmasq[26607]: reply xp.apple.com.edgekey.net is 
13:55:29 dnsmasq[26607]: reply e17437.dscb.akamaiedge.net is 23.214.192.96

例如，DNSCRYPT允许通配符阻塞传出域查询，但它不会自动阻止传入响应，也不会自动阻止s.agentanalytics.com ips的缓存。或者，如果在windows主机中阻止s.agentanalytics.com，或者使用dnscrypt，它仍然可以通过s.update.fbsbx.com访问。

我向他的编码器展示了这个分析域是如何绕过他的通配符保护的，他告诉我"这些条目不在父区域内，并且被所有存根解析器忽略。“和在这里，他讲的更详细。

他还说，“我认为你对dnsmasq是什么日志感到困惑，这是非常令人困惑的。这里只有一个问题A s.update.fbsbx.com和一个匹配的CNAME s.update.fbsbx.com响应，其余的都是解析器忽略的垃圾，因为它不在父区域。”

但是，如果robtex和dnsmasq演示了它包含分析域s.agentanalytics.com https://www.robtex.com/dns-lookup/s.update.fbsbx.com

如果这些IP被存根解析器忽略，那么首先不会缓存这些IP。我也很好奇，这些IP中的一些是否有可能被一个缔约国/MITM的正如这里所建议的在Facebook上浏览时使用，我在C6中看到了s.update.fbsbx.com，那么除了s.agentanalytics.com ip地址以外，这个域会与什么ip相关联呢？当然是s.agentanalytics.com。

简单地说，s.update.fbsbx.com是由dnscrypt和dnsmasq等使用的，而不是s.agentanalytics.com，但是它指向的是与s.agentanalytics.com相关的IP。

如果DNSCRYPT通配符块拒绝缓存这些CNAME ip响应并阻止它们的父域，则可以更好地保护它们的网络安全。

问题很明显，<#>am我的断言不正确，我遗漏了什么吗？

这里还有另一个例子，当Iphone立即连接到WIFI时，会发生21个查询，响应包括72个不属于父域的域&IP。他说这一切都被忽视了。

给你，https://pastebin.com/GYSEw1dY

Answer 1

我是对的。DNSCRYPT的开发人员亲自给了我一个答复，即：

名称黑名单适用于传入的查询。如果有匹配，则不会将任何内容转发给上游解析器。他们不会知道客户问了其中一个名字。反过来说，对于CNAME的回应没有被检查，记录可能与黑名单相匹配。这可能不会实现，但您可以做的是阻止IP地址，因为这些规则适用于响应。

SRC：https://github.com/jedisct1/dnscrypt-proxy/issues/900#issuecomment-516693295