支持多智能线路下的DNS数据更新通知方法及存储介质技术

本发明专利技术公开了一种支持多智能线路下的DNS数据更新通知方法，该方法包括：接收某智能线路下的某区的数据更新请求，生成标准的notify包，判断主服务器是否使能了notify扩展协议，若是，则在所述notify包的view section段中添加数据更新的智能线路名称，若否，则不作修改；把处置后的notify包下发给配置的所有辅服务器。本发明专利技术在RFC1996协议的基础上，扩展了该协议的ViewSection段，结合原有的区名，可以唯一定位修改的部分，解决了原有RFC1996协议在多智能线路下只触发某一个智能线路下数据更新的多匹配缺陷，且能完全兼容之前的通知协议和DNS标准协议，保障系统的平滑升级。保障系统的平滑升级。保障系统的平滑升级。

【技术实现步骤摘要】
支持多智能线路下的DNS数据更新通知方法及存储介质


[0001]本专利技术涉及互联网域名
，具体地，涉及一种支持多智能线路下的DNS数据更新通知方法。

技术介绍

[0002]在DNS领域，为保障域名解析服务的高性能和高可用性，主辅架构被广泛使用。在该架构下，数据更新发送到主服务器上，主服务器更新数据后，再同步给辅服务器。目前有两种数据同步方式：主动方式和被动方式。
[0003]主动方式的工作流程如下：
[0004]1.主服务器数据更新后，通知辅服务器数据有变化；
[0005]2.辅服务器启动获取更新数据流程(AXFR或者IXFR)，进行数据更新。
[0006]被动方式的工作流程如下：
[0007]1.辅服务器定期向主服务器询问是否有数据更新；
[0008]2.辅服务器发现数据更新；
[0009]3.辅服务器启动获取更新数据流程。
[0010]相比于被动方式，主动方式可以在更短的时间保证主辅数据同步，所以在DNS领域应用更广。该机制在RFC1996中描述，也被广泛的应用于DNS的软件中(比如BIND)。
[0011]上述中的主动方式在一般情况下可以很好的提供实时的主辅同步，但对于配置了多DNS智能线路的DNS主辅同步集群而言，则无法很好的提供各个DNS智能线路下实时的数据同步。在RFC1996中，当主服务器进行了数据更新后，会发送一个notify消息给所有配置的辅服务器。这个notify消息里面包括以下信息：
[0012]1.更新了哪个DNS区(zone)的数据；
[0013]2.更新后这个DNS区的序列号(每次更新后该序列号都会增加)。
[0014]当配置了多DNS智能线路的主服务器某个智能线路下的区发生了数据更新，就会按照上述格式向辅服务器发送notify消息。但是由于notify消息中并没有标明是哪个智能线路下的区发生了变化，所以辅服务器只能按照DNS智能解析的默认方式来进行处理，即按照notify源地址进行判断是哪个智能线路下的区，从而只对该智能线路下的区发起数据传送。但在这种情况下，发送notify的源就是主服务器，其IP源地址是固定的，所以当主服务器上不同智能线路下的同名区发生了数据更新，但发送notify消息后，只会触发辅服务器上某一个智能线路的同名区的数据更新，其他智能线路下的同名区只能使用被动触发来进行数据更新，从而导致主辅数据同步有较大延迟。

技术实现思路

[0015]针对现有技术的缺陷，兼容原有的DNS notify协议的基础上，能为配置了多DNS智能线路的主辅DNS集群提供高效的、能快速准确触发所属智能线路下的区数据更新的notify机制。
[0016]本专利技术采用的技术方案如下：
[0017]一种支持多智能线路下的DNS数据更新通知方法，包括：
[0018]接收某智能线路下的某区的数据更新请求，生成标准的notify包，
[0019]判断主服务器是否使能了notify扩展协议，若是，则在所述notify包的view section段中添加数据更新的智能线路名称，若否，则不作修改；
[0020]把处置后的notify包下发给配置的所有辅服务器，使得更新在辅服务器生效。
[0021]进一步地，通过所述notify包的Header段中的ANCOUNT值判断是否使能了notify扩展协议，其中，若ANCOUNT值为0，判定没有所述view section段，若ANCOUNT值为1，判定存在所述view section段。
[0022]进一步地，所述辅服务器接收到所述主服务器发送的notify包后，进行解析，并ANCOUNT值判断view section段是否为空，若为空，则按照原notify源来判断更新的智能线路，若不为空，则从view section段获取本次更新的智能线路的名称。
[0023]进一步地，在判定ANCOUNT值为1时，增加所述view section段，并将其格式改为依次含View Name Wire Format、Type、Class、TTL、RDLEN在内的所有字段。
[0024]进一步地，通过Zone SOA Record和获取的本次更新的智能线路的名称，定位更新的区，触发该区的区传送机制。
[0025]进一步地，所述notify扩展协议是对RFC1996协议进行了扩展，并使用原标准的DNS包作为承载。
[0026]进一步地，所述notify扩展协议的格式由Header段、Zone Section段、View Section段、Zone SOA Record段和Additional Section段组成。
[0027]进一步地，所述Header段的协议格式和标准的RFC1996协议格式一致，但对ANCOUNT做了扩展，使得view section中的RR条目为0或者1；所述Zone Section段的协议格式和标准的RFC1996协议格式一致；所述Zone SOA Record段的协议格式和标准的RFC1996协议格式一致；所述Additional Section段的协议格式和标准的RFC1996协议格式一致。
[0028]进一步地，在View Name Wire Format后增加的Type、Class、TTL、RDLEN的格式符合标准的DNS包RFC1034定义的包格式。
[0029]本专利技术还提供了一种计算机可读存储介质，其具有存储在其上的计算机可读程序指令，所述计算机可读程序指令用于执行根据前述的方法。
[0030]与现有技术相比，本专利技术提供的一种支持多智能线路下的DNS数据更新通知方法，达到了如下技术效果：
[0031]1、本专利技术针对RFC1996协议在多智能线路下主辅同步机制的缺陷，扩展了该协议的View Section段，在该段中增加了修改的智能线路名称，结合原有的区名，可以唯一定位修改的部分，解决了原有RFC1996协议在多智能线路下只触发某一个智能线路下数据更新的多匹配缺陷。
[0032]2、本专利技术在扩展的同时，能完全兼容之前的通知协议和DNS标准协议(前向兼容)，保障系统的平滑升级。
附图说明
[0033]图1是本专利技术实施例中的协议格式的示意图。
[0034]图2是本专利技术实施例中的Header段协议格式的示意图。
[0035]图3是本专利技术实施例中的Zone Section段协议格式的示意图。
[0036]图4是本专利技术实施例中的View Section段协议格式的示意图。
[0037]图5是本专利技术实施例中的SOA记录的格式和示例的示意图。
[0038]图6是本专利技术实施例中的主服务器工作的流程图。
[0039]图7是本专利技术实施例中的辅服务器工作的流程图。
具体实施方式
[0040]下面将结合本专利技术实施例中的附图，对本专利技术实施例中的技术方案进行清楚、完整地描述。显然，所描述的本文档来自技高网...

【技术保护点】

【技术特征摘要】
1.一种支持多智能线路下的DNS数据更新通知方法，其特征在于，所述方法包括：接收某智能线路下的某区的数据更新请求，生成标准的notify包，判断主服务器是否使能了notify扩展协议，若是，则在所述notify包的view section段中添加数据更新的智能线路名称，若否，则不作修改；把处置后的notify包下发给配置的所有辅服务器。2.根据权利要求1所述的方法，其特征在于，通过所述notify包的Header段中的ANCOUNT值判断是否使能了notify扩展协议，其中，若ANCOUNT值为0，判定没有所述view section段，若ANCOUNT值为1，判定存在所述view section段。3.根据权利要求2所述的方法，其特征在于，所述辅服务器接收到所述主服务器发送的notify包后，进行解析，并ANCOUNT值判断view section段是否为空，若为空，则按照notify源来判断更新的智能线路，若不为空，则从view section段获取本次更新的智能线路的名称。4.根据权利要求2所述的方法，其特征在于，在判定ANCOUNT值为1时，增加所述view section段，并将其格式改为依次含View Name Wire Format、Type、Class、TTL、RDLEN在内的所有字段。5.根据权利要求3所述的方法，其特征在于，通过Zone SOA Record...

【专利技术属性】
技术研发人员：蒋超，李文瀚，张智勇，吴琦，邢志杰，毛伟，
申请(专利权)人：互联网域名系统北京市工程研究中心有限公司，
类型：发明
国别省市：