WO2016155373A1 - Dns安全查询方法和装置 - Google Patents

Dns安全查询方法和装置 Download PDF

Info

Publication number
WO2016155373A1
WO2016155373A1 PCT/CN2015/099007 CN2015099007W WO2016155373A1 WO 2016155373 A1 WO2016155373 A1 WO 2016155373A1 CN 2015099007 W CN2015099007 W CN 2015099007W WO 2016155373 A1 WO2016155373 A1 WO 2016155373A1
Authority
WO
WIPO (PCT)
Prior art keywords
dns
data packet
packet
interface
dnssec
Prior art date
Application number
PCT/CN2015/099007
Other languages
English (en)
French (fr)
Inventor
郑劲松
肖鹏
Original Assignee
北京奇虎科技有限公司
奇智软件（北京）有限公司
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 北京奇虎科技有限公司, 奇智软件（北京）有限公司 filed Critical 北京奇虎科技有限公司
Publication of WO2016155373A1 publication Critical patent/WO2016155373A1/zh

Links

Images

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/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • 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
    • 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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication

Definitions

  • the present invention relates to the field of computer networks, and in particular, to a DNS security query method and apparatus.
  • the Domain Name System is a distributed database on the Internet that maps domain names and IP addresses to each other. It enables users to access the Internet more easily without having to remember the number of IPs that can be directly read by the machine. string.
  • the process of obtaining the IP address corresponding to the host name by the host name is called the domain name resolution (or host name resolution) process.
  • the DNS protocol runs on top of the User Datagram Protocol (UDP) and works like other protocols or systems on the Internet in a trusted, clean environment. But today's Internet environment is extremely complex, full of all kinds of fraud and attacks, and the DNS protocol shows its vulnerability.
  • UDP User Datagram Protocol
  • DNS SEC Domain Name System Security Extensions
  • the present invention has been made in order to provide a DNS security query method and apparatus that overcomes the above problems or at least partially solves the above problems.
  • a DNS security query method including:
  • a DNS security query apparatus including:
  • a first capture module configured to capture a DNS request data packet to be sent by the client
  • a transceiver module configured to send a DNS SEC request packet to a DNS server to receive a DNS SEC response packet returned by the DNS server;
  • a second capture module configured to capture a DNS SEC response packet received by the client
  • a verification module adapted to verify the digital signature in the DNS SEC response packet by using a public key provided by the DNS server;
  • a conversion module configured to convert the DNS request packet into a corresponding DNS SEC request packet after the first capture module captures the DNS request packet; and, after the verification module passes the digital signature verification, the DNS SEC response packet Convert to the corresponding DNS response packet;
  • the query processing module is adapted to perform DNS query processing according to the DNS response data packet.
  • a computer program comprising computer readable code that, when executed on a computing device, causes the computing device to perform DNS security as described above Query method.
  • a computer readable medium storing the above computer program is provided.
  • the DNS security query method and apparatus captures a DNS request packet to be sent by a client, converts the DNS request packet into a corresponding DNS SEC request packet, and sends a DNS SEC request packet to the DNS server to receive the DNS.
  • the DNS SEC response packet returned by the server captures the DNS SEC response packet received by the client, and uses the public key provided by the DNS server to verify the digital signature in the DNS SEC response packet; if the digital signature verification is passed, the DNS SEC response packet It is converted into a corresponding DNS response packet, and DNS query processing is performed according to the DNS response packet.
  • the verification process in the DNS SEC is applied to the client, and the trust relationship is configured between the client and the nearest DNS server, thereby forming a complete trust chain with the DNS servers at all levels, and being able to verify the authenticity of the data on the client.
  • Sexuality and integrity further avoid DNS hijacking and spoofing.
  • FIG. 1a shows a flow chart of a DNS security query method in accordance with one embodiment of the present invention
  • Figure 1b shows a schematic diagram of the windows system network architecture.
  • FIG. 2 is a flow chart showing a DNS security query method according to another embodiment of the present invention.
  • FIG. 3 is a flow chart showing a DNS security query method according to another embodiment of the present invention.
  • FIG. 4 is a flowchart showing a DNS security query method according to another embodiment of the present invention.
  • FIG. 5 is a structural block diagram of a DNS security query device according to an embodiment of the present invention.
  • Figure 6 is a schematic block diagram showing a computing device for performing a DNS security query method in accordance with the present invention
  • Fig. 7 schematically shows a storage unit for holding or carrying program code implementing the DNS security query method according to the present invention.
  • the client When a user accesses a website with a domain name, the client generally converts the domain name into an IP address through a domain name resolution server.
  • the domain name resolution server generally needs to query the root domain name server, the top-level domain name server, the authoritative domain name server and other multi-level server nodes to obtain the IP address of the target server in a recursive query manner, and then deliver it to the client.
  • the attacker can fake the responder to send a fake response to the requester, which contains an incorrect IP address.
  • the client or the resolution server that sent the request accepts a fake response, causing the user to be unable to access the normal website, or even redirecting to a fake website.
  • DNS SEC is to solve the above-mentioned insecure in the traditional DNS system.
  • the IETF International Internet Engineering Task Force
  • the goal is to solve various DNS cache spoofing, DNS attacks, DNS hijacking and other issues.
  • the DNS SEC adds digital signature information to the data in the DNS, so that each node's DNS server can check the signature information to determine whether the response data is true after receiving the response information, thereby providing data source verification and data integrity for the DNS data. test.
  • the DNS SEC introduces new resource records in the data packet, including: a public key for storing the verified DNS data; a digital signature for storing the DNS resource record; and a superior authorization signature.
  • the digital signature is generated by encrypting the summary information of the resource record by using a private key; the public key corresponds to the private key for encryption.
  • the superior authorization signature is a signature of the upper-level node of the DNS server to the public key hash value of the DNS server, and is used to prevent the public key from being forged. Through the authorization signature of the superior, the trust chain is configured between the nodes at each level.
  • FIG. 1a shows a flowchart of a DNS security query method according to an embodiment of the present invention.
  • the method of the present invention is applied to a client that initiates a DNS query, such as a PC (Personal Computer).
  • a DNS query such as a PC (Personal Computer).
  • the method includes the following steps:
  • Step S110 Capture a DNS request packet to be sent by the client, and convert the DNS request packet into a corresponding DNS SEC request packet.
  • the DNS SEC is deployed at all levels of server nodes to ensure data authenticity through signature verification. But ultimately The client receiving the DNS query result does not check the signature contained in the DNS record returned by the DNS server. Therefore, if DNS spoofing occurs at this stage, the above DNS SEC deployment is not recognized.
  • the embodiment of the invention provides a method for verifying the authenticity of the returned resource record containing the query result in the client, and further ensuring the authenticity and integrity of the DNS query result.
  • the DNS operating system does not support DNS SEC communication with the DNS server. Therefore, the relevant interface of the domain name resolution in the client system can only form a DNS request packet and cannot form a DNS SEC request packet with the above resource record, and cannot directly request and respond with the DNS SEC mode with the domain name resolution server.
  • a DNS request packet to be sent by a client is captured by a custom function or interface, and converted into a DNS SEC request packet.
  • Figure 1b is a schematic diagram of the windows system network architecture.
  • a hook function can be used to capture a DNS resolution interface of a client system application layer (also called a user layer) to obtain a DNS request packet, and convert the DNS request packet into a DNS SEC-compliant form in a hook function.
  • DNS SEC requests packets.
  • it can be captured and converted in the protocol driver layer of the client system kernel layer or the client transport layer driver interface layer (TDI), as described in the following examples.
  • TTI client transport layer driver interface layer
  • converting the DNS request packet to the corresponding DNS SEC request packet includes adding a resource record that the DNS SEC request packet has in the DNS request packet.
  • Step S120 sending a DNS SEC request packet to the DNS server.
  • the DNS SEC request packet obtained by the above conversion is delivered to the sending interface in the system, and the sending interface is called to send the DNS SEC request packet to the DNS server.
  • Step S130 receiving a DNS SEC response packet returned by the DNS server.
  • the receiving interface in the calling system receives the DNS SEC response packet.
  • the DNS SEC response packet returned by the server includes: the digital signature of the resource record, the public key and the superior authorization signature.
  • Step S140 capturing a DNS SEC response packet received by the client, and verifying the digital signature in the DNS SEC response packet by using the public key provided by the DNS server.
  • the DNS SEC response packet received by the capture client may be specifically performed in the system application layer, the system protocol driver layer, or the client transport layer driver interface layer of the client.
  • the digital signature contained in the DNS SEC response packet is generated by the DNS server using the private key to encrypt the first summary information of the resource record to be returned, wherein the first summary information is generated by the DNS server using the hash function for the resource record.
  • the verification process in this step includes: the client decrypts the digital signature by using the public key provided by the DNS server, and if it can be decrypted, it indicates that the DNS SEC response packet actually comes from the DNS server, and verifies the authenticity of the data source.
  • the first summary information is obtained, and the second summary information is generated by using a hash function for the resource record in the DNS SEC response packet, and then the first summary information and the second summary information are compared. If the first summary information and the second summary information are consistent, it indicates that the resource record is not received in the transmission. The tampering has verified the integrity of the data.
  • the above verification process is done by a custom function or interface.
  • the hook function is used to capture the DNS resolution interface at the client system application layer to obtain the DNS SEC response data packet, and the above verification process is also performed in the hook function.
  • the attacker may also forge the public and private keys of the DNS server, and use the forged private key to generate a digital signature to achieve the purpose of fraud, and the client cannot identify the situation. Therefore, before obtaining the first summary information, the node of the upper level of the DNS server may be queried for the superior authorization signature of the public key, and the superior authorization signature is used to verify whether the public key is correct.
  • the superior authorization signature is formed by encrypting the public key of the DNS server by the upper-level node. If you still don't believe the superior authorization signature, you can continue to query the more advanced nodes recursively.
  • Step S150 If the digital signature verification is passed, the DNS SEC response data packet is converted into a corresponding DNS response data packet, and the DNS query processing is performed according to the DNS response data packet.
  • converting the DNS SEC response packet to the corresponding DNS response packet is also done in a custom function, for example, in the hook function of capturing the DNS SEC response packet above.
  • the converted DNS data packet is transmitted to the DNS resolution interface of the client system, and the DNS resolution interface performs DNS query processing according to the DNS response data packet, for example, the IP information obtained by the query is transmitted to the application.
  • the capture of the DNS request packet, the conversion between the DNS packet and the DNS SEC packet, the transmission and reception of the DNS SEC packet, and the signature verification are transparent to the client system.
  • the authenticity and integrity verification of the DNS response data can be completed on the client.
  • the DNS request packet to be sent by the client is captured, and the DNS request packet is converted into a corresponding DNS SEC request packet; the DNS SEC request packet is sent to the DNS server to Receiving the DNS SEC response packet returned by the DNS server; capturing the DNS SEC response packet received by the client, and verifying the digital signature in the DNS SEC response packet by using the public key provided by the DNS server; if the digital signature verification is passed, the DNS SEC response
  • the data packet is converted into a corresponding DNS response data packet, and the DNS query processing is performed according to the DNS response data packet.
  • the verification process in the DNS SEC is applied to the client, and the trust relationship is configured between the client and the nearest DNS server, thereby forming a complete trust chain with the DNS servers at all levels, and being able to verify the authenticity of the data on the client.
  • Sexuality and integrity further avoid DNS hijacking and spoofing.
  • FIG. 2 shows a flow chart of a DNS security query method in accordance with another embodiment of the present invention.
  • the capture of DNS data is performed at the system application layer of the client.
  • the method includes the following steps:
  • Step S210 using a hook function to capture a DNS resolution interface of the client system application layer to obtain a DNS request data packet.
  • the DNS resolution interface of the application layer of the client system includes a gethostbyname interface and/or a getaddrinfo interface.
  • the behavior of the client system calling the ethostbyname interface and/or the getaddrinfo interface is captured by constructing a hook function to obtain a DNS request packet.
  • Step S220 converting the DNS request packet into a corresponding DNS SEC request packet.
  • This step is done inside the hook function constructed above.
  • Step S230 sending a DNS SEC request packet to the DNS server to receive the DNS SEC response packet returned by the DNS server.
  • Step S240 using a hook function to capture a DNS resolution interface of the client system application layer to obtain a DNS SEC response data packet.
  • step S210 the behavior of the client system calling the ethostbyname interface and/or the getaddrinfo interface is captured by the constructed hook function to obtain the DNS SEC response packet.
  • Step S250 The digital signature in the DNS SEC response packet is verified by using the public key provided by the DNS server. If the digital signature verification is passed, step S260 is performed.
  • the verification process in this step includes: the client decrypts the digital signature by using the public key provided by the DNS server, and if it can be decrypted, it indicates that the DNS SEC response packet actually comes from the DNS server, and verifies the authenticity of the data source.
  • the first summary information is obtained, and the second summary information is generated by using a hash function for the resource record in the DNS SEC response packet, and then the first summary information and the second summary information are compared. If the first summary information and the second summary information are consistent, it indicates that the resource record has not been tampered with in the transmission, and the integrity of the data is verified.
  • Step S260 converting the DNS SEC response data packet into a corresponding DNS response data packet, and performing DNS query processing according to the DNS response data packet.
  • FIG. 3 shows a flow chart of a DNS security query method in accordance with another embodiment of the present invention.
  • the DNS request packet and the DNS SEC response packet received by the client are captured at the client system protocol driver layer.
  • the method includes the following steps:
  • Step S310 capturing an NdisSend/NdisSendPackets interface of the protocol driver layer to obtain a DNS request packet.
  • the NDIS intermediate layer driver is located between the NDIS protocol driver layer and the NDIS port driver layer.
  • the NDIS intermediate layer driver can intercept all local sending data packets and response data packets, and receive the sending data packets or response data packets. , refusal, modification, etc.
  • the NDIS middle layer driver acts as a small port driver for the upper layer and as a protocol driver for the lower layer.
  • NdisSend/NdisSendPackets is called to send the data packet, so the DNS request packet can be obtained by capturing the interface.
  • Step S320 converting the DNS request packet into a corresponding DNS SEC request packet.
  • This step involves adding a resource record in the DNS SEC request packet to the DNS request packet.
  • Step S330 sending a DNS SEC request packet to the DNS server.
  • the step includes: sequentially calling the NdisSend/NdisSendPackets interface, The MiniportSend/MiniportSendPackets interface sends a DNS SEC request packet to the bottom layer; the underlying layer controls the physical network device through the NDIS interface, and sends the DNS SEC request packet to the DNS server.
  • Step S340 receiving a DNSSEC response data packet returned by the DNS server.
  • the step includes: after receiving the DNS SEC response packet by the physical network device, the NDIS port driver layer invokes the NdisMIndicateReceivePacket interface to indicate that the DNS SEC response packet is received.
  • Step S350 capturing a DNS SEC response packet by calling the intermediate driver layer to the ProtocolReceivePacket interface registered by the NDIS.
  • Step S360 verifying the digital signature in the DNS SEC response packet by using the public key provided by the DNS server. If the digital signature verification is passed, step S370 is performed.
  • Step S370 converting the DNS SEC response data packet into a corresponding DNS response data packet, and performing DNS query processing according to the DNS response data packet.
  • performing DNS query processing according to the DNS response packet includes: calling the NdisMIndicateReceivePacket interface to notify the protocol driver layer to receive the DNS response data packet, and then calling the ProtocolReceive interface to process the DNS response data packet, and continuing to call the NdisMIndicateReceivePacket interface to send the DNS response data packet. It is passed to the NDIS protocol driver layer, and the DNS response packet is processed by the corresponding protocol stack.
  • FIG. 4 shows a flow chart of a DNS security query method in accordance with another embodiment of the present invention.
  • the DNS request packet is filtered in the client transport layer driver interface layer.
  • the following is an example of a TDI model for the Win2000 operating system.
  • filtering DNS request packets in the transport layer driver interface layer requires Winsock Kernel (Winsock Kernel) or Windows Filtering Platform.
  • the method includes the following steps:
  • Step S410 generating a filtering device in the transport layer driving interface layer.
  • Step S420 the filtering device binding protocol drives the generated device.
  • TDI Traffic Driver Interface
  • TDI Traffic Driver Interface
  • the application creates a socket, creates a connection with connect, uses send and receive to send and receive packets, etc., and forwards the system call of the upper layer to the protocol driver through TDI.
  • Each protocol driver generates a named device that receives a series of requests, including a request to generate, for example, an IRP_MJ_CREATE request to create a socket for handling bind, connect, and listen.
  • IRP_MJ_INTERNAL_DEVICE_CONTROL request for listening, accept, send, and recv.
  • the device generated by the above protocol driver can be bound by generating a filtering device.
  • step S410 and step S420 are necessary for the TDI model in this embodiment.
  • the transport layer driver interface layer in other operating systems, there are different filtering methods, and different methods may be used without generating a filtering device.
  • Step S430 filtering the DNS request data packet from the application layer by using the filtering device.
  • the filtering device Since the filtering device is generated to bind the device generated by the protocol driver, the request sent from the application layer first passes through the filtering device, and the DNS request packet can be obtained by the filtering device.
  • the distribution function of the created filtering device is DeviceDispatch
  • all the DNS data request packets sent by the upper layer are called back to DeviceDispatch. Further, the DNS request packet is filtered by TDI_SEND_DATAGRAM.
  • Step S440 sending a DNS SEC request packet to the DNS server to receive the DNS SEC response packet returned by the DNS server.
  • Step S450 filtering the DNS SEC response packet from the protocol driver layer by using the filtering device.
  • step S430 the DNS corresponding data packet is filtered by TDI_RECEIVE_DATAGRAM.
  • Step S460 verifying the digital signature in the DNS SEC response packet by using the public key provided by the DNS server. If the digital signature passes the verification, step S470 is performed.
  • Step S470 converting the DNS SEC response data packet into a corresponding DNS response data packet, and performing DNS query processing according to the DNS response data packet.
  • the DNS request packet and the DNS SEC corresponding data packet are captured at the client system application layer, the client system protocol driver layer, and the client transport layer driver interface layer, respectively. Both can apply the authentication process in the DNS SEC to the client, configure a trust relationship between the client and the nearest DNS server, thus forming a complete trust chain with all levels of DNS servers, and can verify the authenticity of the data on the client side. Integrity, further avoiding DNS hijacking and spoofing issues.
  • FIG. 5 is a structural block diagram of a DNS security query device according to an embodiment of the present invention. As shown in FIG. 5, the device includes: a first capture module 510, a transceiver module 520, a second capture module 530, and a verification module 540.
  • the conversion module 550 and the query processing module 560 have the following functions:
  • the first capture module 510 is adapted to capture a DNS request data packet to be sent by the client;
  • the transceiver module 520 is configured to send a DNS SEC request packet to the DNS server to receive the DNS SEC response packet returned by the DNS server;
  • a second capture module 530 configured to capture a DNS SEC response packet received by the client
  • the verification module 540 is adapted to verify the digital signature in the DNS SEC response packet by using the public key provided by the DNS server;
  • the conversion module 550 is adapted to convert the DNS request packet into a corresponding DNS SEC request packet after the first capture module 510 captures the DNS request packet; and after the verification module 540 verifies the digital signature, the DNS SEC is performed.
  • the response packet is converted into a corresponding DNS response packet;
  • the query processing module 560 is adapted to perform DNS query processing according to the DNS response data packet.
  • the first capture module 510 is further adapted to: capture a DNS resolution interface of the client system application layer by using a hook function to obtain a DNS request data packet; accordingly, the second capture module 530 is further adapted to: capture the client by using a hook function
  • the DNS resolution interface of the end system application layer acquires the DNS SEC response data packet.
  • the DNS resolution interface of the application layer of the client system includes a gethostbyname interface and/or a getaddrinfo interface.
  • the first capture module 510 can also perform the capture of the DNS request data packet at the system protocol driver layer. Specifically, the first capture module 510 captures a data packet sending interface of the client system protocol driver layer to obtain a DNS request data packet; accordingly, the second capture module 530 captures a data packet receiving interface of the intermediate driver layer of the client system to obtain a DNS. The SEC responds to the packet.
  • the first capture module 510 is further configured to: capture an NdisSend/NdisSendPackets interface of the protocol driver layer to obtain a DNS request data packet; and the transceiver module 520 is further adapted to: sequentially invoke an NdisSend/NdisSendPackets interface, The MiniportSend/MiniportSendPackets interface sends the converted DNS SEC request packet to the bottom layer for the underlying layer to control the physical network device through the NDIS interface, and sends the DNS SEC request packet to the DNS server.
  • the transceiver module 520 is further adapted to: after the bottom layer receives the DNS SEC response packet through the physical network device, the small port driver layer invokes the NdisMIndicateReceivePacket interface to indicate that the DNS is received.
  • the SEC response data packet; the second capture module 530 is further adapted to: capture the DNS SEC response data packet by calling the intermediate driver layer to the NDIS registered ProtocolReceivePacket interface; the query processing module 560 is further adapted to: call the NdisMIndicateReceivePacket interface again to notify the protocol driver layer Receiving the converted DNS response packet of the conversion module 560, and then calling the ProtocolReceive interface to process the DNS response packet, and continuing to call the NdisMIndicateReceivePacket interface to deliver the DNS response packet to the protocol driver layer, and the corresponding protocol stack to the DNS response packet. Perform DNS query processing.
  • the first capture module 510 is further adapted to filter out the DNS request data packet in the client transport layer driver interface layer; accordingly, the second capture module 530 is further adapted to: filter in the client transport layer driver interface layer Out of the DNS SEC response packet.
  • the device further includes: a generating module 570, configured to generate a filtering device in the transport layer driving interface layer; driving the generated device by the filtering device binding protocol; the first capturing module 510 is further adapted to: use the filtering device pair to The application layer's DNS request packet is filtered; the second capture module 530 is further adapted to: filter the DNS SEC response packet from the protocol driver layer by using the filtering device.
  • the verification module 540 is further adapted to: decrypt the digital signature by using the public key to obtain the first summary information; generate second summary information according to the query result in the DNS; compare the second summary information with the first summary Information, if the second summary information is the same as the first summary information, the digital signature is judged to pass the verification.
  • the verification module 540 is further adapted to:
  • the first capture client sends a DNS request packet
  • the conversion module converts the DNS request packet into a corresponding DNS SEC request packet
  • the transceiver module sends the DNS SEC request data.
  • the second capture module captures the DNS SEC response packet received by the client
  • the verification module uses the public key provided by the DNS server to verify the number in the DNS SEC response packet Signature; if the digital signature verification is passed, the conversion module converts the DNS SEC response packet into a corresponding DNS response packet, and performs DNS query processing according to the DNS response packet.
  • the verification process in the DNS SEC is applied to the client, and the trust relationship is configured between the client and the nearest DNS server, thereby forming a complete trust chain with the DNS servers at all levels, and being able to verify the authenticity of the data on the client. Sex and integrity to further avoid DNS spoofing.
  • modules in the devices of the embodiments can be adaptively changed and placed in one or more devices different from the embodiment.
  • the modules or units or components of the embodiments may be combined into one module or unit or component, and further they may be divided into a plurality of sub-modules or sub-units or sub-components.
  • any combination of the features disclosed in the specification, including the accompanying claims, the abstract and the drawings, and any methods so disclosed, or All processes or units of the device are combined.
  • Each feature disclosed in this specification (including the accompanying claims, the abstract and the drawings) may be replaced by alternative features that provide the same, equivalent or similar purpose.
  • the various component embodiments of the present invention may be implemented in hardware, or in a software module running on one or more processors, or in a combination thereof.
  • a microprocessor or digital signal processor (DSP) is used in practice to implement some or all of the functionality of some or all of the components of the DNS security query device in accordance with embodiments of the present invention.
  • DSP digital signal processor
  • the invention can also be implemented as a device or device program (e.g., a computer program and a computer program product) for performing some or all of the methods described herein.
  • a program implementing the invention may be stored on a computer readable medium or may be in the form of one or more signals.
  • Such signals may be downloaded from an Internet website, provided on a carrier signal, or provided in any other form.
  • Figure 6 illustrates a computing device that can implement a DNS security lookup method.
  • the computing device conventionally includes a processor 610 and a computer program product or computer readable medium in the form of a memory 620.
  • the memory 620 may be an electronic memory such as a flash memory, an EEPROM (Electrically Erasable Programmable Read Only Memory), an EPROM, a hard disk, or a ROM.
  • Memory 620 has a memory space 630 for program code 631 for performing any of the method steps described above.
  • storage space 630 for program code may include various program code 631 for implementing various steps in the above methods, respectively.
  • the program code can be read from or written to one or more computer program products.
  • Such computer program products include program code carriers such as hard disks, compact disks (CDs), memory cards or floppy disks.
  • Such a computer program product is typically a portable or fixed storage unit as described with reference to FIG.
  • the storage unit may have storage segments, storage spaces, and the like that are similarly arranged to memory 620 in the computing device of FIG.
  • the program code can be compressed, for example, in an appropriate form.
  • the storage unit includes computer readable code 631', ie, code readable by a processor, such as 610, that when executed by a computing device causes the computing device to perform each of the methods described above step.

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)
  • Computer And Data Communications (AREA)

Abstract

本发明公开了一种DNS安全查询方法和装置，其中，方法包括：捕获客户端待发送的DNS请求数据包，将DNS请求数据包转换为对应的DNSSEC请求数据包；发送DNSSEC请求数据包至DNS服务器，以接收DNS服务器返回的DNSSEC响应数据包；捕获客户端接收的DNSSEC响应数据包，利用DNS服务器提供的公钥验证DNSSEC响应数据包中的数字签名；若数字签名验证通过，将DNSSEC响应数据包转换为对应的DNS响应数据包，依据DNS响应数据包进行DNS查询处理。根据上述方案，将DNSSEC中的验证过程应用于客户端，在客户端与最近的DNS服务器之间配置信任关系，从而与各级DNS服务器形成完整的信任链，能够在客户端验证数据的真实性和完整性，进一步避免出现DNS劫持和欺骗问题。

Description

DNS安全查询方法和装置 技术领域
本发明涉及计算机网络领域，具体涉及一种DNS安全查询方法和装置。
背景技术
域名系统(Domain Name System，简称：DNS)是因特网上作为域名和IP地址相互映射的一个分布式数据库，能够使用户更方便的访问互联网，而不用去记住能够被机器直接读取的IP数串。通过主机名，最终得到该主机名对应的IP地址的过程叫做域名解析(或主机名解析)过程。
DNS协议运行在用户数据报协议(User Datagram Protocol，简称：UDP)之上，与互联网的其他协议或系统一样，在一个可信的、纯净的环境里运行得很好。但是今天的互联网环境异常复杂，充斥着各种欺诈、攻击，DNS协议表现出其脆弱性。
为避免上述的DNS劫持、欺骗等问题，提高互联网安全性，互联网服务提供商开始布署支持DNS安全扩展(Domain Name System Security Extensions，简称：DNS SEC)的解析服务器。DNS SEC利用数字签名在各级解析服务器之间配置信任链，保证各级解析服务器之间的数据完整性和真实性。
然而，即使在上述各级解析服务器上部署了DNS SEC，但在客户端和直接与客户端交互的解析服务器节点之间并不存在信任链或数据真实性、完整性的验证过程。因此，DNS SEC无法识别出此处发生的DNS欺骗，客户端得到的域名解析结果仍然具有风险。
发明内容
鉴于上述问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的DNS安全查询方法和装置。
根据本发明的一方面，提供了一种DNS安全查询方法，包括：
捕获客户端待发送的DNS请求数据包，将DNS请求数据包转换为对应的DNS SEC请求数据包；
发送DNS SEC请求数据包至DNS服务器，以接收DNS服务器返回的DNS SEC响应数据包；
捕获客户端接收的DNS SEC响应数据包，利用DNS服务器提供的公钥验证DNS SEC响应数据包中的数字签名；若数字签名验证通过，将DNS SEC响应数据包转换为对应的DNS响应数据包，依据DNS响应数据包进行DNS查询处理。
根据本发明的另一方面，提供了一种DNS安全查询装置，包括：
第一捕获模块，适于捕获客户端待发送的DNS请求数据包；
收发模块，适于发送DNS SEC请求数据包至DNS服务器，以接收DNS服务器返回的DNS SEC响应数据包；
第二捕获模块，适于捕获客户端接收的DNS SEC响应数据包；
验证模块，适于利用DNS服务器提供的公钥验证DNS SEC响应数据包中的数字签名；
转换模块，适于在第一捕获模块捕获DNS请求数据包后，将DNS请求数据包转换为对应的DNS SEC请求数据包；以及，在验证模块对数字签名验证通过后，将DNS SEC响应数据包转换为对应的DNS响应数据包；
查询处理模块，适于依据DNS响应数据包进行DNS查询处理。
根据本发明的又一方面，提供了一种计算机程序，其包括计算机可读代码，当所述计算机可读代码在计算设备上运行时，导致所述计算设备执行根据上文所述的DNS安全查询方法。
根据本发明的再一方面，提供了一种计算机可读介质，其中存储了上述的计算机程序。
本发明的有益效果为：
根据本发明的DNS安全查询方法和装置，捕获客户端待发送的DNS请求数据包，将DNS请求数据包转换为对应的DNS SEC请求数据包；发送DNS SEC请求数据包至DNS服务器，以接收DNS服务器返回的DNS SEC响应数据包；捕获客户端接收的DNS SEC响应数据包，利用DNS服务器提供的公钥验证DNS SEC响应数据包中的数字签名；若数字签名验证通过，将DNS SEC响应数据包转换为对应的DNS响应数据包，依据DNS响应数据包进行DNS查询处理。根据上述方案，将DNS SEC中的验证过程应用于客户端，在客户端与最近的DNS服务器之间配置信任关系，从而与各级DNS服务器形成完整的信任链，能够在客户端验证数据的真实性和完整性，进一步避免出现DNS劫持和欺骗问题。
上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。
附图说明
通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：
图1a示出了根据本发明一个实施例的DNS安全查询方法的流程图；
图1b示出了windows系统网络体系结构示意图。
图2示出了根据本发明另一个实施例的DNS安全查询方法的流程图；
图3示出了根据本发明另一个实施例的DNS安全查询方法的流程图；
图4示出了根据本发明另一个实施例的DNS安全查询方法的流程图；
图5示出了根据本发明一个实施例的DNS安全查询装置的结构框图；
图6示意性地示出了用于执行根据本发明的DNS安全查询方法的计算设备的框图；以及
图7示意性地示出了用于保持或者携带实现根据本发明的DNS安全查询方法的程序代码的存储单元。
具体实施方式
下面结合附图和具体的实施方式对本发明作进一步的描述。
在描述本发明各实施例之前，简要介绍与本发明密切相关的DNS及DNS SEC的原理。
用户在用域名访问某一个网站时，客户端一般会通过一个域名解析服务器把域名转换成IP地址。域名解析服务器一般需要通过查询根域名服务器、顶级域名服务器、权威域名服务器等多级服务器节点，以递归查询的方式最终获得目标服务器的IP地址，然后交给客户端。在此过程中，攻击者都可以假冒应答方给请求方发送一个伪造的响应，其中包含一个错误的IP地址。发送请求的客户端或者解析服务器接受了伪造的应答，导致用户无法访问正常网站，甚至可以把重定向到一个伪造的网站上去。
DNS SEC是为了解决传统DNS系统中的上述不安全性，由IETF(国际互联网工程任务组)制定的一套配合现有DNS系统的安全扩展系统，目标在于解决各种DNS缓存欺骗、DNS攻击、DNS劫持等问题。
DNS SEC通过为DNS中的数据添加数字签名信息，使得每个节点的DNS服务器在得到应答信息后可以通过检查此签名信息来判断应答数据是否真实，从而为DNS数据提供数据来源验证和数据完整性检验。为此，DNS SEC在数据包中引入了新的资源记录，包括：用于存储验证DNS数据的公钥；用于存储DNS资源记录的数字签名；以及上级授权签名等。其中，数字签名是使用私钥对资源记录的摘要信息加密生成的；公钥对应于加密用的私钥。上级授权签名是DNS服务器的上一级节点对该DNS服务器的公钥散列值的签名，用于防止公钥被伪造。通过上级授权签名，在各级节点之间配置成信任链。
图1a示出了根据本发明一个实施例的DNS安全查询方法的流程图，本发明的方法应用于发起DNS查询的客户端，如PC(Personal Computer，个人电脑)中。如图1a所示，方法包括如下步骤：
步骤S110，捕获客户端待发送的DNS请求数据包，将DNS请求数据包转换为对应的DNS SEC请求数据包。
DNS SEC在各级服务器节点中部署，通过签名验证保证数据的真实性。但最终 接收DNS查询结果的客户端并不检查DNS服务器返回的DNS记录中包含的签名。因此，如果在此阶段发生DNS欺骗，上述的DNS SEC部署并不能识别。
本发明实施例提供了一种方法，在客户端中对返回的包含查询结果的资源记录的真实性进行验证，进一步保证DNS查询结果的真实性和完整性。
如上文所述，DNS SEC的数据包中增加了几种资源记录，这些资源记录在各级域名解析服务器之间的查询以及响应中被使用。但客户端的操作系统中并不支持以DNS SEC的方式与DNS服务器通信。因此，客户端系统中域名解析的相关接口只能形成DNS请求数据包而无法形成带有上述资源记录的DNS SEC请求数据包，不能直接与域名解析服务器之间以DNS SEC方式进行请求和应答。
在本发明提供的DNS安全查询方法中，以自定义的函数或接口捕获客户端待发送的DNS请求数据包，并将其转换为DNS SEC请求数据包。图1b为windows系统网络体系结构示意图。如图1b所示，可利用钩子函数捕获客户端系统应用层(也称用户层)的DNS解析接口以获取DNS请求数据包，并在钩子函数中将DNS请求数据包转换为符合DNS SEC形式的DNS SEC请求数据包。另外，还可以在客户端系统内核层的协议驱动层，或客户端传输层驱动接口层(TDI)中进行捕获和转换，详见下文实施例介绍。
具体地，将DNS请求数据包转换为对应的DNS SEC请求数据包包括在DNS请求数据包中添加DNS SEC请求数据包具有的资源记录。
步骤S120，发送DNS SEC请求数据包至DNS服务器。
将上述转换后得到的DNS SEC请求数据包传递给系统中的发送接口，调用该发送接口将DNS SEC请求数据包发送至DNS服务器。
步骤S130，接收DNS服务器返回的DNS SEC响应数据包。
调用系统中的接收接口接收DNS SEC响应数据包。服务器返回的DNS SEC响应数据包中包括：资源记录的数字签名，公钥和上级授权签名。
步骤S140，捕获客户端接收的DNS SEC响应数据包，利用DNS服务器提供的公钥验证DNS SEC响应数据包中的数字签名。
与步骤S110类似地，捕获客户端接收的DNS SEC响应数据包具体可以在客户端的系统应用层，系统协议驱动层，或客户端传输层驱动接口层中进行。
DNS SEC响应数据包中包含的数字签名由DNS服务器利用私钥对要返回的资源记录的第一摘要信息加密生成，其中，第一摘要信息是DNS服务器对资源记录使用哈希函数生成的。
具体地，该步骤中的验证过程包括：客户端利用DNS服务器提供的公钥对数字签名进行解密，如果能够解密，表明DNS SEC响应数据包确实来自DNS服务器，验证了数据来源的真实性。解密后得到第一摘要信息，再对DNS SEC响应数据包中的资源记录使用哈希函数生成第二摘要信息，然后进行第一摘要信息和第二摘要信息的比对。如果第一摘要信息和第二摘要信息一致，表明资源记录在传输中没有受到 过篡改，验证了数据的完整性。
上述验证过程由自定义的函数或接口完成。例如，该步骤中利用钩子函数在客户端系统应用层捕获DNS解析接口以获取DNS SEC响应数据包，则上述验证过程也在钩子函数中进行。
此外，攻击者还可能伪造DNS服务器的公钥和私钥，利用伪造的私钥生成数字签名，达到欺骗的目的，客户端对这种情况无法识别。因此，得到第一摘要信息之前，还可以向DNS服务器上一级的节点查询公钥的上级授权签名，利用上级授权签名验证公钥是否正确。其中，上级授权签名是上一级节点对DNS服务器的公钥加密后形成的。如果仍然不相信该上级授权签名，还可以通过递归的方式继续向更高级的节点查询。
步骤S150，若数字签名验证通过，将DNS SEC响应数据包转换为对应的DNS响应数据包，依据DNS响应数据包进行DNS查询处理。
与上一步骤类似地，将DNS SEC响应数据包转换为对应的DNS响应数据包也在自定义的函数中完成，例如，在上文中的捕获DNS SEC响应数据包的钩子函数中完成。
之后，再将转换后的DNS数据包传递给客户端系统的DNS解析接口，供DNS解析接口依据DNS响应数据包进行DNS查询处理，例如，将查询得到的IP信息传递给应用程序。
在上述方案中，DNS请求数据包的捕获、DNS数据包与DNS SEC数据包之间的转换、DNS SEC数据包的发送和接收以及签名验证等对客户端系统是透明的。通过上述各步骤，在当前客户端系统不支持DNS SEC的情况下，能够在客户端完成对DNS响应数据的真实性和完整性的验证。
根据本发明上述实施例提供的DNS安全查询方法，捕获客户端待发送的DNS请求数据包，将DNS请求数据包转换为对应的DNS SEC请求数据包；发送DNS SEC请求数据包至DNS服务器，以接收DNS服务器返回的DNS SEC响应数据包；捕获客户端接收的DNS SEC响应数据包，利用DNS服务器提供的公钥验证DNS SEC响应数据包中的数字签名；若数字签名验证通过，将DNS SEC响应数据包转换为对应的DNS响应数据包，依据DNS响应数据包进行DNS查询处理。根据上述方案，将DNS SEC中的验证过程应用于客户端，在客户端与最近的DNS服务器之间配置信任关系，从而与各级DNS服务器形成完整的信任链，能够在客户端验证数据的真实性和完整性，进一步避免出现DNS劫持和欺骗问题。
图2示出了根据本发明另一个实施例的DNS安全查询方法的流程图。在本实施例中，在客户端的系统应用层进行DNS数据的捕获。如图2所示，该方法包括如下步骤：
步骤S210，利用钩子函数捕获客户端系统应用层的DNS解析接口以获取DNS请求数据包。
其中，客户端系统应用层的DNS解析接口包括gethostbyname接口和/或getaddrinfo接口。通过构造钩子函数捕获客户端系统调用ethostbyname接口和/或getaddrinfo接口的行为，以获取DNS请求数据包。
步骤S220，将DNS请求数据包转换为对应的DNS SEC请求数据包。
该步骤在上述所构造的钩子函数内部完成。
步骤S230，发送DNS SEC请求数据包至DNS服务器，以接收DNS服务器返回的DNS SEC响应数据包。
步骤S240，利用钩子函数捕获客户端系统应用层的DNS解析接口以获取DNS SEC响应数据包。
与步骤S210类似地，通过构造的钩子函数捕获客户端系统调用ethostbyname接口和/或getaddrinfo接口的行为，获取DNS SEC响应数据包。
步骤S250，利用DNS服务器提供的公钥验证DNS SEC响应数据包中的数字签名，若数字签名验证通过，执行步骤S260。
具体地，该步骤中的验证过程包括：客户端利用DNS服务器提供的公钥对数字签名进行解密，如果能够解密，表明DNS SEC响应数据包确实来自DNS服务器，验证了数据来源的真实性。解密后得到第一摘要信息，再对DNS SEC响应数据包中的资源记录使用哈希函数生成第二摘要信息，然后进行第一摘要信息和第二摘要信息的比对。如果第一摘要信息和第二摘要信息一致，表明资源记录在传输中没有受到过篡改，验证了数据的完整性。
步骤S260，将DNS SEC响应数据包转换为对应的DNS响应数据包，依据DNS响应数据包进行DNS查询处理。
图3示出了根据本发明另一个实施例的DNS安全查询方法的流程图。在本实施例中，在客户端系统协议驱动层捕获DNS请求数据包和客户端接收的DNS SEC响应数据包。如图3所示，方法包括如下步骤：
步骤S310，捕获协议驱动层的NdisSend/NdisSendPackets接口以获取DNS请求数据包。
如图1b所示，NDIS中间层驱动位于NDIS协议驱动层和NDIS小端口驱动层之间，NDIS中间层驱动可以拦截本地所有发送数据包和响应数据包，对发送数据包或响应数据包进行接收、拒绝、修改等操作。NDIS中间层驱动对于上层来说充当的是小端口驱动，对于下层来说充当的是协议驱动的作用。当上层的协议驱动发送数据时，调用NdisSend/NdisSendPackets发送数据包，因此，通过捕获该接口可以获取DNS请求数据包。
步骤S320，将DNS请求数据包转换为对应的DNS SEC请求数据包。
该步骤包括在DNS请求数据包中添加DNS SEC请求数据包中具有的资源记录。
步骤S330，发送DNS SEC请求数据包至DNS服务器。
具体地，该步骤包括：依次调用NdisSend/NdisSendPackets接口、 MiniportSend/MiniportSendPackets接口向底层发送DNS  SEC请求数据包；底层通过NDIS接口控制物理网络设备，将DNS SEC请求数据包发送给所述DNS服务器。
步骤S340，接收DNS服务器返回的DNSSEC响应数据包。
具体地，该步骤包括：底层通过物理网络设备接收到DNS SEC响应数据包后，NDIS小端口驱动层调用NdisMIndicateReceivePacket接口指示接收到DNS SEC响应数据包。
步骤S350，通过调用中间驱动层向NDIS注册的ProtocolReceivePacket接口捕获DNS SEC响应数据包。
步骤S360，利用DNS服务器提供的公钥验证DNS SEC响应数据包中的数字签名。若数字签名验证通过，执行步骤S370。
该步骤的具体实施过程与上文实施例类似，此处不再赘述。
步骤S370，将DNS SEC响应数据包转换为对应的DNS响应数据包，依据DNS响应数据包进行DNS查询处理。
具体地，依据DNS响应数据包进行DNS查询处理包括：再次调用NdisMIndicateReceivePacket接口通知协议驱动层接收到DNS响应数据包，而后调用ProtocolReceive接口对DNS响应数据包进行处理，继续调用NdisMIndicateReceivePacket接口将DNS响应数据包传递给NDIS协议驱动层，由相应的协议栈对DNS响应数据包进行DNS查询处理。
图4示出了根据本发明另一个实施例的DNS安全查询方法的流程图。本实施例在客户端传输层驱动接口层中过滤出DNS请求数据包。下文以适用于Win2000操作系统的TDI模型为例进行说明。其他操作系统中，例如，Win7系统中，在传输层驱动接口层中过滤DNS请求数据包需要使用Winsock Kernel(Winsock内核)或Windows Filtering Platform。
如图4所示，方法包括如下步骤：
步骤S410，在传输层驱动接口层中生成过滤设备。
步骤S420，将过滤设备绑定协议驱动生成的设备。
TDI(Tansport Driver Interface)是传输层驱动接口，是一系列接口的集合，这一系列接口用于连接socket(套接字)和协议驱动中间层。应用程序创建socket，用connect创建连接，使用send和receive来发包和收包等，都是通过TDI来将上层的系统调用转发给协议驱动。
每个协议驱动都会生成一个有名字的设备，这个设备会接收一系列请求，包括生成请求，例如，用于创建socket的IRP_MJ_CREATE请求，用于处理bind(绑定)、connect(连接)、listen(监听)、accept(接受)、send(发送)和recv(接收)等的IRP_MJ_INTERNAL_DEVICE_CONTROL请求。
由于协议驱动生成了设备，可以通过生成过滤设备来绑定上述协议驱动生成的设备。
需要说明的是，步骤S410和步骤S420对于本实施例中的TDI模型是必需的。但对于其他操作系统中的传输层驱动接口层，具有不同的过滤方式，而可能采用不同的方式，而无需生成过滤设备。
步骤S430，利用过滤设备对来自应用层的DNS请求数据包进行过滤。
由于生成了过滤设备来绑定上述协议驱动生成的设备，这样，从应用层发过来的请求就会先经过过滤设备，DNS请求数据包就可以由该过滤设备获取。
具体地，设置创建的过滤设备的分发函数为DeviceDispatch，则所有上层发过来的DNS数据请求包都会回调到DeviceDispatch。进一步地，通过TDI_SEND_DATAGRAM来过滤DNS请求数据包。
步骤S440，发送DNS SEC请求数据包至DNS服务器，以接收DNS服务器返回的DNS SEC响应数据包。
步骤S450，利用过滤设备对来自协议驱动层的DNS SEC响应数据包进行过滤。
与步骤S430类似，具体地，通过TDI_RECEIVE_DATAGRAM来过滤DNS相应数据包。
步骤S460，利用DNS服务器提供的公钥验证DNS SEC响应数据包中的数字签名，若数字签名通过验证，执行步骤S470。
步骤S470，将DNS SEC响应数据包转换为对应的DNS响应数据包，依据DNS响应数据包进行DNS查询处理。
在本发明上述实施例中，分别在客户端系统应用层、客户端系统协议驱动层和客户端传输层驱动接口层进行了DNS请求数据包和DNS SEC相应数据包的捕获。都能够将DNS SEC中的验证过程应用于客户端，在客户端与最近的DNS服务器之间配置信任关系，从而与各级DNS服务器形成完整的信任链，能够在客户端验证数据的真实性和完整性，进一步避免出现DNS劫持和欺骗问题。
图5示出了根据本发明一个实施例的DNS安全查询装置的结构框图，如图5所示，该装置包括：第一捕获模块510，收发模块520，第二捕获模块530，验证模块540，转换模块550和查询处理模块560，各模块功能如下：
第一捕获模块510，适于捕获客户端待发送的DNS请求数据包；
收发模块520，适于发送DNS SEC请求数据包至DNS服务器，以接收DNS服务器返回的DNS SEC响应数据包；
第二捕获模块530，适于捕获客户端接收的DNS SEC响应数据包；
验证模块540，适于利用DNS服务器提供的公钥验证DNS SEC响应数据包中的数字签名；
转换模块550，适于在第一捕获模块510捕获DNS请求数据包后，将DNS请求数据包转换为对应的DNS SEC请求数据包；以及，在验证模块540对数字签名验证通过后，将DNS SEC响应数据包转换为对应的DNS响应数据包；
查询处理模块560，适于依据DNS响应数据包进行DNS查询处理。
可选地，第一捕获模块510进一步适于：利用钩子函数捕获客户端系统应用层的DNS解析接口以获取DNS请求数据包；相应地，第二捕获模块530进一步适于：利用钩子函数捕获客户端系统应用层的DNS解析接口以获取所述DNS SEC响应数据包。
其中，客户端系统应用层的DNS解析接口包括gethostbyname接口和/或getaddrinfo接口。
可选地，第一捕获模块510还可以在系统协议驱动层进行DNS请求数据包的捕获。具体地，第一捕获模块510捕获客户端系统协议驱动层的数据包发送接口以获取DNS请求数据包；相应地，第二捕获模块530捕获客户端系统中间驱动层的数据包接收接口以获取DNS SEC响应数据包。
其中，在捕获DNS请求数据包过程中，第一捕获模块510进一步适于：捕获协议驱动层的NdisSend/NdisSendPackets接口以获取DNS请求数据包；收发模块520进一步适于：依次调用NdisSend/NdisSendPackets接口、MiniportSend/MiniportSendPackets接口向底层发送转换模块550转换后的DNS SEC请求数据包，以供底层通过NDIS接口控制物理网络设备，将DNS SEC请求数据包发送给所述DNS服务器。
可选地，在捕获客户端接收的DNS SEC响应数据包过程中，收发模块520进一步适于：底层通过物理网络设备接收到DNS SEC响应数据包后，小端口驱动层调用NdisMIndicateReceivePacket接口指示接收到DNS SEC响应数据包；第二捕获模块530进一步适于：通过调用中间驱动层向NDIS注册的ProtocolReceivePacket接口捕获所述DNS SEC响应数据包；查询处理模块560进一步适于：再次调用NdisMIndicateReceivePacket接口通知协议驱动层接收到转换模块560转换后的DNS响应数据包，而后调用ProtocolReceive接口对DNS响应数据包进行处理，继续调用NdisMIndicateReceivePacket接口将DNS响应数据包传递给协议驱动层，由相应的协议栈对DNS响应数据包进行DNS查询处理。
可选地，第一捕获模块510还适于在客户端传输层驱动接口层中过滤出DNS请求数据包；相应地，第二捕获模块530进一步适于：在客户端传输层驱动接口层中过滤出DNS SEC响应数据包。可选地，装置还包括：生成模块570，适于在传输层驱动接口层中生成过滤设备；将过滤设备绑定协议驱动生成的设备；第一捕获模块510进一步适于：利用过滤设备对来自应用层的DNS请求数据包进行过滤；第二捕获模块530进一步适于：利用过滤设备对来自协议驱动层的DNS SEC响应数据包进行过滤。
可选地，验证模块540进一步适于：利用公钥对数字签名进行解密，得到第一摘要信息；根据DNS中的查询结果生成第二摘要信息；比对第二摘要信息和所述第一摘要信息，若第二摘要信息与第一摘要信息相同，判断数字签名通过验证。
可选地，验证模块540还适于：
在利用公钥对数字签名进行解密，得到第一摘要信息之前，向DNS服务器上一级的节点查询公钥的上级授权签名；利用上级授权签名验证公钥是否正确。
根据本发明上述实施例提供的DNS安全查询装置，第一捕获客户端待发送的DNS请求数据包，转化模块将DNS请求数据包转换为对应的DNS SEC请求数据包；收发模块发送DNS SEC请求数据包至DNS服务器，以接收DNS服务器返回的DNS SEC响应数据包；第二捕获模块捕获客户端接收的DNS SEC响应数据包，验证模块利用DNS服务器提供的公钥验证DNS SEC响应数据包中的数字签名；若数字签名验证通过，转换模块将DNS SEC响应数据包转换为对应的DNS响应数据包，依据DNS响应数据包进行DNS查询处理。根据上述方案，将DNS SEC中的验证过程应用于客户端，在客户端与最近的DNS服务器之间配置信任关系，从而与各级DNS服务器形成完整的信任链，能够在客户端验证数据的真实性和完整性，进一步避免DNS欺骗的发生。
在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。
类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。
本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。
此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。
本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在 实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发明实施例的DNS安全查询装置中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。
例如，图6示出了可以实现DNS安全查询方法的计算设备。该计算设备传统上包括处理器610和以存储器620形式的计算机程序产品或者计算机可读介质。存储器620可以是诸如闪存、EEPROM(电可擦除可编程只读存储器)、EPROM、硬盘或者ROM之类的电子存储器。存储器620具有用于执行上述方法中的任何方法步骤的程序代码631的存储空间630。例如，用于程序代码的存储空间630可以包括分别用于实现上面的方法中的各种步骤的各个程序代码631。这些程序代码可以从一个或者多个计算机程序产品中读出或者写入到这一个或者多个计算机程序产品中。这些计算机程序产品包括诸如硬盘，紧致盘(CD)、存储卡或者软盘之类的程序代码载体。这样的计算机程序产品通常为如参考图7所述的便携式或者固定存储单元。该存储单元可以具有与图6的计算设备中的存储器620类似布置的存储段、存储空间等。程序代码可以例如以适当形式进行压缩。通常，存储单元包括计算机可读代码631’，即可以由例如诸如610之类的处理器读取的代码，这些代码当由计算设备运行时，导致该计算设备执行上面所描述的方法中的各个步骤。
本文中所称的“一个实施例”、“实施例”或者“一个或者多个实施例”意味着，结合实施例描述的特定特征、结构或者特性包括在本发明的至少一个实施例中。此外，请注意，这里“在一个实施例中”的词语例子不一定全指同一个实施例。
应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。
此外，还应当注意，本说明书中使用的语言主要是为了可读性和教导的目的而选择的，而不是为了解释或者限定本发明的主题而选择的。因此，在不偏离所附权利要求书的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。对于本发明的范围，对本发明所做的公开是说明性的，而非限制性的，本发明的范围由所附权利要求书限定。

Claims (22)

  1. 一种DNS安全查询方法，包括：
    捕获客户端待发送的DNS请求数据包，将所述DNS请求数据包转换为对应的DNSSEC请求数据包；
    发送所述DNSSEC请求数据包至DNS服务器，以接收所述DNS服务器返回的DNSSEC响应数据包；
    捕获客户端接收的所述DNSSEC响应数据包，利用所述DNS服务器提供的公钥验证所述DNSSEC响应数据包中的数字签名；若所述数字签名验证通过，将所述DNSSEC响应数据包转换为对应的DNS响应数据包，依据所述DNS响应数据包进行DNS查询处理。
  2. 根据权利要求1所述的方法，其中，所述捕获客户端待发送的DNS请求数据包进一步为：利用钩子函数捕获客户端系统应用层的DNS解析接口以获取DNS请求数据包；
    所述捕获客户端接收的所述DNSSEC响应数据包进一步为：利用钩子函数捕获客户端系统应用层的DNS解析接口以获取所述DNSSEC响应数据包。
  3. 根据权利要求2所述的方法，其中，所述客户端系统应用层的DNS解析接口包括gethostbyname接口和/或getaddrinfo接口。
  4. 根据权利要求1所述的方法，其中，所述捕获客户端待发送的DNS请求数据包进一步为：捕获客户端系统协议驱动层的数据包发送接口以获取DNS请求数据包；
    所述捕获客户端接收的所述DNSSEC响应数据包进一步为：捕获客户端系统中间驱动层的数据包接收接口以获取DNSSEC响应数据包。
  5. 根据权利要求4所述的方法，其中，所述捕获客户端待发送的DNS请求数据包，将所述DNS请求数据包转换为对应的DNSSEC请求数据包，发送所述DNSSEC请求数据包至DNS服务器进一步包括：
    捕获协议驱动层的NdisSend/NdisSendPackets接口以获取DNS请求数据包；
    将所述DNS请求数据包转换为对应的DNSSEC请求数据包；
    依次调用NdisSend/NdisSendPackets接口、MiniportSend/MiniportSendPackets接口向底层发送所述DNSSEC请求数据包；
    底层通过NDIS接口控制物理网络设备，将所述DNSSEC请求数据包发送给所述DNS服务器。
  6. 根据权利要求4所述的方法，其中，所述捕获客户端接收的所述DNSSEC响应数据包，利用所述DNS服务器提供的公钥验证所述DNSSEC响应数据包中的数字签名；若所述数字签名验证通过，将所述DNSSEC响应数据包转换为对应的DNS响应数据包，依据所述DNS响应数据包进行DNS查询处理进一步包括：
    底层通过物理网络设备接收到所述DNSSEC响应数据包后，小端口驱动层调用 NdisMIndicateReceivePacket接口指示接收到所述DNSSEC响应数据包；
    通过调用中间驱动层向NDIS注册的ProtocolReceivePacket接口捕获所述DNSSEC响应数据包，利用所述DNS服务器提供的公钥验证所述DNSSEC响应数据包中的数字签名，若所述数字签名验证通过，将所述DNSSEC响应数据包转换为对应的DNS响应数据包；
    再次调用NdisMIndicateReceivePacket接口通知协议驱动层接收到所述DNS响应数据包，而后调用ProtocolReceive接口对所述DNS响应数据包进行处理，继续调用NdisMIndicateReceivePacket接口将所述DNS响应数据包传递给协议驱动层，由相应的协议栈对所述DNS响应数据包进行DNS查询处理。
  7. 根据权利要求1所述的方法，其中，所述捕获客户端待发送的DNS请求数据包进一步为：在客户端传输层驱动接口层中过滤出DNS请求数据包；
    所述捕获客户端接收的所述DNSSEC响应数据包进一步为：在客户端传输层驱动接口层中过滤出所述DNSSEC响应数据包。
  8. 根据权利要求7所述的方法，其中，在所述在客户端传输层驱动接口层中过滤出DNS请求数据包之前进一步包括：在传输层驱动接口层中生成过滤设备；将所述过滤设备绑定协议驱动生成的设备；
    所述在客户端传输层驱动接口层中过滤出DNS请求数据包进一步为：利用所述过滤设备对来自应用层的DNS请求数据包进行过滤；
    所述在客户端传输层驱动接口层中过滤出所述DNSSEC响应数据包进一步为：利用所述过滤设备对来自协议驱动层的所述DNSSEC响应数据包进行过滤。
  9. 根据权利要求1-8所述的方法，其中，利用所述DNS服务器的公钥验证所述DNSSEC响应数据包中的数字签名进一步包括：
    利用所述公钥对所述数字签名进行解密，得到第一摘要信息；
    根据DNS中的查询结果生成第二摘要信息；
    比对所述第二摘要信息和所述第一摘要信息，若所述第二摘要信息与第一摘要信息相同，判断数字签名通过验证。
  10. 根据权利要求9所述的方法，其中，所述利用所述公钥对所述数字签名进行解密，得到第一摘要信息之前，所述方法还包括：
    向所述DNS服务器上一级的节点查询所述公钥的上级授权签名；
    利用所述上级授权签名验证所述公钥是否正确。
  11. 一种DNS安全查询装置，包括：
    第一捕获模块，适于捕获客户端待发送的DNS请求数据包；
    收发模块，适于发送DNSSEC请求数据包至DNS服务器，以接收所述DNS服务器返回的DNSSEC响应数据包；
    第二捕获模块，适于捕获客户端接收的所述DNSSEC响应数据包；
    验证模块，适于利用所述DNS服务器提供的公钥验证所述DNSSEC响应数据包 中的数字签名；
    转换模块，适于在所述第一捕获模块捕获DNS请求数据包后，将所述DNS请求数据包转换为对应的DNSSEC请求数据包；以及，在所述验证模块对所述数字签名验证通过后，将所述DNSSEC响应数据包转换为对应的DNS响应数据包；
    查询处理模块，适于依据所述DNS响应数据包进行DNS查询处理。
  12. 根据权利要求11所述的装置，其中，所述第一捕获模块进一步适于：利用钩子函数捕获客户端系统应用层的DNS解析接口以获取DNS请求数据包；
    所述第二捕获模块进一步适于：利用钩子函数捕获客户端系统应用层的DNS解析接口以获取所述DNSSEC响应数据包。
  13. 根据权利要求12所述的装置，其中，所述客户端系统应用层的DNS解析接口包括gethostbyname接口和/或getaddrinfo接口。
  14. 根据权利要求11所述的装置，其中，所述第一捕获模块进一步适于：捕获客户端系统协议驱动层的数据包发送接口以获取DNS请求数据包；
    所述第二捕获模块进一步适于：捕获客户端系统中间驱动层的数据包接收接口以获取DNSSEC响应数据包。
  15. 根据权利要求14所述的装置，其中，所述第一捕获模块进一步适于：
    捕获协议驱动层的NdisSend/NdisSendPackets接口以获取DNS请求数据包；
    所述收发模块进一步适于：依次调用NdisSend/NdisSendPackets接口、MiniportSend/MiniportSendPackets接口向底层发送所述转换模块转换后的DNSSEC请求数据包，以供底层通过NDIS接口控制物理网络设备，将所述DNSSEC请求数据包发送给所述DNS服务器。
  16. 根据权利要求14所述的装置，其中，所述收发模块进一步适于：底层通过物理网络设备接收到所述DNSSEC响应数据包后，小端口驱动层调用NdisMIndicateReceivePacket接口指示接收到所述DNSSEC响应数据包；
    所述第二捕获模块进一步适于：通过调用中间驱动层向NDIS注册的ProtocolReceivePacket接口捕获所述DNSSEC响应数据包；
    所述查询处理模块进一步适于：再次调用NdisMIndicateReceivePacket接口通知协议驱动层接收到转换模块转换后的DNS响应数据包，而后调用ProtocolReceive接口对所述DNS响应数据包进行处理，继续调用NdisMIndicateReceivePacket接口将所述DNS响应数据包传递给协议驱动层，由相应的协议栈对所述DNS响应数据包进行DNS查询处理。
  17. 根据权利要求11所述的装置，其中，所述第一捕获模块进一步适于：在客户端传输层驱动接口层中过滤出DNS请求数据包；
    所述第二捕获模块进一步适于：在客户端传输层驱动接口层中过滤出所述DNSSEC响应数据包。
  18. 根据权利要求17所述的装置，其中，所述装置还包括：生成模块，适于在 传输层驱动接口层中生成过滤设备；将所述过滤设备绑定协议驱动生成的设备；
    所述第一捕获模块进一步适于：利用所述过滤设备对来自应用层的DNS请求数据包进行过滤；
    所述第二捕获模块进一步适于：利用所述过滤设备对来自协议驱动层的所述DNSSEC响应数据包进行过滤。
  19. 根据权利要求11-18任一项所述的装置，其中，所述验证模块进一步适于：
    利用所述公钥对所述数字签名进行解密，得到第一摘要信息；
    根据DNS中的查询结果生成第二摘要信息；
    比对所述第二摘要信息和所述第一摘要信息，若所述第二摘要信息与第一摘要信息相同，判断数字签名通过验证。
  20. 根据权利要求19所述的装置，其中，所述验证模块还适于：
    在利用所述公钥对所述数字签名进行解密，得到第一摘要信息之前，向所述DNS服务器上一级的节点查询所述公钥的上级授权签名；
    利用所述上级授权签名验证所述公钥是否正确。
  21. 一种计算机程序，包括计算机可读代码，当所述计算机可读代码在计算设备上运行时，导致所述计算设备执行根据权利要求1至10任一项所述的DNS安全查询方法。
  22. 一种计算机可读介质，其中存储了如权利要求21所述的计算机程序。
PCT/CN2015/099007 2015-03-31 2015-12-25 Dns安全查询方法和装置 WO2016155373A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201510148617.2 2015-03-31
CN201510148617.2A CN104702714B (zh) 2015-03-31 2015-03-31 Dns安全查询方法和装置

Publications (1)

Publication Number Publication Date
WO2016155373A1 true WO2016155373A1 (zh) 2016-10-06

Family

ID=53349471

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2015/099007 WO2016155373A1 (zh) 2015-03-31 2015-12-25 Dns安全查询方法和装置

Country Status (2)

Country Link
CN (1) CN104702714B (zh)
WO (1) WO2016155373A1 (zh)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104702714B (zh) * 2015-03-31 2019-02-01 北京奇虎科技有限公司 Dns安全查询方法和装置
CN106470195B (zh) * 2015-08-20 2019-12-17 互联网域名系统北京市工程研究中心有限公司 消息的签名方法和域名服务器
CN105141612A (zh) * 2015-09-01 2015-12-09 中国互联网络信息中心 一种dns数据包隐私保护方法
CN106888186A (zh) * 2015-12-15 2017-06-23 北京奇虎科技有限公司 移动终端支付类应用程序安全支付方法及装置
CN106888184A (zh) * 2015-12-15 2017-06-23 北京奇虎科技有限公司 移动终端支付类应用程序安全支付方法及装置
CN105847461A (zh) * 2016-03-31 2016-08-10 乐视控股（北京）有限公司 用于智能设备的数据包处理方法和系统
CN108183896A (zh) * 2017-12-26 2018-06-19 珠海市君天电子科技有限公司 浏览器的页面获取方法、装置和电子设备
CN108650244A (zh) * 2018-04-24 2018-10-12 网宿科技股份有限公司 一种域名解析方法、终端及递归dns服务器
CN110532210B (zh) * 2019-08-07 2021-10-22 北京数衍科技有限公司 安全获取操作系统任意输出设备数据的桥接方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101277306A (zh) * 2008-05-14 2008-10-01 华为技术有限公司 一种处理dns业务的方法、系统及设备
CN103957289A (zh) * 2014-05-12 2014-07-30 中国科学院计算机网络信息中心 一种基于复杂网络上的dnssec解析方法
CN104468865A (zh) * 2014-12-25 2015-03-25 北京奇虎科技有限公司 域名解析控制、响应方法及相应的装置
CN104702714A (zh) * 2015-03-31 2015-06-10 北京奇虎科技有限公司 Dns安全查询方法和装置

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101277306A (zh) * 2008-05-14 2008-10-01 华为技术有限公司 一种处理dns业务的方法、系统及设备
CN103957289A (zh) * 2014-05-12 2014-07-30 中国科学院计算机网络信息中心 一种基于复杂网络上的dnssec解析方法
CN104468865A (zh) * 2014-12-25 2015-03-25 北京奇虎科技有限公司 域名解析控制、响应方法及相应的装置
CN104702714A (zh) * 2015-03-31 2015-06-10 北京奇虎科技有限公司 Dns安全查询方法和装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ZHU, GANG: "Development and Application Prospect of DNSSec Technology", TELECOMMUNICATIONS TECHNOLOGY, 30 September 2010 (2010-09-30), ISSN: 1000-1247 *

Also Published As

Publication number Publication date
CN104702714B (zh) 2019-02-01
CN104702714A (zh) 2015-06-10

Similar Documents

Publication Publication Date Title
WO2016155373A1 (zh) Dns安全查询方法和装置
US11216514B2 (en) Secure DNS query
US11706036B2 (en) Systems and methods for preserving privacy of a registrant in a domain name system (“DNS”)
JP6574168B2 (ja) 端末識別方法、ならびにマシン識別コードを登録する方法、システム及び装置
CN109413076B (zh) 域名解析方法及装置
US9219722B2 (en) Unclonable ID based chip-to-chip communication
JP5534373B2 (ja) 評判システムにおける調整されただまし行為を防ぐためのセキュリティトークン内のメタデータの使用
US11489853B2 (en) Distributed threat sensor data aggregation and data export
CN106657010B (zh) 访问数据的方法、装置及系统
JP2018501567A (ja) 装置検証方法及び機器
US10257171B2 (en) Server public key pinning by URL
TW201012156A (en) Secure resource name resolution
EP3210107A1 (en) Method and apparatus for facilitating the login of an account
US12041094B2 (en) Threat sensor deployment and management
CN108259406A (zh) 检验ssl证书的方法和系统
US20180063101A1 (en) Keys for encrypted disk partitions
Bates et al. Forced perspectives: Evaluating an SSL trust enhancement at scale
CN114616795A (zh) 用于防止重试或重放攻击的安全机制
CN109067768B (zh) 一种域名查询安全性的检测方法、系统、设备和介质
JP2011176435A (ja) 秘密鍵共有システム、方法、データ処理装置、管理サーバ、及びプログラム
JP2022534677A (ja) ブロックチェーンを使用するオンラインアプリケーションおよびウェブページの保護
CN111935123A (zh) 一种检测dns欺骗攻击的方法、设备、存储介质
CN104092733B (zh) 一种基于hdfs的可信分布式文件系统
US10462180B1 (en) System and method for mitigating phishing attacks against a secured computing device
TW201143343A (en) Tolerant key verification method

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15887323

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15887323

Country of ref document: EP

Kind code of ref document: A1