WO2011088658A1 - 对dns报文中的身份信息进行认证的方法、服务器和*** - Google Patents

对dns报文中的身份信息进行认证的方法、服务器和*** Download PDF

Info

Publication number
WO2011088658A1
WO2011088658A1 PCT/CN2010/074492 CN2010074492W WO2011088658A1 WO 2011088658 A1 WO2011088658 A1 WO 2011088658A1 CN 2010074492 W CN2010074492 W CN 2010074492W WO 2011088658 A1 WO2011088658 A1 WO 2011088658A1
Authority
WO
WIPO (PCT)
Prior art keywords
key
information
dns
server
query terminal
Prior art date
Application number
PCT/CN2010/074492
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 WO2011088658A1 publication Critical patent/WO2011088658A1/zh

Links

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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • 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
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures

Definitions

  • the present invention relates to the field of Internet technologies, and in particular, to a method, a server, and a system for authenticating identity information in a DNS packet. Background technique
  • the Internet has been widely used in people's work and life.
  • the Domain Name System provides convenience for human beings.
  • FIG. 1 is a schematic structural diagram of a domain name system supporting recursive query in the prior art.
  • the domain name system includes a host terminal, a recursive server, and a plurality of authoritative servers, such as an authoritative server A, a rights server B, and an authoritative server C.
  • the possible process of performing a recursive query in the domain name system shown in Figure 1 is as follows:
  • Step 11 The host terminal sends a DNS packet to the recursive server.
  • the DNS packet is used to query the IP address corresponding to a domain name.
  • Step 12 The recursive server forwards the DNS packet to the authoritative server A.
  • Step 13 If the IP address corresponding to the unknown domain name exists on the authoritative server A, the corresponding IP address is answered to the recursive server.
  • Step 14 The recursive server sends the corresponding IP address to the host terminal that initiated the query.
  • the authoritative server A does not have an associated record but knows that the authoritative server B may have the record, it will advise the recursive server to query the authoritative server B in the response.
  • the authoritative server B has an associated record, it will reply to the recursive server; if the authoritative server B does not have a related record but knows that the authoritative server C may have a relevant record, it will be advised to the recursive server to query the authoritative server C. And so on, until the authoritative server with the record returns the query result to the recursive server, and then the recursive server forwards the query result to the initial launch.
  • the host terminal of the query is not have an associated record but knows that the authoritative server B may have the record, it will advise the recursive server to query the authoritative server B in the response.
  • the authoritative server B has an associated record, it will reply to the recursive server; if the authoritative server B does not have a related record but knows that the authoritative server C may have a relevant record, it will be advised to the recursive server
  • the authoritative server that was last queried will answer a response to the recursive server that the domain name does not exist, and the recursive server will return the response back to the host terminal that initiated the query, thus completing a recursion.
  • the query process If all authoritative servers do not have related records, the authoritative server that was last queried will answer a response to the recursive server that the domain name does not exist, and the recursive server will return the response back to the host terminal that initiated the query, thus completing a recursion. The query process.
  • the embodiment of the invention provides a method, a server and a system for authenticating identity information in a DNS packet to improve the security of the domain name system.
  • the embodiment of the invention provides a method for authenticating identity information in a DNS packet, which includes:
  • the DNS packet includes signature information and verification information
  • the signature information is obtained by encrypting the verification information with a first key, where the verification information includes the query terminal.
  • the embodiment of the invention further provides a server, including:
  • a packet receiving module configured to receive a DNS packet, where the DNS packet includes signature information and verification information, where the signature information is obtained by encrypting the verification information with a first key, and the verification is performed.
  • the information includes identity information of the query terminal;
  • a key acquisition module configured to acquire a second key corresponding to the first key
  • a decryption module configured to decrypt the signature information by using the second key to obtain a decryption result
  • An authentication module configured to end the query when the decrypted result is consistent with the verification information The authentication of the identity information of the terminal is successful.
  • the embodiment of the present invention further provides a system for authenticating identity information in a DNS packet, including the foregoing server.
  • the embodiment of the present invention introduces a mechanism for authenticating the identity information in the DNS packet, and performs security authentication on the queried terminal identity information carried in the DNS packet to ensure that the queried terminal ID information carried in the DNS packet is authentic and reliable, and effectively prevents
  • the server performs the access control by using the identity information of the query terminal, the other terminal fakes the identity information of the query terminal with the access right to defraud the service, thereby improving the security of the domain name system.
  • FIG. 1 is a schematic structural diagram of a domain name system supporting recursive query in the prior art
  • FIG. 2 is a flowchart of a method for authenticating identity information in a DNS packet according to the first embodiment of the present invention
  • FIG. 3 is a flowchart of a method for authenticating identity information in a DNS packet according to a second embodiment of the present invention
  • FIG. 4 is a flowchart of a method for authenticating identity information in a DNS packet according to a third embodiment of the present invention.
  • FIG. 5 is a flowchart of a method for authenticating identity information in a DNS packet according to a fourth embodiment of the present invention.
  • FIG. 6 is a flowchart of a method for authenticating identity information in a DNS packet according to a fifth embodiment of the present invention.
  • FIG. 7 is a schematic structural diagram of a server according to a sixth embodiment of the present invention. detailed description
  • FIG. 2 is a flowchart of a method for authenticating identity information in a DNS packet according to the first embodiment of the present invention.
  • the execution body of this embodiment may be a server, such as an authoritative server or other type of DNS server.
  • the method provided in this embodiment includes:
  • Step 21 The server receives a DNS packet, where the DNS packet includes signature information and verification information.
  • the signature information is obtained by encrypting the verification information with a first key, where the verification information includes Query the identity information of the terminal.
  • the DNS packet can be specifically a DNS query request or other types of packets related to the DNS service.
  • the inquiring terminal is a terminal that initiates a DNS query request, such as a host terminal, a mobile terminal, an intelligent terminal, etc. that initiates a DNS query request.
  • the identity information of the querying terminal may be information such as an identity (ID), an IP address, and a device identifier of the querying terminal.
  • the verification information may be information related to the identity information of the query terminal, for example, the verification information may be specifically the identity information of the query terminal, that is, the verification information may be the content of the ID field in which the identity information of the terminal is located in the DNS message. .
  • the verification information may also be a combination of the identity information of the query terminal and other information, that is, the verification information may include an ID field of the DNS message and content of one or more other fields other than the ID field, such as a message type. , the check code of the ID field, or the ID field plus the check code of other fields.
  • the signature information may be obtained by encrypting the verification information by the query terminal using the first key, or in the domain name system of the recursive query, the signature information may also be obtained by the recursive server using the first key to encrypt the verification information.
  • Step 22 The server acquires a second key corresponding to the first key.
  • the method for obtaining the second key by the server is not limited, for example: the second key may be pre-stored on the server; if the second key is a public key, the public key or the public key may also be queried by the query terminal. Index information is sent directly to the server.
  • Step 23 The server decrypts the signature information by using the second key to obtain a decrypted result.
  • the first key and the second key may be a private key pair, that is, the embodiment may perform encryption and decryption processing by using a symmetric key mechanism.
  • the first key and the second key may be a private key-public key pair, that is, the encryption and decryption processing may be performed by using the mechanism of the asymmetric key in this embodiment.
  • Step 24 The server successfully authenticates the identity information of the query terminal when the decryption result is consistent with the verification information.
  • the identity information in the DNS query message is reliable.
  • the authentication of the identity information of the query terminal is successful, and the server processes the DNS packet to provide services for the query terminal. If the decryption result is inconsistent with the verification information, the identity information in the DNS query message may be fraudulently used by other terminals, and the authentication of the identity information of the query terminal fails.
  • the server refuses to provide a service for the query terminal, and the DNS report may be used.
  • the document is not processed or discarded.
  • the existing domain name system is configured to perform the function of authenticating the identity information of the queried terminal carried in the RADIUS packet, and performing security authentication for the queried terminal identity information carried in the DNS packet to ensure the query terminal carried in the DNS packet.
  • the ID information is authentic and reliable, effectively preventing the server from using the identity information of the query terminal for access control, and other terminals impersonating the identity information of the query terminal having the access right to defraud the service, thereby improving the security of the domain name system.
  • FIG. 3 is a flowchart of a method for authenticating identity information in a DNS packet according to a second embodiment of the present invention.
  • a private key is reserved between the host terminal and the authoritative server, and a symmetric key is used.
  • the law is certified.
  • the method provided in this embodiment includes:
  • Step 31 The private key is pre-agreed between the host terminal and the authoritative server.
  • the private key used by the host terminal may be referred to as the first private key, and the private key used by the authoritative server is referred to as the second private key.
  • the first private key is the same as the second private key.
  • step 31 is not required to be performed in each authentication process. As long as the private key is pre-agreed between the host terminal and the authoritative server, the agreed private key can be used for authentication processing in the subsequent authentication process.
  • Step 32 The host terminal generates a DNS packet, and uses the first private key to encrypt the verification information to obtain signature information, and sends a DNS packet including the signature information and the verification information to the recursive server.
  • the verification information may be specifically the ID of the host terminal, that is, the verification information may be the content of the ID field in which the ID of the host terminal in the DNS packet is located.
  • the verification information may also be a combination of the ID of the host terminal and other information, that is, the verification information may include an ID field of the DNS message, and content of one or more other fields other than the ID field, such as a packet type, The check code of the ID field, or the ID field plus the check code of other fields, and the like.
  • the ID of the host terminal can be a host name or an IP address.
  • Step 33 The recursive server forwards the DNS packet sent by the host terminal to an authoritative server, such as the authoritative server A.
  • Step 34 The authoritative server A pre-establishes a mapping relationship between the host terminal and the key information, and obtains a second private key corresponding to the host terminal according to the mapping relationship.
  • Step 35 The authoritative server A uses the second private key to decrypt the signature information in the DNS packet to obtain the decrypted result.
  • Step 36 The authoritative server A compares the decryption result with the verification information in the DNS packet, and determines whether the decryption result is consistent with the verification information in the DNS packet: If the decryption result is consistent with the verification information in the DNS packet, Then go to step 37; otherwise, go to step 38.
  • Step 37 The authentication is successful, and the authoritative server A provides services for the host terminal;
  • Step 38 The authentication fails, and the authoritative server A refuses to provide services for the host terminal; If the authoritative server does not have the information required for the DNS packet, such as the DNS packet to be queried. For IP addresses, etc., the existing recursive query mechanism can be used, and other authoritative servers, such as the authoritative server B and the authoritative server C, provide services for the host terminal.
  • the implementation of the authentication of the signature information in the DNS packet by the other authoritative server is similar to the implementation of the authentication of the signature information in the DNS packet by the authoritative server A, and details are not described herein.
  • a private key pair is pre-agreed between the host terminal and the authoritative server, and the ID information of the host terminal carried in the DNS packet is securely authenticated based on the private key pair to ensure the DNS packet.
  • the host terminal ID information carried in the device is authentic and reliable, effectively preventing the authoritative server from using the identity information of the host terminal for access control, and other terminals impersonating the identity information of the host terminal having the access authority to defraud the service, thereby improving the security of the domain name system. Sex.
  • FIG. 4 is a flowchart of a method for authenticating identity information in a DNS packet according to a third embodiment of the present invention.
  • a private key is reserved between the recursive server and the authoritative server, and the symmetric key method is used for authentication.
  • the method provided in this embodiment includes:
  • Step 41 Pre-arrange the private key between the recursive server and the authoritative server.
  • the private key used by the recursive server may be referred to as the first private key, and the private key used by the authoritative server is referred to as the second private key.
  • the first private key is the same as the second private key.
  • this embodiment does not need to perform step 41 in each authentication process. As long as the private key is pre-agreed between the recursive server and the authoritative server, in the subsequent authentication process, the agreed private key can be used for authentication processing.
  • Step 42 The host terminal generates a DNS packet, and sends the DNS packet to the recursive server, where the DNS packet includes the verification information.
  • the verification information may be specifically the ID of the host terminal, that is, the verification information may be the content of the ID field in which the ID of the host terminal in the DNS packet is located.
  • the verification information may also be a combination of the ID of the host terminal and other information, that is, the verification information may include an ID field of the DNS message, and content of one or more other fields other than the ID field, such as a packet type, The check code of the ID field, or the ID field plus the check code of other fields, and the like.
  • the ID of the host terminal can be a host name or an IP address.
  • Step 43 The recursive server receives the DNS packet sent by the host terminal, and uses the first private key to encrypt the verification information in the DNS packet to obtain signature information, and obtains the signature information to an authoritative server.
  • the server A sends a DNS message including signature information and verification information.
  • Step 44 - Step 48 Similar to Step 34 - Step 38, and details are not described herein again.
  • the existing recursive query mechanism may be used, and other authoritative servers, such as the authoritative server B and the authoritative server C, may be the host.
  • the terminal provides services.
  • the implementation of the authentication of the signature information in the DNS packet by the other authoritative server is similar to the implementation of the authentication of the signature information in the DNS packet by the authoritative server A, and is not described here.
  • This embodiment is based on a symmetric key authentication mechanism.
  • this embodiment introduces a server guarantee mechanism, that is, a private key pair is pre-arranged between the recursive server and the authoritative server. Based on the private key pair, the ID information of the host terminal carried in the DNS packet is securely authenticated to ensure that the host terminal ID information carried in the DNS packet is authentic and reliable, and the authoritative server is prevented from using the identity information of the host terminal for access control. At the same time, other terminals impersonate the identity information of the host terminal with access rights to defraud the service, thereby improving the security of the domain name system.
  • FIG. 5 is a flowchart of a method for authenticating identity information in a DNS packet according to a fourth embodiment of the present invention.
  • the asymmetric key method is used for authentication, and the public key information can be transmitted in a plaintext manner.
  • the method provided in this embodiment includes:
  • Step 51 Predetermine the private key-public key pair that the host terminal needs to use.
  • the private key-public key pair that needs to be used can be determined by the host terminal itself, or can be determined by other devices and used by the host terminal.
  • the host terminal can encrypt the DNS file by using the private key.
  • the private key is usually only known by the host terminal, and the public key is advertised. There is a correspondence between the public key and the private key.
  • Step 52 The host terminal generates a DNS packet, and uses the private key to encrypt the verification information to obtain signature information, and sends a DNS packet including the signature information, the verification information, and the public key to the recursive server.
  • the verification information may be specifically the ID of the host terminal, that is, the verification information may be the content of the ID field in which the ID of the host terminal in the DNS packet is located. Alternatively, the verification information may also be the ID of the host terminal and The combination of other information, that is, the verification information may include the ID field of the DNS message, and the contents of one or more other fields other than the ID field, such as the message type, the check code of the ID field, or the ID field plus other The checksum of the field, etc.
  • the ID of the host terminal can be a host name or an IP address.
  • the hash value of the public key can be used as the ID of the host terminal, which is equivalent to directly establishing an association between the public key and the host terminal ID. It avoids the need to establish an additional mechanism to associate the host terminal's ID, such as the IP address, with the public key, and can directly determine the identity of the host terminal through calculation, simplifying the user management mechanism; in addition, because the hash value of the public key is relative to the other The ID of the type, such as the stability and encryption function relative to the IP address, therefore, using the hash value of the public key as the ID of the host terminal, and also facilitating statistical analysis of the behavior of the host terminal in the mobile environment.
  • Step 53 The recursive server forwards the DNS packet sent by the host terminal to an authoritative server, such as the authoritative server A.
  • Step 54 The authoritative server A receives the DNS packet sent by the recursive server, and parses the DNS packet to obtain the public key.
  • Step 55 The authoritative server A decrypts the signature information in the DNS packet with the public key, and obtains the decrypted result.
  • Step 56 The authoritative server A compares the decryption result with the verification information in the DNS packet, and determines whether the decryption result is consistent with the verification information in the DNS packet: If the decryption result is consistent with the verification information in the DNS packet, Then step 57 is performed; otherwise, step 58 is performed.
  • Step 57 The authentication is successful, and the authoritative server A provides services for the host terminal;
  • Step 58 The authentication fails, and the authoritative server A refuses to provide services for the host terminal; If the authoritative server does not have the information required for the DNS packet, such as the IP address to be queried for the DNS packet, the existing recursive query mechanism may be used, and other authoritative servers, such as the authoritative server B and the authoritative server C, may be the host.
  • the terminal provides services.
  • the implementation of the authentication of the signature information in the DNS packet by the other authoritative server is similar to the implementation of the authentication of the signature information in the DNS packet by the authoritative server A, and details are not described herein.
  • the asymmetric key authentication mechanism is used to combine the private key and the public key pair to authenticate the host terminal ID information carried in the DNS packet, and ensure that the host terminal ID information carried in the DNS packet is authentic and reliable.
  • the authoritative server uses the identity information of the host terminal to perform access control, the other terminal impersonates the identity information of the host terminal with the access authority to defraud the service, thereby improving the security of the domain name system.
  • the public key can be transmitted in clear text in the DNS packet, and the public key does not need to be stored on the authoritative server, and the storage resource of the authoritative server is saved.
  • FIG. 6 is a flowchart of a method for authenticating identity information in a DNS packet according to a fifth embodiment of the present invention.
  • the asymmetric key method is used for authentication, and the index information of the public key is transmitted in plaintext.
  • the method provided in this embodiment includes:
  • Step 61 Predetermine the private key-public key pair that the host terminal needs to use.
  • the private key-public key pair that needs to be used can be determined by the host terminal itself, or can be determined by other devices and used by the host terminal.
  • the host terminal can encrypt the DNS file by using the private key.
  • the private key is usually only known by the host terminal, and the public key has a corresponding relationship between the public key and the private key.
  • Step 62 The host terminal generates a DNS packet, and obtains signature information by encrypting the verification information by using the private key, and sends the ID, the signature information, the verification information, and the public key index of the host terminal to the recursive server. DNS packet.
  • the verification information may be specifically the ID of the host terminal, that is, the verification information may be the content of the ID field in which the ID of the host terminal in the DNS packet is located.
  • the verification information may also be a combination of the ID of the host terminal and other information, that is, the verification information may include an ID field of the DNS message, and content of one or more other fields other than the ID field, such as a packet type, The check code of the ID field, or the ID field plus the check code of other fields, and the like.
  • the ID of the host terminal can be a host name or an IP address.
  • the ID of the host terminal can also be used as a public key index, which is equivalent to directly establishing an association between the public key index and the host terminal ID.
  • Step 63 The recursive server forwards the DNS packet sent by the host terminal to an authoritative server, such as the authoritative server A.
  • Step 64 The authoritative server A receives the DNS packet sent by the recursive server, and parses the DNS packet to obtain the public key index.
  • Step 65 The authoritative server A obtains the public key corresponding to the public key index by querying the pre-established public key index table, and uses the public key to decrypt the signature information in the DNS packet to obtain a decrypted result.
  • the public key index table stores the correspondence between the public key and the public key, and based on the public key index I query the public key index table, the required public key can be obtained.
  • Step 66-Step 68 Step 56-Step 58 is similar, and details are not described herein again.
  • the existing recursive query mechanism may be used, and other authoritative servers, such as the authoritative server B and the authoritative server C, may be the host.
  • the terminal provides services.
  • the implementation of the authentication of the signature information in the DNS packet by the other authoritative server is similar to the implementation of the authentication of the signature information in the DNS packet by the authoritative server A, and is not described here.
  • the asymmetric key authentication mechanism is used to combine the private key and the public key pair to authenticate the host terminal ID information carried in the DNS packet, and ensure that the host terminal ID information carried in the DNS packet is authentic and reliable.
  • the authoritative server uses the identity information of the host terminal to perform access control, the other terminal impersonates the identity information of the host terminal with the access authority to defraud the service, thereby improving the security of the domain name system.
  • the public key is transmitted in the clear text in the DNS packet, instead of directly transmitting the public key in the plaintext manner, the size of the packet can be reduced, which is beneficial to save resources required for transmitting the message.
  • FIG. 7 is a schematic structural diagram of a server according to a sixth embodiment of the present invention.
  • the server provided in this embodiment includes: a message receiving module 71, a key obtaining module 72, a decrypting module 73, and an authentication module 74.
  • the packet receiving module 71 is configured to receive a DNS packet, where the DNS packet includes signature information and verification information.
  • the signature information is obtained by encrypting the verification information with a first key.
  • the verification information may be specifically the identity information of the query terminal, that is, the verification information may be the body of the query terminal in the DNS message. The content of the ID field where the information is located.
  • the verification information may also be a combination of the identity information of the query terminal and other information, that is, the verification information may include an ID field of the DNS message and content of one or more other fields other than the ID field, such as a message type. , the check code of the ID field, or the ID field plus the check code of other fields.
  • the key obtaining module 72 is configured to acquire a second key corresponding to the first key.
  • the decryption module 73 is configured to decrypt the signature information by using the second key to obtain a decrypted result.
  • the authentication module 74 is configured to successfully authenticate the identity information of the query terminal when the decryption result is consistent with the verification information.
  • the authentication may be performed based on a symmetric key mechanism.
  • the first key is a first private key
  • the second key is a second private key that is the same as the first private key.
  • the message receiving module 71 may be configured to receive the DNS message sent by the query terminal or sent by the query terminal via the recursive server.
  • the signature information included in the DNS message is obtained by the query terminal encrypting the verification information by using the first private key.
  • the key obtaining module 72 is specifically configured to obtain the second private key corresponding to the query terminal according to a mapping relationship between the pre-established terminal and the key information.
  • the key pair is pre-agreed between the recursive server and the server described in this embodiment.
  • the packet receiving module 71 is specifically configured to receive the DNS packet sent by the recursive server, where the signature information included in the DNS packet is received by the recursive server after receiving the query terminal.
  • the verification information is obtained by encrypting the first private key.
  • the key obtaining module 72 is specifically configured to obtain the second private key corresponding to the recursive server according to a mapping relationship between the pre-established recursive server and the key information.
  • the private key and the public key may be combined to perform authentication based on the asymmetric key mechanism.
  • the first key is a private key
  • the second key is a pair with the private key
  • the public key may be transmitted in the DNS message.
  • the message receiving module 71 may be specifically configured to receive the DNS message sent by the query terminal or sent by the query terminal via the recursive server.
  • the signature information included in the DNS file is obtained by the query terminal using the private key to encrypt the verification information; and the DNS message further includes the public key.
  • the key obtaining module 72 is specifically configured to parse the DNS packet to obtain the public key.
  • the index information of the public key can be transmitted in clear text in the DNS packet.
  • the packet receiving module 71 is specifically configured to receive the DNS packet sent by the query terminal or sent by the query terminal via a recursive server, where the signature information included in the DNS packet is The querying terminal obtains the encrypted information by using the private key to obtain the verification information; and the DNS packet further includes index information of the public key.
  • the key obtaining block 72 is specifically configured to parse the DNS packet, obtain the index information, and obtain the public key corresponding to the index information by querying a pre-established public key index table.
  • the server can perform security authentication on the queried terminal identity information carried in the DNS packet based on the symmetrical or asymmetric crypto mechanism, and ensure that the queried terminal ID information carried in the DNS packet is authentic and reliable, thereby effectively preventing the server from using the query terminal.
  • identity information is subjected to access control, other terminals impersonate the identity information of the query terminal having the access right to defraud the service, thereby improving the security of the domain name system.
  • the performance entity of the server in this embodiment is not limited, such as an authoritative server or other types of DNS servers; the working mechanism can be referred to the description of the corresponding embodiment in FIG. 2, and the records of the authoritative server in FIG. 3-6. This will not be repeated here.
  • the embodiment of the invention further provides a system for authenticating identity information in a DNS packet, the system comprising the above server.
  • the server may be specifically an authoritative server; the recursive server, the query terminal, and the at least two authoritative servers may constitute a domain name system that supports recursive query.
  • the system result diagram can be seen in the description of FIG. 1 , the query terminal, the recursive server, and the authoritative servers. For the function and its interaction mechanism, refer to the corresponding description of FIG. 3 to FIG. 6 , and details are not described herein again.
  • the foregoing storage medium includes: a medium that can store a program code, such as a ROM, a RAM, a magnetic disk, or an optical disk.

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)

Description

对 DNS报文中的身份信息进行认证的方法、 服务器和*** 技术领域
本发明涉及互联网技术领域， 特别是涉及一种对 DNS报文中的身份信息 进行认证的方法、 服务器和***。 背景技术
伴随着科学技术的不断发展， 互联网在人们的工作和生活中得到了越来 越广泛的应用， 作为互联网中的重要组成部分， 域名*** （Doma in Name Sys tem, 简称 DNS )提供了在方便人类记忆的域名和计算机使用的 IP地址之 间进行映射查询的服务。
图 1为现有技术支持递归查询的域名***结构示意图。 如图 1所示， 域 名***包括主机终端、 递归服务器和多个权威服务器， 如权威服务器 A、 权 威服务器 B和权威服务器 C等。 在图 1所示的域名***中进行一次递归查询 的可能过程如下：
步骤 11 : 主机终端会向递归服务器发送一个 DNS报文， 该 DNS报文用于 请求查询某域名对应的 IP地址。
步骤 12: 递归服务器向权威服务器 A转发 DNS报文。
步骤 13: 如果权威服务器 A上存有该未知域名对应的 IP地址， 则将相 应 IP地址应答给递归服务器。
步骤 14: 递归服务器将相应 IP地址发送给发起查询的主机终端。
如果权威服务器 A没有相关的记录却知道权威服务器 B可能具有该纪录 的话， 会在应答中向递归服务器建议其向权威服务器 B进行查询。 同样地， 如果权威服务器 B具有相关记录， 会应答给递归服务器； 如果权威服务器 B 不具有相关记录但是知道权威服务器 C可能具有相关记录， 则会向递归服务 器建议其向权威服务器 C查询。 以此类推， 直至具有该记录的权威服务器将 查询结果返回给递归服务器， 再由递归服务器将该查询结果转发给最初发起 查询的主机终端。 如果所有权威服务器都不具有相关记录， 则最后被查询到 的权威服务器会回答一条该域名不存在的应答给递归服务器， 递归服务器将 该应答转回给发起查询的主机终端， 至此完成了一次递归查询过程。
发明人在实现本发明实施例过程中发现， 现有技术域名***提供服务时 缺少对 DNS报文的认证机制， 因此域名***存在安全隐患。 发明内容
本发明实施例提供一种对 DNS报文中的身份信息进行认证的方法、 服务 器和***， 以提高域名***的安全性。
本发明实施例提供了一种对 DNS报文中的身份信息进行认证的方法， 包 括：
接收 DNS报文， 所述 DNS报文包括签名信息和校验信息； 所述签名信息 通过对所述校验信息釆用第一密钥加密后得到 , 所述校验信息包括所述查询 终端的身份信息；
获取与所述第一密钥对应的第二密钥；
釆用所述第二密钥对所述签名信息进行解密， 得到解密结果；
在所述解密结果与所述校验信息一致时， 对所述查询终端的身份信息的 认证成功。
本发明实施例还提供了一种服务器， 包括：
报文接收模块， 用于接收 DNS报文， 所述 DNS报文包括签名信息和校验 信息； 所述签名信息通过对所述校验信息釆用第一密钥加密后得到， 所述校 验信息包括所述查询终端的身份信息；
密钥获取模块， 用于获取与所述第一密钥对应的第二密钥；
解密模块， 用于釆用所述第二密钥对所述签名信息进行解密， 得到解密 结果；
认证模块， 用于在所述解密结果与所述校验信息一致时， 对所述查询终 端的身份信息的认证成功。
本发明实施例还提供了一种对 DNS报文中的身份信息进行认证的***， 包括上述月良务器。
本发明实施例引入对 DNS报文中的身份信息进行认证的机制，通过对 DNS 报文中携带的查询终端身份信息进行安全认证， 保证 DNS报文中携带的查询 终端 ID信息真实可靠，有效防止了服务器在利用查询终端的身份信息进行访 问控制时， 其他终端假冒具有访问权限的查询终端的身份信息来骗取服务， 从而提高了域名***的安全性。 附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案， 下面将对实 施例或现有技术描述中所需要使用的附图作简单地介绍， 显而易见地， 下面 描述中的附图仅仅是本发明的一些实施例， 对于本领域普通技术人员来讲， 在不付出创造性劳动性的前提下， 还可以根据这些附图获得其他的附图。
图 1为现有技术支持递归查询的域名***结构示意图；
图 2为本发明第一实施例提供的 DNS报文中的身份信息进行认证的方法 流程图；
图 3为本发明第二实施例提供的 DNS报文中的身份信息进行认证的方法 流程图；
图 4为本发明第三实施例提供的 DNS报文中的身份信息进行认证的方法 流程图；
图 5为本发明第四实施例提供的 DNS报文中的身份信息进行认证的方法 流程图；
图 6为本发明第五实施例提供的 DNS报文中的身份信息进行认证的方法 流程图；
图 7为本发明第六实施例提供的服务器的结构示意图。 具体实施方式
下面将结合本发明实施例中的附图， 对本发明实施例中的技术方案进行 清楚、 完整地描述， 显然， 所描述的实施例仅仅是本发明一部分实施例， 而 不是全部的实施例。 基于本发明中的实施例， 本领域普通技术人员在没有付 出创造性劳动前提下所获得的所有其他实施例， 都属于本发明保护的范围。
图 2为本发明第一实施例提供的 DNS报文中的身份信息进行认证的方法 流程图。 本实施例的执行主体可为服务器， 如权威服务器或其他类型的 DNS 月良务器等。 如图 2所示， 本实施例提供的方法包括：
步骤 21 :服务器接收 DNS报文，所述 DNS报文包括签名信息和校验信息； 所述签名信息通过对所述校验信息釆用第一密钥加密后得到， 所述校验信息 包括所述查询终端的身份信息。
DNS报文可具体为 DNS查询请求或与 DNS服务相关的其他类型报文。 查 询终端即为发起 DNS查询请求的终端， 如发起 DNS查询请求的主机终端、 手 机终端、 智能终端等。
查询终端的身份信息可为查询终端的身份标识（ ID )、 IP地址、 设备标 识等信息。 校验信息可为与查询终端的身份信息相关的信息， 如： 校验信息 可具体为查询终端的身份信息， 即校验信息可为 DNS报文中查询终端的身份 信息所在的 ID字段的内容。 或者， 校验信息还可为查询终端的身份信息与其 他信息的组合， 即校验信息可包括 DNS报文的 ID字段、 以及 ID字段以外的 一个或多个其他字段的内容， 如报文类型、 ID字段的校验码、 或者 ID字段 加上其他字段的校验码等。
签名信息可由查询终端釆用第一密钥对校验信息加密后得到， 或者， 在 递归查询的域名***中， 签名信息也可由递归服务器釆用第一密钥对校验信 息加密后得到。
步骤 22: 服务器获取与所述第一密钥对应的第二密钥。 服务器获取第二密钥的方式不受限制， 例如： 可在服务器上预先存储第 二密钥； 如果第二密钥是一公钥， 则还可通过查询终端将该公钥或该公钥的 索引信息， 直接发送给服务器。
步骤 23: 服务器釆用所述第二密钥对所述签名信息进行解密， 得到解密 结果。
第一密钥与第二密钥可为一私钥对， 即本实施例可釆用对称密钥的机制 进行加密和解密处理。 或者， 第一密钥与第二密钥可为一私钥-公钥对， 即本 实施例可釆用非对称密钥的机制进行加密和解密处理。
步骤 24: 服务器在所述解密结果与所述校验信息一致时， 对所述查询终 端的身份信息的认证成功。
如果解密结果与校验信息一致， 说明 DNS查询报文中的身份信息真实可 靠， 则该查询终端的身份信息的认证成功， 服务器对该 DNS报文进行处理， 以便为该查询终端提供服务。 如果解密结果与校验信息不一致， 说明 DNS查 询报文中的身份信息可能被其他终端冒用了， 则该查询终端的身份信息的认 证失败， 服务器拒绝为查询终端提供服务， 可对该 DNS报文不进行处理或丟 弃该 DNS 艮文。 本实施例在现有域名***中， 引入对 DNS 艮文中携带的查询 终端身份信息进行认证的机制， 为 DNS报文中携带的查询终端身份信息进行 安全认证， 保证 DNS报文中携带的查询终端 ID信息真实可靠， 有效防止了服 务器在利用查询终端的身份信息进行访问控制时， 其他终端假冒具有访问权 限的查询终端的身份信息来骗取服务， 从而提高了域名***的安全性。
下面各详述实施例分别以图 1所示的支持递归查询的域名***为应用实 例， 对本发明技术方案进行详细说明。 需要说明的是， 本发明还可应用到其 他域名***， 如不支持递归查询的域名***中， 以下的应用实例不应理解为 对本发明的限制。
图 3为本发明第二实施例提供的 DNS报文中的身份信息进行认证的方法 流程图。 本实施例在主机终端与权威服务器之间预约私钥， 釆用对称密钥方 法进行认证。 如图 3所示， 本实施例提供的方法包括：
步骤 31 : 主机终端与权威服务器之间预先约定私钥。
不妨将主机终端使用的私钥称为第一私钥， 权威服务器使用的私钥称为 第二私钥。 第一私钥和第二私钥相同。
需要说明的是， 本实施例并不是在每次认证过程中都需要执行步骤 31。 只要在主机终端和权威服务器之间预先约定好私钥， 则在后续认证过程中， 即可釆用约定好的私钥进行认证处理。
步骤 32: 主机终端生成 DNS报文， 并釆用第一私钥对校验信息进行加密 后得到签名信息，向递归服务器发送包括有签名信息和校验信息的 DNS报文。 校验信息可具体为主机终端的 ID,即校验信息可为 DNS报文中主机终端的 ID 所在的 ID字段的内容。 或者， 校验信息还可为主机终端的 ID与其他信息的 组合， 即校验信息可包括 DNS报文的 ID字段、 以及 ID字段以外的一个或多 个其他字段的内容， 如报文类型、 ID字段的校验码、 或者 ID字段加上其他 字段的校验码等。 主机终端的 ID可为主机名或 IP地址等。
步骤 33: 递归服务器向某一权威服务器， 如权威服务器 A转发主机终端 发送的 DNS报文。
步骤 34：权威服务器 A预先建立有主机终端与密钥信息之间的映射关系 , 根据该映射关系， 得到与主机终端对应的第二私钥。
步骤 35 :权威服务器 A釆用第二私钥对 DNS报文中的签名信息进行解密， 得到解密结果。
步骤 36: 权威服务器 A将解密结果与 DNS报文中的校验信息进行比较， 判断解密结果与 DNS报文中的校验信息是否一致： 如果解密结果与 DNS报文 中的校验信息一致， 则执行步骤 37; 否则， 执行步骤 38。
步骤 37: 认证成功， 权威服务器 A为主机终端提供服务； 结束。
步骤 38: 认证失败， 权威服务器 A拒绝为主机终端提供服务； 结束。 如果权威服务器自身没有 DNS报文所需的信息， 如 DNS报文需要查询的 IP地址等， 则可釆用现有递归查询机制， 由其他权威服务器， 如权威服务器 B、权威服务器 C等为主机终端提供服务。 其他权威服务器对 DNS报文中的签 名信息进行认证的实现方式， 与权威服务器 A对 DNS报文中的签名信息进行 认证的实现方式相似， 在此不再赘述。
本实施例基于对称性密钥认证机制， 在主机终端和权威服务器之间预先 约定私钥对，基于该私钥对为 DNS报文中携带的主机终端的 ID信息进行安全 认证， 保证 DNS报文中携带的主机终端 ID信息真实可靠， 有效防止了权威服 务器在利用主机终端的身份信息进行访问控制时， 其他终端假冒具有访问权 限的主机终端的身份信息来骗取服务， 从而提高了域名***的安全性。
图 4为本发明第三实施例提供的 DNS报文中的身份信息进行认证的方法 流程图。 本实施例在递归服务器与权威服务器之间预约私钥， 釆用对称密钥 方法进行认证。 如图 4所示， 本实施例提供的方法包括：
步骤 41 : 递归服务器与权威服务器之间预先约定私钥。
不妨将递归服务器使用的私钥称为第一私钥， 权威服务器使用的私钥称 为第二私钥。 第一私钥和第二私钥相同。
需要说明的是， 本实施例并不是在每次认证过程中都需要执行步骤 41。 只要在递归服务器和权威服务器之间预先约定好私钥，则在后续认证过程中， 即可釆用约定好的私钥进行认证处理。
步骤 42:主机终端生成 DNS报文，向递归服务器发送该 DNS报文，该 DNS 报文包括校验信息。 校验信息可具体为主机终端的 ID, 即校验信息可为 DNS 报文中主机终端的 ID所在的 ID字段的内容。 或者， 校验信息还可为主机终 端的 ID与其他信息的组合， 即校验信息可包括 DNS报文的 ID字段、 以及 ID 字段以外的一个或多个其他字段的内容， 如报文类型、 ID字段的校验码、 或 者 ID字段加上其他字段的校验码等。主机终端的 ID可为主机名或 IP地址等。
步骤 43: 递归服务器接收主机终端发送的 DNS报文， 并釆用第一私钥对 DNS 报文中的校验信息进行加密后得到签名信息， 向某一权威服务器， 如权 威服务器 A发送包括有签名信息和校验信息的 DNS报文。
步骤 44-步骤 48: 与步骤 34-步骤 38相似， 在此不再赘述。
如果权威服务器自身没有 DNS报文所需的信息， 如 DNS报文需要查询的 IP地址等， 则可釆用现有递归查询机制， 由其他权威服务器， 如权威服务器 B、权威服务器 C等为主机终端提供服务。 其他权威服务器对 DNS报文中的签 名信息进行认证的实现方式， 与权威服务器 A对 DNS报文中的签名信息进行 认证的实现方式相似， 在此不再赘述。
本实施例基于对称性密钥认证机制， 为了避免终端用户较多时需要建立 过多的私钥对， 本实施例引入服务器担保机制， 即只在递归服务器和权威服 务器之间预先约定私钥对， 基于该私钥对为 DNS报文中携带的主机终端的 ID 信息进行安全认证， 保证 DNS报文中携带的主机终端 ID信息真实可靠， 有效 防止了权威服务器在利用主机终端的身份信息进行访问控制时， 其他终端假 冒具有访问权限的主机终端的身份信息来骗取服务， 从而提高了域名***的 安全性。
图 5为本发明第四实施例提供的 DNS报文中的身份信息进行认证的方法 流程图。 本实施例釆用非对称密钥方法进行认证， 且公钥信息可通过明文的 方式传输。 如图 5所示， 本实施例提供的方法包括：
步骤 51 : 预先确定主机终端需要使用的私钥-公钥对。
预先确定主机终端需要使用的私钥-公钥对。 需要使用的私钥-公钥对可 由主机终端自身确定， 或者， 还可由其他设备确定并给主机终端使用。 主机 终端可使用私钥对 DNS 文进行加密处理，私钥通常只有主机终端自己知道， 而公钥向外发布， 公钥和私钥间存在对应关系。
步骤 52: 主机终端生成 DNS报文， 并釆用私钥对校验信息进行加密后得 到签名信息， 向递归服务器发送包括有签名信息、 校验信息和公钥等信息的 DNS报文。 校验信息可具体为主机终端的 ID, 即校验信息可为 DNS报文中主 机终端的 ID所在的 ID字段的内容。 或者， 校验信息还可为主机终端的 ID与 其他信息的组合， 即校验信息可包括 DNS报文的 ID字段、 以及 ID字段以外 的一个或多个其他字段的内容， 如报文类型、 ID字段的校验码、 或者 ID字 段加上其他字段的校验码等。 主机终端的 ID可为主机名或 IP地址等。
在使用 DNS报文直接传递公钥的情况下， 可以使用该公钥的哈希值作为 主机终端的 ID, 这样就相当于直接建立了公钥与主机终端 ID之间的关联。 避免了需要建立额外的机制将主机终端的 ID, 如 IP地址， 与公钥关联， 可 以通过计算直接认定主机终端的身份， 简化的用户管理机制； 此外， 由于公 钥的哈希值相对于其他类型的 ID, 如相对于 IP地址具有稳定性的特点和加 密功能， 因此， 使用该公钥的哈希值作为主机终端的 ID, 还便于在移动环境 下对主机终端的行为进行统计分析。
步骤 53: 递归服务器向某一权威服务器， 如权威服务器 A转发主机终端 发送的 DNS报文。
步骤 54: 权威服务器 A接收递归服务器发送的 DNS报文， 解析该 DNS报 文得到上述公钥。
步骤 55: 权威服务器 A釆用公钥对 DNS报文中的签名信息进行解密， 得 到解密结果。
步骤 56: 权威服务器 A将解密结果与 DNS报文中的校验信息进行比较， 判断解密结果与 DNS报文中的校验信息是否一致： 如果解密结果与 DNS报文 中的校验信息一致， 则执行步骤 57; 否则， 执行步骤 58。
步骤 57: 认证成功， 权威服务器 A为主机终端提供服务； 结束。
步骤 58: 认证失败， 权威服务器 A拒绝为主机终端提供服务； 结束。 如果权威服务器自身没有 DNS报文所需的信息， 如 DNS报文需要查询的 IP地址等， 则可釆用现有递归查询机制， 由其他权威服务器， 如权威服务器 B、权威服务器 C等为主机终端提供服务。 其他权威服务器对 DNS报文中的签 名信息进行认证的实现方式， 与权威服务器 A对 DNS报文中的签名信息进行 认证的实现方式相似， 在此不再赘述。 本实施例基于非对称性密钥认证机制， 将私钥和公钥对相组合对 DNS报 文中携带的主机终端 ID信息进行认证， 保证 DNS报文中携带的主机终端 ID 信息真实可靠， 有效防止了权威服务器在利用主机终端的身份信息进行访问 控制时， 其他终端假冒具有访问权限的主机终端的身份信息来骗取服务， 从 而提高了域名***的安全性。 本实施例公钥可在 DNS报文中明文传输， 不需 要在权威服务器上存储公钥， 还有利于节省权威服务器的存储资源。
图 6为本发明第五实施例提供的 DNS报文中的身份信息进行认证的方法 流程图。 本实施例釆用非对称密钥方法进行认证， 且釆用明文的方式传输公 钥的索引信息。 如图 6所示， 本实施例提供的方法包括：
步骤 61 : 预先确定主机终端需要使用的私钥-公钥对。
预先确定主机终端需要使用的私钥-公钥对。 需要使用的私钥-公钥对可 由主机终端自身确定， 或者， 还可由其他设备确定并给主机终端使用。 主机 终端可使用私钥对 DNS 文进行加密处理，私钥通常只有主机终端自己知道， 而公钥向外发布公钥和私钥间存在对应关系。
步骤 62: 主机终端生成 DNS报文， 并釆用私钥对校验信息进行加密后得 到签名信息， 向递归服务器发送包括有主机终端的 ID、 签名信息、 校验信息 和公钥索引等信息的 DNS报文。 校验信息可具体为主机终端的 ID, 即校验信 息可为 DNS报文中主机终端的 ID所在的 ID字段的内容。 或者， 校验信息还 可为主机终端的 ID与其他信息的组合， 即校验信息可包括 DNS报文的 ID字 段、 以及 ID字段以外的一个或多个其他字段的内容， 如报文类型、 ID字段 的校验码、 或者 ID字段加上其他字段的校验码等。 主机终端的 ID可为主机 名或 IP地址等。
可选的， 主机终端的 ID也可以作为公钥索引使用， 这样就相当于直接建 立了公钥索引与主机终端 ID之间的关联。
步骤 63: 递归服务器向某一权威服务器， 如权威服务器 A转发主机终端 发送的 DNS报文。 步骤 64 : 权威服务器 A接收递归服务器发送的 DNS报文， 解析该 DNS报 文得到上述公钥索引。
步骤 65 : 权威服务器 A通过查询预先建立的公钥索引表， 获取与上述公 钥索引对应的公钥， 并釆用该公钥对 DNS报文中的签名信息进行解密， 得到 解密结果。
公钥索引表中存储了公钥索弓 I和公钥之间对应关系， 基于上述公钥索弓 I 查询公钥索引表， 可得到所需的公钥。
步骤 66-步骤 68 : 步骤 56-步骤 58相似， 在此不再赘述。
如果权威服务器自身没有 DNS报文所需的信息， 如 DNS报文需要查询的 IP地址等， 则可釆用现有递归查询机制， 由其他权威服务器， 如权威服务器 B、权威服务器 C等为主机终端提供服务。 其他权威服务器对 DNS报文中的签 名信息进行认证的实现方式， 与权威服务器 A对 DNS报文中的签名信息进行 认证的实现方式相似， 在此不再赘述。
本实施例基于非对称性密钥认证机制， 将私钥和公钥对相组合对 DNS报 文中携带的主机终端 ID信息进行认证， 保证 DNS报文中携带的主机终端 ID 信息真实可靠， 有效防止了权威服务器在利用主机终端的身份信息进行访问 控制时， 其他终端假冒具有访问权限的主机终端的身份信息来骗取服务， 从 而提高了域名***的安全性。 本实施例在 DNS报文中明文传输公钥索引， 而 不是直接以明文的方式传输公钥， 可以减小报文的大小， 有利于节省传输报 文所需的资源。
图 7为本发明第六实施例提供的服务器的结构示意图。 如图 7所示， 本 实施例提供的服务器包括： 报文接收模块 71、 密钥获取模块 72、 解密模块 73和认证模块 74。
报文接收模块 71用于接收 DNS报文，所述 DNS报文包括签名信息和校验 信息； 所述签名信息通过对所述校验信息釆用第一密钥加密后得到。 校验信 息可具体为查询终端的身份信息， 即校验信息可为 DNS报文中查询终端的身 份信息所在的 ID字段的内容。 或者， 校验信息还可为查询终端的身份信息与 其他信息的组合， 即校验信息可包括 DNS报文的 ID字段、 以及 ID字段以外 的一个或多个其他字段的内容， 如报文类型、 ID字段的校验码、 或者 ID字 段加上其他字段的校验码等。
密钥获取模块 72用于获取与所述第一密钥对应的第二密钥。
解密模块 73用于釆用所述第二密钥对所述签名信息进行解密，得到解密 结果。
认证模块 74用于在所述解密结果与所述校验信息一致时，对所述查询终 端的身份信息的认证成功。
在上述技术方案的基础上， 可选的， 可基于对称密钥机制进行认证。 所 述第一密钥为第一私钥， 所述第二密钥为与所述第一私钥相同的第二私钥。
如果在查询终端和服务器之间预先约定密钥对， 该情形下报文接收模块 71具体可用于接收所述查询终端发送的或所述查询终端经由递归服务器发送 的所述 DNS 艮文， 所述 DNS 艮文包括的所述签名信息， 由所述查询终端釆用 所述第一私钥对所述校验信息加密后得到。密钥获取模块 72具体可用于根据 预先建立的终端与密钥信息之间的映射关系， 获取与所述查询终端对应的所 述第二私钥。
为了避免查询终端数量较大时***需要设置数量较大的私钥， 则可引入 服务器担保机制。 即在递归服务器和本实施例所述服务器之间预先约定密钥 对。该情形下报文接收模块 71具体可用于接收递归服务器发送的所述 DNS报 文， 所述 DNS报文包括的所述签名信息， 由所述递归服务器在接收到所述查 询终端发送的包括校验信息的 DNS报文时， 釆用所述第一私钥对所述校验信 息加密后得到。密钥获取模块 72具体可用于根据预先建立的递归服务器与密 钥信息之间的映射关系， 获取与所述递归服务器对应的所述第二私钥。
在上述技术方案的基础上， 可选的， 可将私钥和公钥相结合， 基于非对 称密钥机制进行认证。 所述第一密钥为私钥， 所述第二密钥为与所述私钥对 应的公钥； 可在 DNS报文中明文传输公钥， 该情形下， 报文接收模块 71具体 可用于接收所述查询终端发送的或所述查询终端经由递归服务器发送的所述 DNS 文， 所述 DNS 文包括的所述签名信息， 由所述查询终端釆用所述私 钥对所述校验信息加密后得到； 所述 DNS报文还包括所述公钥。 密钥获取模 块 72具体可用于解析所述 DNS报文， 得到所述公钥。
或者， 可在 DNS报文中明文传输公钥的索引信息。 该情形下， 报文接收 模块 71 具体可用于接收所述查询终端发送的或所述查询终端经由递归服务 器发送的所述 DNS报文， 所述 DNS报文包括的所述签名信息， 由所述查询终 端釆用所述私钥对所述校验信息加密后得到； 所述 DNS报文还包括所述公钥 的索引信息。 密钥获耳 莫块 72具体可用于解析所述 DNS报文， 得到所述索引 信息， 并通过查询预先建立的公钥索引表， 获取与所述索引信息对应的所述 公钥。
本实施例服务器可基于对称或非对称加密机制， 对 DNS报文中携带的查 询终端身份信息进行安全认证，保证 DNS报文中携带的查询终端 ID信息真实 可靠， 有效防止了服务器在利用查询终端的身份信息进行访问控制时， 其他 终端假冒具有访问权限的查询终端的身份信息来骗取服务， 从而提高了域名 ***的安全性。 本实施例服务器的表现实体不受限制， 如权威服务器或其他 类型的 DNS服务器等； 其工作机理， 可参见图 2对应实施例的记载， 以及图 3-图 6中关于权威服务器的记载， 在此不再赘述。
本发明实施例还提供了一种对 DNS报文中的身份信息进行认证的***， 该***包括上述服务器。 上述服务器可具体为权威服务器； 递归服务器、 查 询终端以及至少二个权威服务器， 可构成支持递归查询的域名***， 其*** 结果示意图可参见图 1的记载， 查询终端、 递归服务器和各权威服务器的功 能及其交互机理， 可参见图 3-图 6对应的记载， 在此不再赘述。
本领域普通技术人员可以理解： 附图只是一个实施例的示意图， 附图中 的模块或流程并不一定是实施本发明所必须的。 本领域普通技术人员可以理解： 实施例中的装置中的模块可以按照实施 例描述分布于实施例的装置中， 也可以进行相应变化位于不同于本实施例的 一个或多个装置中。 上述实施例的模块可以合并为一个模块， 也可以进一步 拆分成多个子模块。
上述本发明实施例序号仅仅为了描述， 不代表实施例的优劣。
本领域普通技术人员可以理解： 实现上述方法实施例的全部或部分步骤 可以通过程序指令相关的硬件来完成， 前述的程序可以存储于一计算机可读 取存储介质中， 该程序在执行时， 执行包括上述方法实施例的步骤； 而前述 的存储介质包括： R0M、 RAM, 磁碟或者光盘等各种可以存储程序代码的介质。
最后应说明的是： 以上实施例仅用以说明本发明的技术方案， 而非对其 限制； 尽管参照前述实施例对本发明进行了详细的说明， 本领域的普通技术 人员应当理解： 其依然可以对前述实施例所记载的技术方案进行修改， 或者 对其中部分技术特征进行等同替换； 而这些修改或者替换， 并不使相应技术 方案的本质脱离本发明实施例技术方案的精神和范围。

Claims

权利要求
1、 一种对 DNS报文中的身份信息进行认证的方法， 其特征在于， 包括： 接收 DNS报文， 所述 DNS报文包括签名信息和校验信息； 所述签名信息 通过对所述校验信息釆用第一密钥加密后得到 , 所述校验信息包括所述查询 终端的身份信息；
获取与所述第一密钥对应的第二密钥；
釆用所述第二密钥对所述签名信息进行解密， 得到解密结果；
在所述解密结果与所述校验信息一致时， 对所述查询终端的身份信息的 认证成功。
2、 根据权利要求 1所述的方法， 其特征在于， 所述校验信息还包括： 所 述 DNS报文中除了所述查询终端的身份信息所在字段之外的一个或多个其他 字段的内容。
3、 根据权利要求 1或 2所述的方法， 其特征在于， 所述第一密钥为第一 私钥， 所述第二密钥为与所述第一私钥相同的第二私钥；
所述接收 DNS 艮文， 具体为： 接收所述查询终端发送的或所述查询终端 经由递归服务器发送的所述 DNS报文， 所述 DNS报文包括的所述签名信息， 由所述查询终端釆用所述第一私钥对所述校险信息加密后得到；
所述获取与所述第一密钥对应的第二密钥， 具体为： 根据预先建立的终 端与密钥信息之间的映射关系， 获取与所述查询终端对应的所述第二私钥。
4、 根据权利要求 1或 2所述的方法， 其特征在于， 所述第一密钥为第一 私钥， 所述第二密钥为与所述第一私钥相同的第二私钥；
所述接收 DNS报文， 具体为： 接收递归服务器发送的所述 DNS报文， 所 述 DNS报文包括的所述签名信息， 由所述递归服务器在接收到所述查询终端 发送的包括所述校验信息的 DNS报文时， 釆用所述第一私钥对所述校验信息 加密后得到； 所述获取与所述第一密钥对应的第二密钥， 具体为： 根据预先建立的递 归服务器与密钥信息之间的映射关系， 获取与所述递归服务器对应的所述第 二私钥。
5、根据权利要求 1或 2所述的方法，其特征在于，所述第一密钥为私钥， 所述第二密钥为与所述私钥对应的公钥；
所述接收 DNS 艮文， 具体为： 接收所述查询终端发送的或所述查询终端 经由递归服务器发送的所述 DNS报文， 所述 DNS报文包括的所述签名信息， 由所述查询终端釆用所述私钥对所述校验信息加密后得到； 所述 DNS报文还 包括所述公钥；
所述获取与所述第一密钥对应的第二密钥， 具体为： 解析所述 DNS报文， 得到所述公钥。
6、根据权利要求 1或 2所述的方法，其特征在于，所述第一密钥为私钥， 所述第二密钥为与所述私钥对应的公钥；
所述接收 DNS 艮文， 具体为： 接收所述查询终端发送的或所述查询终端 经由递归服务器发送的所述 DNS报文， 所述 DNS报文包括的所述签名信息， 由所述查询终端釆用所述私钥对所述校验信息加密后得到； 所述 DNS报文还 包括所述公钥的索引信息；
所述获取与所述第一密钥对应的第二密钥， 具体为： 解析所述 DNS报文， 得到所述索引信息， 并通过查询预先建立的公钥索引表， 获取与所述索引信 息对应的所述公钥。
7、 根据权利要求 1或 2所述的方法， 其特征在于， 所述查询终端的身份 信息为所述查询终端的主机名或 IP地址。
8、 根据权利要求 5所述的方法， 其特征在于， 所述查询终端的身份信息 为所述公钥的哈希值。
9、 一种服务器， 其特征在于， 包括：
报文接收模块， 用于接收 DNS报文， 所述 DNS报文包括签名信息和校验 信息； 所述签名信息通过对所述校验信息釆用第一密钥加密后得到， 所述校 验信息包括所述查询终端的身份信息；
密钥获取模块， 用于获取与所述第一密钥对应的第二密钥；
解密模块， 用于釆用所述第二密钥对所述签名信息进行解密， 得到解密 结果；
认证模块， 用于在所述解密结果与所述校验信息一致时， 对所述查询终 端的身份信息的认证成功。
1 0、 根据权利要求 9所述的服务器， 其特征在于， 所述校验信息还包括： 所述 DNS报文中除了所述查询终端的身份信息所在字段之外的一个或多个其 他字段的内容。
1 1、 根据权利要求 9或 1 0所述的服务器， 其特征在于， 所述第一密钥为 第一私钥， 所述第二密钥为与所述第一私钥相同的第二私钥；
所述报文接收模块， 具体用于接收所述查询终端发送的或所述查询终端 经由递归服务器发送的所述 DNS报文， 所述 DNS报文包括的所述签名信息， 由所述查询终端釆用所述第一私钥对所述校险信息加密后得到；
所述密钥获取模块， 具体用于根据预先建立的终端与密钥信息之间的映 射关系， 获取与所述查询终端对应的所述第二私钥。
1 2、 根据权利要求 9或 1 0所述的服务器， 其特征在于， 所述第一密钥为 第一私钥， 所述第二密钥为与所述第一私钥相同的第二私钥；
所述报文接收模块， 具体用于接收递归服务器发送的所述 DNS报文， 所 述 DNS报文包括的所述签名信息， 由所述递归服务器在接收到所述查询终端 发送的包括查询终端的身份信息和校验信息的 DNS报文时， 釆用所述第一私 钥对所述校验信息加密后得到；
所述密钥获取模块， 具体用于根据预先建立的递归服务器与密钥信息之 间的映射关系， 获取与所述递归服务器对应的所述第二私钥。
1 3、 根据权利要求 9或 1 0所述的服务器， 其特征在于， 所述第一密钥为 私钥， 所述第二密钥为与所述私钥对应的公钥；
所述报文接收模块， 具体用于接收所述查询终端发送的或所述查询终端 经由递归服务器发送的所述 DNS报文， 所述 DNS报文包括的所述签名信息， 由所述查询终端釆用所述私钥对所述校验信息加密后得到； 所述 DNS报文还 包括所述公钥；
所述密钥获取模块， 具体用于解析所述 DNS报文， 得到所述公钥。
14、 根据权利要求 9或 10所述的服务器， 其特征在于， 所述第一密钥为 私钥， 所述第二密钥为与所述私钥对应的公钥；
所述报文接收模块， 具体用于接收所述查询终端发送的或所述查询终端 经由递归服务器发送的所述 DNS报文， 所述 DNS报文包括的所述签名信息， 由所述查询终端釆用所述私钥对所述校验信息加密后得到； 所述 DNS报文还 包括所述公钥的索引信息；
所述密钥获取模块， 具体用于解析所述 DNS报文， 得到所述索引信息， 并通过查询预先建立的公钥索引表， 获取与所述索引信息对应的所述公钥。
15、 一种对 DNS报文中的身份信息进行认证的***， 其特征在于， 包括： 如 权利要求 9-14任一所述的服务器。
PCT/CN2010/074492 2010-01-22 2010-06-25 对dns报文中的身份信息进行认证的方法、服务器和*** WO2011088658A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201010100355.X 2010-01-22
CN201010100355A CN101841521A (zh) 2010-01-22 2010-01-22 对dns报文中的身份信息进行认证的方法、服务器和***

Publications (1)

Publication Number Publication Date
WO2011088658A1 true WO2011088658A1 (zh) 2011-07-28

Family

ID=42744646

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2010/074492 WO2011088658A1 (zh) 2010-01-22 2010-06-25 对dns报文中的身份信息进行认证的方法、服务器和***

Country Status (2)

Country Link
CN (1) CN101841521A (zh)
WO (1) WO2011088658A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110324347A (zh) * 2019-07-08 2019-10-11 秒针信息技术有限公司 一种信息整合方法、装置及电子设备
CN112306753A (zh) * 2020-10-30 2021-02-02 联想(北京)有限公司 一种数据修复方法、装置及***

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101997878A (zh) * 2010-11-23 2011-03-30 蓝汛网络科技（北京）有限公司 一种验证域名链接的方法、装置及***
CN102546632B (zh) * 2012-01-09 2015-05-06 北京佳讯飞鸿电气股份有限公司 Ip多媒体子***的网元设备域名自动配置方法
CN103916359A (zh) * 2012-12-30 2014-07-09 航天信息股份有限公司 防止网络中arp中间人攻击的方法和装置
CN104243413A (zh) * 2013-06-14 2014-12-24 航天信息股份有限公司 对局域网中的arp中间人攻击进行防范的方法和***
CN104348924A (zh) * 2013-07-30 2015-02-11 深圳市腾讯计算机***有限公司 一种域名解析方法、***及装置
CN103634314B (zh) * 2013-11-28 2017-06-16 新华三技术有限公司 一种基于虚拟路由器vsr的服务访问控制方法及设备
CN104735065B (zh) * 2015-03-16 2019-02-05 联想(北京)有限公司 一种数据处理方法、电子设备及服务器
CN105141612A (zh) * 2015-09-01 2015-12-09 中国互联网络信息中心 一种dns数据包隐私保护方法
CN108650244A (zh) * 2018-04-24 2018-10-12 网宿科技股份有限公司 一种域名解析方法、终端及递归dns服务器
CN111182497A (zh) * 2019-12-27 2020-05-19 国家计算机网络与信息安全管理中心 V2x匿名认证方法、设备及存储介质
CN111935123B (zh) * 2020-08-04 2023-04-28 广东科徕尼智能科技有限公司 一种检测dns欺骗攻击的方法、设备、存储介质
CN112671779B (zh) * 2020-12-25 2022-10-18 赛尔网络有限公司 基于DoH服务器的域名查询方法、装置、设备及介质
CN113556413B (zh) * 2021-08-13 2023-07-25 中国互联网络信息中心 一种报文处理方法及装置
CN114826654B (zh) * 2022-03-11 2023-09-12 中国互联网络信息中心 一种基于域名***命名的客户端认证方法及***
CN116032591A (zh) * 2022-12-23 2023-04-28 迈普通信技术股份有限公司 一种哑终端仿冒识别方法及***

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101141396A (zh) * 2007-09-18 2008-03-12 华为技术有限公司 报文处理方法和网络设备
WO2008147302A1 (en) * 2007-05-09 2008-12-04 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for protecting the routing of data packets
CN101336535A (zh) * 2005-12-27 2008-12-31 法国电信公司 管理dnssec请求的服务器和方法
CN101594230A (zh) * 2008-05-30 2009-12-02 华为技术有限公司 处理动态主机配置消息的方法、装置及***

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101330438B (zh) * 2007-06-21 2011-06-08 华为技术有限公司 一种节点间安全通信的方法及***

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101336535A (zh) * 2005-12-27 2008-12-31 法国电信公司 管理dnssec请求的服务器和方法
WO2008147302A1 (en) * 2007-05-09 2008-12-04 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for protecting the routing of data packets
CN101141396A (zh) * 2007-09-18 2008-03-12 华为技术有限公司 报文处理方法和网络设备
CN101594230A (zh) * 2008-05-30 2009-12-02 华为技术有限公司 处理动态主机配置消息的方法、装置及***

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110324347A (zh) * 2019-07-08 2019-10-11 秒针信息技术有限公司 一种信息整合方法、装置及电子设备
CN112306753A (zh) * 2020-10-30 2021-02-02 联想(北京)有限公司 一种数据修复方法、装置及***

Also Published As

Publication number Publication date
CN101841521A (zh) 2010-09-22

Similar Documents

Publication Publication Date Title
WO2011088658A1 (zh) 对dns报文中的身份信息进行认证的方法、服务器和***
US6993652B2 (en) Method and system for providing client privacy when requesting content from a public server
US10638321B2 (en) Wireless network connection method and apparatus, and storage medium
US10530582B2 (en) Method and device for information system access authentication
Li et al. A secure chaotic maps and smart cards based password authentication and key agreement scheme with user anonymity for telecare medicine information systems
WO2017028593A1 (zh) 网络接入设备接入无线网络接入点的方法、网络接入设备、应用程序服务器和非易失性计算机可读存储介质
KR101405509B1 (ko) 온라인 제 3 신뢰 기관을 도입함으로써 엔티티 공개키 획득, 인증서 검증 및 인증을 수행하는 방법 및 시스템
US20110040974A1 (en) Authentication of email servers and personal computers
CN111050322A (zh) 基于gba的客户端注册和密钥共享方法、装置及***
CN103023911A (zh) 可信网络设备接入可信网络认证方法
CN107517194B (zh) 一种内容分发网络的回源认证方法和装置
WO2005088892A1 (en) A method of virtual challenge response authentication
JP2001186122A (ja) 認証システム及び認証方法
CN114513339A (zh) 一种安全认证方法、***及装置
CN110138558B (zh) 会话密钥的传输方法、设备及计算机可读存储介质
CN111314269B (zh) 一种地址自动分配协议安全认证方法及设备
WO2022033350A1 (zh) 注册服务的方法及设备
CN103368918A (zh) 一种动态口令认证方法、装置及***
CN110048842B (zh) 会话密钥处理方法、设备及计算机可读存储介质
RU2698424C1 (ru) Способ управления авторизацией
Limbasiya et al. Cryptanalysis and improvement of a mutual user authentication scheme for the Internet of Things
US9882891B2 (en) Identity verification
EP3125595A1 (en) Method to provide identification in privacy mode
He et al. An asymmetric authentication protocol for M-Commerce applications
Zhu et al. A web database Security model using the Host identity protocol

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: 10843698

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: 10843698

Country of ref document: EP

Kind code of ref document: A1