这是鸟哥网站的工作日志～
终于在 2014 年的 2 月份初期将鸟站移机到新的机器上面，这个新机器使用 4 核 8 绪的 CPU，配合 32GB 的内存，以及保障硬盘数据的硬件磁盘数组， 配合少少的 5 颗 2TB 硬盘，对于我们鸟站这个小站来说，这样的硬件设备是 OK 的了。同时参考 2013 年工作日志里面谈到的， 使用虚拟机还是有不少的好处的。因此，在这个机器设备上面，鸟哥使用了虚拟机， 4 绪 CPU 加上 8G 内存的硬件规模来搭建鸟站所需要的环境。 初期运作状况让人相当满意！除了某些 big5 转 utf8 以及小程序的运作有点出错之外，其余的运作倒是还 OK 的！反应速度也够快。
不过出事了！因为过去都没有仔细研究一下 DNS named.conf 内的 recursive query 的项目，而新 named.conf 内缺省的 recursive 是 yes 的环境， 鸟哥竟然就这样沿用了！但是，这个 recursive yes 的参数，会让所有的 client 都可以通过这部 DNS 来查找数据，这称之为 Open DNS 的设置！就跟 mail server 的 open relay 一样，会导致很严重的后果！
上星期六 (2014/02/15) 鸟哥连进系统操作 http 的相关作业时，发现新站的连接速度好慢，甚至慢到会无法反应！这太奇怪了！用 ssh 连进去瞧一瞧， 要死了！ CPU loading 冲高到 60~70% ，平时几乎都在 10% 以下的～然后用 top 看一下，整个 CPU 性能被 named 占用了！怎么回事呢？ 查找 log 都没有纪录重大的事件啊！那怎办？好～通过 tcpdump 去抓 port 53 看看吧～果然，一堆人在用 port 53 ！随便抓个 1 分钟的 tcpdump 结果数据来分析，log 文件几乎大到几百 MB 了！单纯的抓 port 53 而已ㄟ！怎么可能会这么大？
好吧！在来看看 MRTG 的流量解析结果好了，结果，一看整个人昏倒！竟然流出的流量平均到达 30~40MBytes/s ，这么高个带宽使用量，是要吓死谁？ 赶紧关掉 DNS 然后继续检查，这才发现 recursive yes 会产生的严重问题～之后关掉了 recursive yes 改成 allow-recursive 的设置，只开放某些信任的网域作为 recursive 的方式而已。重新启动 DNS。 不过，要命的是！依旧非常忙碌！虽然 CPU loading 降低到 20% 左右了 (还是比平时高)，但是 log 文件竟然一直长大，12 小时长大了 25GB 左右～ 如果不是隔天有继续关注，恐怕整个 /var 会被冲爆！
为什么会这样呢？由于鸟哥已经关闭了 named 的 recursive 功能，因此当有其他人还想要来做 recursive 的查找时，系统会显示 deny 的作用。 但由于鸟哥的主机已经被锁定了，因此在这 12 小时期间，系统还是一直被攻击的！所以，deny 就一直产生，系统的 log 就一直长大！ 结果除了 /var/log/messages 产生很多的垃圾消息，另外，/var/named/data/* 也产生很多的垃圾消息！要死了！这样系统不死掉才怪！ 好佳在鸟哥以前就遇到过 /var/ 爆表的问题，因此分割上面还有特别将 /var/ 切出来，可以避免出问题啦！所以系统没死掉，不过， 也跟差点死掉差不多了！如何解决啊这问题？
因为一直被攻击，鸟哥又用 tcpdump 去分析一下，果然是攻击 udp 而已。好，那我将 port 53 的 udp 关闭总可以吧？那您会问， DNS 服务会不会死掉呢？好佳在，并不会。因为 DNS 的 udp 连不上的话，就会转以 tcp 连接，因此关闭 udp 并不会让系统死掉！ 太好了，那就直接关闭吧！果然 cpu loading 与 log 都正常了。但是，分析 mrtg 还是发现 input 的流量非常大！不过，至少已经是在比较正常的流量值， 这样应该就不会被鸟哥的 ISP 骂了吧！哈哈哈！
又过了一天， input 的流量终于也恢复正常了！好一个佳在～终于可以正常的提供服务。这时鸟哥也将 port 53 udp 再次的让他放行， 这样也才让鸟站的整体服务通通正常～唉～好不容易啊！以此为鉴，大家要注意 DNS 这服务的正确性喔！ ^_^
