這是鳥哥網站的工作日誌～
終於在 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 這服務的正確性喔！ ^_^
