{"action":"created","issue":{"url":"https://api.github.com/repos/chengr28/Pcap_DNSProxy/issues/395","repository_url":"https://api.github.com/repos/chengr28/Pcap_DNSProxy","labels_url":"https://api.github.com/repos/chengr28/Pcap_DNSProxy/issues/395/labels{/name}","comments_url":"https://api.github.com/repos/chengr28/Pcap_DNSProxy/issues/395/comments","events_url":"https://api.github.com/repos/chengr28/Pcap_DNSProxy/issues/395/events","html_url":"https://github.com/chengr28/Pcap_DNSProxy/issues/395","id":387930632,"node_id":"MDU6SXNzdWUzODc5MzA2MzI=","number":395,"title":"原理、功能：可以用这个方式判断污染域名--又发现一个无解析返回的bug","user":{"login":"Justsoos","id":3480043,"node_id":"MDQ6VXNlcjM0ODAwNDM=","avatar_url":"https://avatars2.githubusercontent.com/u/3480043?v=4","gravatar_id":"","url":"https://api.github.com/users/Justsoos","html_url":"https://github.com/Justsoos","followers_url":"https://api.github.com/users/Justsoos/followers","following_url":"https://api.github.com/users/Justsoos/following{/other_user}","gists_url":"https://api.github.com/users/Justsoos/gists{/gist_id}","starred_url":"https://api.github.com/users/Justsoos/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Justsoos/subscriptions","organizations_url":"https://api.github.com/users/Justsoos/orgs","repos_url":"https://api.github.com/users/Justsoos/repos","events_url":"https://api.github.com/users/Justsoos/events{/privacy}","received_events_url":"https://api.github.com/users/Justsoos/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":18,"created_at":"2018-12-05T20:24:53Z","updated_at":"2018-12-06T19:09:30Z","closed_at":null,"author_association":"NONE","body":"https://dnsparanoia.com/\r\n`dig 任意域名 @dnsp.co`\r\n由于这个网站在wall外，必然通过污染网关。\r\n只要返回不是 123.45.67.89 就说明是被污染的。\r\n在本地维护一个确定被污染域名缓存库，是很有意思的一个方向"},"comment":{"url":"https://api.github.com/repos/chengr28/Pcap_DNSProxy/issues/comments/444991921","html_url":"https://github.com/chengr28/Pcap_DNSProxy/issues/395#issuecomment-444991921","issue_url":"https://api.github.com/repos/chengr28/Pcap_DNSProxy/issues/395","id":444991921,"node_id":"MDEyOklzc3VlQ29tbWVudDQ0NDk5MTkyMQ==","user":{"login":"Justsoos","id":3480043,"node_id":"MDQ6VXNlcjM0ODAwNDM=","avatar_url":"https://avatars2.githubusercontent.com/u/3480043?v=4","gravatar_id":"","url":"https://api.github.com/users/Justsoos","html_url":"https://github.com/Justsoos","followers_url":"https://api.github.com/users/Justsoos/followers","following_url":"https://api.github.com/users/Justsoos/following{/other_user}","gists_url":"https://api.github.com/users/Justsoos/gists{/gist_id}","starred_url":"https://api.github.com/users/Justsoos/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Justsoos/subscriptions","organizations_url":"https://api.github.com/users/Justsoos/orgs","repos_url":"https://api.github.com/users/Justsoos/repos","events_url":"https://api.github.com/users/Justsoos/events{/privacy}","received_events_url":"https://api.github.com/users/Justsoos/received_events","type":"User","site_admin":false},"created_at":"2018-12-06T19:09:30Z","updated_at":"2018-12-06T19:09:30Z","author_association":"NONE","body":"由于以下一些考虑：\r\n第一，对Pcap的核心标准要求，是本地 DNS 代理，或者说，就是本地 DNS。像本贴讨论的 保留地址，其实对很多网络程序是相当重要的。越能模仿一个正常 DNS 公网服务器给出返回越合格。\r\n这是基本出发点。DNS 实际是网络访问最重要的一个部分。\r\n\r\n第二，目前Pcap给出的以第一基本要求来看显得 “怪异” 行为看，本贴内提到，多数和这个 IPFilter.ini 的 [Blacklist] 有关，而【代码逻辑处理问题】即，facebook 的 这个 IP 31.13.65.18 本身是无错的，如果确定某 facebook 域名解析出这个 IP，Pcap 的逻辑将导致这个正确查询是否出错呢？\r\n\r\n其实这个IP当时举例不太好，因为它虽然目前在 wikipedia 的列表里，但并不在 Pcap 的黑名单里，这里就看出这个网站 https://dnsparanoia.com/ 对基本逻辑严格化启发非常有帮助，找到另一个 IP：\r\n\r\n` dig 37.61.54.158.spec.dnsp.co` 这个域名，返回就是前缀的 IP  `37.61.54.158 ` 这个 IP 就在 Pcap 黑名单里。上面这个 dig 命令会导致 Pcap UDP查询超时无返回出错，+TCP 会出现如下拒绝连接的错误。\r\n```\r\n# dig 37.61.54.158.spec.dnsp.co +tcp\r\n;; Connection to fec0:0:0:ffff::1#53(fec0:0:0:ffff::1) for 37.61.54.158.spec.dnsp.co failed: connection refused.\r\n;; Connection to fec0:0:0:ffff::2#53(fec0:0:0:ffff::2) for 37.61.54.158.spec.dnsp.co failed: connection refused.\r\n```\r\n而这个出错，和 https://github.com/chengr28/Pcap_DNSProxy/issues/391 提到的出错**行为**是极其类似的，相当于 Pcap 强硬的拒绝了客户端查询的返回，而不是标准DNS应该有的返回行为，在 Pcap 错误日志里也没有任何表示，这说明 Pcap 没有将此认定为程序错误。\r\n\r\n这个行为首先来说，这不是正常 DNS 应该有的行为，尤其是 污染常用 wikipedia 列表（小数量）和保留地址（大数量）都被放在 `IPFilter.ini ` 文件内情况下，对符合诸多 RFC 标准的查询，Pcap 目前都没有正确返回，而实际上，很多用来作程序开发的程序员对此并不知情，这容易导致相当多严重逻辑误判问题。\r\n\r\n其次，表明 Pcap 对这些 IP 处理并没有考虑**如果确实是一个正确 域名 指向情况下**的代码对 IP 背后 domain name 误杀问题。这不是对投毒过的 domain name 查询的反污染处理，反而是对查询之后 IP 独立进行黑名单，这是 Pcap 对自身功能定位逻辑过于简单化的出错了。\r\n\r\n说句题外话，我本想去 dynu 去注册个主机名，指向任何 `IPFilter.ini` 里黑名单的 IP 地址任何一个，都会引发 Pcap 出错。但这个网站 https://dnsparanoia.com/ 的确很有意思，把大量 dns 上经常出现的问题都考虑到了。这个`.spec.dnsp.co ` 就非常方便，可以返回任何 IP 地址指向，用来测试。\r\n\r\n第三，通过对 Pcap 的研究，发现工作原理，本贴最早一贴其实是个抛砖引玉，鉴于目前 Pcap 的原理，使用的是类似西厢计划的先返回 DNS 包A是污染的，后返回B，C是正确的。 -- 这是个 `与时俱进` 的原理，一旦未来某 wall 确定 drop 掉A，只返回污染的C 呢？我觉得，这个只返回 123.45.67.89 ，建立在海外的伪 DNS，是个非常有意义的用来查询、建立污染域名库的手段。可以内置在 Pcap 里，甚至可以独立成产品。"}}
{"actor":{"display_login":"Justsoos"}}