CN105141612A - DNS (Domain Name System) data packet privacy protection method - Google Patents
DNS (Domain Name System) data packet privacy protection method Download PDFInfo
- Publication number
- CN105141612A CN105141612A CN201510552889.9A CN201510552889A CN105141612A CN 105141612 A CN105141612 A CN 105141612A CN 201510552889 A CN201510552889 A CN 201510552889A CN 105141612 A CN105141612 A CN 105141612A
- Authority
- CN
- China
- Prior art keywords
- server
- public key
- dns
- client
- dns request
- 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
Links
- 238000000034 method Methods 0.000 title claims abstract description 22
- 230000004044 response Effects 0.000 claims abstract description 24
- 239000003999 initiator Substances 0.000 claims abstract description 14
- 230000008569 process Effects 0.000 claims description 7
- 230000005540 biological transmission Effects 0.000 abstract description 8
- 238000012795 verification Methods 0.000 description 8
- 238000012423 maintenance Methods 0.000 description 5
- 238000004891 communication Methods 0.000 description 3
- 230000011664 signaling Effects 0.000 description 3
- 238000011161 development Methods 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 238000013475 authorization Methods 0.000 description 1
- ZPUCINDJVBIVPJ-LJISPDSOSA-N cocaine Chemical group O([C@H]1C[C@@H]2CC[C@@H](N2C)[C@H]1C(=O)OC)C(=O)C1=CC=CC=C1 ZPUCINDJVBIVPJ-LJISPDSOSA-N 0.000 description 1
Classifications
-
- 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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
- H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
-
- 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]
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
本发明涉及一种DNS数据包隐私保护方法,其步骤包括:1)客户端、递归服务器和权威服务器生成并维护各自的非对称密钥对;2)客户端或递归服务器在发起DNS请求时,将自己的公钥信息包含在DNS请求数据包中;3)DNS请求发起方将DNS请求数据包用对端服务器公钥进行加密,然后发给对端服务器;4)对端服务器用自己的私钥解密接收到的包含DNS请求发起方公钥信息的DNS请求数据包,并对返回的响应数据包以DNS请求数据包包含的公钥进行加密,然后发送给DNS请求发起方;5)DNS请求发起方用自己的私钥解密接收到的响应数据包,得到最终查询结果。本发明能够保证DNS数据传输的隐私性。
The invention relates to a privacy protection method for DNS data packets. The steps include: 1) a client, a recursive server and an authoritative server generate and maintain their respective asymmetric key pairs; 2) when the client or the recursive server initiates a DNS request, Include your own public key information in the DNS request packet; 3) The DNS request initiator encrypts the DNS request packet with the public key of the peer server, and then sends it to the peer server; 4) The peer server uses its own private key The key decrypts the received DNS request packet containing the public key information of the DNS request initiator, and encrypts the returned response packet with the public key contained in the DNS request packet, and then sends it to the DNS request initiator; 5) DNS request The initiator decrypts the received response packet with its own private key to obtain the final query result. The invention can guarantee the privacy of DNS data transmission.
Description
技术领域technical field
本发明属于网络技术、信息安全技术领域,具体涉及一种DNS数据包隐私保护方法。The invention belongs to the technical fields of network technology and information security, and in particular relates to a privacy protection method for DNS data packets.
背景技术Background technique
在互联网蓬勃发展的今天,互联网用户迅猛增加,各种上层应用层出不穷。域名服务系统(DomainNameSystem,DNS)作为解析互联网资源名字及互联网资源地址的基础服务,其重要性愈发突出。而作为DNS解析入口的根服务体系,其安全稳定是整个域名解析业务正常高效运作的先决条件。Today, with the rapid development of the Internet, Internet users are increasing rapidly, and various upper-level applications emerge in endlessly. As a basic service for resolving Internet resource names and Internet resource addresses, Domain Name System (DNS) is becoming more and more important. The security and stability of the root service system as the entrance of DNS resolution is a prerequisite for the normal and efficient operation of the entire domain name resolution business.
DNS是一种将域名映射为某些预定义类型资源记录(如IP地址)的分布式互联网服务系统。作为一种互联网应用层的资源寻址服务,域名服务是其它互联网络应用服务的基础,常见的互联网络应用服务(如Web服务、电子邮件服务、FTP服务等)都以域名服务为基础来实现资源的寻址和定位。DNS is a distributed Internet service system that maps domain names to certain predefined types of resource records, such as IP addresses. As a resource addressing service at the Internet application layer, domain name service is the basis of other Internet application services. Common Internet application services (such as Web services, email services, FTP services, etc.) are all implemented based on domain name services. Addressing and location of resources.
DNS的原始协议是一种轻量级协议,它不能对服务数据内容提供安全保证;而且DNS数据在互联网上以明文方式进行传输,数据在传输过程中很容易遭到劫持或篡改。由于DNS协议本身不提供数据内容的完整性保护机制,因此接收方无法判别接收到的消息是否遭到篡改及来源是否正确;此外,DNS协议的实现通常以UDP协议为基础,缺乏通信的可靠性保证,这进一步加重了消息被篡改或被伪造的可能性。正是由于DNS协议所暴露出来的以上安全缺陷,促使了DNSSEC的产生和发展。The original DNS protocol is a lightweight protocol, which cannot provide security guarantees for service data content; moreover, DNS data is transmitted in plain text on the Internet, and the data is easily hijacked or tampered with during transmission. Since the DNS protocol itself does not provide an integrity protection mechanism for data content, the receiver cannot tell whether the received message has been tampered with or whether the source is correct; in addition, the implementation of the DNS protocol is usually based on the UDP protocol, which lacks the reliability of communication guarantee, which further heightens the possibility of messages being tampered with or forged. It is precisely because of the above security flaws exposed by the DNS protocol that the emergence and development of DNSSEC has been prompted.
DNSSEC协议是一个针对DNS协议的安全扩展,它通过给DNS的应答消息添加基于非对称加密算法的数字签名,来保证数据未经篡改且来源正确;再通过域名体系自下而上逐级向父域提交自己的公共密钥,来实现整个域名体系的逐级安全认证。具体而言,DNSSEC为DNS数据提供了三方面的安全保障:(1)来源验证:保证DNS应答消息来自被授权的权威服务器;(2)完整性验证:保证DNS应答消息在传输途中未经篡改;(3)否定存在验证:当用户请求一个不存在的域名时,DNS服务器也能够给出包含数字签名的否定应答消息,以保证这个否定应答的可靠性。The DNSSEC protocol is a security extension for the DNS protocol. It adds a digital signature based on an asymmetric encryption algorithm to the DNS response message to ensure that the data has not been tampered with and the source is correct; The domain submits its own public key to realize the level-by-level security certification of the entire domain name system. Specifically, DNSSEC provides three security guarantees for DNS data: (1) source verification: to ensure that the DNS response message comes from an authorized authoritative server; (2) integrity verification: to ensure that the DNS response message has not been tampered with during transmission (3) Negative Existence Verification: When a user requests a domain name that does not exist, the DNS server can also give a negative response message containing a digital signature to ensure the reliability of the negative response.
DNSSEC本质上是在域名系统树形授权体系的基础上,再建立一套基于密码学手段的签名/验证体系,也就是信任链体系,通过信任链上的逐级安全验证,来确保DNS查询结果的真实可靠(数据完整性和非否认性)。DNSSEC is essentially based on the tree-shaped authorization system of the domain name system, and then establishes a signature/verification system based on cryptography, that is, the chain of trust system, through the level-by-level security verification on the chain of trust, to ensure DNS query results authenticity (data integrity and non-repudiation).
然而,通过互联网进行通信的应用程序也面临信息被偷听、篡改或伪造的威胁,为应对上述威胁,当前互联网数据的传输一般采用传输层安全(TransportLayerSecurity,TLS)协议,对信道进行加密,来确保数据的完整性、机密性。传输层安全协议使用了数据加密与签名技术,其安全程度的高低取决于其使用的密钥,若私钥被泄漏或公钥被伪造,则所传输数据的安全性将严重削弱甚至完全丧失。However, applications that communicate through the Internet are also faced with the threat of information being eavesdropped, tampered with or forged. Ensure data integrity and confidentiality. The transport layer security protocol uses data encryption and signature technology, and its level of security depends on the key used. If the private key is leaked or the public key is forged, the security of the transmitted data will be severely weakened or even completely lost.
传输层安全协议利用密钥算法在互联网上提供端点身份认证与通信保密,其基础是数字认证机构(CertificationAuthority,CA),即通过数字证书来绑定公钥与相关信息(包括所有者的名字、CA名称、公钥的有效期、CA的数字签名等)。数字认证机构会妥善保管其私钥,为TLS服务器签发数字证书,并将其公钥提供给TLS客户端。TLS客户端将数字认证机构的公钥视为“信任锚点”,并以此来验证TLS服务器证书的有效性。验证通过后,TLS服务器与客户端之间就可以进行安全通信了。The transport layer security protocol uses key algorithms to provide endpoint identity authentication and communication confidentiality on the Internet. Its basis is a digital certification authority (CertificationAuthority, CA), which uses digital certificates to bind public keys and related information (including the owner's name, CA name, validity period of the public key, digital signature of the CA, etc.). The digital certification authority will properly keep its private key, issue a digital certificate for the TLS server, and provide its public key to the TLS client. The TLS client regards the public key of the digital certification authority as a "trust anchor" and uses it to verify the validity of the TLS server certificate. After the verification is passed, secure communication between the TLS server and the client can be performed.
上述公共CA模式虽应用广泛,但仍存在不尽如人意的地方,给信息的安全传输带来隐患。如CA模式允许任何CA为TLS服务器签发数字证书,这会使系统变得脆弱,一旦某个CA违背安全承诺,不管是因为主观原因还是客观原因(如私钥发生泄漏),必将造成该CA签发的所有数字证书失去安全功能。Although the above-mentioned public CA model is widely used, there are still some unsatisfactory places, which bring hidden dangers to the safe transmission of information. For example, the CA mode allows any CA to issue digital certificates for the TLS server, which will make the system vulnerable. Once a certain CA violates its security commitment, whether it is due to subjective reasons or objective reasons (such as private key leakage), it will definitely cause the CA to fail. All digital certificates issued lose their security features.
基于DNSSEC协议,IETFDANE工作组设计了一种新的DNS资源记录TLSA(TLSA仅是一种资源记录的名称,无其它含义),以使用DNSSEC基础设施来保存TLS协议中用到的数字证书或公钥。DANE协议的核心是:依托DNSSEC基础设施来限制TLS服务器可用的CA范围,从而使区操作员可以声明可供TLS客户端使用的数字签名的范围。假设客户端为Charlie,在其访问example.cn时,可以收到上述TLSA资源记录,并使用上述内容来验证其收到的、来自example.cn的TLS数字证书。若该证书由Bob签发,则有效;否则无效。Based on the DNSSEC protocol, the IETFDANE working group designed a new DNS resource record TLSA (TLSA is only the name of a resource record, with no other meaning) to use the DNSSEC infrastructure to store digital certificates or public domains used in the TLS protocol. key. The core of the DANE protocol is: Relying on the DNSSEC infrastructure to limit the range of CAs available to TLS servers, so that zone operators can declare the range of digital signatures available to TLS clients. Assuming that the client is Charlie, when he visits example.cn, he can receive the above TLSA resource record, and use the above content to verify the TLS digital certificate he received from example.cn. If the certificate is signed by Bob, it is valid; otherwise it is invalid.
DANE协议使用DNSSEC基础设施来保存TLS协议中用到的数字证书或公钥,这使得DANE协议继承了DNSSEC协议的各种优点。虽然原理与CA模型类似,但它在以下三个方面对传统的CA模型做了改进:The DANE protocol uses the DNSSEC infrastructure to save the digital certificate or public key used in the TLS protocol, which makes the DANE protocol inherit various advantages of the DNSSEC protocol. Although the principle is similar to the CA model, it improves the traditional CA model in the following three aspects:
(1)密钥是与DNS中的域名相绑定,而不是与任意的标识符相绑定,以便各类互联网协议使用;(1) The key is bound to the domain name in DNS, not to any identifier, so that it can be used by various Internet protocols;
(2)签名后的公钥可以通过DNS系统来获取,客户端只需发送一个普通的DNS请求就可查询到所需的公钥,公钥的分发非常简单;(2) The signed public key can be obtained through the DNS system. The client only needs to send an ordinary DNS request to query the required public key. The distribution of the public key is very simple;
(3)一个区(zone)的密钥只能由其父区的密钥来签名,例如,区“example.com”的密钥只能由区“.com”来签名,而区“.com”的密钥只能由根密钥来签名。(3) The key of a zone (zone) can only be signed by the key of its parent zone, for example, the key of the zone "example.com" can only be signed by the zone ".com", while the zone ".com" " keys can only be signed by the root key.
虽然DNSSEC提供了对DNS数据进行完成性和来源的验证,且DANE基于DNSSEC提供了一种互联网命名实体的证书管理和验证机制。但DNS仍然是一种明文传输协议,在客户端和递归服务器及递归服务器和权威服务器之间缺乏对传输数据包的加密保护,以最大限度地保障DNS数据的隐私性。Although DNSSEC provides verification of the completeness and origin of DNS data, DANE provides a certificate management and verification mechanism for Internet named entities based on DNSSEC. However, DNS is still a plaintext transmission protocol, and there is no encryption protection for transmission data packets between the client and the recursive server, and between the recursive server and the authoritative server, so as to maximize the privacy of DNS data.
发明内容Contents of the invention
本发明针对上述问题,提出一种DNS数据包隐私保护方法,能够保证DNS数据传输的隐私性。Aiming at the above problems, the present invention proposes a DNS data packet privacy protection method, which can ensure the privacy of DNS data transmission.
本发明的一种DNS数据包隐私保护方法,其步骤包括:A kind of DNS packet privacy protection method of the present invention, its step comprises:
1)客户端、递归服务器和权威服务器生成并维护各自的非对称密钥对;1) The client, recursive server and authoritative server generate and maintain their own asymmetric key pairs;
2)客户端在发起DNS请求时,将其公钥信息包含在DNS请求数据包中;同理,递归服务器发起DNS请求时,将其公钥信息包含在DNS请求数据包中;2) When the client initiates a DNS request, its public key information is included in the DNS request packet; similarly, when the recursive server initiates a DNS request, its public key information is included in the DNS request packet;
3)DNS请求发起方将DNS请求数据包用对端服务器公钥进行加密,然后发给对端服务器;3) The DNS request initiator encrypts the DNS request data packet with the public key of the peer server, and then sends it to the peer server;
4)对端服务器用自己的私钥解密接收到的包含DNS请求发起方公钥信息的DNS请求数据包,并对返回的响应数据包以DNS请求数据包包含的公钥进行加密,然后发送给DNS请求发起方;4) The peer server uses its own private key to decrypt the received DNS request packet containing the public key information of the DNS request initiator, and encrypts the returned response packet with the public key contained in the DNS request packet, and then sends it to DNS request initiator;
5)DNS请求发起方用自己的私钥解密接收到的响应数据包,得到最终查询结果。5) The initiator of the DNS request decrypts the received response data packet with its own private key to obtain the final query result.
进一步地,所述递归服务器在反向区中维护包含其公钥信息的TLSA资源记录,所述权威服务器在正向区中维护包含其公钥信息的TLSA资源记录。Further, the recursive server maintains a TLSA resource record containing its public key information in the reverse zone, and the authoritative server maintains a TLSA resource record containing its public key information in the forward zone.
进一步地,步骤2)对DNS请求数据包的包头格式进行扩展,以在DNS请求数据包中携带DNS请求发起方的公钥信息,所述扩展包括两个部分:Further, step 2) expands the packet header format of the DNS request packet to carry the public key information of the DNS request initiator in the DNS request packet, and the extension includes two parts:
a)在保留的字段中增加一个字节的标志位PP,表明这个DNS请求者希望应答者对数据包进行加密,且在Additoanl字段中携带请求者公钥信息;a) Add a byte flag PP in the reserved field, indicating that the DNS requester wants the responder to encrypt the data packet, and carry the requester's public key information in the Additoanl field;
b)ARCOUNT置为1,表明在请求数据包中包含一个Additional字段,用于存储请求者公钥信息。b) ARCOUNT is set to 1, indicating that an Additional field is included in the request packet, which is used to store the requester's public key information.
进一步地,所述请求者公钥信息基于EDNS0格式,携带在请求消息的Additional字段中,所述Additional字段包括:Further, the requester's public key information is based on the EDSO format, and is carried in the Additional field of the request message, and the Additional field includes:
OPTION-CODE:表明存储用户公钥信息的EDNS0选项编号;OPTION-CODE: Indicates the EDNS0 option number for storing user public key information;
OPTION-LENGTH:选项长度;OPTION-LENGTH: option length;
TYPE:密钥生成算法;TYPE: key generation algorithm;
KEY-DATA:公钥数据。KEY-DATA: public key data.
本发明基于DNS的成熟和标准化协议,提出了一种DNS扩展协议,用于加密客户端与递归服务器、递归服务器与权威服务器之间交互的DNS数据包,能够保证DNS数据传输的隐私性。Based on the mature and standardized protocol of DNS, the present invention proposes a DNS extension protocol for encrypting the DNS data packets exchanged between the client and the recursive server, and between the recursive server and the authoritative server, so as to ensure the privacy of DNS data transmission.
附图说明Description of drawings
图1是实施例中扩展的DNS包头示意图。Fig. 1 is a schematic diagram of the expanded DNS packet header in the embodiment.
图2是携带请求消息的Additional字段中RDATA格式示意图。Fig. 2 is a schematic diagram of the RDATA format in the Additional field carrying the request message.
图3是客户端和递归服务器数据包加密流程图。Fig. 3 is a flowchart of client and recursive server data packet encryption.
图4是递归服务器和权威服务器数据包加密流程图。Fig. 4 is a flowchart of data packet encryption of the recursive server and the authoritative server.
具体实施方式Detailed ways
为使本发明的上述目的、特征和优点能够更加明显易懂,下面通过具体实施例和附图,对本发明做进一步说明。In order to make the above objects, features and advantages of the present invention more obvious and understandable, the present invention will be further described below through specific embodiments and accompanying drawings.
本发明提出的DNS数据包隐私保护方法,用于加密客户端与递归服务器、递归服务器与权威服务器之间交互的DNS数据包,具体改进之处包括:1.提出基于DANE协议维护DNS服务器(包含递归服务器与权威服务器)的公钥信息;2.客户端自己生成并维护非对称密钥对,在发起DNS请求时,将其公钥信息包含在DNS请求数据包中;同理,递归服务器发起DNS请求时,将其公钥信息包含在DNS请求数据包中;扩展DNS信令消息,使其包含数据包发起方的公钥信息;3.DNS请求数据包用对端服务器公钥进行加密;4.接收到包含公钥信息的DNS请求数据包后,服务器首先用自己的私钥进行解密,并对返回的响应数据包以DNS请求数据包包含的公钥进行加密。The DNS data packet privacy protection method proposed by the present invention is used to encrypt DNS data packets interacted between the client and the recursive server, and the recursive server and the authoritative server. The specific improvements include: 1. Propose maintenance of the DNS server based on the DANE protocol (including The public key information of the recursive server and the authoritative server); 2. The client generates and maintains an asymmetric key pair by itself, and includes its public key information in the DNS request packet when it initiates a DNS request; similarly, the recursive server initiates When DNS requests, its public key information is included in the DNS request data packet; the DNS signaling message is expanded to include the public key information of the originator of the data packet; 3. The DNS request data packet is encrypted with the public key of the peer server; 4. After receiving the DNS request packet containing the public key information, the server first decrypts it with its own private key, and encrypts the returned response packet with the public key contained in the DNS request packet.
1)DNS服务器公钥信息维护1) DNS server public key information maintenance
对于递归服务器来说,一般只有IP地址信息;但是对于权威服务器来说,一般具有NS资源记录,标明该服务器的名字。因此,本发明中所用的DNS服务器公钥信息维护可能存在两种情况:在正向区中(如.cn,.com等);在反向区中(如ip6.arpa和in-addr.arpa)。如果服务器有名字,即在正向区中维护包含其公钥信息的TLSA资源记录,如果服务器仅有IP地址,即在反向区中维护包含其公钥信息的TLSA资源记录。For a recursive server, generally there is only IP address information; but for an authoritative server, generally there is an NS resource record indicating the name of the server. Therefore, there may be two situations in the maintenance of the DNS server public key information used in the present invention: in the forward zone (as. cn, .com etc.); in the reverse zone (as ip6.arpa and in-addr.arpa ). If the server has a name, it maintains a TLSA resource record containing its public key information in the forward zone, and if the server only has an IP address, it maintains a TLSA resource record containing its public key information in the reverse zone.
举例如下:Examples are as follows:
A)递归服务器公钥信息维护A) Recursive server public key information maintenance
假设某递归服务器的IP地址为1.2.4.8,那么该服务器生成公钥信息后,在in-addr.arpa区中维护如下资源记录:Assuming that the IP address of a recursive server is 1.2.4.8, after the server generates public key information, it maintains the following resource records in the in-addr.arpa area:
_53._udp.8.4.2.1.in-addr.arpaLifetimeINTLSAPub_key-Server_53._udp.8.4.2.1.in-addr.arpaLifetimeINTLSAPub_key-Server
其中各字段含义如下:The meanings of each field are as follows:
●_53._udp.8.4.2.1.in-addr.arpa标识这个递归服务器的TLSA记录对应名字,表示地址为1.2.4.8的服务器基于UDP在53端口提供DNS解析服务;_53._udp.8.4.2.1.in-addr.arpa identifies the corresponding name of the TLSA record of this recursive server, indicating that the server with address 1.2.4.8 provides DNS resolution service on port 53 based on UDP;
●Lifetime标识这个TLSA记录的有效时间,服务器应该在该记录过期之间及时更新资源记录,本发明不限定该Lifetime的具体时长。此外,对于服务器采用何种方式进行密钥轮转也不予限定;● Lifetime identifies the valid time of the TLSA record, and the server should update the resource record in time before the record expires. The present invention does not limit the specific duration of the Lifetime. In addition, there are no restrictions on the method used by the server to perform key rotation;
●IN标识这是一条互联网类型(InternetClass)的资源记录;●IN indicates that this is a resource record of Internet type (InternetClass);
●TLSA标识此资源记录类型为TLSA;TLSA identifies the resource record type as TLSA;
●Pub_key-Server标识这个服务器所使用的公钥信息。●Pub_key-Server identifies the public key information used by this server.
递归服务器对应的私钥(Pte_key-Server)保密维护。The private key (Pte_key-Server) corresponding to the recursive server is kept confidential.
B)权威服务器公钥信息维护B) Authoritative server public key information maintenance
假设.cn的权威服务器的NS为ns1.cn,那么该服务器生成公钥信息后,在.cn区中维护如下资源记录:Assuming that the NS of the authoritative server of .cn is ns1.cn, then after the server generates the public key information, it maintains the following resource records in the .cn area:
_53._udp.ns1.cnLifetimeINTLSAPub-key_Server_53._udp.ns1.cnLifetimeINTLSAPub-key_Server
其中各个字段含义如下:The meanings of each field are as follows:
●_53._udp.ns1.cn标识这个权威服务器的TLSA记录对应名字,表示服务器名字为ns1.cn的服务器基于UDP在53端口提供DNS解析服务;●_53._udp.ns1.cn identifies the corresponding name of the TLSA record of this authoritative server, indicating that the server whose server name is ns1.cn provides DNS resolution service on port 53 based on UDP;
●Lifetime标识这个TLSA记录的有效时间,服务器应该在该记录过期之间及时更新资源记录,本发明不限定该Lifetime的具体时长。此外,对于服务器采用何种方式进行密钥轮转也不予限定;● Lifetime identifies the valid time of the TLSA record, and the server should update the resource record in time before the record expires. The present invention does not limit the specific duration of the Lifetime. In addition, there are no restrictions on the method used by the server to perform key rotation;
●IN标识这是一条互联网类型(InternetClass)的资源记录;●IN indicates that this is a resource record of Internet type (InternetClass);
●TLSA标识此资源记录类型为TLSA;TLSA identifies the resource record type as TLSA;
●Pub_key-Server标识这个服务器所使用的公钥信息。●Pub_key-Server identifies the public key information used by this server.
权威服务器对应的私钥(Pte_key-Server)由其对应服务器保密维护。The private key (Pte_key-Server) corresponding to the authoritative server is kept confidential by its corresponding server.
2)客户端密钥生成2) Client key generation
客户端可以基于任何算法(RSA、Elgamal和背包算法等)生成非对称密钥对,其中私钥为Pte_key-Client,公钥为Pub_key-Client。The client can generate an asymmetric key pair based on any algorithm (RSA, Elgamal, knapsack algorithm, etc.), where the private key is Pte_key-Client and the public key is Pub_key-Client.
3)DNS请求数据包扩展3) DNS request packet extension
为了传递公钥信息,发起DNS请求一方需要在DNS请求数据包中携带发起方的公钥信息,对DNS数据包的包头格式扩展如图1所示。In order to transmit the public key information, the party that initiates the DNS request needs to carry the public key information of the originator in the DNS request data packet. The header format extension of the DNS data packet is shown in Figure 1.
本发明对DNS数据包的包头扩展主要包括两个部分:The present invention mainly comprises two parts to the Baotou extension of DNS packet:
a)在保留的字段中增加一个字节的标志位(PP,PrivacyProtection),表明这个DNS请求者希望应答者对数据包进行加密,且在Additoanl字段中携带请求者公钥信息;a) Add a flag bit (PP, PrivacyProtection) in the reserved field, indicating that the DNS requester wants the responder to encrypt the data packet, and carry the requester's public key information in the Additoanl field;
b)ARCOUNT置为1,表明在请求数据包中包含一个Additional字段,用于存储请求者公钥信息。b) ARCOUNT is set to 1, indicating that an Additional field is included in the request packet, which is used to store the requester's public key information.
本发明所述请求者公钥信息基于EDNS0格式,携带在请求消息的Additional字段中(OPT=41)。Additional字段中RDATA具体格式如图2所示。本发明称该选项为Client-Pub_key,其各部分含义如下:The requester's public key information in the present invention is based on the EDNS0 format, and is carried in the Additional field of the request message (OPT=41). The specific format of RDATA in the Additional field is shown in Figure 2. The present invention claims that this option is Client-Pub_key, and its each part meaning is as follows:
OPTION-CODE:表明存储用户公钥信息的EDNS0选项编号;OPTION-CODE: Indicates the EDNS0 option number for storing user public key information;
OPTION-LENGTH:选项长度;OPTION-LENGTH: option length;
TYPE:密钥生成算法;TYPE: key generation algorithm;
KEY-DATA:公钥数据。KEY-DATA: public key data.
4)DNS数据隐私保护流程4) DNS data privacy protection process
基于上述扩展协议和数据,本发明提出完整的DNS数据包隐私保护流程。Based on the above-mentioned extended protocol and data, the present invention proposes a complete DNS data packet privacy protection process.
A)客户端与递归服务器数据加密流程如图3所示。A) The data encryption process between the client and the recursive server is shown in Figure 3.
●客户端首先通过DANE查询所配置的递归服务器的公钥信息(Pub_key-Server-R);●The client first queries the public key information of the configured recursive server (Pub_key-Server-R) through DANE;
●客户端请求某个域名,在DNS查询消息中设置PP为1,表明请求递归服务器对响应数据包进行加密处理,此外,客户端在请求消息中通过EDNS0携带Client-Pub_key选项,其中包含客户端的公钥信息为Pub_key-Client。客户端用递归服务器的公钥Pub_key-Server-R对这个扩展的DNS请求数据包进行加密,并发送给递归服务器;●The client requests a domain name, and sets PP to 1 in the DNS query message, indicating that the request recursive server encrypts the response data packet. In addition, the client carries the Client-Pub_key option through EDNS0 in the request message, which contains the client’s The public key information is Pub_key-Client. The client encrypts the extended DNS request packet with the public key Pub_key-Server-R of the recursive server and sends it to the recursive server;
●递归服务器使用Pub_key-Server-R对应的私钥进行数据包解密之后,得到客户端请求的域名以及客户端的公钥信息(Pub_key-Client),递归服务器用该公钥信息对响应数据包进行加密;After the recursive server uses the private key corresponding to Pub_key-Server-R to decrypt the data packet, it obtains the domain name requested by the client and the client’s public key information (Pub_key-Client), and the recursive server uses the public key information to encrypt the response data packet ;
●客户端只有通过Pub_key-Client对应的私钥才能解密响应数据包,得到最终查询结果。●The client can decrypt the response data packet only through the private key corresponding to Pub_key-Client, and obtain the final query result.
基于上述流程,DNS请求数据包和DNS响应数据包都进行了加密处理,保障了DNS信令消息的隐私性。Based on the above process, both the DNS request data packet and the DNS response data packet are encrypted to ensure the privacy of the DNS signaling message.
B)递归服务器与权威服务器数据加密流程如图4所示。B) The flow of data encryption between the recursive server and the authoritative server is shown in Figure 4.
●递归服务器先通过DANE查询所请求权威服务器的公钥信息(Pub_key-Server-A);●The recursive server first queries the public key information (Pub_key-Server-A) of the requested authoritative server through DANE;
●递归服务器查询该权威服务器时,在DNS查询消息中设置PP为1,表明请求权威服务器对响应数据包进行加密处理,此外,递归服务器在请求消息中通过EDNS0携带Client-Pub_key选项,其中包含递归服务器的公钥信息为Pub_key-Server-R。递归服务器用权威服务器的公钥Pub_key-Server-A对这个扩展的DNS请求数据包进行加密,并发送给权威服务器;●When the recursive server queries the authoritative server, it sets PP to 1 in the DNS query message, indicating that the authoritative server is requested to encrypt the response data packet. In addition, the recursive server carries the Client-Pub_key option through EDNS0 in the request message, which contains recursive The server's public key information is Pub_key-Server-R. The recursive server encrypts the extended DNS request packet with the public key Pub_key-Server-A of the authoritative server and sends it to the authoritative server;
●权威服务器使用Pub_key-Server-A对应的私钥进行数据包解密之后,得到递归服务器请求的域名以及递归服务器的公钥信息(Pub_key-Server-R),权威服务器用该公钥信息对响应数据包进行加密;After the authoritative server uses the private key corresponding to Pub_key-Server-A to decrypt the data packet, it obtains the domain name requested by the recursive server and the public key information (Pub_key-Server-R) of the recursive server, and the authoritative server uses the public key information to respond to the data The package is encrypted;
●递归服务器只有通过Pub_key-Server-R对应的私钥才能解密响应数据包,得到最终查询结果。●The recursive server can decrypt the response data packet only through the private key corresponding to Pub_key-Server-R, and obtain the final query result.
基于上述流程,DNS请求数据包和DNS响应数据包都进行了加密处理,保障了DNS信令消息的隐私性。Based on the above process, both the DNS request data packet and the DNS response data packet are encrypted to ensure the privacy of the DNS signaling message.
以上实施例仅用以说明本发明的技术方案而非对其进行限制,本领域的普通技术人员可以对本发明的技术方案进行修改或者等同替换,而不脱离本发明的精神和范围,本发明的保护范围应以权利要求书所述为准。The above embodiments are only used to illustrate the technical solution of the present invention and not to limit it. Those of ordinary skill in the art can modify or equivalently replace the technical solution of the present invention without departing from the spirit and scope of the present invention. The scope of protection should be determined by the claims.
Claims (6)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201510552889.9A CN105141612A (en) | 2015-09-01 | 2015-09-01 | DNS (Domain Name System) data packet privacy protection method |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201510552889.9A CN105141612A (en) | 2015-09-01 | 2015-09-01 | DNS (Domain Name System) data packet privacy protection method |
Publications (1)
Publication Number | Publication Date |
---|---|
CN105141612A true CN105141612A (en) | 2015-12-09 |
Family
ID=54726820
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201510552889.9A Pending CN105141612A (en) | 2015-09-01 | 2015-09-01 | DNS (Domain Name System) data packet privacy protection method |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN105141612A (en) |
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN108400953A (en) * | 2017-02-06 | 2018-08-14 | 中兴通讯股份有限公司 | Control terminal is surfed the Internet and the method for terminal online, router device and terminal |
CN108476246A (en) * | 2015-09-25 | 2018-08-31 | 微软技术许可有限责任公司 | Secure domain name parsing in computer network |
CN109413076A (en) * | 2018-11-06 | 2019-03-01 | 北京奇虎科技有限公司 | Domain name analytic method and device |
CN110113364A (en) * | 2019-05-29 | 2019-08-09 | 深圳市网心科技有限公司 | Domain Hijacking defence method and device, computer installation and storage medium |
CN111615820A (en) * | 2018-10-15 | 2020-09-01 | 华为技术有限公司 | Method and equipment for performing domain name resolution by sending key value to GRS server |
CN111953678A (en) * | 2020-08-11 | 2020-11-17 | 福州职业技术学院 | Method and system for verifying DNS request security |
CN113014561A (en) * | 2021-02-18 | 2021-06-22 | 支付宝(杭州)信息技术有限公司 | Privacy protection method and device for DNS request message |
CN113347144A (en) * | 2021-04-14 | 2021-09-03 | 西安慧博文定信息技术有限公司 | Method, system, equipment and storage medium for reciprocal data encryption |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101242426A (en) * | 2007-02-06 | 2008-08-13 | 华为技术有限公司 | Method, system and device for establishing secure connection at transmission layer |
CN101841521A (en) * | 2010-01-22 | 2010-09-22 | 中国科学院计算机网络信息中心 | Method, server and system for authenticating identify information in DNS message |
CN103929435A (en) * | 2014-05-05 | 2014-07-16 | 中国科学院计算机网络信息中心 | A trusted verification method based on DNSSEC and DANE protocol |
CN104702714A (en) * | 2015-03-31 | 2015-06-10 | 北京奇虎科技有限公司 | DNS (Domain Name Server) safety querying method and device |
-
2015
- 2015-09-01 CN CN201510552889.9A patent/CN105141612A/en active Pending
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101242426A (en) * | 2007-02-06 | 2008-08-13 | 华为技术有限公司 | Method, system and device for establishing secure connection at transmission layer |
CN101841521A (en) * | 2010-01-22 | 2010-09-22 | 中国科学院计算机网络信息中心 | Method, server and system for authenticating identify information in DNS message |
CN103929435A (en) * | 2014-05-05 | 2014-07-16 | 中国科学院计算机网络信息中心 | A trusted verification method based on DNSSEC and DANE protocol |
CN104702714A (en) * | 2015-03-31 | 2015-06-10 | 北京奇虎科技有限公司 | DNS (Domain Name Server) safety querying method and device |
Non-Patent Citations (2)
Title |
---|
M. DEMPSKY: "DNSCurve: Link-Level Security for the Domain Name System draft-dempsky-dnscurve-01", 《IETF》 * |
许海涛等: "DNS 数据安全解决方案", 《计 算 机 系 统 应 用》 * |
Cited By (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN108476246A (en) * | 2015-09-25 | 2018-08-31 | 微软技术许可有限责任公司 | Secure domain name parsing in computer network |
CN108400953A (en) * | 2017-02-06 | 2018-08-14 | 中兴通讯股份有限公司 | Control terminal is surfed the Internet and the method for terminal online, router device and terminal |
CN111615820B (en) * | 2018-10-15 | 2022-04-05 | 华为技术有限公司 | Method and equipment for performing domain name resolution by sending key value to GRS server |
CN111615820A (en) * | 2018-10-15 | 2020-09-01 | 华为技术有限公司 | Method and equipment for performing domain name resolution by sending key value to GRS server |
CN109413076A (en) * | 2018-11-06 | 2019-03-01 | 北京奇虎科技有限公司 | Domain name analytic method and device |
CN109413076B (en) * | 2018-11-06 | 2022-11-29 | 北京奇虎科技有限公司 | Domain name resolution method and device |
CN110113364A (en) * | 2019-05-29 | 2019-08-09 | 深圳市网心科技有限公司 | Domain Hijacking defence method and device, computer installation and storage medium |
CN110113364B (en) * | 2019-05-29 | 2022-02-25 | 深圳市网心科技有限公司 | Domain name hijacking defense method and device, computer device and storage medium |
CN111953678B (en) * | 2020-08-11 | 2022-04-12 | 福州职业技术学院 | Method and system for verifying DNS request security |
CN111953678A (en) * | 2020-08-11 | 2020-11-17 | 福州职业技术学院 | Method and system for verifying DNS request security |
CN113014561A (en) * | 2021-02-18 | 2021-06-22 | 支付宝(杭州)信息技术有限公司 | Privacy protection method and device for DNS request message |
CN113014561B (en) * | 2021-02-18 | 2022-09-06 | 支付宝(杭州)信息技术有限公司 | Privacy protection method and device for DNS request message |
CN113347144A (en) * | 2021-04-14 | 2021-09-03 | 西安慧博文定信息技术有限公司 | Method, system, equipment and storage medium for reciprocal data encryption |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN105141612A (en) | DNS (Domain Name System) data packet privacy protection method | |
JP6526244B2 (en) | Secure Delegated Delivery of Private Keys via Domain Name Service | |
Li et al. | LIVE: Lightweight integrity verification and content access control for named data networking | |
CN109711184B (en) | A block chain data access control method and device based on attribute encryption | |
JP2018182487A (en) | Electronic certification system | |
CN110493367B (en) | Unaddressed IPv6 non-public server, client and communication method | |
US20160149711A1 (en) | Distributed identification system for peer to peer message transmission | |
CN104811450A (en) | Data storage method based on identity in cloud computing and integrity verification method based on identity in cloud computing | |
US20130124870A1 (en) | Cryptographic document processing in a network | |
CN104486325A (en) | Safe login certification method based on RESTful | |
Schwittmann et al. | SoNet--Privacy and replication in federated online social networks | |
Munivel et al. | New authentication scheme to secure against the phishing attack in the mobile cloud computing | |
CN104468859B (en) | Support the DANE expanding query method and systems of carrying address of service information | |
Pallickara et al. | A framework for secure end-to-end delivery of messages in publish/subscribe systems | |
CN116684093B (en) | Identity authentication and key exchange method and system | |
CN108833339A (en) | An Encrypted Access Control Method in Content-Centric Network | |
JP2018182710A (en) | Electronic certification system | |
CN115883088B (en) | BGP route-based autonomous domain security parameter updating method | |
CN104410635B (en) | A kind of NDN safety certifying methods based on DANE | |
Cheng et al. | Research on vehicle-to-cloud communication based on lightweight authentication and extended quantum key distribution | |
Liu et al. | Building an IPv6 address generation and traceback system with NIDTGA in address driven network | |
CN109995723B (en) | Method, device and system for DNS information interaction of domain name resolution system | |
Aiash et al. | An integrated authentication and authorization approach for the network of information architecture | |
CN108696539B (en) | Information service agent method for safety, fairness and privacy protection | |
Chetioui et al. | New Protocol E-DNSSEC to Enhance DNSSEC Security. |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20151209 |
|
RJ01 | Rejection of invention patent application after publication |