数据中心DNS建设需求分析：

       随着银行业务快速发展、资产规模迅速扩张，业务系统的支撑应对能力格外重要，对银行IT系统建设也提出了更高的要求。目前，全国很多银行在网络架构上逐渐由单数据中心发展到两地三中心，而在多中心的建设过程中原有通过IP访问业务的方式已无法适应新架构快速容灾和切换的需求：
       1、客户如何访问我们的业务？
       2、数据中心业务之间如何相互调用？
       3、数据中心切换如何做到客户无感知？
       4、没有DNS，就没有域名到IP地址的翻译过程？
       5、没有DNS，就没有数据中心业务系统间灵活的调度体系？
       6、没有DNS，切换时难道我们需要让客户修改访问的IP地址？

       业务系统域名化改造注意事项：

       1、C/S架构类型

       现有的Client端程序在连接Server端时采用的是IP，如果修改成域名，那么可能会需要修改Client端的代码并重新发布。如果Client端程序已无法修改，那么则无法完成改造。支持改造的Client端程序，在改造的过程中要注意以下细节：是否在Client程序层面支持缓存DNS解析结果；如果DNS应答域名解析结果是多个IP地址时，如何选择？例如，优先用第1个，如果第1个超时则尝试用第2个？

       2、B/S架构类型

       B/S架构类的业务系统，域名化改造相对简单，在实施域名化改造的过程中要注意以下细节：要注意浏览器自身缓存DNS的机制对业务访问带来的影响。例如域名解析的IP地址已经发生切换，但由于浏览器自身缓存没有过期或者清除导致依旧尝试访问已经存在问题的IP。

       3、应用间互访类型

       当以上这些应用间的互访均采用域名的方式时，各应用模块的容灾调度将变的更加灵活，但应用在域名化改造的过程中必须要考虑“切换接续”的问题。生产中心业务A的web通过域名访问业务A的app，当DNS服务器接到web服务器发来的域名解析请求后，会优先应答生产中心业务A的app服务IP，同城中心访问机制同理；当智能DNS系统通过健康检测发现运行在生产中心业务A的app服务异常时，生产中心业务A的web再向DNS发业务A的app域名请求时，DNS的解析果为同城中心业务A的app服务IP，进而实现灾难场景的切换；在实际的生产案例中，业务系统要结合自身业务特点选择是否“自动切换”、“手动切换”。

       迪讯多数据中心DNS建设原则最佳实践：
       1、数据和服务分离：建立集中DNS数据配置管理平台，分离DNS域名数据配置和DNS服务；
       2、DNS角色分离：使用隐藏的DNS主服务器，将权威服务器和缓存服务器分开；
       3、全局DNS负载：支持智能解析，静态就近性，全局可用性，返回备用IP，轮询等负载均衡算法；
       4、健康检测机制：实时检测服务器健康状态，故障自动切换，充分保证关键业务冗余；
       5、双栈DNS支持：采用IPv4/IPv6双栈共存方式，既同一台域名解析设备支持双栈域名解析；
       6、DNS ANYCAST支持：支持基于OSPF+ANYCAST 技术的DNS架构，支持虚拟IP对外发布业务。
       7、DNS安全扩展：支持定义DNS TSIG，支持EDNS，支持DNSSEC，避免DNS欺骗及漏洞攻击；
       8、DNS安全策略：禁止DNS ANY类型请求，防止DDOS攻击和放大攻击，DNS响应请求限速；
       9、恶意域名过滤：自定义DNS URL过滤，DNS黑名单阻断，识别恶意域名并进行阻断或重定向；
       10、防火墙响应策略：针对域名进行阻断，包括域名不存在、存在无响应、丢弃、域名劫持等；
       11、域名一致性检测：针对域名劫持，对重点域名的资源记录进行监测，出现异常送告警信息；
       12、递归失败转发：在解析失败的情况，转发到第三方可以解析的DNS平台，保证业务连续性。