当金融机构逐步向多数据中心架构演进时，敏捷的灾难切换恢复能力变得至关重要，如何在保证生产数据或存储一致性的基础上在各数据中心间调度流量，确保业务的持续运行和快速恢复，已成为行业的关键需求。域名解析系统（DNS）作为这一需求的核心支撑，已经从简单的域名到IP地址的映射，转变为数据中心流量管理和调度的关键枢纽。近些年陆续发生数据中心内网域名解析系统故障，引发大面积网络瘫痪及业务中断，如何防范和应对域名解析系统故障，做好域名解析系统高可用架构、容灾机制和应急预案的设计已成为数据中心技术团队关注的焦点，今天我们就讲讲G行数据中心域名解析系统设计思路及思考。
本篇文章会从系统架构到策略配置逐步展开，带领大家一步一步了解G行域名解析系统架构是怎么形成的，其中涉及一些DNS技术专业术语，可以参考另外两篇基础文章《浅谈DNS域名解析系统》和《浅谈DNS域名解析系统之Local DNS》，本文不再赘述。
一、架构设计
“凡事预则立，不预则废”，对于构建足以影响整个数据中心运转的全局类网络域名解析系统时，第一步需要考虑的就是整体可用性，要保证系统部分故障不影响整体对外的服务能力，这就要求设计的系统架构具备低耦合、高冗余特性，同时建议支持产品异构部署。
DNS的协议标准非常灵活，根、权威、递归服务器等角色，可以独立部署，也可以部署在同一台服务器上。对于大型数据中心，从健壮性和容量的角度思考，还是需要对各层角色进行解耦并独立异构部署，充分利用域名解析系统各个角色的特性。从同业的调研中，也证实了这一点，大型企业级数据中心多是根、权威、递归服务器分角色部署的方式。整个分层解耦架构设计示例如下：
根、权威、递归分层，每个角色服务器都在多中心分布式部署。
01 根服务器（Root Server）
根服务器采取高冗余分布式部署，每个数据中心至少部署两台根服务器，从而应对本地数据中心单台设备故障，同时提供数据中心级冗余能力。
02 权威服务器（Name Server）
权威采用多级授权的方式，根授权一级域名的权威服务器，一级域名的权威服务器授权二级域名的权威服务器，以此类推。各级权威服务器可以通过增加授权进行横向扩容。二级域名权威服务器可以授权给需要域名自主权的系统自行管理。如全栈云平台、域控、内网CDN平台、子机构等等。
03 递归服务器（Local DNS server）
考虑办公和生产属性的不同，递归服务器采用办公和生产的独立的方式进行部署，分别为办公终端和生产服务器提供域名解析服务，办公递归服务器引入不同信创产品和非信创产品进行异构部署。
G行递归服务器每个节点采用负载均衡集群部署，这样设计有许多优点：
二、域名规划
域名规划可能是域名解析系统可持续的关键，一个好的域名架构规划可以实现清晰的上下级域名关系、区分管理职责、灵活的扩容和拆分等等，这里我们主要考虑动静区份、内外区分和风险隔离租户区分三个关键因素，以支持多数据中心的业务需求：
01动静区分
“动静”指动态域名和静态域名。在高可用架构中，通常通过域名解析系统来实现应用系统的高可用，域名服务器根据客户端请求所在的位置来动态解析出不同的IP地址，或者通过轮询方式解析多个IP地址实现多活系统服务IP的负载均衡，又或者需要通过域名切换地址来实现应用系统的主备切换能力等等。借助域名解析系统健康检查监控和智能解析算法来实现单个域名和多个IP地址绑定关系的域名，叫做动态域名。相对的，域名和IP地址做简单绑定的域名叫做静态域名。
动态域名需要域名解析系统消耗更多的资源，包括实时的健康检查策略、负载均衡、拓扑算法等智能解析算法等等。在架构设计的考量中，动态域名将来可能成为系统性能的瓶颈，为了便于独立部署，明确的动态域名应该使用独立的子域，如内网CDN系统、多AZ的全栈云系统等等。
02内外区分
“内外”指内网域名和互联网域名，互联网DMZ区的服务器通常存在既访问内网又访问互联网的需求，为避免内外网域名混淆，应避免内网和互联网使用同一个一级域名。而纯内网环境应该与互联网完全隔离，不具备解析互联网域名的能力。
03风险隔离租户区分
独立的机构域名建议使用独立的子域，比如分行、信用卡或者子公司，后续如果出现单机构业务发展过快或者管理架构调整的情况，可以方便进行独立拆分。
综上，整体域名规划如下：域名由根域名（“.”）进行授权，数据中心内部使用统一的一级域名，名字应该与互联网域名有所区分，二级域名按照机构区分，三级域名根据动静态使用区分，可以根据功能再划分子域。
三、策略设计
01智能解析机制
域名解析系统的智能解析能力是数据中心实现业务多活的基础能力，通俗的说，智能解析是域名解析系统依据用户属性，结合对系统服务状态的监测，返回相应的服务IP地址的能力。典型的使用场景如“近源访问”：
应用系统在两个数据中心都提供相同的服务，不同的数据中心发布不同的服务地址，需求是发布同一个域名，用户访问这个域名的时候能够访问到离自己物理位置最近的数据中心的服务节点，如果这个服务节点故障，则自动访问到另一个数据中心的服务节点，用户对访问到哪个数据中心服务节点无感知。
“近源访问”的典型HTTP/HTTPS应用如“CDN内容分发网络”。“近源访问”可以大大减少数据中心间通信的带宽资源，降低成本，同时由于访问距离近，也能提高用户访问的速度，增强用户体验。在这个场景里，域名解析系统会根据用户请求的源地址来判断返回哪个数据中心的服务地址，同时域名解析系统会通过健康检查机制持续探测应用系统的服务端口可用性，如果探测失败，则自动隔离该地址，按照解析顺序，会解析下一个可用地址，实现自动切换能力。
可以看出智能解析的关键点有两个：1、通过源地址判断返回哪个服务地址，2、健康检查机制。健康检查机制比较简单，在这里不做详述，主要讲一下怎么获取用户地址。熟悉DNS原理的同学可能会发现一个问题，当域名解析系统分角色部署的时候，权威服务器能获取到的是递归服务器的地址，而获取不到用户的真实地址。
技术上可以通过两种方式解决：第一种方式是使用EDNS (Extension Mechanisms for DNS) 技术，EDNS是对于原有DNS协议的一种扩展，旨在增强其功能性和灵活性。它的主要特性是将DNS消息的大小由512字节提高到4096字节，并引入了额外的选项字段，使得DNS报文可以携带更多类型的信息，在这里我们主要是用到ECS（Client Subnet，客户端子网）扩展字段，ECS扩展不是EDNS的一个直接字段，而是作为EDNS的一个选项（OPT Resource Record）中的一个部分来传送的。当DNS解析请求通过递归解析器转发到权威服务器时，ECS选项会包含发起请求的客户端地址的信息，权威服务器可以因此获得用户的真实地址。第二种解决方案是目前互联网常用的方式，在每个数据中心都建设独立的递归服务器，由递归服务器的地址来代表用户的地理位置，权威服务器根据递归服务器地址就可以知道请求来自哪里。
从架构设计角度结合部署产品情况，G行目前采用第二种解决方案。第一种解决方案有一些优势，比如成本比较低，不需要太多的权威服务器，而且配置也不算复杂，同时权威服务器可以直接获得用户的IP，在通过解析日志分析用户行为方面可以获得很有效的数据；但是这个方案有个致命的问题，开启源地址插入功能后，需要放弃递归服务器的缓存能力，因为每个请求都是要带不同的源地址的，意味着每次请求都要在权威上做独立的判断，不然就无法做到就近解析，而放弃缓存能力，可能成百上千倍增加权威服务器的系统压力，在同时启用智能解析的情况下可能直接导致权威服务器性能不足而故障的情况，第二种方案成熟、简单易行，并且互联网有大规模部署的案例，不过需要提醒的是每台递归服务器都需要开通到所有根和权威服务器的访问关系。成本控制方面，需要在多个位置部署递归服务器，在用户较少的位置，可以考虑低端服务器或者虚拟机方式，对于不需要智能解析的位置则不用部署。
02缓存机制
在智能解析中我们提到了递归服务器的缓存机制，在域名解析系统架构的设计中，缓存策略的设计直接影响域名解析系统的整体性能。递归服务器启用缓存后，缓存时间内，递归服务器不再将请求转发给权威服务器解析，而是将缓存的结果直接返回给用户，不仅大大缓解了权威服务器的访问压力，也提高了域名解析的速度。
开启缓存非常有必要，但是缓存时间是不得不考虑的因素，缓存时间太短，无法有效降低权威服务器的压力，缓存时间太长，可能导致域名地址变更无法快速更新，域名解析系统的智能解析机制无法快速生效等等。缓存时间建议通过权威服务器上域名配置的TTL时间来设置，不同类型的域名可以有不同的TTL时间策略，对于需要地址快速切换的重要业务域名，建议降低TTL时间值，特别应用甚至可以设置为0，对于有一定业务影响承受能力的业务域名，可以参考通用时间来设置。
综合考虑域名解析系统的整体性能和大部分应用系统的需求，设计通用TTL时间可以提高应用需求的沟通成本，以健康检查失败超时30秒，TTL时间60秒为例，可以计算出可能的业务影响时间为60~90秒，如果小于业务的RTO时间，那就是可以接受的TTL时间。
另外，客户侧还存在其他域名缓存可能导致域名切换失效，包括操作系统、中间件、java组件、浏览器等，建议应用部署时管理员应该充分评估可能域名缓存的组件，如果有，应该调整设置为不缓存或遵循域名TTL值。
03域名解析时延
域名解析作为网络访问的第一步，必然会消耗一定的时延，如果是服务器间的互访，那么增加时延可能对时延敏感的应用系统产生影响，这也是应用系统在考虑使用域名访问前的一些顾虑。解析时延主要可能有两种情况，（1）递归服务器有缓存，那么由递归服务器直接返回结果，由于递归服务器就近部署的原则，解析时延通常在1-2ms左右；（2）递归服务器没有缓存或者缓存时间超过TTL设置，那么递归服务器将重新发起迭代查询，根据域名迭代查询的次数不同，时延可能在几毫秒到几十毫秒不等，如果TTL值为60秒，那么每60秒可能会发生一次较缓慢的域名解析。
对于长连接应用，域名解析时延的影响仅体现在第一次的解析过程，建立TCP连接后，连接中断前不再请求DNS（不再增加访问延时），解析时延影响较低；对于短连接高频访问的应用，由于递归服务器近客户端部署，各地客户端均访问本地的递归服务器，仅在缓存超时后会出现短暂的延时增加，平均时延没有明显增长。
针对延时要求敏感的业务，递归服务器建议开启“缓存刷新”功能，在缓存到期时递归服务器主动向权威域名更新解析记录，保证客户端都从缓存里获得解析结果。如果DNS产品不支持缓存刷新，可以在前端负载均衡上增加对应域名的健康检查，利用负载均衡来快速更新缓存。
对于CS访问方式，如果域名解析延时或者解析失败对应用影响较大，可以考虑通过使用HTTPDNS方式通过HTTP方式直接从权威服务器获取域名解析结果，但是需要对C端进行一定的改造。
04容灾策略
整体域名解析系统的容灾策略主要从架构和性能两方面考虑。
架构方面，由于域名解析系统根和权威服务器都采用分布式部署，任意单个节点故障对系统整体无影响，递归服务器采用负载均衡集群方式部署，递归服务器采用资源池方式部署，负载均衡使用域名解析探测作为健康检查方式，单台设备不可用可以自动隔离。负载均衡组采用多台集群部署，保证负载均衡自身的可用性。根、权威、递归服务器都考虑异构部署，避免产品级故障。对于目前比较流行的“双平面”部署（使用两套异构产品部署完全对等的两套环境，一套主用一套备用，主用环境出现问题时直接切换到备用环境上），在分布式架构下意义不大，如果存在异构的两套环境，完全可以同时提供服务，无需采用热备方式造成资源的浪费。另外如果是性能容量相等的两套环境，那么主用环境出现性能问题时，备用环境同样是无能为力的，不如同时使用将整体性能提升一倍。
性能方面，系统设计整体性能容量应满足未来五年的发展需求，通过开启递归服务器缓存可以极大降低权威服务器的性能压力，保证域名解析系统性能有足够的冗余。当出现权威服务器性能压力过大时，首先确定造成压力突增的域名，增加该域名的TTL时间以增加域名在LDNS上的缓存时间来缓解权威服务器压力，紧急情况下，考虑直接关闭智能解析，降低智能解析占用的服务器性能，采用静态解析方式提供域名服务。
四、域名安全设计
01安全威胁防御
面对DNS flood攻击、DNS污染和DNS隐蔽隧道等安全威胁，我们采取了一系列监控和防护措施，确保系统的安全性。
02其他管控措施分析
是否需要关闭DNS的TCP53端口？
建议区域间的防火墙关闭TCP53访问。DNS协议实际规定了TCP 53和UDP 53都是DNS服务端口，正常情况下DNS使用UDP协议进行通信，当DNS数据报文过大时，如zone transfer操作，DNS将通过TCP端口进行报文传输。但是日常DNS使用仅仅请求域名和应答解析地址，对于大报文传输是没有要求的。反而是异常行为，如DNS隐蔽隧道、恶意域名解析、通过zone transfer窃取域名信息等会需要用到更大的报文。因此如果只是正常使用域名，建议防火墙关闭TCP 53端口访问。
是否需要启用DNSSEC？
不建议启用。DNSSEC将DNS的通信变成了加密通信，可以提高DNS的安全性，有效防止DNS劫持和DNS污染，但是DNSSEC涉及加密通信会大大降低DNS的整体性能，使其发更容易性能耗尽，同时加密通信会增加额外的带宽开销，可能需要开通TCP53端口来允许大报文的传输，引入其他安全风险，另外流量分析类产品也会因为无法分析加密流量而失效，对于隐蔽隧道的监控会彻底失效，同样的，DNS问题定位所需要的抓包分析手段也会失效。简单来说启用DNSSEC引入的风险和管理难度增加，不建议开启。
五、总结
G行数据中心的域名解析系统通过低耦合、高冗余等原则，支撑了多数据中心间的高效流量调度和业务双活。随着全栈云、大数据、人工智能技术的推广，域名解析系统将面临更大规模的域名请求和流量调度的需求。G行的域名解析系统也将与时俱进，通过不断的技术更新和架构升级来满足这些新兴技术带来的挑战，实现持续安全运营。
作者| 张林
专注于网络四到七层技术及相关安全技术的研究和应用，网络领域中最懂应用，应用领域中最懂网络，争取再发光20年。