CN104468859B - 支持携带服务地址信息的dane扩展查询方法和系统 - Google Patents

支持携带服务地址信息的dane扩展查询方法和系统 Download PDF

Info

Publication number
CN104468859B
CN104468859B CN201410705519.XA CN201410705519A CN104468859B CN 104468859 B CN104468859 B CN 104468859B CN 201410705519 A CN201410705519 A CN 201410705519A CN 104468859 B CN104468859 B CN 104468859B
Authority
CN
China
Prior art keywords
server
address
resource records
tlsa
client
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.)
Active
Application number
CN201410705519.XA
Other languages
English (en)
Other versions
CN104468859A (zh
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 Internet Network Information Center
Original Assignee
Computer Network Information Center of CAS
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 Computer Network Information Center of CAS filed Critical Computer Network Information Center of CAS
Priority to CN201410705519.XA priority Critical patent/CN104468859B/zh
Priority to PCT/CN2014/095172 priority patent/WO2016082274A1/zh
Publication of CN104468859A publication Critical patent/CN104468859A/zh
Application granted granted Critical
Publication of CN104468859B publication Critical patent/CN104468859B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • 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/40—Network security protocols
    • 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/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • 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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • 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/16—Implementing security features at a particular protocol layer
    • H04L63/166—Implementing security features at a particular protocol layer at the transport layer

Landscapes

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

Abstract

本发明涉及一种支持携带服务地址信息的DANE扩展查询方法和系统。客户端发送查询TLSA资源记录的DNS请求消息，所述DNS请求消息的头部设有服务地址标志位；递归服务器和权威服务器响应客户端发来的DNS请求消息，根据所述服务地址标志位的设置情况填充对应的地址信息，将该地址信息和TLSA资源记录通过响应数据包返回给客户端。本发明通过在其TLSA资源记录中增加标志位和数据字段实现了DANE协议的扩展机制，能够显著提高整个域名解析流程的效率。

Description

支持携带服务地址信息的DANE扩展查询方法和系统
技术领域
本发明属于网络技术、DNS技术领域，具体涉及一种支持携带服务地址信息的DANE扩展查询方法和系统。
背景技术
通过互联网进行通信的应用程序面临信息被偷听、篡改或伪造的威胁，为此，当前互联网上有安全需求的数据传输一般采用传输层安全(Transport Layer Security，TLS)协议，对信道进行加密，来确保数据的完整性、机密性。TLS协议利用密钥算法在互联网上提供端点身份认证与通信保密，其基础是数字认证机构(Certification Authority，CA)，即通过数字证书来绑定公钥与相关信息(包括所有者的名字、CA名称、公钥的有效期、CA的数字签名等)。CA机构会妥善保管其私钥，为TLS服务器签发数字证书，并将其公钥提供给TLS客户端。TLS客户端将CA机构自己的公钥视为“信任锚点”，并以此来验证TLS服务器证书的有效性。验证通过后，TLS服务器与客户端之间就可以进行安全通信了。上述公共CA模式虽应用广泛，但仍存在不尽如人意的地方，给信息的安全传输带来隐患：CA模式允许任何CA为TLS服务器签发数字证书，这会使系统变得脆弱，一旦某个CA违背安全承诺，不管是因为主观原因还是客观原因(如私钥发生泄漏)，都必将造成该CA签发的所有数字证书失去安全功能。例如，微软曾发布过一条CA安全预警，发现一家名为Comodo的CA机构颁发了欺骗性的数字证书，给微软、谷歌等公司的网站带来损害。
为此，IETF DANE(DNS-Based Authentication of Named Entities，基于DNS的命名实体认证)工作组设计了一种新的DNS资源记录TLSA(TLSA仅是一种资源记录的名称，无其它含义)，以使用DNSSEC(Domain Name System Security Extensions，DNS安全扩展)基础设施来保存TLS协议中用到的数字证书或公钥。DANE协议的核心是：依托DNSSEC(DNSSEC是由IETF提供的一系列DNS安全认证的机制(可参考RFC2535)。它提供了DNS数据的来源鉴定和完整性保证)基础设施来限制TLS服务器可用的CA范围，从而使区(zone)操作员可以声明可供TLS客户端使用的数字签名的范围。
具体而言，此类声明分为三大类：
(1)CA限制声明：TLS客户端只能接受某些特定CA颁发的数字证书，若TLS服务器传输的数字证书不是由这些特定的CA所颁发，则TLS客户端可视这些数字证书为无效；
(2)证书限制声明：TLS客户端只能接受某个特定的数字证书(或公钥)，而不是其它证书(或公钥)，这样就对TLS能用的CA数字证书或公钥做了进一步限制；
(3)信任锚点声明：TLS客户端应使用由该区声明的信任锚点来验证该区的数字证书。
所有上述三类声明均可视为对信任锚点范围的限制，前两类主要限制当前已有信任锚点的范围，而第三类为TLS客户端提供了一个新的信任锚点。
RFC6698定义了DANE资源记录TLSA的具体协议格式，TLSA资源记录包含四个选项，分别为：Cert.Usage、Selector、Matching Type和Certificate Association Data。
其作用分别为：
(1)Cert.Usage：用来指示声明的具体类型；由上可知，共分三种类型：CA限制型、证书限制型、信任锚点声明；
(2)Selector：用来指示Certificate Association Data中所存的数据来自TLS服务器证书中的哪一部分；Selector有两个选项：一个用于指示所存数据为数字证书，另一个用于指示所存数据为公钥；
(3)Matching Type：用来指示TLSA资源记录中的Certificate Association Data如何与TLS服务器数字证书中的原始数据进行匹配；共有三种方式：原始数据直接匹配、对原始数据进行SHA-256哈希后匹配、对原始数据进行SHA-512哈希后匹配；
(4)Certificate Association Data：存储相关数据，数据类型由Selector指定。
现举例说明DANE原理如下：
假设Alice在区example.cn上维护着一些Web资源，为确保该域名的安全运行，Alice不希望随便哪个CA都可以为example.cn颁发数字证书，则Alice需要指定某个CA(假设为Bob)，且只有由该CA为example.cn颁发的数字证书才有效。此时，Alice希望告诉所有的客户端：只有Bob的数字证书才是有效的，其它任何CA的数字证书都是无效的。有了TLSA记录，这一愿望就很容易实现，Alice只需在TLSA资源记录中增加以下内容：
●Usage：限制CA
●Selector：数字证书
●Matching Type：SHA-256哈希
●Certificate Association Data：Bob数字证书的SHA-256哈希值
假设客户端为Charlie，在其访问example.cn的Web资源时，可以收到上述TLSA资源记录，并使用上述内容来验证其收到的、来自example.cn的TLS数字证书。若该证书由Bob签发，则有效，否则无效。
DANE协议使用DNSSEC基础设施来保存TLS协议中用到的数字证书或公钥，这使得DANE协议继承了DNSSEC协议的各种优点。DNSSEC是由IETF提供的一系列DNS安全认证机制，用于提供一种关于来源鉴定和数据完整性的扩展。虽然原理与CA模型类似，DNSSEC也是基于数字签名等技术，但它在以下三个方面对基础的CA模型做了改进。
(1)密钥是与DNS中的域名相绑定，而不是与任意的标识符相绑定，以便各类互联网协议使用；
(2)签名后的公钥可以通过DNS系统来获取，客户端只需发送一个普通的DNS请求就可以查询到所需的公钥，公钥的分发非常简单；
(3)一个区的密钥只能由其父区的密钥来签名，例如，区“example.com”的密钥只能由区“.com”来签名，而区“.com”的密钥只能由根密钥来签名。
在CA模型和DNSSEC中，客户端都保存了信任机构的公钥并用此来验证其它实体身份信息的合法性；不同的是，在DNSSEC中，该公钥只保存在单个根域中，而在CA模型中，公钥却保存在不同的CA中。
DANE协议为DNS区操作员带来了配置灵活性，为TLS传输增加了安全性，但DANE协议的加入会增大TLS连接过程的延时。除完成TLS握手以及数字证书验证之外，TLS客户端还需等待若干个DNS往返信令交互后才能获知经验证的证书以及可访问的服务器地址。这将导致TLS连接建立时延长达数秒，使一些实时性较高的业务无法忍受。这主要由于DANE的查询需要生成一个包含特殊前缀信息的域名，前缀中包含支持TLS服务的端口号和对应的协议类型，如：
1)如请求一个在443端口运行TLS的HTTP服务器，服务器域名为www.example.com，那么查询的TLSA资源记录对应域名为：_443._tcp.www.example.com；
2)如请求一个在25端口运行STARTTLS的SMTP服务器，服务器域名为mail.example.com，那么查询的TLSA资源记录对应域名为：_25._tcp.mail.example.com。
因此，客户端查询服务器的地址信息(A记录或AAAA记录)与其TLSA记录成为两个分离的步骤，带来了协议开销的不必要增大和服务时延的增加。
发明内容
本发明针对上述问题，提供一种支持携带服务地址信息的DANE扩展查询方法和系统，通过在其TLSA资源记录中增加标志位和数据字段实现了DANE协议的扩展机制，能够显著提高整个域名解析流程的效率。
为实现上述目的，本发明采用如下技术方案：
一种支持携带服务地址信息的DANE扩展查询方法，包括如下步骤：
1)客户端发送查询TLSA资源记录的DNS请求消息，所述DNS请求消息的头部设有服务地址(Service Address，SA)标志位；
2)递归服务器和权威服务器响应客户端发来的DNS请求消息，根据所述服务地址标志位的设置情况填充对应的地址信息，将该地址信息和TLSA资源记录通过响应数据包返回给客户端。
进一步地，所述服务地址标志位为两比特标志位，其取值为00、01、10和11，其含义分别如下：
00：客户端不请求服务器的任何地址信息；
01：客户端请求在TLSA资源记录返回同时携带服务器的IPv4地址信息，在DNS响应消息中不仅包含服务器的TLSA资源记录，还携带至少一个32比特的IPv4地址；
10：客户端请求在TLSA资源记录返回同时携带服务器的IPv6地址信息，在DNS响应消息中不仅包含服务器的TLSA资源记录，还携带至少一个128比特的IPv6地址；
11：客户端请求在TLSA资源记录返回同时携带服务器的IPv4和IPv6地址信息，在DNS响应消息中不仅包含服务器的TLSA资源记录，还携带至少一个32比特IPv4地址以及至少一个128比特的IPv6地址。
进一步地，步骤2)采用递归服务器模式实现：递归服务器接收到客户端的DNS请求消息之后，根据服务地址标志位和待查询的服务域名构造对应的A记录查询请求和/或AAAA记录查询请求，并将新的请求消息发送给对应的权威服务器，递归服务器从权威服务器接收到TLSA以及A/AAAA记录查询应答后，将其返回给客户端。
进一步地，步骤2)采用权威服务器模式实现：递归服务器把从客户端接收到的DNS请求消息不修改地发送给对应的权威服务器，权威服务器根据服务地址标志位的设置情况构造响应消息，并发送回递归服务器进而发送给客户端。
一种采用上述方法的支持携带服务地址信息的DANE扩展查询系统，包括客户端、递归服务器和权威服务器，其特征在于，所述客户端发出的DNS请求消息的头部设有服务地址(Service Address，SA)标志位；递归服务器和权威服务器响应客户端发来的DNS请求消息时，根据所述服务地址标志位的设置情况填充对应的地址信息，将该地址信息和TLSA资源记录通过响应数据包返回给客户端。
本发明通过在其TLSA资源记录中增加标志位和数据字段，实现了支持携带服务地址信息的DANE扩展机制，以及基于该扩展机制的DNS查询，减小了TLS连接过程的延时，优化了客户端与递归服务器、权威服务器之间的传输开销，显著提高了整个域名解析流程的效率。
附图说明
图1是实施例中扩展的DNS请求消息示意图。
图2是实施例中扩展的DNS查询流程图。
具体实施方式
下面通过具体实施例和附图，对本发明做进一步说明。
本发明扩展了DANE协议，在其TLSA资源记录中增加了标志位和数据字段，并规范了其协议流程，主要内容包括：在DNS消息头部增加两比特的SA(Service Address，服务地址)标志位；规范了在查询TLSA资源记录时如何包含IPv4地址的32比特数据字段和包含IPv6地址的128比特数据字段；定义了使用SA标志位及其数据字段的规则和扩展的DANE协议流程。
1)SA标志位
SA标志位为两比特标志位，其有效性仅存在于DNS请求消息的类型的TLSA，本发明扩展后的DNS请求消息头部格式如图1所示：
SA取值为00、01、10和11。其含义分别如下：
●00：客户端不请求服务器的任何地址信息；
●01：客户端请求在TLSA资源记录返回同时携带服务器的IPv4地址信息，如果置此值，在DNS响应消息中不仅应包含服务器的TLSA资源记录，还应携带至少一个32比特的IPv4地址；
●10：客户端请求在TLSA资源记录返回同时携带服务器的IPv6地址信息，如果置此值，在DNS响应消息中不仅应包含服务器的TLSA资源记录，还应携带至少一个128比特的IPv6地址；
●11：客户端请求在TLSA资源记录返回同时携带服务器的IPv4和IPv6地址信息，如果置此值，在DNS响应消息中不仅应包含服务器的TLSA资源记录，还应携带至少一个32比特IPv4地址以及至少一个128比特的IPv6地址。
上述SA的四个取值只是标识作用，因此也可以采用其它顺序对应上述四种含义，比如01也可以用来表示00的含义，00也可以用来表示01的含义等，本发明不受此限制。
2)地址信息
本发明旨在以可扩展的方式在一个TLSA请求过程中按照客户端需求返回一个或多个IP地址。因此，可以完全兼容使用基本DNS消息的响应格式，故提出两种携带地址信息的机制：
(1)将地址信息放置在TLSA RDATA之后，以此来灵活支持多个地址信息(由于TLSA资源记录只有一个，其响应消息中的RDLENGTH可以控制RDATA的大小)。此外，在DNS响应消息中，应该指示所包含的地址的类型，可以通过响应消息中的TYPE进行指示。在本发明中暂不规定TYPE的取值，但在实际应用中需要通过TYPE区分如下四种类型：
●仅包含TLSA资源记录；
●包含TLSA资源记录和A资源记录；
●包含TLSA资源记录和AAAA资源记录；
●包含TLSA、A和AAAA资源记录。
A与AAAA资源记录的数量可以通过传统DNS响应消息中的RDLENGTH指示。如不能按照请求类型返回相关地址，则应在响应消息中进行错误指示，但尽可能返回服务地址，例如：客户端请求A和AAAA资源记录，但服务器并不支持IPv6，则只返回A资源记录。
(2)另一种实施方案是在DNS响应数据包的Additional字段中携带上述地址信息。
3)查询模式
基于此扩展机制的实际应用场景，本发明提出两种查询模式：
●递归服务器模式
在此模式下，希望查询TLSA记录同时返回服务地址信息的客户端首先在DNS请求消息中设置SA标志位。递归服务器接收到客户端的DNS请求消息之后，发现其中有非00的SA标志位设置，将认为客户端希望获得TLSA记录同时能得到该服务的地址信息，递归服务器进一步将根据SA标志位和待查询的服务域名构造对应的A记录查询请求或(和)AAAA记录查询请求，并将新的请求消息独立发送给对应的权威服务器。
递归服务器接收到TLSA以及A/AAAA记录查询应答后，以两种模式返回给客户端：1)构造一个响应消息，其中按照SA标志位指示填充对应的地址信息；2)接收到该域名的查询响应就立刻按返回顺序传输给客户端。
●权威服务器模式
在此模式下，递归服务器把从客户端接收到的DNS查询请求消息不修改地发送给对应的权威服务器，权威服务器根据SA标志位的设置情况构造响应消息，并发送回递归服务器进而发送给客户端。
●比较
在递归服务器模式下，权威服务器无需支持本发明所提机制，但其对于基本协议的优化程度较低，即仅优化了客户端和递归服务器之间的传输开销；在权威服务器模式下，权威服务器需支持本发明所提机制，当然也实现了最大限度的优化，显著提高了整个域名解析流程的效率。对于后者，应根据具体实施选择如何携带地址信息(即是否放在Additional字段中)。
4)示例
本实施例中，客户端希望访问在443端口运行TLS的HTTP服务器，服务器域名为www.example.com，那么查询的TLSA资源记录对应域名为_443._tcp.www.example.com。假设客户端没有www.example.com的服务地址，并希望能通过IPv4或IPv6访问该服务。因此通过两种模式的查询如图2所示。
在模式(1)即递归服务器模式下，客户端首先发送DNS请求，其中包含的查询域名为_443._tcp.www.example.com，表示查询该域名的TLSA资源记录，此外请求消息中包含设置为11的SA标志位，表明此客户端希望查询该域名对应的A和AAAA资源记录。递归服务器接收到之后，拆分该数据包为查询TLSA类型的DNS请求以及查询www.example.com的ANY类型(包含该域名的A与AAAA等多种记录的DNS请求类型)的DNS请求。这两个消息都是通常的DNS请求，所以没有SA标志位。权威服务器则分别对其进行响应，进而由递归服务器发送给客户端。
在模式(2)即权威服务器模式下，客户端首先发送DNS请求，其中包含的查询域名为_443._tcp.www.example.com，表示查询该域名的TLSA资源记录，此外请求消息中包含设置为11的SA标志位，表明此客户端希望查询该域名对应的A和AAAA资源记录。递归服务器直接转发该查询数据包权威服务器，权威服务器接收到查询请求后意识到该递归服务器希望获得该域名的TLSA以及对应的地址信息。所以构造一个响应数据包，其中也包含设置为11的SA标志位，进而由递归服务器发送给客户端。
以上实施例仅用以说明本发明的技术方案而非对其进行限制，本领域的普通技术人员可以对本发明的技术方案进行修改或者等同替换，而不脱离本发明的精神和范围，本发明的保护范围应以权利要求所述为准。

Claims (10)

1.一种支持携带服务地址信息的DANE扩展查询方法，其特征在于，包括如下步骤：
1)客户端发送查询TLSA资源记录的DNS请求消息，所述DNS请求消息的头部设有用于查询A资源记录和/或AAAA资源记录的服务地址标志位；
2)递归服务器和权威服务器响应客户端发来的DNS请求消息，根据所述服务地址标志位的设置情况填充对应的地址信息，该地址信息为A资源记录和/或AAAA资源记录，将该地址信息和TLSA资源记录通过响应数据包返回给客户端。
2.如权利要求1所述的方法，其特征在于：所述服务地址标志位为两比特标志位，其取值为00、01、10和11，其含义分别如下：
00：客户端不请求服务器的任何地址信息；
01：客户端请求在TLSA资源记录返回同时携带服务器的IPv4地址信息，在DNS响应消息中不仅包含服务器的TLSA资源记录，还携带至少一个32比特的IPv4地址；
10：客户端请求在TLSA资源记录返回同时携带服务器的IPv6地址信息，在DNS响应消息中不仅包含服务器的TLSA资源记录，还携带至少一个128比特的IPv6地址；
11：客户端请求在TLSA资源记录返回同时携带服务器的IPv4和IPv6地址信息，在DNS响应消息中不仅包含服务器的TLSA资源记录，还携带至少一个32比特IPv4地址以及至少一个128比特的IPv6地址。
3.如权利要求1或2所述的方法，其特征在于：所述递归服务器和权威服务器响应客户端的DNS请求消息时，将地址信息放置在TLSA RDATA之后，或者在DNS响应数据包的Additional字段中携带上述地址信息。
4.如权利要求3所述的方法，其特征在于：对于所述将地址信息放置在TLSA RDATA之后的方式，在DNS响应消息中通过TYPE指示所包含的地址的类型，包括四种类型：仅包含TLSA资源记录；包含TLSA资源记录和A资源记录；包含TLSA资源记录和AAAA资源记录；包含TLSA、A和AAAA资源记录。
5.如权利要求4所述的方法，其特征在于：通过传统DNS响应消息中的RDLENGTH指示A与AAAA资源记录的数量；如不能按照请求类型返回相关地址，则应在响应消息中进行错误指示。
6.如权利要求1所述的方法，其特征在于，步骤2)采用递归服务器模式实现：递归服务器接收到客户端的DNS请求消息之后，根据服务地址标志位和待查询的服务域名构造对应的A记录查询请求和/或AAAA记录查询请求，并将新的请求消息发送给对应的权威服务器，递归服务器从权威服务器接收到TLSA以及A和/或AAAA记录查询应答后，将其返回给客户端。
7.如权利要求6所述的方法，其特征在于，递归服务器将TLSA以及A和/或AAAA记录查询应答以两种模式返回给客户端：a)构造一个响应消息，其中按照服务地址标志位指示填充对应的地址信息；b)接收到该域名的查询响应就立刻按返回顺序传输给客户端。
8.如权利要求1所述的方法，其特征在于，步骤2)采用权威服务器模式实现：递归服务器把从客户端接收到的DNS请求消息不修改地发送给对应的权威服务器，权威服务器根据服务地址标志位的设置情况构造响应消息，并发送回递归服务器进而发送给客户端。
9.一种采用权利要求1所述方法的支持携带服务地址信息的DANE扩展查询系统，包括客户端、递归服务器和权威服务器，其特征在于，所述客户端发出的DNS请求消息的头部设有用于查询该A资源记录和/或AAAA资源记录的服务地址标志位；递归服务器和权威服务器响应客户端发来的DNS请求消息时，根据所述服务地址标志位的设置情况填充对应的地址信息，该地址信息为A资源记录和/或AAAA资源记录，将该地址信息和TLSA资源记录通过响应数据包返回给客户端。
10.如权利要求9所述的系统，其特征在于：所述服务地址标志位为两比特标志位，其取值为00、01、10和11，其含义分别如下：
00：客户端不请求服务器的任何地址信息；
01：客户端请求在TLSA资源记录返回同时携带服务器的IPv4地址信息，在DNS响应消息中不仅包含服务器的TLSA资源记录，还携带至少一个32比特的IPv4地址；
10：客户端请求在TLSA资源记录返回同时携带服务器的IPv6地址信息，在DNS响应消息中不仅包含服务器的TLSA资源记录，还携带至少一个128比特的IPv6地址；
11：客户端请求在TLSA资源记录返回同时携带服务器的IPv4和IPv6地址信息，在DNS响应消息中不仅包含服务器的TLSA资源记录，还携带至少一个32比特IPv4地址以及至少一个128比特的IPv6地址。
CN201410705519.XA 2014-11-27 2014-11-27 支持携带服务地址信息的dane扩展查询方法和系统 Active CN104468859B (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN201410705519.XA CN104468859B (zh) 2014-11-27 2014-11-27 支持携带服务地址信息的dane扩展查询方法和系统
PCT/CN2014/095172 WO2016082274A1 (zh) 2014-11-27 2014-12-26 支持携带服务地址信息的dane扩展查询方法和系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201410705519.XA CN104468859B (zh) 2014-11-27 2014-11-27 支持携带服务地址信息的dane扩展查询方法和系统

Publications (2)

Publication Number Publication Date
CN104468859A CN104468859A (zh) 2015-03-25
CN104468859B true CN104468859B (zh) 2018-01-30

Family

ID=52914206

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201410705519.XA Active CN104468859B (zh) 2014-11-27 2014-11-27 支持携带服务地址信息的dane扩展查询方法和系统

Country Status (2)

Country Link
CN (1) CN104468859B (zh)
WO (1) WO2016082274A1 (zh)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109257450A (zh) * 2017-07-13 2019-01-22 中国移动通信有限公司研究院 域名解析方法、网络终端及域名解析系统及存储介质
CN110392123B (zh) * 2018-04-23 2022-06-14 阿里巴巴集团控股有限公司 检测出口ip地址的方法、装置和系统
CN110741361B (zh) * 2018-11-08 2024-02-06 Oppo广东移动通信有限公司 资源查询处理方法、装置、计算机设备和存储介质
CN109547583B (zh) * 2018-11-22 2022-02-25 中国移动通信集团江苏有限公司 域名资源查询方法、装置、设备及计算机存储介质
CN112667309A (zh) * 2020-12-22 2021-04-16 互联网域名系统北京市工程研究中心有限公司 DoT在DNS权威服务器上的支持方法及系统
CN114006724B (zh) * 2021-09-18 2023-08-29 中国互联网络信息中心 一种加密dns解析器发现及认证的方法与系统

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103078877A (zh) * 2013-01-31 2013-05-01 中国科学院计算机网络信息中心 基于dns的用户认证和域名访问控制方法及系统
CN103491073A (zh) * 2013-09-09 2014-01-01 中国科学院计算机网络信息中心 在c/s网络架构下基于tlsa协议的安全通信方法
CN103929435A (zh) * 2014-05-05 2014-07-16 中国科学院计算机网络信息中心 一种基于dnssec及dane协议的可信验证方法

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140244998A1 (en) * 2010-11-09 2014-08-28 Secure64 Software Corporation Secure publishing of public-key certificates

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103078877A (zh) * 2013-01-31 2013-05-01 中国科学院计算机网络信息中心 基于dns的用户认证和域名访问控制方法及系统
CN103491073A (zh) * 2013-09-09 2014-01-01 中国科学院计算机网络信息中心 在c/s网络架构下基于tlsa协议的安全通信方法
CN103929435A (zh) * 2014-05-05 2014-07-16 中国科学院计算机网络信息中心 一种基于dnssec及dane协议的可信验证方法

Also Published As

Publication number Publication date
WO2016082274A1 (zh) 2016-06-02
CN104468859A (zh) 2015-03-25

Similar Documents

Publication Publication Date Title
CN104468859B (zh) 支持携带服务地址信息的dane扩展查询方法和系统
CN105009509B (zh) 在信息中心网络中通过信任锚点扩增基于名称/前缀的路由协议
Ghodsi et al. Naming in content-oriented architectures
CN109983752A (zh) 带有编码dns级信息的网络地址
Wachs et al. A censorship-resistant, privacy-enhancing and fully decentralized name system
US20100088399A1 (en) Enterprise security setup with prequalified and authenticated peer group enabled for secure DHCP and secure ARP/RARP
JP2009277234A (ja) コンテンツセントリックネットワークにおける通信を円滑化するための方法
CN104410635B (zh) 一种基于dane的ndn安全认证方法
Evdokimov et al. Multipolarity for the object naming service
Cho et al. TwinPeaks: An approach for certificateless public key distribution for the internet and internet of things
US11582201B1 (en) Establishing and maintaining trusted relationship between secure network devices in secure peer-to-peer data network based on obtaining secure device identity containers
Liu et al. Building an IPv6 address generation and traceback system with NIDTGA in address driven network
Tehrani et al. The missing piece: On namespace management in NDN and how DNSSEC might help
Liu et al. Secure name resolution for identifier-to-locator mappings in the global internet
CN108243190A (zh) 一种网络标识的可信管理方法和系统
Micheloni et al. Laribus: privacy-preserving detection of fake SSL certificates with a social P2P notary network
KR101326360B1 (ko) Ｄｎｓ 서버 간의 보안 통신 방법 및 이를 위한 관할 ｄｎｓ 서버, 그리고 보안 통신 시스템
Kent An infrastructure supporting secure internet routing
Cho et al. TwinPeaks: A new approach for certificateless public key distribution
Li et al. DIIA: Blockchain‐Based Decentralized Infrastructure for Internet Accountability
CN115883088B (zh) 基于bgp路由的自治域安全参数更新方法
Meng et al. Establish the intrinsic binding in naming space for future internet using combined public key
Ould-Brahim et al. BGP-based auto-discovery for layer-1 VPNs
Chetioui et al. Security of the DNS protocol-Implementation and weaknesses analyses of DNSSEC
ROSTAMPOUR Deploying DNS Security Extensions

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant
TR01 Transfer of patent right

Effective date of registration: 20210223

Address after: 100190 room 506, building 2, courtyard 4, South 4th Street, Zhongguancun, Haidian District, Beijing

Patentee after: CHINA INTERNET NETWORK INFORMATION CENTER

Address before: 100190 No. four, 4 South Street, Haidian District, Beijing, Zhongguancun

Patentee before: Computer Network Information Center, Chinese Academy of Sciences

TR01 Transfer of patent right