DNS中的ACL機制介紹
試想一下，如果允許遞歸（或查詢）的客戶端太多，而且它們不在同一網段中，那么如何實現配置呢？
如：allow-query { 192.168.241.0/16;127.0.0.0/8;10.0.0.0/8 };，如果allow-recursion {}、allow-transfer{}也都寫一遍相同的內容，非常麻煩。而我們在寫腳本時，可以使用變量、函數等結構化的方式來解決此類問題。而在named.conf中也可以使用這種機制，這就是ACL（訪問控制列表，即若都用到定義這些相同的客戶端，可以講這些客戶端總結放在前頭，並給它取一個名字，以后用到隨時使用即可）。
acl定義方法：（必須先定義才能使用）
定義：
acl ACL_NAME{
IP列表
};
使用如下所示：
acl innet{
192.168.241.0/24;
127.0.0.0/8;
};
allow-query { innet; };
named內置的兩個常用列表：
none;
any;（表示任意）
配置文件中使用：
智能 DNS
中國有兩大網絡運營商：telecom、unicom，電信和聯通兩個網絡有各自獨立的接口。它們彼此之間的網絡沒有結合起來，而是兩個獨立的網絡。而在某個機房中有一個總接口將兩個網絡連接起來了。總貸款大約只有100G。
因此兩個網絡之間的交互會變得非常慢，但在網內的速度會比較快。
若建立一個網站放在聯通機房，那么來自於電信的客戶端訪問速度會很慢。而如果在聯通、電信各放一台服務器，在它們數據同步時仍然會占據很多帶寬，效率很慢。由此可以想到的解決辦法是雙線接入，電信有一根、網通有一根，而后在它們內部使用協議實現路由，因此我們可以在機房中只放一台服務器，只不過可以給它配一個或兩個IP地址，只要服務器或機房本身能夠實現雙線接入那么使用一個IP地址就能連接兩個網絡了。
此時在假設一種極端情況，向淘寶這樣的站點在雙11的時候服務器的壓力是非常大的。有一種緩解服務器壓力的辦法是把全國分成幾個大區，在每一個大區中，不論用戶來自於哪個網絡，假如都是雙線機房放置一組服務器，用戶直接在離自己最近的服務器交易，將來統計有多少筆交易時，可以在最后進行匯總。而交易只需要在離用戶最近的服務器完成即可。
那么回到我們的DNS服務器來說，DNS服務器能夠實現這種每一個用戶訪問的時候都訪問離自己最近的那台服務器的功能嗎？
DNS服務器能夠根據客戶端來源所屬的網絡進行判斷並且返回給用戶一個我們實現定義好的IP地址，這種機制稱為智能DNS。
智能DNS實現機制：DNS在自己的服務器內部可以做視圖（View）。
例：DNS服務器解析域名www.test.com
將所有客戶端來源分成兩類，一類是聯通網的，一類來自電信網的。現在服務器期望來自聯通網的用戶解析www.test.com結果是位於聯通機房服務器的地址，而來自於電信網絡的用戶返回來自電信網絡的IP地址。
實現方法：可以將數據文件切割成兩部分，如果客戶端來自聯通，查找對應聯通的數據文件，電信同理。像這樣使用兩個數據文件分別對應來自不同網絡的請求，由此，可以將一個域名的解析結果一分為二，這種結果稱為（split prain）腦鏈。而只要能夠把客戶端分成幾類，就能提供對應不同的數據文件，如全國可區分成不同地域（湖南聯通、湖南電信、浙江聯通、浙江電信、河南聯通、河南電信...）。
web對象緩存：
在用戶訪問Web頁面請求Web資源的情景之下，當公司內部雙線機房中放置服務器組，在各地網絡中各自放了一個緩存服務器，當用戶第一次訪問離它最近的緩存服務器時，緩存中沒有相關內容，緩存服務器會聯系相應的服務器取得內容並緩存web對象（或頁面）至本地，當同一個網絡當中的第二個用戶來訪問的時候，若訪問的是同一個緩存服務器，則直接從緩存服務器返回結果即可。將來若需要修改直接從原始服務器修改即可。因此雖然第一次請求時可能較慢，但運行一段時間之后，內容都會被緩存到離用戶最近的緩存服務器
而像這種能夠判斷客戶端來源並且返回離用戶最近的服務器並且能夠根據原始服務器取得內容后緩存到本地的這種網絡就稱為CDN（內容分發網絡，Content Delivery Network）。對於Web服務器而言，僅能獲取靜態內容（圖片等），動態內容才需要從原始服務器獲取，而且動態內容絕大部分也能通過策略設定進行靜態化並緩存至本地，所以這種結果速度要快得多了。
CDN有一個重要的前提是：能夠判斷客戶端來源，而且能夠根據客戶端來源返回離它最近服務器地址。而智能DNS就可以實現這樣的功能，因此智能DNS對於現代網絡運營來講是一個比較重要的功能。
模擬實現智能DNS：
假設有兩個網絡：
假定電信網絡地址為：192.168.241.0/24，127.0.0.0、8
其它為電信網絡
那么來自不同客戶端用戶請求同一個域名解析結果，結果是否能夠實現不同呢？
1、安裝配置DNS（需要三台主機模擬實現功能，（一個為DNS服務器，兩台模擬位於不同網絡的客戶端））
2、配置DNS智能解析功能
view VIEW_NAME{
};
注意：一旦使用了視圖，所有的區域都必須定義在視圖中，zone "." IN 只需要定義在需要遞歸的視圖中。
定義兩個視圖，分別表示電信、網通：
#match-clients { any; }; #定義匹配來自什么地方的客戶端
在屬於不同網絡的不同主機上進行測試，查看結果。
實現一台DNS服務器解析多個域，如解析test.com.和a.net.並且a.net.不區分客戶端來源，實現如下：
測試：
DNS服務器啟動完成之后，它會將數據文件直接載入內存，所以其解析過程、查找過程是在內存中完成的，所以其速度非常快。
如果數據文件改動重新啟動需要重新分析並加載數據文件，但若數據文件非常大，速度會非常慢，由此，我們可以把區域的定義不再寫入到配置文件中，而是存放到數據庫的數據表中，DNS啟動時，會將表中的數據抽取出來，存到內存中去，而且新加的內容不用每次都去重啟直接添加即可。哪一個域用到了，臨時去查數據庫得到的結果，而不是直接載入內存；隨時改，隨時生效，不用重新讀取；但每一次讀取都需要查詢數據庫，在內存中可能通過0.0001秒就能完成，而通過數據庫需要10秒才能完成。
所以使用數據庫固然使得管理方便了，但效率降低了，但對於某些公用服務器來講，這是比較常見的做法，如：互聯網上較著名的兩個項目：
- dnspod：中國著名的免費智能DNS提供商。將來注冊域名時，可以將域名服務器指向dnspod服務器，在dnspod上建立記錄實現智能解析，不但能分網，還能分省和分網，如：教育網，聯通，電信，國外；甚至於付費可解析全國各地網絡（在數據庫中建立區域，實時查找）；
- www.dns.la；
dlz：
實現數據文件放在MySQL數據庫的一種機制。
DNS日志系統
啟用DNS日志：
測試：
使用日志記錄BIND的工作機制：
category：日志源
可選項：
- 查詢
- 區域傳送
可以通過category自定義日志來源
channel：日志保存位置
發給syslog：記錄至/var/log/message
file：自定義保存日志信息的文件
定義channel：
需要注意的是，一個日志類別產生的多個不同類別的信息可以發往不同的位置，但每一個位置只能保存來自於一個category的信息（一個category可以被定向到多個channel，但一個channel只能屬於一個category）
定義DNS BIND日志的格式：
示例：
實現在/var/log/下新建一個文件夾bind用於記錄查詢日志：
測試：
記錄傳輸日志：
測試：
這是一個非常具有彈性的日志系統，可以自己定義哪一種信息放置在什么位置。一般來講，查詢日志和安全日志最好不要開啟，因為它們所面臨的日志信息太多，而跟更新相關的信息應該開啟。
日志編寫格式參照：
推薦書籍：
《Bind97 Manual》
《OReilly DNS and BIND 5th(2006)》（學習DNS最經典的一本書）
DNS服務器性能
軟件：
- dnstop
用於監控DNS服務器在每秒鍾能夠接受多少個查詢，而且都是對應哪個域名發起的查詢請求的。
- queryperf
用於對DNS做壓力測試，測試每秒鍾能夠做多少次域名請求。
queryperf使用示例：
安裝開發環境：
至此可使用queryperf命令了；
使用示例：
復制將test文件中的內容若干次（10萬行+）
在另一台虛擬機上測試：
拷貝至測試機：
測試機測試：
dnstop使用示例：
libcap-devel：抓包工具
