技术领域
[0001] 本
发明涉及互联网应用技术领域，特别涉及一种数据存储结构及DNS数据存储系统。
背景技术
[0002] 在人们的日常生活中，使用网络进行资料或者数据或者信息进行查询时，通常接收到利用域名解析系统(DomainName System，以下简称DNS)技术缓存的结果。但是，DNS缓存结果具有一定的时效性，即在有效时间内，应答结果是不变的，因此可以放在
服务器设备的高速缓存中，这样可以在极短时间内返回给客户端
请求的结果。在有效时间过期后，系统去外部网络进行该域名的查询，并将结果更新在高速缓存中。
[0003] 为实现对主动请求的DNS解析信息进行保存，现需要一种能大量存储且易于查询
修改的数据存储技术，故决定采用
数据库技术来解决这一问题。目前，在袁春阳等人的《域名信息主动获取及备份系统的设计和实现》论文中提到了一种用于存储获取到的DNS信息的数据库设计模式，该数据库设计模式以DNS权威资源记录表为“被参照”表，其他资源记录为“参照”表而设计，该数据库设计模式在实现时存在的问题是当一个域名存在有多个权威服务器的信息时，这样数据库设计模式会导致多个权威服务器的信息无法被同时记录，并且在采用分表记录不同资源信息却没有记录附加信息的表，也会导致信息记录的遗漏。
发明内容
[0004] 为了解决背景技术存储的技术问题，本发明的目的是提供一种数据存储结构及DNS数据存储系统。
[0005] 为实现上述目的，本发明提供了如下方案：
[0006] 一种数据存储结构，所述数据存储结构包括以域名为被参照表的域名表、一般资源记录表、邮件交换资源记录表和权威资源记录表；
[0007] 所述域名表的关系模式为查询域名；所述查询域名为所述域名表的关系模式的主键；
[0008] 所述一般资源记录表的关系模式为IP地址或
别名，查询域名，记录类型，类，生存时间，数据长度；所述IP地址或别名为所述一般资源记录表的关系模式的主键；所述查询域名为所述一般资源记录表的关系模式的外键；
[0009] 所述邮件交换资源记录表的关系模式为邮件服务器域名，查询域名，记录类型，类，生存时间，数据长度，优先权；所述邮件服务器域名为所述邮件交换资源记录表的关系模式的主键；所述查询域名为所述邮件交换资源记录表的关系模式的外键；
[0010] 所述权威资源记录表的关系模式为权威服务器域名，查询域名，记录类型，类，生存时间，数据长度，负责人邮箱，序列号，刷新间隔，重试间隔，过期间隔，预设最小生存时间；所述权威服务器域名为所述权威资源记录表的关系模式的主键；所述查询域名为所述权威资源记录表的关系模式的外键。
[0011] 可选的，所述域名表、所述一般资源记录表、所述邮件交换资源记录表、所述权威资源记录表均满足实体完整性约束条件、参照完整性约束条件以及用户自定义完整性约束条件。
[0012] 可选的，所述实体完整性约束条件为使所述域名表、所述一般资源记录表、所述邮件交换资源记录表、所述权威资源记录表中每一行都能表示唯一实体的约束条件；所述域名表、所述一般资源记录表、所述邮件交换资源记录表、所述权威资源记录表均用设置主键的方式保证数据的实体完整性。
[0013] 可选的，所述参照完整性约束条件是指所述数据存储结构中被参照表的主键和参照表的外键的数据保持一致，且所述参照表的外键字段不为空；所述被参照表为域名表；所述参照表包括一般资源记录表、所述邮件交换资源记录表、所述权威资源记录表。
[0014] 可选的，所述用户自定义完整性约束条件是针对关系数据库设置的约束条件，所述用户自定义完整性约束条件反映具体应用时满足的语义要求，所述语义要求包括列名、数据类型、长度、主/外键、是否可为空。
[0015] 可选的，在所述域名表、所述一般资源记录表、所述邮件交换资源记录表、所述权威资源记录表上均添加相应的索引。
[0016] 一种DNS数据存储系统，所述DNS数据存储系统包括数据接收单元、数据上传单元和用户
接口单元；
[0017] 所述数据接收单元用于接收来自前端主动请求的DNS数据；
[0018] 所述数据上传单元用于接收来自所述数据接收单元的输出DNS数据，并将DNS数据上传至用户
指定内存；
[0019] 所述用户接口单元在域名解析网络中开辟数据存储结构，实现对所述数据上传单元上传数据的管理，所述数据存储结构为
权利要求1～6中任一所述的数据存储结构。
[0020] 可选的，所述数据接收单元为DNS数据接收单元，所述DNS数据接收单元用于接收来自前端采用DNS协议数据报文格式进行传输的数据。
[0021] 可选的，所述DNS数据存储系统是基于Mysql
数据库管理系统而建立的。
[0022] 根据本发明提供的具体
实施例，本发明公开了以下技术效果：
[0023] 本发明提供了一种数据存储结构及DNS数据存储系统。本发明通过设置由以域名为被参照表的域名表、一般资源记录表、邮件交换资源记录表和权威资源记录表组成的数据存储结构，既减少了大量的数据冗余，又避免了数据记录的遗漏。另外该数据存储结构中的每个表均符合主键唯一原则，进而也保证了数据的唯一性。
附图说明
[0024] 为了更清楚地说明本发明实施例或
现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
[0025] 图1为本发明实施例概念模型示意图；
[0026] 图2为本发明实施例DNS数据存储系统的结构示意图。
具体实施方式
[0027] 下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
[0028] 本发明的目的是提供一种数据存储结构及DNS数据存储系统，既减少了大量的数据冗余，又避免了数据记录的遗漏。
[0029] 为使本发明的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本发明作进一步详细的说明。
[0030] 本发明实施例提供的数据存储结构包括以域名为被参照表的域名表、一般资源记录表、邮件交换资源记录表和权威资源记录表。
[0031] 所述域名表的关系模式为查询域名；所述查询域名为所述域名表的关系模式的主键。
[0032] 所述一般资源记录表的关系模式为IP地址或别名，查询域名，记录类型，类，生存时间，数据长度；所述IP地址或别名为所述一般资源记录表的关系模式的主键；所述查询域名为所述一般资源记录表的关系模式的外键。
[0033] 所述邮件交换资源记录表的关系模式为邮件服务器域名，查询域名，记录类型，类，生存时间，数据长度，优先权；所述邮件服务器域名为所述邮件交换资源记录表的关系模式的主键；所述查询域名为所述邮件交换资源记录表的关系模式的外键。
[0034] 所述权威资源记录表的关系模式为权威服务器域名，查询域名，记录类型，类，生存时间，数据长度，负责人邮箱，序列号，刷新间隔，重试间隔，过期间隔，预设最小生存时间；所述权威服务器域名为所述权威资源记录表的关系模式的主键；所述查询域名为所述权威资源记录表的关系模式的外键。
[0035] 其中，所述域名表、所述一般资源记录表、所述邮件交换资源记录表、所述权威资源记录表均满足实体完整性约束条件、参照完整性约束条件以及用户自定义完整性约束条件。
[0036] 在所述域名表、所述一般资源记录表、所述邮件交换资源记录表、所述权威资源记录表上均添加相应的索引。
[0037] 下面介绍下本发明实施例提供的数据存储结构的设计过程。
[0038] 为实现对主动请求的DNS解析信息进行保存，现需要一种能大量存储且易于查询、修改的数据存储技术，故决定采用数据库技术来解决这一问题。本发明提供的数据存储结构是建立在对大量DNS数据报文进行测试和分析后，根据DNS数据报文结构对数据库的概念模型、逻辑模型、物理模型进行设计。
[0039] 为实现对所捕获的DNS解析信息进行存储，首先需要确定用于进行数据保存的数据库的实体表、表间关系以及数据结构。因此本发明从以下数据存储结构设计的三个阶段进行分析：
[0040] 概念模型设计
[0041] 根据DNS数据报文结构来看，无论请求类型是哪一种，响应的DNS数据报文(DNS数据报文中包含了DNS解析信息)中唯一且不会改变的只有域名，并且回答部分多为以DNS数据报文中五元组资源记录为标准，其他有所变化的就只有邮件交换记录和授权信息记录，并在最后的数据字段又分成了多个特有字段。因此，本发明将接收到的DNS数据报文内容存储在以域名为被参照表的域名表、一般资源记录表、邮件交换资源记录表、权威资源记录表这四张实体表中(可根据后期需要进行扩充)，并将域名表、一般资源记录表、邮件交换资源记录表、权威资源记录表各自抽象为对应的实体表，进而根据所有的实体表绘制画出数据存储结构的概念模型图(E-R图)，如图1所示。
[0042] 逻辑结构设计
[0043] 逻辑结构就是关系模型，是根据已绘制出的概念模型图(E-R图)转换获取的，概念模型向关系模型转换要解决的问题是如何将实体类型和实体之间的联系转换为关系模式和如何确定这些关系模式的主外键。其中，每个实体类型可以转换成一个关系模式，实体的属性即为关系的属性，实体标识符即为关系的键。
[0044] 关系模型的结构是一组关系模式的集合。该数据存储结构的关系模式如下：
[0045] Name(域名表)
[0046] (查询的域名)
[0047] PTRrecord(一般资源记录表)
[0048] (IP地址或别名，查询域名，记录类型，类，生存时间，数据长度)[0049] MXrecord(邮件交换资源记录表)
[0050] (邮件服务器的域名，查询的域名，记录类型，类，生存时间，数据长度，[0051] 优先权)
[0052] SOArecord(权威资源记录表)
[0053] (权威服务器域名，查询域名，记录类型，类，生存时间，数据长度，负责人邮箱，序列号，刷新间隔，重试间隔，过期间隔，预设最小生存时间)
[0054] 其中，带下划线的属性为各关系模式的主键，字体为粗体的属性为各关系模式的外键。
[0055] 物理结构设计
[0056] 这部分将设计每张表中数据的“用户自定义完整性”及物理结构，包括数据的类型，数据长度，是否为空等，如表1-4所示：
[0057] 表1 Name(域名表)
[0058]
[0059] 表2 PTRrecord(一般资源记录表)
[0060]
[0061]
[0062] 表3 MXrecord(邮件交换资源记录表)
[0063]
[0064] 表4 SOArecord(权威资源记录表)
[0065]
[0066]
[0067] 设计好的域名表、一般资源记录表、邮件交换资源记录表、权威资源记录表均满足实体完整性约束条件、参照完整性约束条件以及用户自定义完整性约束条件。
[0068] 其中，实体完整性约束条件：规定每个表中的每一行都能表示唯一实体，并用设置主键的方式可以保证数据的实体完整性。
[0069] 参照完整性约束条件：是指被参照表的主键和参照表的外键的数据应保持一致，且参照表中的外键字段不为空，这样以外键为约束可以保证被参照表和参照表之间的数据一一对应，且参照表中多条数据可设置相同的外键，以实现被参照表中的一条数据可对应参照表中多条数据。被参照表为域名表；参照表包括一般资源记录表、邮件交换资源记录表、权威资源记录表。
[0070] 用户自定义完整性约束条件：用户定义的完整性即是针对某个特定关系数据库设置的约束条件，它反映某一具体应用必须满足的语义要求，如列名、数据类型、长度、主/外键、是否为空等。
[0071] 图2为本发明实施例DNS数据存储系统的结构示意图，如图2所示，本发明实施例提供的DNS数据存储系统数据接收单元100、数据上传单元200和用户接口单元300。
[0072] 所述数据接收单100元用于接收来自前端主动请求的DNS数据。
[0073] 所述数据上传单元200用于接收来自所述数据接收单元100的输出DNS数据，并将DNS数据上传至用户指定内存。
[0074] 所述用户接口单元300在域名解析网络中开辟数据存储结构，实现对所述数据上传单元200上传数据的管理，所述数据存储结构为上述内容介绍的数据存储结构。
[0075] 其中，所述数据接收单元100为DNS数据接收单元，所述DNS数据接收单元用于接收来自前端采用DNS协议数据报文格式进行传输的数据。
[0076] 所述DNS数据存储系统是基于Mysql数据库管理系统而建立的
[0077] 与现有技术相比，本发明的技术效果如下：
[0078] 第一，本发明使用主外键关联建立表间关系实现了一个域名对应多条资源记录和权威信息记录的实际情况，既减少了大量的数据冗余，也在设计上避免了数据记录的遗漏。
[0079] 第二，本发明提供的数据存储结构中的每张表均满足主键约束条件和外键约束条件，既保证了数据的唯一性，也避免了出现不需要的资源记录被存储到该数据存储结构中。
[0080] 其中，主键约束条件：根据主键唯一的原则，每张表中可区分不同记录的字段；域名表：查询域名；邮件交换记录表：邮件服务器域名；资源记录表：IP或别名；授权资源记录表：权威服务器域名，从而能保证数据的唯一性。
[0081] 外键约束条件：除域名表外，其他表中name字段都是该域名表参照域名表设置的外键，通过外键建立域名与其他资源记录间的对应关系，也就是说参照表(一般资源记录表、邮件交换资源记录表、权威资源记录表)中的name字段的每一条数据都能在其被参照表(域名表)中找到对应数据，避免出现不需要的资源记录被存储进数据库中。
[0082] 第三，考虑到当数据量逐渐增大时，数据库数据删除和插入动作将占用大量资源和时间,系统效率会大大降低，因此本发明采用了创建索引的方法，在各表查询时都添加相应的索引，经测试发现效率显著提高。
[0083] 第四，本发明建立在Mysql的数据库管理系统上，在实现大量DNS解析信息存储的
基础上，通过搭建数据库服务器可实现多应用共享，使用视图的机制能够更加方便管理员的查阅和审计。
[0084] 本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本
说明书内容不应理解为对本发明的限制。
