單位有3個域名，用量很大，2014年開始本人研究部署了Bind+DLZ +Mysql的三機智能多鏈路DNS，非常好用，優點是：
1、使用Mysql管理記錄，配置、管理、查詢方便。
2、自動判斷運營商，返回指定IP，實現智能多鏈路。目前我們單位有電信、移動、教育網專線和固定IP，通過Bind的View，判斷請求源IP自動返回對應運營商的服務IP。很好很強大也很實用。
3、根據配置自動為內網分配對應的運營商解析。。。我單位內網用戶較多，有一個不少見的需求，內網部分用戶要使用電信專線、部分用戶要使用移動專線，然而走電信的就得用電信DNS解析、走移動就得用移動DNS解析，同樣的，Bind的View也很好的解決了這個問題。
然而、、、、、今天突然讓我崩潰了，有2、3個域名外網訪問部分出錯、打不開網頁。我仔細研究，發現外網被解析成了內網IP。。。如下圖：
這讓我很頭疼呀，仔細分析，把Bind從Dump緩存、Config文件、ACL文件全部翻了個遍，沒發現問題。。。。。這個問題的狀況是這樣的：只有2、3個域名有這個問題，其它子域名（近幾十個）都沒問題。。。。
很奇葩，我都有點懷疑跟服務器有沒有關系呀。。。。。
折騰2、3天沒搞定，也沒想通。。。今天晚上從路由器入手打算再走一遍，我手頭有3個路由器，一行行看配置，終於找到點眉頭，被解析錯誤的地址，我在其中一個路由器上做了NAT回流。。。
好吧，什么是NAT回流？這里簡單講講，詳細的大家上網搜吧，就是我做了nat server，比如： nat server protocol tcp global X.X.X.X any inside 192.168.200.57 any。這時外網用戶通過X.X.X.X的公網IP、內網用戶通過192.168.200.57的IP分別可以訪問對應的服務，當然主要是用DNS了，但是如果我內網里有人用X.X.X.X的公網IP去訪問呢？這時正常、默認的NAT配置是訪問不了了，詳細我也不說了，搜到這篇文章的興許就是這個故障，這時就要做一個NAT回流，讓路由器從內網過來的訪問公網IP請求能夠像在外網一樣訪問，這時配置NAT回流就可以，我是這樣弄的（路由器是H3C的）：
1、先搞個回流的ACL。。。我的故障就在這里了，一會說。
acl number 3010
rule 5 permit ip source 172.16.0.0 0.0.255.255
rule 6 permit ip source 172.17.0.0 0.0.255.255
rule 7 permit ip source 172.21.0.0 0.0.255.255
rule 8 permit ip source 172.22.0.0 0.0.255.255
rule 15 permit ip source 192.168.0.0 0.0.255.255
rule 100 deny ip
2、在內網接口上配置，注意是內網，而不是外網。
interface GigabitEthernet2/2/0
port link-mode route
nat outbound 3010
nat server protocol icmp global X.X.X.X inside 192.168.200.57
nat server protocol tcp global X.X.X.X any inside 192.168.200.57 any
ip address 10.10.248.1 255.255.255.252
那為什么這個回流會導致外網解析到了內網IP呢？？？原因是我在做Acl的時候，當時只是為了測試一下這個200.57的業務內網用公網IP訪問，就簡單的內網IP都給Permit了，這個配置NAT回流是可以了，但由於沒有匹配目標IP，導致所有包都能回流，導致內網的DNS回傳給外網DNS服務器的響應包識別為是內網地址段來的，就丟了個內網IP給人家運營商服務器。。。把上面Acl改完善就OK了，完整的應該是這樣：
rule 5 permit ip source 172.16.0.0 0.0.255.255 destination 192.168.200.57 0
rule 6 permit ip source 172.17.0.0 0.0.255.255 destination 192.168.200.57 0
rule 7 permit ip source 172.21.0.0 0.0.255.255 destination 192.168.200.57 0
rule 8 permit ip source 172.22.0.0 0.0.255.255 destination 192.168.200.57 0
rule 100 deny ip
也就是嚴格匹配內網地址段 to 內網需要NAT回流的服務器內網地址。。。這樣對這台的NAT回流也正常（內網用它的公網IP也可以訪問）、同時也不會出現BIND解析出錯的問題。。。
當然如果你不提供像我的這個智能BIND解析服務，那你就像上面那個籠統的ACL也是可以的。。。我這是兩個功能在一起就沖突了的。
2016-11-18補充：
后來發現，其實光ACL也沒用，還是會這樣呀。。。。。苦苦研究一個多月，最終在廠商工程師的幫助下解決了問題，原來是路由器的DNS-ALG在作怪，H3C路由器V5平台下ALG功能默認是開啟的，而V7下默認是關閉了就沒這問題。我的是V5，得手動關閉一下：系統視圖下：undo alg dns
解決問題了。。。。OK，那么alg dns是什么鬼呢？來看看：
NAT ALG 功能，僅在要通過NAT 設備進行DNS、FTP、SIP 和RTSP 等應用（如DNS 服務器在公網中，需要在內網中使用域名訪問位於內網的服務器時）時，需要配置NAT ALG 功能。使能ALG 功能可以使NAT 設備識別被封裝在報文數據部分的IP 地址或端口信息，並根據動態形成的NAT 地址（或同時包括端口號）映射表項進行替換，使報文正常穿越NAT。
所以呢，nat server只在inbound生效，應該是報文從內網返回命中內斂口，出去了返回的是私網解析。。。
至此，該問題徹底解決。。。