教育数字化知识图谱

数据中心 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 平台，保证业务连续性。