每个人。
我的 ISP 会过滤 DNS 请求。具体是怎么过滤的呢？我不知道。
为了避免（或者至少缓解）这个问题，我在 192.168.3.1 上安装了我自己的 BIND。
这是我的配置：
logging {
channel default_syslog {
print-severity yes;
syslog;
severity notice;
};
};
acl homenets {
192.168.0.0/16;
localhost;
localnets;
};
options {
directory "/var/named";
/*
* If there is a firewall between you and nameservers you want
* to talk to, you might need to uncomment the query-source
* directive below. Previous versions of BIND always asked
* questions using port 53, but BIND 8.1 uses an unprivileged
* port by default.
*/
// query-source address * port 53;
//Lockywolf's edition
recursion yes;
dnssec-validation auto;
dnssec-enable yes;
auth-nxdomain no;
listen-on-v6 { any; };
allow-recursion { homenets; };
};
key DHCP_UPDATER {
algorithm HMAC-MD5.SIG-ALG.REG.INT;
secret "TOP_SECRET";
};
//
// a caching only nameserver config
//
zone "." IN {
type hint;
file "caching-example/named.root";
};
zone "localhost" IN {
type master;
file "caching-example/localhost.zone";
allow-update { none; };
};
zone "0.0.127.in-addr.arpa" IN {
type master;
file "caching-example/named.local";
allow-update { none; };
};
// Lockywolf's added zones
zone "lwfhome" IN {
type master;
file "caching-example/lwfhome.zone";
allow-update { key DHCP_UPDATER; };
// allow-transfer { ns1.namecheap.com; };
};
zone "168.192.in-addr.arpa" IN {
type master;
file "caching-example/168.192.in-addr.arpa.zone";
allow-update { key DHCP_UPDATER; };
// allow-transfer { ns1.namecheap.com; };
};
至少部分配置工作正常。也就是说，我可以解析一些名称，而 www.dnssec-failed.org 返回 SERVFAIL。
但：
已过滤的地址仍在被过滤......但方式很奇怪。
当我请求 dig youporn.com +trace +dnssec 时，我得到了一个完全虚假的答复：
root@server:~# dig youporn.com +trace +dnssec
; <<>> DiG 9.10.4-P4 <<>> youporn.com +trace +dnssec
;; global options: +cmd
. 463433 IN NS e.root-servers.net.
. 463433 IN NS l.root-servers.net.
. 463433 IN NS a.root-servers.net.
. 463433 IN NS g.root-servers.net.
. 463433 IN NS h.root-servers.net.
. 463433 IN NS d.root-servers.net.
. 463433 IN NS b.root-servers.net.
. 463433 IN NS j.root-servers.net.
. 463433 IN NS c.root-servers.net.
. 463433 IN NS m.root-servers.net.
. 463433 IN NS f.root-servers.net.
. 463433 IN NS i.root-servers.net.
. 463433 IN NS k.root-servers.net.
. 517170 IN RRSIG NS 8 0 518400 20170226170000 20170213160000 61045 . ckPc/tLcnZ7g2jyLswmho73QA4WWPe3gUwyKZtbrxRZas70RSTS58P/Z KwTm+lJGJU+B6/9eOOerFv+qQ+hr9e4u/FNp3+bXDHnPYvsdEnxdr1r8 KMnjjw8vXjD8Qm3A8rLcMRD/kRFO6M8EmqZa9WvFSZHg9AF810c0Zuqf wocYLLbmT5JvuShyE0WBNks5a86vhxzNGjeKvoMg2op8yC3V0efSRZK2 uhcKupd0eSRrer3mNfjFLQFD/WGPMXYCFpPjxnwtDiXnevJ7FP2dkFWH rHHuxM10sXEUMvNKtLn7tJewzyJs5RUZdHiDYigsmKvaAsPy3x6GwDLF 7x8hjA==
;; Received 1044 bytes from 192.168.3.1#53(192.168.3.1) in 0 ms
youporn.com. 1026 IN A 213.167.39.27
;; Received 49 bytes from 192.203.230.10#53(e.root-servers.net) in 1 ms
这是谎言，至少因为根服务器不保存有关“youporn.com”的任何信息。而且 IP 也是错误的。
但是，当我调用：dig youporn.com +trace +dnssec +aaonly
答案出奇的正确：
root@server:~# dig youporn.com +trace +dnssec +aaonly
; <<>> DiG 9.10.4-P4 <<>> youporn.com +trace +dnssec +aaonly
;; global options: +cmd
. 463269 IN NS b.root-servers.net.
. 463269 IN NS h.root-servers.net.
. 463269 IN NS d.root-servers.net.
. 463269 IN NS a.root-servers.net.
. 463269 IN NS e.root-servers.net.
. 463269 IN NS k.root-servers.net.
. 463269 IN NS l.root-servers.net.
. 463269 IN NS m.root-servers.net.
. 463269 IN NS j.root-servers.net.
. 463269 IN NS f.root-servers.net.
. 463269 IN NS i.root-servers.net.
. 463269 IN NS c.root-servers.net.
. 463269 IN NS g.root-servers.net.
. 517006 IN RRSIG NS 8 0 518400 20170226170000 20170213160000 61045 . ckPc/tLcnZ7g2jyLswmho73QA4WWPe3gUwyKZtbrxRZas70RSTS58P/Z KwTm+lJGJU+B6/9eOOerFv+qQ+hr9e4u/FNp3+bXDHnPYvsdEnxdr1r8 KMnjjw8vXjD8Qm3A8rLcMRD/kRFO6M8EmqZa9WvFSZHg9AF810c0Zuqf wocYLLbmT5JvuShyE0WBNks5a86vhxzNGjeKvoMg2op8yC3V0efSRZK2 uhcKupd0eSRrer3mNfjFLQFD/WGPMXYCFpPjxnwtDiXnevJ7FP2dkFWH rHHuxM10sXEUMvNKtLn7tJewzyJs5RUZdHiDYigsmKvaAsPy3x6GwDLF 7x8hjA==
;; Received 1044 bytes from 192.168.3.1#53(192.168.3.1) in 0 ms
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 86400 IN DS 30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
com. 86400 IN RRSIG DS 8 1 86400 20170226170000 20170213160000 61045 . UTYkZHzqLF8kqv9+7HVSKaMXwfLPMeLx3YMoU8ZWjTz1FiCjTOFzEp+2 s4hzjucEB7569Ppzru+0UuzTm9tumkSUJoGhBLdfOUi4b6dKTSGb3Ybn GApoSrTGMnMGrtiIApYLhdQ1a9KZ6PaarPwbpOQ6Td+8ClqSCYK3/xdA nyUXCd1qdfYFyC3WPyouoDZsK+Ahc9B2VMnevfB561j5eX2JxNzqnI8a YaVUTrMzKhIL1rK51fRboXcdkVVmJN8eKV/ulXx73W2P2qGNeuuyy9RV MuAFrclZjzrPx2l7AB6Xpy7b9r7SmONc1ekD3RFcXBTF2zEHeepwRSzg bR1L9w==
;; Received 863 bytes from 199.7.91.13#53(d.root-servers.net) in 57 ms
youporn.com. 172800 IN NS ns1.p44.dynect.net.
youporn.com. 172800 IN NS ns2.p44.dynect.net.
youporn.com. 172800 IN NS ns3.p44.dynect.net.
youporn.com. 172800 IN NS ns4.p44.dynect.net.
youporn.com. 172800 IN NS sdns3.ultradns.net.
youporn.com. 172800 IN NS sdns3.ultradns.com.
youporn.com. 172800 IN NS sdns3.ultradns.org.
youporn.com. 172800 IN NS sdns3.ultradns.biz.
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A NS SOA RRSIG DNSKEY NSEC3PARAM
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20170218054619 20170211043619 31697 com. CEbyhokcC5jQBv+v5W2XQt6rpLb6sLXLpAiOf34X2grUTdlMQfbUInmV MDwYVpuK+lK/CSwRrCWvP3k/7QqwsC4AkveIoi3WMfvAZMTkhMV6an2x FH3jeym2vFA3XSYTBaLIE7ut/MzrZci5qfdGqufBB04OcKLhKNKLRI1J HiI=
PUFL8VGRQ3N4TC6QV3G2R207UO9KDLM8.com. 86400 IN NSEC3 1 1 0 - PUFN28L13OQTHBV8S731Q0AG2FJBS4QT NS DS RRSIG
PUFL8VGRQ3N4TC6QV3G2R207UO9KDLM8.com. 86400 IN RRSIG NSEC3 8 2 86400 20170220053808 20170213042808 31697 com. wtNzw5INtkN3aUd90oZJX/i/eQGSb4WG2zcXtIY1QXP1YddWOUhNcU8x kynuuaGJrFPQdskDnDs8w61xhBAL7r4VDii/vAfCIV65KFxHcSL1/GMB KRY5dnUyUfCNnC88zxoIEUqdmiQCLgjpHPgZ1WcaMKOHTTaMY5L0IPeW WXo=
;; Received 885 bytes from 192.54.112.30#53(h.gtld-servers.net) in 25 ms
youporn.com. 300 IN A 31.192.120.44
youporn.com. 86400 IN NS sdns3.ultradns.biz.
youporn.com. 86400 IN NS ns2.p44.dynect.net.
youporn.com. 86400 IN NS sdns3.ultradns.org.
youporn.com. 86400 IN NS ns1.p44.dynect.net.
youporn.com. 86400 IN NS ns3.p44.dynect.net.
youporn.com. 86400 IN NS sdns3.ultradns.com.
youporn.com. 86400 IN NS ns4.p44.dynect.net.
youporn.com. 86400 IN NS sdns3.ultradns.net.
;; Received 264 bytes from 204.13.250.44#53(ns2.p44.dynect.net) in 55 ms
我不明白这个配置。如果 ISP 足够聪明，可以伪造根服务器的签名，那么为什么最后一个命令有效？
如果他们做不到这一点，那么为什么我会看到来自“根服务器”的“youporn.com”的虚假回复。我期望信任层次结构能够一直工作到 youporn 自己的名称服务器，并期望从他们那里收到一个虚假 IP（被 MITM 劫持），但没有，他们已经设法劫持了第一步。
有人能解释一下发生了什么事吗？
答案1
劫持通常并不像你想象的那么具体。ISP 可能不会关心您正在查询哪个 DNS 服务器 – 它们会拦截到端口 53 的所有 UDP 数据包，并且只要查询是youporn.com虚假的，就会返回答复。
除非你设置了额外的标志，使 ISP 的过滤器感到困惑，并让其通过原始查询。例如，查询中的 AA 位实际上是非标准的（dig 中的选项仅仅是剩下的)，所以也许 ISP 的过滤器认为这些查询格式不正确并且不会扫描它们？（同样，在某些地方，只有 UDP 被过滤，而通过 TCP 进行 DNS 查询则工作正常。）
ISP 没有伪造任何签名。请注意，虚假回复没有有一 – 他们只列出了虚假的 A 记录，但没有 RRSIG。
（即使有签名，dig 也不会真正验证这些签名——它的+dnssec选项只是告诉服务器包括首先，dig 会检查签名，但 dig 不会对它们做任何事情。您需要使用drill -S或之类的工具drill -TD来执行客户端验证。
无论如何，DNSSEC只能提醒您有关虚假数据的信息，而不能防止防止数据被伪造。绕过 DNS 过滤的最常见方法涉及加密 - 即 DNS-over-TLS（由 Unbound 支持）或 DNSCrypt（有自己的代理守护程序）。