[~]# /usr/bin/dig +recurs @MYIP www.facebook.com ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.10.rc1.el6_3.5 <<>> +recurs @MYIP www.facebook.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 31758 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;www.facebook.com. IN A ;; Query time: 24 msec ;; SERVER: MYIP#53(MYIP) ;; WHEN: Tue Apr 2 22:39:24 2013 ;; MSG SIZE rcvd: 34 和
options { /* make named use port 53 for the source of all queries, to allow * firewalls to block all ports except 53: */ // query-source port 53; /* We no longer enable this by default as the dns posion exploit has forced many providers to open up their firewalls a bit */ // Put files that named is allowed to write in the data/ directory: directory "/var/named"; // the default pid-file "/var/run/named/named.pid"; dump-file "data/cache_dump.db"; statistics-file "data/named_stats.txt"; /* memstatistics-file "data/named_mem_stats.txt"; */ allow-transfer {"none";}; recursion no; };
这是否意味着我受到基于DNS的攻击的保护？ 像reflection器一样的攻击？
你把你的问题说错了。 适当的措辞就像“我的DNS服务器configuration正确，不放大DNSreflection器攻击？”。 – 这是因为认识到攻击者不会攻击DNS服务器是非常重要的，他们滥用攻击选定的受害者，当我们处理DNSreflection器/放大器types的滥用当然（是的，受害者仍然可以是主机运行DNS，但这是不相干的）。
所以，如果你的问题只是这个，你可以运行tcpdump并比较DNS请求和响应的大小，但是，因为你已经禁用了recursion，这意味着你的服务器不会发送任何与自己区域无关的数据。 但是，如果它所在的区域有一些非常冗长的logging，正如你可能理解的那样，它仍然可以作为放大器（按照定义）对伪造的简短答案做出反应。 虽然攻击者以这种方式使用它会比较困难，但与开放recursion服务器相比，仍然有可能。
缓解这种攻击的唯一正确的方法是从分配开始，在所有可能的级别上实施反恶意保护。 对于单独的DNS服务器来说，通常来说，这太迟了，通常没有办法find它是否对欺骗IP源做出反应。
UPD：实际上，您可以查看有关此主题的IETF备忘录： http : //tools.ietf.org/html/rfc5358