CN116866306A - 域名的解析方法及装置、相关设备 - Google Patents

域名的解析方法及装置、相关设备 Download PDF

Info

Publication number
CN116866306A
CN116866306A CN202310851292.9A CN202310851292A CN116866306A CN 116866306 A CN116866306 A CN 116866306A CN 202310851292 A CN202310851292 A CN 202310851292A CN 116866306 A CN116866306 A CN 116866306A
Authority
CN
China
Prior art keywords
domain name
file
root
target domain
authoritative
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202310851292.9A
Other languages
English (en)
Inventor
李婷婷
李国辉
金鹏程
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
China Mobile Communications Group Co Ltd
China Mobile Suzhou Software Technology Co Ltd
Original Assignee
China Mobile Communications Group Co Ltd
China Mobile Suzhou Software Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by China Mobile Communications Group Co Ltd, China Mobile Suzhou Software Technology Co Ltd filed Critical China Mobile Communications Group Co Ltd
Priority to CN202310851292.9A priority Critical patent/CN116866306A/zh
Publication of CN116866306A publication Critical patent/CN116866306A/zh
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本公开提供一种域名的解析方法及装置、相关设备，其中，该方法包括：在基于客户端对目标域名进行解析时，从区块链域名解析网络的根对等节点中搜索目标域名所对应根区域文件，其中，根区域文件中包括目标域名中的顶级域名TLD信息和哈希值；区块链域名解析网络包括根对等节点和权威对等节点；基于从客户端获取的与目标域名对应的公钥对根区域文件进行验证；在验证通过的情况下，从与哈希值匹配的权威对等节点中获取子区域文件；从子区域文件中的资源集中解析出与目标域名对应的IP地址。在本申请实施例中由于根区域文件中的哈希值与子区域文件一一对应，因此保证了根区域与子区域数据存储的一致性，从而保证了资源记录集的一致性。

Description

域名的解析方法及装置、相关设备
技术领域
本公开涉及域名解析技术领域，具体涉及一种域名的解析方法及装置、相关设备。
背景技术
DNS(Domain Name System，域名系统)是为互联网上的域名解析提供服务的关键基础设施。使用域名的互联网应用程序(例如Web和电子邮件)依赖这些服务将域名正确转换为IP(Internet Protocol，网际互连协议)地址。目前，DNS不断发展并在互联网上发挥着广泛的作用，但域名解析过程的可用性和一致性长期以来一直困扰着DNS。域名解析可用性问题是指域的权威服务器无法响应域名解析请求，可用性问题是由拒绝服务(Denial ofService，DoS)攻击或单点故障(Single Point of Failure，SPOF)引起的。一致性问题源于权威服务器副本之间或父/子权威服务器之间缺乏强制数据同步机制，域名解析一致性问题是指一个域名的资源记录集(Resource Record Set，RRSet)在不同的存储位置不一致。针对可用性和一致性问题，增加DNS的加密安全保护是目前使用比较广泛的方法。目前主要的解决方案如下：
DNS缓存可以增加访问效率，DNS服务器执行递归并继续查询其他DNS服务器，直到它具有返回给客户端的IP地址为止，缓存递归DNS查询通常比迭代查询的解析速度更快。递归DNS服务器将对执行的每个查询的最终答案进行缓存，并将该最终答案保存一定的时间。
但DNS缓存会缓存不一致的问题，DNS缓存不一样的现象主要包括以下三种情况：1)父区的粘合记录与子区的存储不一致。这种被称为委托不一致现象。2)同一个RRSet在不同权威服务器副本之间不一致，称之为副本不一致现象。3)递归解析器中缓存的RRSet与权威服务器中存储的不一致，称之为缓存不一致现象。
发明内容
本公开的目的在于提供一种域名的解析方法及装置、相关设备，用于解决相关技术现有技术中DNS缓存存在数据缓存不一致的技术问题。
第一方面，本公开实施例提供一种域名的解析方法，所述方法包括：在基于客户端对目标域名进行解析时，从区块链域名解析网络的根对等节点中搜索目标域名所对应根区域文件，其中，所述根区域文件中包括所述目标域名中的顶级域名TLD信息和哈希值；所述区块链域名解析网络包括根对等节点和权威对等节点；基于从所述客户端获取的与所述目标域名对应的公钥对所述根区域文件进行验证；在验证通过的情况下，从与所述哈希值匹配的权威对等节点中获取子区域文件，其中，所述哈希值与所述子区域文件存在一一对应的关系；从所述子区域文件中的资源集中解析出与所述目标域名对应的IP地址。
在一个实施例中，在基于客户端对目标域名进行解析之前，所述方法还包括：在目标区块链网络的多个第一对等节点中存储所述根区域文件，并设置所述多个第一对等节点基于相同智能合约约束，以得到多个所述根对等节点；其中，所述根区域文件中包括哈希值，所述哈希值用于索引一一对应的子区域文件；在所述目标区块链网络的多个第二对等节点中存储所述子区域文件，以得到多个所述权威对等节点，其中，所述多个第二对等节点都以相同身份存储数据；基于多个所述根对等节点和多个所述权威对等节点构建所述区块链域名解析网络。
在一个实施例中，所述根区域文件和所述子区域文件均至少包括以下类型的数据：属于分层命名空间的域名、域名映射至的域数据、域名的公钥。
在一个实施例中，所述根区域文件包括：第一结构和第二结构；其中，所述第一结构包括用于存储TLD名称的第一字段、用于存储子域文件哈希值的第二字段、用于存储位置标识TLD授权实体公钥的第三字段、用于存储根授权生成的数字签名的第四字段、用于存储TLD机构生成的数字签名的第五字段；所述第二结构包括用于表征资源记录集的第六字段和用于对资源记录集进行签名生成的数字签名的第七字段。
在一个实施例中，基于从所述客户端获取的与所述目标域名对应的公钥对所述根区域文件进行验证，包括：获取所述根区域文件中第三字段中存储的公钥；基于从所述客户端获取的与所述目标域名对应的公钥与所述第三字段中存储的公钥进行比较。
在一个实施例中，在验证通过的情况下，从与所述哈希值匹配的权威对等节点中获取子区域文件，包括：在所述根区域文件中第三字段中存储公钥与所述目标域名对应的公钥匹配的情况下，从所述根区域文件中第二字段中获取所述哈希值；从与所述哈希值一一对应的权威对等节点中获取所述子区域文件。
在一个实施例中，所述方法还包括：在区域文件的容量大于预设阈值的情况下，将所述区域文件拆分为多个小文件块，并对所述多个小文件块进行上传和检索；在对所述多个小文件块进行上传和检索完成后，确定所述多个小文件块所对应的哈希值，并基于确定出的哈希值将所述多个小文件组合到新的区域文件中。
第二方面，本公开实施例还提供一种域名的解析装置，包括：搜索模块，用于在基于客户端对目标域名进行解析时，从区块链域名解析网络的根对等节点中搜索目标域名所对应根区域文件，其中，所述根区域文件中包括所述目标域名中的顶级域名TLD信息和哈希值；所述区块链域名解析网络包括根对等节点和权威对等节点；验证模块，用于基于从所述客户端获取的与所述目标域名对应的公钥对所述根区域文件进行验证；获取模块，用于在验证通过的情况下，从与所述哈希值匹配的权威对等节点中获取子区域文件，其中，所述哈希值与所述子区域文件存在一一对应的关系；解析模块，用于从所述子区域文件中的资源集中解析出与所述目标域名对应的IP地址。
第三方面，本公开实施例还提供一种电子设备，包括处理器、存储器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现上述的域名的解析方法的步骤。
第四方面，本公开实施例还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现上述的域名的解析方法的步骤。
在本公开实施例中，
在本申请实施例中的区块链域名解析网络包括根对等节点和权威对等节点，而跟对等节点相当于根服务器，权威对等节点相当于权威服务器，因此，在对目标域名进行解析时，可以从根对等节点中搜索目标域名所对应根区域文件，进而与目标域名对应的公钥对根区域文件进行验证，在验证通过的情况下，从与哈希值匹配的权威对等节点中获取子区域文件，并从该子区域文件中解析出对应的IP地址。由于本申请实施例中的根区域文件中的哈希值与子区域文件一一对应，因此保证了根区域与子区域数据存储的一致性，从而保证了资源记录集的一致性，解决了现有技术中DNS缓存存在数据缓存不一致的问题。
附图说明
为了更清楚地说明本公开实施例的技术方案，下面将对本公开实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1是本公开实施例提供的一种域名的解析方法的流程示意图；
图2是本公开实施例提供的另一种域名的解析方法的流程示意图；
图3是本公开实施例提供的在具体示例中区块链域名解析网络示意图；
图4是本公开实施例提供的在具体示例中对等节点的示意图；
图5是本公开实施例提供的在具体示例中区域文件结构示意图；
图6是本公开实施例提供的域名委托验证的示意图；
图7是本公开实施例提供的一种域名的解析装置的结构示意图；
图8是本公开实施例提供的一种电子设备的结构示意图。
具体实施方式
下面将结合本公开实施例中的附图，对本公开实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本公开一部分实施例，而不是全部的实施例。基于本公开中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本公开保护的范围。
本公开实施例提供一种域名的解析方法，如图1所示，所述方法包括：
步骤101，在基于客户端对目标域名进行解析时，从区块链域名解析网络的根对等节点中搜索目标域名所对应根区域文件，其中，根区域文件中包括目标域名中的顶级域名TLD信息和哈希值；区块链域名解析网络包括根对等节点和权威对等节点；
步骤102，基于从客户端获取的与目标域名对应的公钥对根区域文件进行验证；
步骤103，在验证通过的情况下，从与哈希值匹配的权威对等节点中获取子区域文件，其中，哈希值与子区域文件存在一一对应的关系；
步骤104，从子区域文件中的资源集中解析出与目标域名对应的IP地址。
通过本申请实施例的上述步骤101至步骤104可知，在本申请实施例中的区块链域名解析网络包括根对等节点和权威对等节点，而跟对等节点相当于根服务器，权威对等节点相当于权威服务器，因此，在对目标域名进行解析时，可以从根对等节点中搜索目标域名所对应根区域文件，进而与目标域名对应的公钥对根区域文件进行验证，在验证通过的情况下，从与哈希值匹配的权威对等节点中获取子区域文件，并从该子区域文件中解析出对应的IP地址。由于本申请实施例中的根区域文件中的哈希值与子区域文件一一对应，因此保证了根区域与子区域数据存储的一致性，从而保证了资源记录集的一致性，解决了现有技术中DNS缓存存在数据缓存不一致的问题。
也就是说，本申请实施例中的子域的区域文件的索引信息包含在父域的区域文件中，因此客户端能通过多次迭代查询得到目标域名的解析数据。现有技术中的DNS是通过存储子域区域文件的权威服务器的IP地址(粘合记录)来索引子域的区域文件，由于权威服务器与存储的数据不存在绑定关系，因此无法完全避免父子域的不一致。在本申请实施例中通过索引根区域文件的哈希值来索引子域的区域文件可以保证存储数据的一致性。另外，由于散列函数的特性，散列函数得到的区域文件的哈希值与区域文件具有天然的绑定关系。当客户端从根区域文件获取子区域文件的哈希值时，存储子域数据的区域文件是唯一确定的。在本申请实施例的具体示例中，散列函数的模型可以是：h＝H(M)，其中，M是子域数据的区域文件，h是存储子域数据的区域文件的哈希值，h具有固定的长度，且与M的长度无关；H存在单向性质：(1)给定H和M，很容易计算得出h；(2)给定h和H，很难计算得到M；(3)不存在M1和M2，使得H(M1)＝H(M2)。
在本申请实施例的可选实施方式中，在基于客户端对目标域名进行解析之前，如图2所示，本申请实施例的方法还可以包括：
步骤201，在目标区块链网络的多个第一对等节点中存储根区域文件，并设置多个第一对等节点基于相同智能合约约束，以得到多个根对等节点；其中，根区域文件中包括哈希值，哈希值用于索引一一对应的子区域文件；
步骤202，在目标区块链网络的多个第二对等节点中存储子区域文件，以得到多个权威对等节点，其中，多个第二对等节点都以相同身份存储数据；
步骤203，基于多个根对等节点和多个权威对等节点构建区块链域名解析网络。
通过上述步骤201至步骤203可知，在本申请实施例中的区块链域名解析网络包括两层，一层是根对等节点，一层是权威对等节点，如图3所示。其中，根对等节点充当DNS中的根服务器，响应根区域数据的查询。此外，根对等节点以身份检查的方式加入许可的区块链域名解析网络。所有根对等节点都执行描述实体(根/TLD授权)对资源的操作，例如TLD委托和域数据发布。该操作由所有根对等节点的基于共识的智能合约定义。因此，所有通过根节点发起操作的实体都受到相同智能合约的约束。每个实体都可以控制已委托给自己的TLD资源。此外，每个实体都可以基于合同约束参与其他实体资源的协同管理。
权威对等节点的作用类似于DNS中各个级别的权威服务器，为所有存储的域数据提供权威响应。在这个网络中，所有节点都可以作为所有域名(如TLD、二级域(SLD)等，根域除外)的权威服务器。存储域名数据的对等节点不再区分主从角色，所有对等节点都以相同的身份存储数据。
如图4所示，TLD Ta和Tc的两个权威对等节点，TLD Te的三个对等节点和SLD Sa的一个对等节点。每个对等节点都可以充当多个域的权威节点。例如，对等No.1是三个域(TLDa/c/e)的权威对等点，对等No.3是三个域(TLD c/e和SLD a)的权威对等点。
此外，本申请实施例中涉及到的根区域文件和子区域文件均至少包括以下类型的数据：属于分层命名空间的域名、域名映射至的域数据、域名的公钥。
可选地，本申请实施例中的根区域文件包括：第一结构和第二结构；其中，第一结构包括用于存储TLD名称的第一字段、用于存储子域文件哈希值的第二字段、用于存储位置标识TLD授权实体公钥的第三字段、用于存储根授权生成的数字签名的第四字段、用于存储TLD机构生成的数字签名的第五字段；第二结构包括用于表征资源记录集的第六字段和用于对资源记录集进行签名生成的数字签名的第七字段。
对于上述结构和字段，在具体示例的区域文件如图5所示：
结构IndexItem(第一结构)用于存储TLD的索引信息。IndexItem使用SubDomainName(对应于第一字段)、ZonefileHash(对应于第二字段)、AuthorityPublicKey(对应于第三字段)、PublicationSig(对应于第四字段)和DelegationSig(对应于第五字段)五个字段来索引TLD zonefile(区域文件)：
1)Sub DomainName字段存储TLD名称。
2)ZonefileHash字段存储子域区域文件的哈希值。
3)AuthorityPublicKey字段存储唯一标识TLD授权实体的公钥。
4)DelegationSig字段是根授权生成的数字签名，代表一个授权动作，这意味着TLD(SubDomainName)被授权给持有公钥(AuthorityPublicKey)的实体。
5)PublicationSig字段是TLD机构生成的数字签名，用于确保用于索引TLD区域数据的哈希值ZonefileHash的真实性和完整性。
结构DomainDataItem(对应于第二结构)存储属于根域名的数据。DomainDataItem至少包括两个字段：
1)RRSet(对应于第六字段)表示一个资源记录集，其格式符合DNS协议，由五个字段组成：name(名称)、class(种类)、type(类型)、ttl(生存时间)和rdata(记录数据)。
2)RRSig(对应于第七字段)字段是根权威机构对RRSet字段进行签名生成的数字签名，用于保护域数据的真实性和完整性。
此外，在本申请实施例的可选实施方式中，对于大区域文件存储，可以采用如下方式：在区域文件的容量大于预设阈值的情况下，将区域文件拆分为多个小文件块，并对多个小文件块进行上传和检索；在对多个小文件块进行上传和检索完成后，确定多个小文件块所对应的哈希值，并基于确定出的哈希值将多个小文件组合到新的区域文件中。
上述预设阈值可以根据实际需求进行相应的设置，例如将预设阈值设置为100MB，120MB等等。
基于上述本申请实施例中的区块链域名解析网络，对于上述步骤102中基于从客户端获取的与目标域名对应的公钥对根区域文件进行验证的方式，进一步可以包括：
步骤11，获取根区域文件中第三字段中存储的公钥；
步骤12，基于从客户端获取的与目标域名对应的公钥与第三字段中存储的公钥进行比较。
对于上述步骤11和步骤12，在具体示例中如图6中所示域名委托验证通过验证子域名的委托结果(DelegationSig)来实现的，需要Verify([parent]AuthorityPublicKey,DelegationSig)＝True来保证子域名委托给正确的注册人。即持有公钥(AuthorityPublicKey)的实体的注册人产生的数字签名与DelegationSig保持一致。
基于上述本申请实施例中的区块链域名解析网络，对于上述步骤103中涉及到的在验证通过的情况下，从与哈希值匹配的权威对等节点中获取子区域文件的方式，进一步包括：
步骤21，在根区域文件中第三字段中存储公钥与目标域名对应的公钥匹配的情况下，从根区域文件中第二字段中获取哈希值；
步骤22，从与哈希值一一对应的权威对等节点中获取子区域文件。
对于上述步骤21和步骤22，在具体示例中如图6中所示的区域文件数据验证，以对区域文件的真实性检查，验证子域a,sdkcfjdkmsmkqklmbv,l,,,,,,,,,,,,,,,,,,,,,,,3ercbffnhgdbjmngrjnhcdbfvvgdc域区域文件。
基于此，在具体示例中在本申请实施例中的架构中解析目标域名“www.example.com”的IP地址并确保域名解析过程的的步骤包括：
步骤31，为了解析“www.example.com”，根对等节点搜索根区域文件，然后将包含TLD“com”的IndexItem返回给客户端。
步骤32，客户端验证(最左边的红色箭头)TLD“com”已被委托给代表TLD授权实体的公钥。
步骤33，客户端使用正确的哈希值验证(最左边的蓝色箭头)由TLD“com”机构发布的区域文件。
步骤34客户端使用区域文件哈希来索引TLD“com”区域文件，以查找包含SLD“example.com”的IndexItem。
步骤35，客户端重复验证操作，直到获得“www.example.com”IP地址的RRSet和RRSig，到此目标域名被安全地解析。
因此，通过本申请实施例中的方式，使用散列函数使得散列函数得到的区域文件的散列值与区域文件具有天然的绑定关系，避免父子域不一致的情况；域名数据存储在区块链系统中，保证了数据的可用性。此外，在本申请实施例中的区域文件的数据结构中，使用域的权威公钥来保护域名解析结果的真实性；根权威机构签名生成的数字签名，有效保证了解析数据的完整性。另外，本申请实施例中的域名解析过程引入了去中心化，使得域名解析服务的数据安全，可溯源性得到了保证。去中心化存储是把数据将被切割成小块，经过加密后，分散存储在众多节点上，发挥了存储共享的优势，节省了中心化存储的建设成本。
如图7所示，本公开实施例还提供一种域名的解析装置700，所述装置700包括：
搜索模块702，用于在基于客户端对目标域名进行解析时，从区块链域名解析网络的根对等节点中搜索目标域名所对应根区域文件，其中，根区域文件中包括目标域名中的顶级域名TLD信息和哈希值；区块链域名解析网络包括根对等节点和权威对等节点；
验证模块704，用于基于从客户端获取的与目标域名对应的公钥对根区域文件进行验证；
获取模块706，用于在验证通过的情况下，从与哈希值匹配的权威对等节点中获取子区域文件，其中，哈希值与子区域文件存在一一对应的关系；
解析模块706，用于从子区域文件中的资源集中解析出与目标域名对应的IP地址。
可选地，本申请实施例中的装置还包括：第一存储模块，用于在基于客户端对目标域名进行解析之前，在目标区块链网络的多个第一对等节点中存储根区域文件，并设置多个第一对等节点基于相同智能合约约束，以得到多个根对等节点；其中，根区域文件中包括哈希值，哈希值用于索引一一对应的子区域文件；第二存储模块，用于在目标区块链网络的多个第二对等节点中存储子区域文件，以得到多个权威对等节点，其中，多个第二对等节点都以相同身份存储数据；构建模块，用于基于多个根对等节点和多个权威对等节点构建区块链域名解析网络。
可选地，本申请实施例中的根区域文件和子区域文件均至少包括以下类型的数据：属于分层命名空间的域名、域名映射至的域数据、域名的公钥。
可选地，本申请实施例中的根区域文件包括：第一结构和第二结构；其中，第一结构包括用于存储TLD名称的第一字段、用于存储子域文件哈希值的第二字段、用于存储位置标识TLD授权实体公钥的第三字段、用于存储根授权生成的数字签名的第四字段、用于存储TLD机构生成的数字签名的第五字段；第二结构包括用于表征资源记录集的第六字段和用于对资源记录集进行签名生成的数字签名的第七字段。
可选地，本申请实施例中的验证模块包括：第一获取单元，用于获取根区域文件中第三字段中存储的公钥；比较单元，用于基于从客户端获取的与目标域名对应的公钥与第三字段中存储的公钥进行比较。
可选地，本申请实施例中的获取模块包括：第二获取单元，用于在根区域文件中第三字段中存储公钥与目标域名对应的公钥匹配的情况下，从根区域文件中第二字段中获取哈希值；第三获取单元，用于从与哈希值一一对应的权威对等节点中获取子区域文件。
可选地，本申请实施例中的装置还包括：第一处理模块，用于在区域文件的容量大于预设阈值的情况下，将区域文件拆分为多个小文件块，并对多个小文件块进行上传和检索；第二处理模块，用于在对多个小文件块进行上传和检索完成后，确定多个小文件块所对应的哈希值，并基于确定出的哈希值将多个小文件组合到新的区域文件中。
本公开实施例提供的域名的解析装置700能够实现上述方法实施例中的各个过程，且达到相同的技术效果，为避免重复，这里不再赘述。
请参见图8，图8是本公开实施例提供的一种电子设备的结构示意图，如图8所示，电子设备包括：可以包括处理器801、存储器802及存储在存储器802上并可在处理器801上运行的程序8021。
程序8021被处理器801执行时可实现图1对应的方法实施例中的任意步骤及达到相同的有益效果，此处不再赘述。
本领域普通技术人员可以理解实现上述实施例方法的全部或者部分步骤是可以通过程序指令相关的硬件来完成，所述的程序可以存储于一可读取介质中。
本公开实施例还提供一种可读存储介质，所述可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时可实现上述图1对应的方法实施例中的任意步骤，且能达到相同的技术效果，为避免重复，这里不再赘述。
本公开实施例的计算机可读存储介质，可以采用一个或多个计算机可读的介质的任意组合。计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质。计算机可读存储介质例如可以是电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本文件中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。
计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。
存储介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、电线、光缆、RF等等，或者上述的任意合适的组合。
可以以一种或多种程序设计语言或其组合来编写用于执行本公开操作的计算机程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、Smalltalk、C++，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或终端上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络——包括局域网(LAN)或广域网(WAN)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。
以上所述是本公开实施例的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本公开所述原理的前提下，还可以作出若干改进和润饰，这些改进和润饰也应视为本公开的保护范围。

Claims (10)

1.一种域名的解析方法，其特征在于，所述方法包括：
在基于客户端对目标域名进行解析时，从区块链域名解析网络的根对等节点中搜索目标域名所对应根区域文件，其中，所述根区域文件中包括所述目标域名中的顶级域名TLD信息和哈希值；所述区块链域名解析网络包括根对等节点和权威对等节点；
基于从所述客户端获取的与所述目标域名对应的公钥对所述根区域文件进行验证；
在验证通过的情况下，从与所述哈希值匹配的权威对等节点中获取子区域文件，其中，所述哈希值与所述子区域文件存在一一对应的关系；
从所述子区域文件中的资源集中解析出与所述目标域名对应的IP地址。
2.根据权利要求1所述的方法，其特征在于，在基于客户端对目标域名进行解析之前，所述方法还包括：
在目标区块链网络的多个第一对等节点中存储所述根区域文件，并设置所述多个第一对等节点基于相同智能合约约束，以得到多个所述根对等节点；其中，所述根区域文件中包括哈希值，所述哈希值用于索引一一对应的子区域文件；
在所述目标区块链网络的多个第二对等节点中存储所述子区域文件，以得到多个所述权威对等节点，其中，所述多个第二对等节点都以相同身份存储数据；
基于多个所述根对等节点和多个所述权威对等节点构建所述区块链域名解析网络。
3.根据权利要求1所述的方法，其特征在于，所述根区域文件和所述子区域文件均至少包括以下类型的数据：属于分层命名空间的域名、域名映射至的域数据、域名的公钥。
4.根据权利要求3所述的方法，其特征在于，所述根区域文件包括：第一结构和第二结构；
其中，所述第一结构包括用于存储TLD名称的第一字段、用于存储子域文件哈希值的第二字段、用于存储位置标识TLD授权实体公钥的第三字段、用于存储根授权生成的数字签名的第四字段、用于存储TLD机构生成的数字签名的第五字段；
所述第二结构包括用于表征资源记录集的第六字段和用于对资源记录集进行签名生成的数字签名的第七字段。
5.根据权利要求4所述的方法，其特征在于，基于从所述客户端获取的与所述目标域名对应的公钥对所述根区域文件进行验证，包括：
获取所述根区域文件中第三字段中存储的公钥；
基于从所述客户端获取的与所述目标域名对应的公钥与所述第三字段中存储的公钥进行比较。
6.根据权利要求5所述的方法，其特征在于，在验证通过的情况下，从与所述哈希值匹配的权威对等节点中获取子区域文件，包括：
在所述根区域文件中第三字段中存储公钥与所述目标域名对应的公钥匹配的情况下，从所述根区域文件中第二字段中获取所述哈希值；
从与所述哈希值一一对应的权威对等节点中获取所述子区域文件。
7.根据权利要求1所述的方法，其特征在于，所述方法还包括：
在区域文件的容量大于预设阈值的情况下，将所述区域文件拆分为多个小文件块，并对所述多个小文件块进行上传和检索；
在对所述多个小文件块进行上传和检索完成后，确定所述多个小文件块所对应的哈希值，并基于确定出的哈希值将所述多个小文件组合到新的区域文件中。
8.一种域名的解析装置，其特征在于，包括：
搜索模块，用于在基于客户端对目标域名进行解析时，从区块链域名解析网络的根对等节点中搜索目标域名所对应根区域文件，其中，所述根区域文件中包括所述目标域名中的顶级域名TLD信息和哈希值；所述区块链域名解析网络包括根对等节点和权威对等节点；
验证模块，用于基于从所述客户端获取的与所述目标域名对应的公钥对所述根区域文件进行验证；
获取模块，用于在验证通过的情况下，从与所述哈希值匹配的权威对等节点中获取子区域文件，其中，所述哈希值与所述子区域文件存在一一对应的关系；
解析模块，用于从所述子区域文件中的资源集中解析出与所述目标域名对应的IP地址。
9.一种电子设备，其特征在于，包括处理器、存储器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现如权利要求1至7中任一项所述方法的步骤。
10.一种可读存储介质，其特征在于，所述可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如权利要求1至7中任一项所述方法的步骤。
CN202310851292.9A 2023-07-12 2023-07-12 域名的解析方法及装置、相关设备 Pending CN116866306A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202310851292.9A CN116866306A (zh) 2023-07-12 2023-07-12 域名的解析方法及装置、相关设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202310851292.9A CN116866306A (zh) 2023-07-12 2023-07-12 域名的解析方法及装置、相关设备

Publications (1)

Publication Number Publication Date
CN116866306A true CN116866306A (zh) 2023-10-10

Family

ID=88221173

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202310851292.9A Pending CN116866306A (zh) 2023-07-12 2023-07-12 域名的解析方法及装置、相关设备

Country Status (1)

Country Link
CN (1) CN116866306A (zh)

Similar Documents

Publication Publication Date Title
US10178069B2 (en) Systems and methods for managing top-level domain names using consortium blockchain
US10230526B2 (en) Out-of-band validation of domain name system records
CN108064444B (zh) 一种基于区块链的域名解析系统
Afanasyev et al. NDNS: A DNS-like name service for NDN
US20230370284A1 (en) Proving top level domain name control on a blockchain
US10057207B2 (en) Smart navigation for shortened URLs
Kaminsky et al. Decentralized user authentication in a global file system
CN111031074B (zh) 一种认证方法、服务器和客户端
TW200424866A (en) Method and system for peer-to-peer authorization
US10848301B1 (en) DNS-based public key infrastructure for digital object architectures
van Adrichem et al. A measurement study of DNSSEC misconfigurations
Wang et al. Blockzone: A blockchain-based dns storage and retrieval scheme
JP7553055B2 (ja) 分散台帳に関連付けられた宛先アドレッシング
CN114567553A (zh) 一种基于工业互联网标识解析体系的设备入网方法及装置
Zhang et al. Blockchain‐Based DNS Root Zone Management Decentralization for Internet of Things
US20050086213A1 (en) Server apparatus, information providing method and program product therefor
CN113037886B (zh) 网络设备的管理方法、装置、介质以及电子设备
CN110071810A (zh) 一个基于开源dns软件的自证根实现方法
Liu et al. A secure domain name resolution and management architecture based on blockchain
CN116938875A (zh) 域名检测方法、域名解析器、电子设备和存储介质
Ma et al. Stale TLS certificates: investigating precarious third-party access to valid TLS keys
CN115941280B (zh) 基于web指纹信息的渗透方法、装置、设备及介质
CN116866306A (zh) 域名的解析方法及装置、相关设备
WO2023040070A1 (zh) 一种域名接管漏洞的检测方法和装置
US10432584B1 (en) Managing lame delegated domains within a managed DNS service

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination