10萬域名求自建DNS解決方案？

公司現在有10w個域名，目前使用的第三方DNS服務，但更新記錄手動加域名等等是一項巨型工作。所以目前我們打算自己部署DNS伺服器，我想到使用Bind架設但是他默認是基於zone files方式記錄如果加成千上萬的域名在文件夾內會有數10w的文件這樣是不現實，文件數會受系統限制。Bind如果使用mysql的話性能方面會不會很差？

題主應該是在域名註冊商所在的公司上班吧。

很有幸我主導過超大型第三方dns開發（CloudXNS - 免費智能DNS解析服務）, 支持海量域名，100多條解析線路，還有很多私有記錄，整體系統工作得很好。

我介紹下cloudxns其中系統架構的衍化過程，應該能減少題主的彎路。

2009-2011年，我所處在的CDN公司有不少CDN客戶將DNS解析直接託管給我們，和CDN的權威DNS混在一塊管理（此時CDN的權威DNS也是用BIND），這樣的託管數量少沒有問題，數量多了 1) 影響CDN調度解析數據的下發速度，2) 也容易產生管理混亂, 3) 由於沒有用戶界面，客戶用郵件形式通知修改，實際修改由運維同事處理，增加運維工作量。

2011-2012年，域名託管數量一直在增加，我們團隊就開始著手對這類業務拆分到一個新項目cloudxns。起初，我們用BIND+DLZ+NOTIFY+AXFR來做底層支撐，DLZ是讓BIND從資料庫動態讀取解析配置的一個模塊。

BIND+DLZ會讓DNS解析查詢性能下降到不用DLZ的1/10甚至更多（4-5K QPS），但為了給用戶提供一個WEB界面，有個資料庫的底層支撐會節省很多工作量，因此我們只用BIND+DLZ做master, 僅提供SLAVE的AXFR複製查詢，不對外提供實際DNS解析查詢； DLZ的mysql數據和WEB系統打通，WEB系統將用戶填寫的數據實時寫到mysql, 然後出發notify通知SLAVE自動化過來AXFR拉取新版本的DNS配置文件。

這個第一個版本的CloudXNS系統做到了：
1）客戶自助解析
2）「實時生效」（域名*線路少時候1分鐘之內，域名*線路多就不確定了）
3）SLAVE的性能沒有打任何折扣（10萬-20萬QPS）

本來以後可以就此打住了，但是這樣架構僅僅支撐了半年，我們又開始進行了新的征程。
原因：
1）既然已經有成型的產品，而且原有域名託管用戶轉到自助的CloudXNS上還總體比較滿意。
2）恰恰中國雲計算市場在此時開始高歌猛進佈道之時，做為網路入口的域名解析，開始成為各大巨頭要爭的戰略要地。
那麼CloudXNS也就被順利成章包裝出去運營，接來下用戶數量進一步增加，域名解析行業無法繞過的劫數，黑客軍團的時不時利用DDOS攻擊也開始向我們「宣戰」了。BIND+DLZ+NOTIFY+AXFR方案什麼時候會停擺掛掉，一直是像高懸在我們頭頂一把利劍。

2012-2013年， 我經過一段時間的痛苦掙扎和不斷反思，終於決定要放棄BIND, 重新實現一個海量第三方域名解析伺服器。

BIND
VIEW*ZONE模型，也就是線路*域名的意思，線路多了，數據冗餘很大，如何降低冗餘，提高zone_transfer效率，比如很多用戶整個東北地
區都是一個解析，但有少部分用戶東北每個省有各自的解析，那麼多大部分用戶按VIEW*ZONE進行zone_transfer將有大量的重複冗餘數據。

要解決的問題（這些問題限於篇幅我就不講了解決的細節了，大家有興趣可以登錄CloudXNS - 免費智能DNS解析服務）：
1） 如何組織用於解析配置傳輸的數據結構模型最有效
2）如何實現界面配置後秒級生效，更重要的是如何做到和託管的數量級沒有關係
3）如何實現一個兼容超精細解析（省*運營商）和普通精細解析（到運營商級別）用戶需求的系統。
4）如何將DNS性能大幅提高，盡量逼近網卡限速。

技術選型：
1）內核模塊,（當初的想法是：路由器那麼高的性能，為什麼不能把dns伺服器當路由器來做？）
2）dpdk（intel剛剛推出的新技術，不是第一個吃螃蟹，也是第一批沒有先後的吃螃蟹人）
綜合各因素和團隊成員，我們最終選型是用內核模塊來實現下一版本的CloudXNS伺服器。

經過整個團隊（加我自己，3個C工程師+1.5PHP工程師）3個月的連續奮戰，我們順利攻克了各個
問題並成功上線，做到了當時國內的各項指標的極致。
1）生效速度（解析填寫到權威解析生效），0.5秒
2）解析配置線路可伸可縮，兼容精超細解析需求和普通精細解析用戶（支持線路130多個）
3）單機性能到達350萬QPS（實際業務環境由於加了其他一些功能，有所下降）

2014-2015 軟體上沒有進行大架構調整，僅進行產品功能迭代，界面改版。開始安排專業運營人員進行運營，知名度也慢慢起來了，有大量知名互聯網企業大量使用CloudXNS。

此時由於用戶量增加（50億次解析量每天），攻擊的規模和頻次大幅攀升，
這時DPDK技術也開始成熟起來了，CloudXNS也開始著手DPDK版本的研發，畢竟內核模塊的性能還沒有到達網卡限速，而DPDK更容易達到這個目標，這也是抗攻擊的最大手段了（除了增加伺服器之外）。

2015-2016 再後來我離開了這家公司，我原來的團隊在繼續努力，做的還不錯（快100億每天的解析量了）。