今天被 BIND 的一个报错折腾了一整天。 有大量的类似于 Aug 19 10:49:25 bj48-144 named[32158]: client XX.XX.XX.XX#53037: RFC 1918 response from Internet for 15.86.168.192.in-addr.arpa
这样的 LOG 生成直接填满了硬盘分区,导致机器基本崩溃。
经查询,得知 Recursive DNS server 在遇到内网 IP 等不应该被反解的 IP 的反解查询的时候,就会报这个警告,而晚上刚刚好有一批机器因为某种原因大量进行了内网 IP 的反解查询。
解决方法是屏蔽掉所有的内网查询,不让 BIND 试图去做 Recursive lookup:
// Private Use Networks (RFC 1918) zone "10.in-addr.arpa" { type master; file "empty"; }; zone "16.172.in-addr.arpa" { type master; file "empty"; }; zone "17.172.in-addr.arpa" { type master; file "empty"; }; zone "18.172.in-addr.arpa" { type master; file "empty"; }; zone "19.172.in-addr.arpa" { type master; file "empty"; }; zone "20.172.in-addr.arpa" { type master; file "empty"; }; zone "21.172.in-addr.arpa" { type master; file "empty"; }; zone "22.172.in-addr.arpa" { type master; file "empty"; }; zone "23.172.in-addr.arpa" { type master; file "empty"; }; zone "24.172.in-addr.arpa" { type master; file "empty"; }; zone "25.172.in-addr.arpa" { type master; file "empty"; }; zone "26.172.in-addr.arpa" { type master; file "empty"; }; zone "27.172.in-addr.arpa" { type master; file "empty"; }; zone "28.172.in-addr.arpa" { type master; file "empty"; }; zone "29.172.in-addr.arpa" { type master; file "empty"; }; zone "30.172.in-addr.arpa" { type master; file "empty"; }; zone "31.172.in-addr.arpa" { type master; file "empty"; }; zone "168.192.in-addr.arpa" { type master; file "empty"; };
当然,其实需要屏蔽的反解查询不止这些。在这里有一个比较完整的列表。
这件事情给我的教训是, DNS 的错误,不出则已,一出,必定会产生大量的 LOG, 因为 DNS 的查询实在是太多了。所以一定不能吧 named 的 log 直接丢给 syslog 还不做 rotate, 最好独立出来单独的 LOG 文件并且做好 rotate 或者磁盘监控。
What does "RFC 1918 response from Internet for 0.0.0.10.IN-ADDR.ARPA" mean?
zone "10.IN-ADDR.ARPA" { type master; file "empty"; }; zone "16.172.IN-ADDR.ARPA" { type master; file "empty"; }; ... zone "31.172.IN-ADDR.ARPA" { type master; file "empty"; }; zone "168.192.IN-ADDR.ARPA" { type master; file "empty"; };If the IN-ADDR.ARPA name covered refers to a internal address space you are using then you have failed to follow RFC 1918 usage rules and are leaking queries to the Internet. You should establish your own zones for these addresses to prevent you querying the Internet's name servers for these addresses. Please see http://public.as112.net/ for details of the problems you are causing and the counter measures that have had to be deployed.
If you are not using these private addresses then a client has queried for them. You can just ignore the messages, get the offending client to stop sending you these messages as they are most probably leaking them, or setup your own zones empty zones to serve answers to these queries.
empty:
@ 10800 IN SOA <name-of-server>. <contact-email>. ( 1 3600 1200 604800 10800 ) @ 10800 IN NS <name-of-server>.
Future versions of named are likely to do this automatically.