CN112565477B - 支持多智能线路下的dns数据更新通知方法及存储介质 - Google Patents

Abstract

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

Description

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

技术领域

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

背景技术

在DNS领域，为保障域名解析服务的高性能和高可用性，主辅架构被广泛使用。在该架构下，数据更新发送到主服务器上，主服务器更新数据后，再同步给辅服务器。目前有两种数据同步方式：主动方式和被动方式。

主动方式的工作流程如下：

1.主服务器数据更新后，通知辅服务器数据有变化；

2.辅服务器启动获取更新数据流程(AXFR或者IXFR)，进行数据更新。

被动方式的工作流程如下：

1.辅服务器定期向主服务器询问是否有数据更新；

2.辅服务器发现数据更新；

3.辅服务器启动获取更新数据流程。

相比于被动方式，主动方式可以在更短的时间保证主辅数据同步，所以在DNS领域应用更广。该机制在RFC1996中描述，也被广泛的应用于DNS的软件中(比如BIND)。

上述中的主动方式在一般情况下可以很好的提供实时的主辅同步，但对于配置了多DNS智能线路的DNS主辅同步集群而言，则无法很好的提供各个DNS智能线路下实时的数据同步。在RFC1996中，当主服务器进行了数据更新后，会发送一个notify消息给所有配置的辅服务器。这个notify消息里面包括以下信息：

1.更新了哪个DNS区(zone)的数据；

2.更新后这个DNS区的序列号(每次更新后该序列号都会增加)。

当配置了多DNS智能线路的主服务器某个智能线路下的区发生了数据更新，就会按照上述格式向辅服务器发送notify消息。但是由于notify消息中并没有标明是哪个智能线路下的区发生了变化，所以辅服务器只能按照DNS智能解析的默认方式来进行处理，即按照notify源地址进行判断是哪个智能线路下的区，从而只对该智能线路下的区发起数据传送。但在这种情况下，发送notify的源就是主服务器，其IP源地址是固定的，所以当主服务器上不同智能线路下的同名区发生了数据更新，但发送notify消息后，只会触发辅服务器上某一个智能线路的同名区的数据更新，其他智能线路下的同名区只能使用被动触发来进行数据更新，从而导致主辅数据同步有较大延迟。

发明内容

针对现有技术的缺陷，兼容原有的DNS notify协议的基础上，能为配置了多DNS智能线路的主辅DNS集群提供高效的、能快速准确触发所属智能线路下的区数据更新的notify机制。

本发明采用的技术方案如下：

一种支持多智能线路下的DNS数据更新通知方法，包括：

接收某智能线路下的某区的数据更新请求，生成标准的notify包，

判断主服务器是否使能了notify扩展协议，若是，则在所述notify包的viewsection段中添加数据更新的智能线路名称，若否，则不作修改；

把处置后的notify包下发给配置的所有辅服务器，使得更新在辅服务器生效。

进一步地，通过所述notify包的Header段中的ANCOUNT值判断是否使能了notify扩展协议，其中，若ANCOUNT值为0，判定没有所述view section段，若ANCOUNT值为1，判定存在所述view section段。

进一步地，所述辅服务器接收到所述主服务器发送的notify包后，进行解析，并ANCOUNT值判断view section段是否为空，若为空，则按照原notify源来判断更新的智能线路，若不为空，则从view section段获取本次更新的智能线路的名称。

进一步地，在判定ANCOUNT值为1时，增加所述view section段，并将其格式改为依次含View Name Wire Format、Type、Class、TTL、RDLEN在内的所有字段。

进一步地，通过Zone SOA Record和获取的本次更新的智能线路的名称，定位更新的区，触发该区的区传送机制。

进一步地，所述notify扩展协议是对RFC1996协议进行了扩展，并使用原标准的DNS包作为承载。

进一步地，所述notify扩展协议的格式由Header段、Zone Section段、ViewSection段、Zone SOA Record段和Additional Section段组成。

进一步地，所述Header段的协议格式和标准的RFC1996协议格式一致，但对ANCOUNT做了扩展，使得view section中的RR条目为0或者1；所述Zone Section段的协议格式和标准的RFC1996协议格式一致；所述Zone SOA Record段的协议格式和标准的RFC1996协议格式一致；所述Additional Section段的协议格式和标准的RFC1996协议格式一致。

进一步地，在View Name Wire Format后增加的Type、Class、TTL、RDLEN的格式符合标准的DNS包RFC1034定义的包格式。

本发明还提供了一种计算机可读存储介质，其具有存储在其上的计算机可读程序指令，所述计算机可读程序指令用于执行根据前述的方法。

与现有技术相比，本发明提供的一种支持多智能线路下的DNS数据更新通知方法，达到了如下技术效果：

1、本发明针对RFC1996协议在多智能线路下主辅同步机制的缺陷，扩展了该协议的View Section段，在该段中增加了修改的智能线路名称，结合原有的区名，可以唯一定位修改的部分，解决了原有RFC1996协议在多智能线路下只触发某一个智能线路下数据更新的多匹配缺陷。

2、本发明在扩展的同时，能完全兼容之前的通知协议和DNS标准协议(前向兼容)，保障系统的平滑升级。

附图说明

图1是本发明实施例中的协议格式的示意图。

图2是本发明实施例中的Header段协议格式的示意图。

图3是本发明实施例中的Zone Section段协议格式的示意图。

图4是本发明实施例中的View Section段协议格式的示意图。

图5是本发明实施例中的SOA记录的格式和示例的示意图。

图6是本发明实施例中的主服务器工作的流程图。

图7是本发明实施例中的辅服务器工作的流程图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述。显然，所描述的实施例为实施本发明的较佳实施方式，所述描述是以说明本发明的一般原则为目的，并非用以限定本发明的范围。本发明的保护范围应当以权利要求所界定者为准，基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明实施例提供了一种支持多智能线路下的DNS数据更新通知方法，该方法包括：

接收某智能线路下的某区的数据更新请求，生成标准的notify包，

判断主服务器是否使能了notify扩展协议，若是，则扩展原来RFC1996协议中的View Section段，在所述notify包的view section段中添加数据更新的智能线路名称，若否，则不作修改，按照原RFC1996协议执行更新通知；

把处置后的notify包下发给配置的所有辅服务器，辅服务器根据是否使能了notify扩展协议进行不同方式的通知更新。

本发明针对RFC1996在多智能线路下主辅同步机制的缺陷，扩展了该协议的ViewSection段，在该段中增加了修改的智能线路名称，结合原有的区名，可以唯一定位修改的部分，解决了原有RFC1996协议在多智能线路下只触发某一个智能线路下数据更新的多匹配缺陷。

其中，判断是否使能了notify扩展协议，是通过所述notify包的Header段中的ANCOUNT值来判断。其中，若ANCOUNT值为0，说明不占有该空间，判定没有所述view section段，若ANCOUNT值为1，说明占了一条空间，存在扩展，也即判定存在所述view section段。

关于辅服务器的更新通知，具体来说，辅服务器接收到所述主服务器发送的notify包后，进行解析，并ANCOUNT值判断view section段是否为空，也即DNS Header中的ANCOUNT是否为0，若为空，则按照notify源来判断更新的智能线路，若不为空，则从viewsection段获取本次更新的智能线路的名称。

本发明在扩展的同时，扩展的View Section段也符合标准的RFC1034定义的包格式，包含View Name Wire Format、Type、Class、TTL、RDLEN在内的所有字段，能完全兼容之前的通知协议和DNS标准协议(前向兼容)，保障了系统的平滑升级。

下面来对本发明实施例中的支持多智能线路下的DNS数据更新通知方法采用的协议进行详述。

本发明对RFC1996协议进行了扩展，依然使用标准的DNS包(RFC1034)作为承载，协议格式如附图1所示，包括Header段、Zone Section段、View Section段、Zone SOA Record段和Additional Section段。其中各个部分的具体格式如下：

1)Header段协议格式(和标准RFC1996一致)如附图2所示，其中：

QDCOUNT表明Zone Section中的RR条目，对于notify来说，只能为1；

ANCOUNT表明View Section中的RR条目，对于notify来说，只能为0或者1，0和现有的RFC1996相同，1则是本发明扩展的；也就是说，这个字段只能为0，就表明该段没有包含任何的RR，但是本发明对该字段进行了扩展，使其还能为1，为1的时候，说明需要添加ViewName信息。

NSCOUNT表明Zone SOA Record中RR条目，对于notify来说，只能为1；

ARCOUNT表明Additional Section中RR条目，对于notify来说，只能为0或者1，0是不带EDNS0的情况，1是带EDNS0的情况。

2)Zone Section段协议格式(和标准RFC1996一致)如附图3所示，其中：

Zone Name Wire Format：是指DNS数据更新的区(Zone)名称的线性格式(RFC1034中定义)，表明这次修改的是哪个区；

Type：必须为SOA(6)，长度为2个byte；

Class：必须为CLASS_IN(1)，长度为2个byte。

3)View Section段，对RFC1996进行了扩展，如果ANCOUNT为0，那么就没有该section；如果ANCOUNT为1，就有该section，协议格式如附图4所示，其中：

View Name Wire Format：是指DNS数据更新的智能线路名称的线性格式；

Type：必须为TYPE_NONE(0)，长度为2个byte；

Class：必须为CLASS_IN(1)，长度为2个byte；

TTL：必须为0，长度为4个byte；

RDLEN：必须为0，长度为2个byte。

如果在HEADER中的ANCOUNT字段为0，那么就和标准的RFC1996相同(前向兼容)；如果为1，则为本方法提出的扩展方式。这样可以在该section中提供智能线路的名称(ViewName)。因为考虑到该扩展也必须是准许标准的RFC1034定义的包格式，所以需要在ViewName后面加上Type、Class、TTL、RDLEN来构成完成的条目格式(RR format)。虽然这几个字段没有被使用，但考虑到后向兼容性，本本发明也需对这几个字段也进行限定，保证协议的正常解析。

当辅服务器收到notify包后，会判断ANCOUNT为0还是1，如果为0，就按之前的方式继续执行；否则，会获得View Section中的View Name，并且判断其他字段的有效性。从而获取本次修改的智能线路的名称。

4)Zone SOA Record(和标准RFC1996一致)：

该段只包含一条SOA记录，该记录会通知辅区：是哪个区发生了数据变化，变化后的序列号是多少。其中SOA记录的格式和示例如附图5所示。

5)Additional Section(和标准RFC1996一致)：

该section如果存在的话，就只能放置EDNS0资源记录，与RFC1996协议相同，在此不再赘述。

下面结合图6、图7按照主辅同步机制中主服务器和辅服务器的角色分别对本发明的实施方式做进一步地详细描述。

一、对于主服务器：

1.主服务器接收某个智能线路下的某个区的数据更新，并在本机生效；

2.主服务器生成标准的notify包；

3.判断主服务器是否使能了notify扩展协议；

3.1.如果使能了notify扩展协议，就在view section段添加数据更新的智能线路名称；

3.2.如果没有使能，则不采取任何行动；

4.把该notify消息下发给配置的所有辅服务器。

二、对于辅服务器：

1.辅服务器接收到notify消息，并按照标准DNS包进行解析；

2.判断view section段是否为空(DNS Header中的ANCOUNT是否为0)

2.1.如果为空，就按照notify源来判断更新的智能线路；

2.2.如果不为空，则从view section段获取本次更新的智能线路的名称；

通过Zone SOA Record和2中获得的智能线路，定位更新的区，触发该区的区传送机制。

此外，替代地，上述方法能够通过计算机程序产品，即计算机可读存储介质来实现。计算机程序产品可以包括计算机可读存储介质，其上载有用于执行本发明的各个方面的计算机可读程序指令。计算机可读存储介质可以是可以保持和存储由指令执行设备使用的指令的有形设备。计算机可读存储介质例如可以是但不限于电存储设备、磁存储设备、光存储设备、电磁存储设备、半导体存储设备或者上述的任意合适的组合。计算机可读存储介质的更具体的例子(非穷举的列表)包括：便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、静态随机存取存储器(SRAM)、便携式压缩盘只读存储器(CD-ROM)、数字多功能盘(DVD)、记忆棒、软盘、机械编码设备、例如其上存储有指令的打孔卡或凹槽内凸起结构、以及上述的任意合适的组合。这里所使用的计算机可读存储介质不被解释为瞬时信号本身，诸如无线电波或者其他自由传播的电磁波、通过波导或其他传输媒介传播的电磁波(例如，通过光纤电缆的光脉冲)、或者通过电线传输的电信号。

上述说明示出并描述了本发明的若干优选实施例，但如前所述，应当理解本发明并非局限于本文所披露的形式，不应看作是对其他实施例的排除，而可用于各种其他组合、修改和环境，并能够在本文所述发明构想范围内，通过上述教导或相关领域的技术或知识进行改动。而本领域人员所进行的改动和变化不脱离本发明的精神和范围，则都应在本发明所附权利要求的保护范围内。

Claims (9)

1.一种支持多智能线路下的DNS数据更新通知方法，其特征在于，所述方法包括：

接收某智能线路下的某区的数据更新请求，生成标准的notify包；

通过所述notify包的Header段中的ANCOUNT值判断主服务器是否使能了notify扩展协议，若是，则在所述notify包的view section段中添加数据更新的智能线路名称，若否，则不作修改；其中，若ANCOUNT值为0，判定没有所述view section段，若ANCOUNT值为1，判定存在所述view section段；

把处置后的notify包下发给配置的所有辅服务器。

2.根据权利要求1所述的方法，其特征在于，所述辅服务器接收到所述主服务器发送的notify包后，进行解析，并根据所述ANCOUNT值判断view section段是否为空，若为空，则按照notify源来判断更新的智能线路，若不为空，则从view section段获取本次更新的智能线路的名称。

3.根据权利要求1所述的方法，其特征在于，在判定ANCOUNT值为1时，增加所述viewsection段，并将其格式改为依次含ViewName Wire Format、Type、Class、TTL、RDLEN在内的所有字段。

4.根据权利要求2所述的方法，其特征在于，通过Zone SOA Record和获取的本次更新的智能线路的名称，定位更新的区，触发该区的区传送机制。

5.根据权利要求1所述的方法，其特征在于，所述notify扩展协议是对RFC1996协议进行了扩展，并使用原标准的DNS包作为承载。

6.根据权利要求1或5所述的方法，其特征在于，所述notify扩展协议的格式由Header段、Zone Section段、View Section段、Zone SOA Record段和Additional Section段组成。

7.根据权利要求6所述的方法，其特征在于，所述Header段的协议格式和标准的RFC1996协议格式一致，但对ANCOUNT做了扩展，使得view section中的RR条目为0或者1；所述Zone Section段的协议格式和标准的RFC1996协议格式一致；所述Zone SOA Record段的协议格式和标准的RFC1996协议格式一致；所述Additional Section段的协议格式和标准的RFC1996协议格式一致。

8.根据权利要求3所述的方法，其特征在于，在ViewName Wire Format后增加的Type、Class、TTL、RDLEN的格式符合标准的DNS包RFC1034定义的包格式。

9.一种计算机可读存储介质，其具有存储在其上的计算机可读程序指令，所述计算机可读程序指令用于执行根据权利要求1至8中任一项所述的方法。

Images