Domain name control right verification method, device and system

Abstract

The invention discloses a domain name control right verification method, device and system, and belongs to the technical field of communication. The method is applied to a first device in a communication network. The method comprises the following steps: acquiring a first task issued by a certificate management server when the first device applies for a digital certificate; in response to the first task, sending a DNS update request including update operation information and first verification information to the domain name server, the update operation indicated by the update operation information being an operation of adding a target DNS record determined based on parameters of the first task in the domain name server; and sending a task response used for indicating to query the target DNS record in the domain name server to a certificate management server, wherein a result of the query operation is used for indicating whether the first equipment has the control right for the domain name of the first equipment or not. According to the method, the blank that the requester configures the DNS record in the domain name server in the process of applying for the domain name control right of the digital certificate requester in the verification communication network is filled.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a method, apparatus and system for verifying domain name control rights. Background Technology

[0002] To enhance the flexibility and agility of network deployment, network functions virtualization (NFV) technology is widely used. NFV technology can subdivide the functions of network elements into different network functions (NFs) and deploy NFs on network platforms / devices in a virtualized form, thereby enabling rapid deployment of network functions.

[0003] When one NF needs to obtain services from another NF, a transport layer security (TLS) link must first be established between the two NFs. According to the relevant agreements of the 3GPP Service and System Aspects Working Group 3 (SA3), the two NFs need to perform mutual authentication when establishing a secure link. This mutual authentication is based on public key certificates using Public Key Infrastructure (PKI). Since different NFs may reside in different network domains, mutual authentication between NFs involves cross-domain authentication. Therefore, 3GPP SA3 introduces a cross-domain certificate issuance architecture. In this architecture, different network domains need to deploy subordinate certificate authority (CA) servers within each other's domains to issue public key certificates for each other's NFs.

[0004] Currently, in public key certificates issued for NFs, the fully qualified domain name (FQDN) of the NF can be used as the identifier of the NF. In this case, the CA server needs to verify the NF's control over the domain name during the process of issuing a public key certificate for the NF. Summary of the Invention

[0005] This application provides a method, apparatus, and system for verifying domain name control rights. This method fills the gap in the process of verifying domain name control rights of a party applying for a digital certificate in a communication network, where the requester configures DNS records in the domain name server. The technical solution provided by this application is as follows.

[0006] In a first aspect, this application provides a method for verifying domain name control rights. This method is applied to a first device, which is a network element in a communication network. The method includes: obtaining a first task issued by a certificate management server when the first device applies for a digital certificate; the first task instructs verification of whether the first device has control rights over a first domain name, where the first domain name is the domain name of the first device; responding to the first task, sending a domain name service (DNS) update request to a domain name server; the DNS update request includes update operation information and first verification information; the first verification information is used to verify whether the update operation indicated by the update operation information is allowed to be executed; the update operation is an operation of adding a target DNS record to the domain name server, where the target DNS record is determined based on the parameters of the first task; and sending a task response to the certificate management server; the task response instructs querying the target DNS record in the domain name server, and the result of the query operation is used to indicate whether the first device has control rights over the first domain name.

[0007] For any network element in a communication network, such as the first device, the method provided in this application enables the verification of the first device's domain name control rights through a DNS challenge (i.e., the first task) against the domain name. Compared to related technologies where devices in a communication network cannot modify the domain name server due to a lack of demand, this application allows devices in a communication network to add DNS records to the DNS system of the domain name server via a DNS update request to prove their control over the domain name to the certificate management server, thereby completing the application for a digital certificate. That is, this application allows the first device in a communication network to update the DNS records used for domain control validation (DCV) via an authenticated DNS update request (implemented by carrying first verification information). This enables the first device applying for a digital certificate to securely update the DNS records required for DCV, thereby further enabling the issuance of a digital certificate to the first device after its domain name control verification is successful. In other words, the method of this application fills the gap in the process of verifying the domain name control rights of a digital certificate applicant in a communication network, where the requester configures specific DNS records (i.e., the DNS records used by DCV) in the domain name server.

[0008] In another possible design, before sending the DNS update request to the domain name server, the method further includes: obtaining a first key, which is used to generate first verification information. Wherein, the first key is a first private key in an asymmetric key set, and the first verification information includes a signature of the DNS update request generated based on the first private key; or, the first key is a first symmetric key, and the first verification information includes a message authentication code (MAC) of the DNS update request generated based on the first symmetric key.

[0009] With this possible design, the first device can authenticate the sender of the DNS update request using a signature generated by an asymmetric key or a MAC generated by a symmetric key, demonstrating the flexibility of the implementation method.

[0010] In another possible design, the first key is a first private key, and obtaining the first key includes: generating a key pair, the key pair including a first private key and a first public key, the first public key being used to verify the signature generated based on the first private key; or, receiving the first private key.

[0011] This possible design allows for the configuration of a first private key for the first device, and the implementation method is flexible.

[0012] In another possible design, the first private key is generated by the first device, and the method further includes: sending a configuration message containing the first public key to a domain name server, the configuration message further including second verification information, the second verification information being used to verify whether the first public key is configured, the second verification information including a signature of the configuration message generated based on the second private key, or the second verification information including a MAC of the configuration message generated based on the second symmetric key.

[0013] With this possible design, the first device can configure the first public key for the domain name server via an authentication configuration message (implemented by carrying second authentication information), thereby establishing a trust relationship between the first device holding the first private key and the domain name server holding the corresponding public key (i.e., the first public key belonging to the same key pair as the first private key).

[0014] In another possible design, the first key is a first symmetric key, and obtaining the first key includes:

[0015] Generate the first symmetric key; or,

[0016] Receive the first symmetric key; or,

[0017] A negotiation message for negotiating a first symmetric key is sent to a domain name server. This negotiation message also includes third verification information, which verifies whether the operation of determining the first symmetric key based on the negotiation message has been performed. The third verification information includes a signature of the negotiation message generated based on a second private key, or the third verification information includes the MAC address of the negotiation message generated based on the second symmetric key. A response message for the negotiation message returned by the domain name server is received. This response message includes fourth verification information, which verifies whether the operation of determining the first symmetric key based on the response message has been performed. The fourth verification information includes a signature of the response message generated based on the third private key, or the fourth verification information includes the MAC address of the response message generated based on the second symmetric key. If the fourth verification information passes verification, the first symmetric key is determined based on the response message.

[0018] This possible design enables the configuration of a first symmetric key for a first device, and the implementation is flexible. Furthermore, when the first device determines the first symmetric key through the response message used to negotiate the first symmetric key, the first device transmits the negotiation message (implemented by carrying third authentication information) and its response message (implemented by carrying a fourth authentication message) in an authenticated manner, thus ensuring high security of the configured first symmetric key.

[0019] In another possible design, the target DNS record includes a record type, a target subdomain, and a value. Before sending a DNS update request to the domain name server, the method further includes: determining the record type and the target subdomain based on the task type of the first task and the first domain name, wherein the target subdomain is the subdomain among the subdomains included in the first domain name that corresponds to the task type of the first task; and calculating the value of the target DNS record according to the parameters of the first task.

[0020] This possible design allows for the generation of the target DNS record corresponding to the first task.

[0021] In another possible design approach, the above method also includes obtaining a digital certificate from a certificate management server when the first device has control over the first domain name.

[0022] This possible design enables the certificate management server to issue a digital certificate to the first device when the first device has control over the first domain name.

[0023] Secondly, this application provides a method for verifying control over a domain name. This method is applied to a domain name server and includes: receiving a DNS update request sent by a first device. The DNS update request includes update operation information and first verification information. The update operation information indicates that the update operation is an operation to add a target DNS record to the domain name server. The target DNS record is determined based on parameters of a first task, which is a task issued by a certificate management server when the first device applies for a digital certificate. The first task indicates whether the first device has control over a first domain name. The first device is a network element in a communication network. The first verification information is then verified to determine whether the update operation is allowed. If the update operation is allowed, a target DNS record is added. The target DNS record is used to verify whether the first device has control over the first domain name.

[0024] In one possible design, before verifying the first verification information, the method further includes: obtaining a second key; the second key is used to verify the first verification information; wherein, if the second key is a first public key, the first verification information includes a signature of a DNS update request generated based on the first private key, and the first private key and the first public key belong to the same key pair; or, if the second key is a first symmetric key, the first verification information includes a MAC of a DNS update request generated based on the first symmetric key.

[0025] In another possible design approach, the above method further includes: configuring the operation permissions corresponding to the second key, wherein the operation permissions corresponding to the second key include the operations that are allowed to be performed after the information is verified by the second key and the verification is successful.

[0026] By configuring operation permissions for the public key corresponding to the private key of the first device in the domain name server through this possible design, it is possible to control the scope of influence of the public key in the domain name server, thereby enabling the provision of the minimum permissions required for DCV to the first device.

[0027] In another possible design, the second key is the first public key, and obtaining the second key includes:

[0028] Receive the first public key sent by the network management system, which is used to manage and / or maintain the network where the first device is located; or...

[0029] The system receives a configuration message containing a first public key sent by a first device. The configuration message also includes second verification information, which includes a signature of the configuration message generated based on a second private key, or the second verification information includes a MAC of the configuration message generated based on a second symmetric key. The system verifies the second verification information using a verification key to determine whether to configure the first public key. If it is determined that the first public key is to be configured, the system stores the first public key.

[0030] In another possible design, the second key is the first symmetric key, and obtaining the second key includes:

[0031] Receives a first symmetric key sent by a network management system, which is used to manage and / or maintain the network where the first device resides; or...

[0032] The system receives a negotiation message sent by a first device for negotiating a first symmetric key. The negotiation message further includes third verification information, which includes a signature of the negotiation message generated based on a second private key, or the third verification information includes a MAC of the negotiation message generated based on the second symmetric key. The system verifies the third verification message using a verification key to determine whether to perform the operation of determining the first symmetric key based on the negotiation message. If the third verification information is verified successfully, the system determines the first symmetric key based on the negotiation message.

[0033] In another possible design, the above method further includes: returning a response message of the negotiation message to the first device, the response message including fourth verification information, the fourth verification information being used to verify whether the operation of determining the first symmetric key based on the response message has been performed, the fourth verification information including a signature of the response message generated based on the third private key, or the fourth verification information including the MAC of the response message generated based on the second symmetric key.

[0034] In another possible design, before verifying the verification information using the verification key, the above method further includes: obtaining the verification key; configuring the operation permissions corresponding to the verification key, the operation permissions corresponding to the verification key including the operations allowed to be performed after the information is verified using the verification key and the verification is successful.

[0035] By configuring operation permissions for the verification key in the domain name server through this possible design, it is possible to control the scope of influence (or usage) of the verification key in the domain name server. For example, the verification key may only be used for: the signature or MAC key required by the device that generates the digital certificate application to send the DNS update request to the domain name server during the DCV negotiation process.

[0036] It is understood that the beneficial effects of the solutions provided by the second aspect and any of its possible design methods can be referred to the description of the beneficial effects of the corresponding solutions in the first aspect, and will not be repeated here.

[0037] Thirdly, this application provides a domain name control verification device, which is used to execute any of the methods provided in the first aspect. This application can divide the domain name control verification device into functional modules according to any of the methods provided in the first aspect. For example, each function can be divided into its own functional modules, or two or more functions can be integrated into one processing module. For example, this application can divide the domain name control verification device into an acquisition unit and a sending unit, etc., according to function. The descriptions of possible technical solutions and beneficial effects of the above-described functional modules can refer to the solutions provided in the first aspect and any possible design method within the first aspect, and will not be repeated here.

[0038] Fourthly, this application provides a domain name control verification device for executing any of the methods provided in the second aspect above. This application can divide the domain name control verification device into functional modules according to any of the methods provided in the second aspect above. For example, each function can be divided into its own functional modules, or two or more functions can be integrated into one processing module. For example, this application can divide the domain name control verification device into a receiving unit, a verification unit, and an adding unit, etc., according to function. The descriptions of possible technical solutions and beneficial effects of the above-described functional modules can refer to the solutions provided in the second aspect above and any possible design method within the second aspect, and will not be repeated here.

[0039] Fifthly, this application provides a domain name control verification device, the device comprising: a memory, a communication interface, and one or more processors, the one or more processors receiving or sending data through the communication interface, the one or more processors being configured to read program instructions stored in the memory to execute the method provided by the first aspect and any possible design of the first aspect, or to execute the method provided by the second aspect and any possible design of the second aspect.

[0040] The domain name control verification device described in the third or fifth aspect can be, for example, a network element in a communication network, including but not limited to physical network elements or virtual network elements, where virtual network elements are also called NFs. The domain name control verification device described in the fourth or fifth aspect can be implemented as a domain name server, such as an authoritative domain name server.

[0041] Sixthly, this application provides a domain name control verification system, comprising: a first device, a domain name server, and a certificate management server. The first device executes the method provided by the first aspect and any possible design scheme thereof, and the domain name server executes the method provided by the second aspect and any possible design scheme thereof, thereby adding a target domain name service DNS record in the domain name server based on parameters determined by a first task. The first task is a task issued by the certificate management server when the first device applies for a digital certificate. The first task instructs verification of whether the first device has control over a first domain name, where the first domain name is the domain name of the first device. The certificate management server queries the target DNS record in the domain name server and determines whether the first device has control over the first domain name based on the result of the query operation.

[0042] In a seventh aspect, this application provides a computer-readable storage medium that is a non-volatile computer-readable storage medium, the computer-readable storage medium including computer program instructions, which, when executed by a processor, a computing device including a processor, or a computer system, perform the method provided by the first aspect and any possible design of the first aspect, or perform the method provided by the second aspect and any possible design of the second aspect.

[0043] Eighthly, this application provides a computer program product containing instructions that, when executed by a processor, a computing device including a processor, or a computer system, cause the processor, the computing device including a processor, or the computer system to perform the method provided by the first aspect and any possible design of the first aspect, or to perform the method provided by the second aspect and any possible design of the second aspect.

[0044] Ninthly, this application provides a chip including a processor for running program instructions or code. The chip or a device including the chip can be used to perform the methods provided by the first aspect and any possible design scheme of the first aspect, or to perform the methods provided by the second aspect and any possible design scheme of the second aspect. Exemplarily, the chip further includes an input interface, an output interface, and a memory. The chip's input interface, output interface, processor, and memory are connected via internal interconnection paths. The memory in the chip is used to store program instructions or code executed by the processor, and the chip's input interface and output interface are used for communication and connection between the chip and other chips or devices.

[0045] It is understood that any of the message ordering devices, network devices, computer-readable storage media, computer program products or chips provided above can be applied to the corresponding methods provided above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods, and will not be repeated here.

[0046] In this application, the names of the aforementioned domain name control verification device, domain name control verification system, etc., do not limit the devices or functional modules themselves. In actual implementation, these devices or functional modules may appear under other names. As long as the functions of each device or functional module are similar to those in this application, they all fall within the protection scope of this application. Attached Figure Description

[0047] Figure 1 This is a schematic diagram of a 5G network based on a service-oriented architecture.

[0048] Figure 2 This is a schematic diagram of the domain name space structure of a DNS system;

[0049] Figure 3 This is a schematic diagram of a process for obtaining a digital certificate based on the DNS-01 challenge supported by the ACME protocol;

[0050] Figure 4 This is a schematic diagram of an implementation environment for the method provided in the embodiments of this application;

[0051] Figure 5 This is a schematic diagram of another implementation environment of the method provided in the embodiments of this application;

[0052] Figure 6 This is a flowchart illustrating a domain name control verification method provided in an embodiment of this application;

[0053] Figure 7 This is another flowchart illustrating the domain name control verification method provided in this application embodiment;

[0054] Figure 8 This is a flowchart illustrating another method for verifying domain name control provided in an embodiment of this application;

[0055] Figure 9 This is another flowchart illustrating the domain name control verification method provided in this application embodiment;

[0056] Figure 10 This is another flowchart illustrating the domain name control verification method provided in this application embodiment;

[0057] Figure 11 This is a schematic diagram of the structure of a domain name control verification device provided in an embodiment of this application;

[0058] Figure 12 This is a schematic diagram of another domain name control verification device provided in an embodiment of this application;

[0059] Figure 13 This is a schematic diagram of the structure of another domain name control verification device provided in the embodiments of this application;

[0060] Figure 14 This is a schematic diagram of the hardware structure of a computing device provided in an embodiment of this application. Detailed Implementation

[0061] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0062] To facilitate understanding, the technologies and background involved in the embodiments of this application will be explained below.

[0063] 1) NFV

[0064] To enhance the flexibility and agility of network deployment, NFV technology is widely used. NFV technology can subdivide the functions of network elements into different NFs and deploy NFs on network platforms / devices in a virtualized form, thereby enabling rapid deployment of network functions. The virtualized network elements are also called NFs.

[0065] Virtualized network elements can interact through a service-based architecture (SBA). Taking a network using 5G technology as an example, refer to... Figure 1 , Figure 1 This diagram illustrates a 5G network architecture based on a service-oriented architecture. Figure 1 As shown, Figure 1 The network elements within the dashed box shown are virtualized network elements in the 5G network (denoted as virtualized network elements). Different virtualized network elements typically exchange services by sending service requests through service interfaces using the Hypertext Transfer Protocol (HTTP). Figure 1Detailed explanations of the network slice selection function (NSSF), authentication server function (AUSF), unified data management (UDM), network exposure function (NEF), network repository function (NRF), access and mobility management function (AMF), session management function (SMF), policy control function (PCF), application function (AF), service communication proxy (SCP), data network (DN), user plane function (UPF), radio access network (RAN), and user equipment (UE) can be found in the descriptions of the relevant technologies. Figure 1 Detailed explanations of the service interfaces between the various network elements shown, such as the NSSF service interface Nnssf, AUSF service interface Nausf, UDM service interface Nudm, NEF service interface Nnef, NRF service interface Nnrf, AMF service interface Namf, SMF service interface Nsmf, PCF service interface Npcf, AF service interface Naf, and SCP service interface Nscp, can be found in the descriptions in relevant technical documents. In these abbreviations, the "N" stands for Network Function Virtualization. Additionally, Figure 1 For detailed explanations of the N1 interface between the UE and AMF, the N2 interface between the RAN and AMF, the N3 interface between the RAN and UPF, the N4 interface between the UPF and SMF, and the N6 interface between the UPF and DN, please refer to the description of related technologies. In the N1 to N6 interfaces, N represents the non-access stratum, which will not be elaborated in the embodiments of this application.

[0066] 2) Symmetric key, MAC

[0067] Symmetric keys and MACs are both important concepts in cryptography, and they play different roles in data security and integrity protection.

[0068] Symmetric keys, also known as shared keys or private keys, refer to keys used by both the sender and receiver for cryptographic computations. Algorithms using symmetric keys require that both the sender and receiver use the same key for computation.

[0069] A MAC (Authentication Code) is a technique that uses a symmetric key and the message content to generate a short authentication code. Specifically, the sender uses a symmetric key and algorithm to generate a MAC for the message to be sent and sends this MAC along with the message to the receiver. The receiver regenerates a MAC using the same symmetric key and algorithm and compares it with the received MAC. If the two MACs are identical, it means the message has not been tampered with during transmission, thus ensuring data integrity and authenticity, and confirming that the message came from the intended sender.

[0070] In other words, by generating a MAC based on a symmetric key at the sender's end, it can be ensured that only the receiver holding the same key can successfully verify the MAC, thus enabling the receiver to verify the sender's identity.

[0071] 3) Asymmetric keys and digital signatures

[0072] An asymmetric key consists of a key pair: a public key and a private key. In practical applications of asymmetric keys, data encrypted by either key in the asymmetric key pair can only be decrypted by the other key in the same pair.

[0073] A digital signature (also known as a signature) involves the sender using the private key from an asymmetric key pair to compute (also known as a signing operation) a digital signature on the information. The receiver then uses the public key from the key pair to verify the signature, confirming the integrity and origin of the information. In other words, similar to a MAC, a digital signature ensures that information has not been tampered with during transmission and can verify the identity of the sender.

[0074] 4) Digital certificates and certificate authorities (CAs)

[0075] A digital certificate (also known as a certificate) is an electronic document that binds a public key to an entity, used to prove the identity of the public key owner. This document contains public key information, the owner's identity information (subject), and the certificate authority's signature on the document.

[0076] A Certificate Authority (CA), also known as a Certificate Authority or Certificate Certification Authority, is an authoritative body responsible for issuing and managing certificates. A CA receives certificate requests from users and, after verifying the applicant's identity, issues a certificate that binds to their identity information. As a trusted third party jointly trusted by the certificate holder and the relying party, the CA is responsible for proving the certificate holder's ownership of the public key.

[0077] 5) DNS system

[0078] The DNS system is a distributed database that provides a service mapping domain names to Internet Protocol (IP) addresses.

[0079] refer to Figure 2 , Figure 2 A schematic diagram of the domain name space structure of the DNS system is shown. For example... Figure 2 As shown, the DNS system's domain name space structure is a tree-like structure radiating downwards from the root domain (represented by a dot). The root domain is managed by DNS root servers. Under the root domain are multiple top-level domains (TLDs), such as .com, .net, and .org. Each TLD can be further subdivided into subdomains, such as example.com, where example.com can be any domain with the .com suffix. After each domain name is registered, its resolution records are stored by one or more authoritative name servers. In other words, authoritative name servers provide authoritative answers to the DNS resource records (RRs) (or simply DNS records) for the domain name space (zone) they are responsible for. DNS root servers can be understood as the authoritative servers that manage the root domain name space. Authoritative name servers are sometimes simply referred to as domain name servers or DNS servers.

[0080] In addition to authoritative name servers, the DNS system also includes DNS resolvers. Typically, a DNS resolver works by sending DNS query requests to a DNS server and reading the returned results. It's important to note that the meaning of "DNS resolver" varies depending on the context; here, it refers to the client that sends the DNS query request.

[0081] Data stored in the DNS system exists in the form of DNS records. A DNS record includes a record type, a domain name, and the data corresponding to that domain name. There are various record types for DNS, each with different meanings. For example, an A record (address record) maps a domain name to an IPv4 address. Another example is an AAAA record (Internet Protocol Version 6 address record, IPv6 address record), which maps a domain name to an IPv6 address. Yet another example is a name server (NS) record, which entrusts the management of a domain's zone to an authoritative name server. A text (TXT) record indicates that arbitrary text information can be stored under a domain name, and so on.

[0082] Because the tree-like DNS domain name space emanating from the root domain is divided into multiple subtrees, each subtree's corresponding zone is managed by an authoritative name server. For a zone, the authoritative name server managing that zone is responsible for maintaining a zone file, which contains the authoritative DNS records under that zone. When it's necessary to change DNS records, such as adding a new TXT record to the a.example.com domain, the zone file of the zone containing that domain needs to be modified. It should be noted that in specific implementations, the zone file can be a text or binary file stored on a hard drive, in memory, or as a record in a database. The Internet Engineering Task Force (IETF) request for comments (RFC) 2136 defines the DNS update message, which is used to request updates (including creation or deletion) of DNS records from authoritative name servers. When updating DNS records, authoritative name servers need to verify the identity of the requester and authorize it according to their own configuration policies, allowing the authorized requester to update the DNS records.

[0083] The main schemes for authoritative domain name servers to authenticate the requester of DNS record updates include: Scheme a1, based on the transaction signature (TSIG) record defined in RFC8945, which adds a MAC calculated based on a shared key between the sender and the receiver to the DNS update message. The receiver then uses the shared key to verify the MAC in the DNS update message to verify the sender's identity; Scheme a2, based on the SIG(0) record defined in RFC2931, which adds a signature calculated by the sender's private key to the DNS update message. The receiver then uses the sender's public key to verify the signature to verify the sender's identity.

[0084] For scheme a1, the sender and receiver can establish a shared key for the TSIG record by exchanging messages containing the transfer key (TKEY) record defined in RFC2930.

[0085] For scheme a2, a SIG(0) record is a resource record used to provide signing and verification functions in DNS. SIG(0) records are primarily used to ensure the integrity and authenticity of DNS data, preventing data tampering. Here, SIG in SIG(0) record stands for signature, and the public key used to decrypt the signature in the SIG(0) record can be pre-recorded in a key record (i.e., a KEY record) stored on the authoritative server. RFC 2535 defines KEY records, which can be used to store the public key used to verify the signature of DNSSEC.

[0086] It should be noted that the "sender" mentioned above can be the sender of the DNS update request message (i.e., the client) or the sender of the DNS update response message (i.e., the DNS server).

[0087] Furthermore, the symmetric key used by TSIG is typically assigned a domain name, which can also be considered an identifier (ID) for that symmetric key. The public key used by SIG(0) is usually stored in the DNS KEY record, which, like other DNS records, belongs to a specific domain name. Therefore, both the TSIG and SIG(0) keys used by the domain name server to verify DNS messages (such as DNS update messages) sent by the client can be identified by a domain name.

[0088] In some examples, the domain name of the symmetric key negotiated via the TKEY record can be... <client-specified-domain> . <server-tkey-domain>In the form of, <client-specified-domain>It is the domain name specified by the client in the TKEY query request. <server-tkey-domain>It is the suffix specified by the DNS server.

[0089] Of course, the ID of the key (including symmetric and asymmetric keys) can also be an identifier of other types besides the domain name, and there are no restrictions on this.

[0090] 6) Automated Certificate Management Environment (ACME) Protocol

[0091] The ACME protocol is defined in IETF RFC 8555. It provides a scalable certificate management framework for automating domain name verification and certificate application, revocation, and other management processes covering the entire certificate lifecycle. By automating certificate application, verification, issuance, and renewal, the ACME protocol reduces human error and maintenance costs, making it particularly suitable for large-scale certificate management.

[0092] 3GPP Research Report 33.776 lists solutions for certificate management using ACME under the SBA architecture. When the ACME client is deployed in NF, the solutions for NF to obtain digital certificates from the ACME server mainly include the following three types.

[0093] Option b1 uses the NF's domain name as its identifier. The ACME client reuses challenges for domain name certificates (such as HTTP-01 challenges, DNS-01 challenges, etc.) to allow the ACME server to verify the NF's control over the domain name and issue a domain-based digital certificate to the NF upon successful verification. Here, the challenge refers to the specific verification process required when applying for a digital certificate using the ACME protocol to prove the applicant's control over the domain name.

[0094] Scheme b2 uses the NF instance ID as the identifier of the NF. The ACME client uses ACME's tkauth-01 challenge (a mechanism for verifying domain control) to prove to the ACME server that the NF has control over the NF instance ID by verifying the authority token generated by the operation and management (OAM) device. When the verification is successful, the ACME server issues a digital certificate for the NF based on the NF instance ID.

[0095] Scheme b3 uses the NF instance ID as the identifier for the NF. The ACME client uses the NF instance ID to perform a challenge and completes the challenge using the initial trust information defined in TS 33.310. This proves to the ACME server that the NF has control over the NF instance ID. Upon successful verification, the ACME server issues a digital certificate based on the instance ID to the NF. The initial trust can be achieved through a certificate issued by the OAM, an initial attestation key (IAK), or a signature set by the OAM for the NF profile. The NF profile is the registration information of network functions in the 5G core network, including addressing information and capability information of network elements.

[0096] It should be noted that the embodiments of this application involve the specific implementation of scheme b1. In the process of an NF with an ACME client obtaining a domain-based digital certificate through scheme b1, the domain control validation (DCV) process described in scheme b1 mainly includes: the ACME server provides a random token; after receiving the random token, the ACME client calculates a key authorization value by combining it with its own ACME account public key, and configures the hash value of this key authorization value into the DNS record of the domain name server (e.g., through DNS-01 challenge) or the website (web) server (e.g., through HTTP-01 challenge) for the ACME server to verify, so that the verification result proves whether the device where the ACME client is located has control over the domain name.

[0097] The ACME protocol primarily supports network request-based challenges and DNS-based challenges. This application's embodiments involve DNS-based challenges, including but not limited to: the DNS-01 challenge defined in RFC8555 and the DNS-02 and DNS-ACCOUNT-01 challenges defined in ID.ietf-acme-scoped-dns-challenges.

[0098] refer to Figure 3 , Figure 3 This diagram illustrates the process of obtaining a digital certificate based on the DNS-01 challenge supported by the ACME protocol. Figure 3 As shown, the process includes the following steps S1 to S8.

[0099] S1. The ACME client sends an order request to the ACME server to create a digital certificate.

[0100] The order request includes one or more identifiers for user devices that need to apply for digital certificates. This ID can be a DNS identifier (i.e., a domain name) defined in RFC8555, or other extended identifiers (such as IP addresses, NFinstance IDs, etc.). The user device can be a physical device (such as a physical network element) or a virtual device (such as a virtual network element). In this embodiment, the identifier for the user device is the domain name of the user device.

[0101] It should be noted that before step S1, the ACME client has already completed account registration on the ACME server. Therefore, each message / request sent by the ACME client to the ACME server (such as the order request described in step S1) contains a signature generated by the ACME client's private key. Correspondingly, after receiving each message / request from the ACME client, the ACME server needs to use the corresponding public key to verify the signature, in order to verify the identity of the ACME client (that is, to determine that the received message / request is sent by an ACME client with a registered account that holds the private key corresponding to its configured public key). The following will not elaborate further on the signature generated by the ACME client's private key in the messages / requests sent by the ACME client, nor will it elaborate further on the ACME server's use of public key verification to determine the identity of the ACME client.

[0102] For example, before the ACME client executes step S1, the ACME client can first generate an ACME account key pair and send a registration account request to the ACME server. This request includes the public key from the aforementioned key pair. In response, the ACME server performs the registration account operation based on the information carried in the received registration account request and returns response information to the ACME client. This response information contains the account address configured for the ACME client. In this way, the ACME client's account registration on the ACME server is completed.

[0103] S2. The ACME server receives the order request and sends a response message to the ACME client.

[0104] The response message may include an order object created by the ACME server based on the received order request. The order object contains one or more authorizations that the ACME server requires the ACME client to complete. Each authorization object includes one or more challenges (such as DNS-01 challenge, DNS-02 challenge, etc.) that the ACME client needs to perform to complete the authorization. It should be noted that for a digital certificate order, the ACME client needs to complete all authorizations within the order object. For an authorization, the ACME client only needs to complete any one challenge within that authorization. The specific data structures and interrelationships of the order object, authorization object, and challenge object can be found in sections 7.1.3-7.1.5 of RFC 8555 and will not be repeated here.

[0105] It should be noted that when the identifier of the user device in the order request is the domain name of the user device, common challenge types include the HTTP-01 challenge and DNS-01 challenge defined in RFC8555, the TLS-ALPN-01 challenge defined in RFC8737, and the DNS-02 challenge and DNS-ACCOUNT-01 challenge defined in ID.ietf-acme-scoped-dns-challenges.

[0106] S3. The ACME client receives the response message, determines the authorization to be completed based on the response message, selects a challenge based on the authorization to be completed, and obtains the challenge parameters from the ACME server.

[0107] It should be understood that after receiving the response message of the order request, the ACME client needs to send another request to obtain the parameter content of the specific authorized object and challenge. Figure 3 The process of making multiple requests has been omitted and will not be described in detail.

[0108] For challenges selected by the ACME client, such as the DNS-01 challenge, the ACME client obtains the token assigned by the ACME server for that challenge from the content of the challenge sent by the ACME server, calculates the key authorization value based on this token, and sets it in the DNS record specified by the DNS-01 challenge. Here, the calculation process of the key authorization value (see section 8.1 of RFC 8555 for details) includes: key authorization = token || '.' || base64url (thumbprint(accountkey)). Here, '||' represents string concatenation, thumbprint represents calculating the SHA-256 digest, SHA stands for secure hash algorithm, and base64url is an encoding method for representing data as a string. Furthermore, according to the DNS-01 challenge, the ACME client needs to configure the SHA-256 digest of the key authorization into the TXT record of the domain name "_acme-challenge.<domain name to be verified>" in the DNS system. Here, the domain name to be verified is the domain name for which control is to be verified, which is also the domain name of the user device mentioned in step S1. In one example, if the domain to be verified is example.com, then the domain of the TXT record that needs to be configured is: _acme-challenge.example.com.

[0109] It should be noted that, apart from the DNS-01 challenge, other challenge types can have different definitions for key authorization, or can omit key authorization, or can omit the token; there are no restrictions on this.

[0110] S4. The ACME client sends a challenge response to the ACME server. The challenge response is used to instruct the ACME server to verify the challenge executed by the ACME client.

[0111] The challenge response includes the address of the challenge executed by the ACME client. For DNS-based challenges, the response includes the address of the domain name server. This allows the ACME server to verify the challenge executed by the ACME client at the domain name server.

[0112] S5, the ACME server responds to the received challenge response and verifies the challenge executed by the ACME client.

[0113] For DNS-based challenges, the ACME server needs to initiate a DNS query request for the domain specified in the DNS challenge (such as "_acme-challenge.example.com" above) to retrieve the TXT records under that domain. After obtaining the TXT records, the ACME server compares its calculated SHA-256 digest of the key authorization with the value of the TXT record. If the comparison result indicates that the calculated SHA-256 digest of the key authorization and the value of the TXT record are the same, it means that the verification result of the challenge executed by the ACME client is successful. It should be understood that a domain name can correspond to multiple TXT records in the DNS system. In this case, the ACME server only needs to ensure that the value of one TXT record is the same as its calculated SHA-256 digest of the key authorization.

[0114] When the ACME server verifies that the challenge executed by the ACME client has succeeded, the ACME server determines that the ACME client has control over the domain to be verified. Therefore, the ACME server updates the status of the challenge for the domain to be verified to "valid," and the status of the authorization containing the challenge is also updated to "valid." If all authorizations in an order object containing the authorization are invalid, the ACME server updates the status of the order containing that order object to "ready." For details on the status updates of challenges, authorizations, and orders, please refer to section 7.1.6 of RFC 8555; further details are omitted here.

[0115] S6. The ACME client confirms whether the ACME server has completed the challenge verification.

[0116] In one example, the ACME client can poll the ACME server to check if challenge verification is complete. This is because when using HTTP as the data transmission protocol, the ACME server typically cannot proactively send messages to the ACME client. Therefore, if the ACME client needs to obtain the status of a challenge, authorization, or order, it needs to proactively send a status query request to the ACME server. Consequently, the ACME client will generally periodically send status query requests to the ACME server after executing S4 until it confirms that the ACME server has completed challenge verification.

[0117] In another example, the ACME client can default to the ACME server completing the challenge verification after a preset time period. The value of the preset time period is not specifically limited.

[0118] S7. Once the ACME client confirms that all authorizations corresponding to the order request are valid, the ACME client sends a finalize order request to the ACME server. The finalize order request includes a certificate signing request (CSR).

[0119] The Certificate Signature (CSR) is typically a file encoded in binary or text format. The CSR can specify the domain name that has successfully passed the domain control verification steps S3-S5 above as the common name or subject alternative name (subjectAltName) of the digital certificate subject. The CSR can be signed with a private key and contain the corresponding public key. Upon receiving the CSR, the ACME server needs to check its validity based on the public key contained within it; the specific checking process is not detailed here. It's also important to note that the common name is part of the subject, the subject is part of the digital certificate, while subjectAltName is a part of the digital certificate other than the subject.

[0120] The S8 and ACME servers issue digital certificates to ACME clients based on the CSR and their own configurations.

[0121] The process of issuing a digital certificate generally includes the following steps: After receiving an order completion request, the ACME server issues a digital certificate based on the CSR in the order completion request and its own configuration, and updates the order status to "processing". After successfully issuing the digital certificate, the ACME server updates the order status to "valid". Subsequently, similar to S6, the ACME client needs to query the order status to obtain the order status. When the ACME client determines that the order status is valid, the ACME client sends a certificate download request to the ACME server. After receiving the certificate download request, the ACME server sends the successfully issued digital certificate to the ACME client through a response message. At this point, the ACME client obtains the digital certificate issued by the ACME server.

[0122] In related technologies, the various ACME challenges defined by the IETF standards define the effects that a client requesting a digital certificate needs to achieve that can be verified by the server, such as configuring a specific DNS record in the domain name server (e.g., the DNS record corresponding to the DNS-01 challenge), but they do not define how to achieve this effect. In other words, related technologies do not define how the requester of the digital certificate configures that specific DNS record in the domain name server.

[0123] Based on this, this application provides a method for verifying domain name control. Specifically, after receiving a first task, a first device sends a DNS update request to a domain name server to add a target DNS record determined by the parameters of the first task, thereby verifying the first device's control over the first domain name. The first task is a task issued by the certificate management server when the first device applies for a digital certificate, and the first task instructs verification of whether the first device has control over the first domain name. The first domain name is the domain name of the first device. Furthermore, when the certificate management server determines that the first device has control over the first domain name, it can issue a digital certificate based on the first domain name to the first device. The first device is any network element in the communication network that needs to apply for a digital certificate from the certificate management server. This method fills the gap in the process of verifying the domain name control of a requester applying for a digital certificate in a communication network by configuring a specific DNS record in the domain name server.

[0124] refer to Figure 4 , Figure 4 A schematic diagram of an implementation environment for the method provided in the embodiments of this application is shown. Figure 4 As shown, the implementation environment includes a certificate management server and at least one device that needs to apply for a digital certificate from the certificate management server. The at least one device that needs to apply for a digital certificate from the certificate management server includes, for example: Figure 4 The devices shown are 410, 420, etc. In one example, the device requesting a digital certificate can be a physical device or a virtual device. A virtual device is, for example, an NF (also called a virtual network element), and an NF is, for example, an NF in a communication network; this is not limited. The communication network can be any network capable of enabling device communication, such as a 5G network. In another example, the certificate management server can be a CA server. In yet another example, the certificate management server can be a registration authority (RA) server. An RA server is a server used to manage digital certificate applications, primarily responsible for receiving digital certificate requests and authenticating the requesting entity.

[0125] In this embodiment, when a device requests a digital certificate from a certificate management server, it involves verifying the device's control over its domain name through a DNS-based challenge. Therefore, the implementation environment also includes a domain name server storing zone files, such as an authoritative domain name server. Through the interaction between the device requesting the digital certificate, the certificate management server, and the domain name server, the device requesting the digital certificate can obtain the digital certificate from the certificate management server. Detailed processes can be found in the description of the method embodiments below, and will not be repeated here. It is understood that this embodiment does not limit the transmission protocol used for communication between the device requesting the digital certificate, the certificate management server, and the domain name server; for example, it can be the HTTP protocol.

[0126] In one exemplary embodiment, when a device requiring a digital certificate obtains the digital certificate from a certificate management server, this can be achieved through the ACME protocol. Based on this, combined with... Figure 4 ,refer to Figure 5 , Figure 5 A schematic diagram illustrating another implementation environment of the method provided in the embodiments of this application is shown. For example... Figure 5 As shown, the device requiring a digital certificate in this implementation environment (referred to as the first device) has an ACME client deployed on it, and the certificate management server in this implementation environment has an ACME server deployed on it. Through communication between the ACME client, the ACME server, and the domain name server, the ACME client can obtain a digital certificate for the first device from the certificate management server. The detailed process of obtaining the digital certificate can be found in the description of the method embodiment below, and will not be repeated here.

[0127] It should be understood that the above content is an exemplary description of the implementation environment of the method provided in the embodiments of this application, and does not constitute a limitation on the implementation environment of the method. As those skilled in the art know, as business needs change, the implementation environment can be adjusted according to application requirements, and the embodiments of this application do not list them one by one.

[0128] This application embodiment also provides a domain name control verification device. The verification device can be applied to a device that needs to apply for a digital certificate in the above implementation environment, or to a certificate management server in the above implementation environment, or to a domain name server in the above implementation environment, to execute the domain name control verification method provided in this application embodiment.

[0129] Optionally, the verification device can be any computing device or a functional module within a computing device. In one example, the computing device can be a terminal device such as a general-purpose computer, laptop, or mobile phone. In another example, the computing device can be implemented as a network element (including physical network elements and / or virtualized network elements) or a domain name server (such as an authoritative domain name server) in a communication network.

[0130] The method for verifying domain name control provided in this application will be described below with reference to the accompanying drawings and through multiple embodiments.

[0131] Example 1

[0132] In this embodiment, when the first device applying for a digital certificate performs a DNS-based challenge, it uses an asymmetric key to prove its identity to the domain name server during the process of configuring specific DNS records in the domain name server. In this case, it is necessary to first configure a private key for the first device and a public key for the domain name server. Specific configuration methods include, but are not limited to, the following implementation methods 11 to 13.

[0133] In implementation method 11, the network management system generates a key pair, which includes a private key (denoted as the first private key) and a public key (denoted as the first public key). The first private key is used to generate a signature, and the first public key is used to verify the signature generated based on the first private key. The detailed process of the network management system generating the key pair can be found in related technologies, and will not be elaborated upon in this embodiment. The network management system is used to manage and / or maintain the network where the first device is located. For example, the network management system can be implemented by a network management system / device, or by an OAM system / device / equipment, and is not limited thereto. The detailed process of the network management system generating the key pair can be found in related technologies, and will not be elaborated upon in this embodiment.

[0134] Next, the network management system sends the IDs of the first private key and the first public key (such as the domain name that identifies the first public key) to the first device. In response, the first device receives the IDs of the first private key and the first public key; that is, the first device is configured to obtain the IDs of the first private key and the first public key.

[0135] The network management system also configures a DNS KEY record to store the first public key with the domain name server. For example, the network management system can send a DNS update message containing a KEY record to the domain name server, which includes the ID and value of the first public key. Upon receiving the DNS update message from the network management system, the domain name server, in response, adds the KEY record carried in the DNS update message to its stored zone file. That is, the domain name server receives the first public key and configures a KEY record to store it. In this way, the domain name server obtains a first public key belonging to the same key pair as the first private key.

[0136] In implementation method 12, the first device generates a key pair, which includes a first private key and a first public key. The first private key is used to generate a signature, and the first public key is used to verify the signature generated based on the first private key. Thus, the first device obtains the first private key and the first public key from the asymmetric key configuration. The detailed process of the first device generating the key pair can be found in related technologies, and will not be elaborated upon in this embodiment.

[0137] The first device also sends the configured first public key to the network management system. Upon receiving the first public key, the network management system configures a DNS KEY record to store it with the domain name server. For example, the network management system can send a DNS update message to the domain name server, which includes the KEY record. The DNS update message instructs the domain name server to add the KEY record, which includes the ID and value of the first public key. The ID of the first public key can be specified by the first device, which sends the ID to the network management system along with the first public key. Alternatively, the ID of the first public key can also be specified by the network management system that receives the first public key; in this case, the network management system also needs to return the ID of the first public key to the first device.

[0138] After receiving a DNS update message from the network management system, the domain name server responds by adding a KEY record carried in the DNS update message to its stored zone file. In this way, the domain name server obtains a first public key belonging to the same key pair as the first private key. That is, the domain name server receives the first public key and configures a KEY record to store it.

[0139] Since the first device lacks the authority to update the domain name server (DNS) and there is no trusted communication between the first device and the DNS server, both implementations 11 and 12 achieve the purpose of configuring the first public key for the DNS server through DNS update messages sent by the network management system to the DNS server. In this case, both implementations 11 and 12 require prior authorization for the network management system to modify the DNS records on the DNS server. Therefore, by configuring the network management system with the authority to modify the DNS records on the DNS server, any device managed and maintained by the network management system that needs to obtain a digital certificate can configure the first public key for the DNS server through the network management system.

[0140] In implementation method 13, the user generates a key pair including a first private key and a first public key through any device, or manually configures a key pair including a first private key and a first public key. Then, the user inputs the IDs of the first private key and the first public key into the first device via its input interface (such as a keyboard). In response, the first device receives the input IDs of the first private key and the first public key. Alternatively, the user can also input the first public key and its ID into the domain name server via its input interface (such as a keyboard). In response, the domain name server receives the input IDs of the first public key. When the ID of the first public key is a domain name, the domain name server can configure a KEY record based on the received first public key and the domain name used as the first public key ID.

[0141] In one example, when the device generating the key pair is the first device, the user can obtain the first public key and its ID generated by the first device through its output interface (such as a display). In this case, the user can input the first public key and its ID to the domain name server through its input interface (such as a keyboard) so that the domain name server can be configured to obtain the first public key and its ID.

[0142] It is understood that in an embodiment where the first device generates a first private key and a first public key, the first private key will not be known to any other device besides the first device, thus improving the security of the private key.

[0143] By configuring a first private key for the first device and a first public key belonging to the same key pair as the first private key for the domain name controller through implementation methods 11 and 13, an initial trust relationship can be established between the first device and the domain name server.

[0144] Subsequently, the domain name server configures corresponding operation permissions for the obtained first public key. These permissions include operations allowed after verifying information using the first public key and upon successful verification. In the scenario of applying for a digital certificate, the operations allowed by the operation permissions corresponding to the first public key include, but are not limited to: updating (adding / deleting, etc.) DNS records corresponding to DNS challenges.

[0145] In one example, the domain name to be verified is " <domain-to-validate>When the DNS challenge is a DNS-01 challenge, the corresponding DNS record for the DNS challenge is: the subdomain of the domain to be verified, "_acme-challenge". <domain-to-validate>The TXT record contains the domain name. Here, "domain-to-validate" refers to any valid domain name, and the angle brackets <> indicate that the content is filled in based on the actual situation, which will not be elaborated further below.

[0146] In another example, the domain name to be verified is " <domain-to-validate>When the DNS challenge is a DNS-02 challenge, the corresponding DNS record for the DNS challenge includes: the subdomain of the domain to be verified, "_acme-host-challenge". <domain-to-validate>The TXT record for the domain to be verified is for the subdomain "_acme-wildcard-challenge". <domain-to-validate>The TXT record for "" and the subdomain "_acme-domain-challenge" of the domain to be verified. <domain-to-validate>The TXT record of "".

[0147] In yet another example, the domain name to be verified is " <domain-to-validate>When the DNS challenge is a DNS-ACCOUNT-01 challenge, the corresponding DNS record for the DNS challenge includes: subdomains of the domain to be verified. <acme-acc>._acme-host-challenge. <domain-to-validate>The TXT record for the domain to be verified contains the subdomain of the domain to be verified. <acme-acc>._acme-wildcard-challenge. <domain-to-validate>"TXT records of the domain to be verified, subdomains of the domain to be verified" <acme-acc>._acme-domain-challenge. <domain-to-validate>The TXT record contains the value "acme-acc", which is a value calculated based on the account registered by the first device with the certificate management server. This will not be elaborated further below.

[0148] It is understood that when configuring the above-mentioned operation permissions for the first public key in the domain name server, it can be configured manually or by out-of-band (OOB) method. This application embodiment does not limit this.

[0149] It should be noted that when configuring the operation permissions corresponding to the first public key, this embodiment of the application can realize the correspondence between the first public key and its allowed operations by configuring the ID content of the first public key, thereby realizing the configuration of the operation permissions corresponding to the first public key. For example, when configuring the ID for the first public key, this embodiment of the application makes the ID of the first public key include the domain name to be verified.

[0150] For example, the domain name to be verified is still " <domain-to-validate>For example, in verifying the first device's... <domain-to-validate>When controlling the public key, in this embodiment of the application, the ID of the first public key can be configured as: "_acme-dns-key". <domain-to-validate>Thus, the ID is "_acme-dns-key". <domain-to-validate>The operation permissions corresponding to the first public key include, but are not limited to:

[0151] Allow adding the subdomain "_acme-challenge" of the domain to be verified. <domain-to-validate>"TXT records;

[0152] Allow adding the subdomain "_acme-host-challenge" of the domain to be verified. <domain-to-validate>"TXT records;

[0153] Allow adding the subdomain "_acme-wildcard-challenge" of the domain to be verified. <domain-to-validate>"TXT records;

[0154] Allow adding the subdomain "_acme-domain-challenge" of the domain to be verified. <domain-to-validate>"TXT records;

[0155] Allow adding subdomains of the domain to be verified. <acme-acc>._acme-host-challenge. <domain-to-validate>"TXT records;

[0156] Allow adding subdomains of the domain to be verified. <acme-acc>._acme-wildcard-challenge. <domain-to-validate>"TXT records;

[0157] Allow adding subdomains of the domain to be verified. <acme-acc>._acme-domain-challenge. <domain-to-validate>The TXT record of "".

[0158] It should be understood that by configuring operation permissions for the public key corresponding to the private key of the first device in the domain name server, the first device can be provided with the minimum permissions required for DCV, thereby controlling the scope of influence of the public key in the domain name server.

[0159] It should also be understood that when the first private key and the first public key are used for other scenarios besides verifying domain control that require verifying the integrity and source of information, the corresponding operation permissions can be configured for the first public key, which will not be elaborated further.

[0160] Thus, based on the first private key configured for the first device in implementation methods 11 to 13, the first public key configured for the domain name server that belongs to the same key pair as the first private key, and the subsequent operation permissions configured for the first public key corresponding to the first public key, it is possible to verify the control of the domain name of the first device when the first device applies for a digital certificate.

[0161] It should be noted that after configuring the first private key and the first public key for the first device and the domain name server through implementation methods 11 to 13 in this application embodiment, whenever the first device needs to perform a DNS-based challenge task to verify domain name control in order to apply for a digital certificate, the first private key and the first public key can be used to authenticate the message sender. Of course, this application embodiment can also periodically or as needed use any of the implementation methods 11 to 13 to update the private key and public key of the same key pair configured for the first device and the domain name server, so as to realize the update of the private key and public key of the same key pair configured for the first device and the domain name server, thereby ensuring that the identity of the message sender can be verified by using a secure and reliable public key and the corresponding private key. The verification process is described in the method description below.

[0162] refer to Figure 6 , Figure 6 A flowchart illustrating a domain name control verification method provided in an embodiment of this application is shown. Optionally, this method can be applied to... Figure 4 or Figure 5 In the implementation environment shown, the process is performed by any device in that environment that needs to obtain a digital certificate from the certificate management server (taking the first device as an example), the domain name server, and the certificate management server. Optionally, the process may include steps 101 to 105 as described below.

[0163] Step 101: The first device acquires the first task.

[0164] Wherein, the first device is a network element in the communication network, the first task is a task issued by the certificate management server when the first device applies for a digital certificate, the first task instructs to verify whether the first device has control over the first domain name, and the first domain name is the domain name of the first device.

[0165] Optionally, when the first device applies for a digital certificate from the certificate management server, the certificate management server issues one or more tasks to the first device, where the first task is any one of these tasks. For example, the first task could be any DNS-based challenge issued by the certificate management server.

[0166] Taking the first task as a DNS-based challenge issued by the certificate management server as an example, the first device obtaining the first task issued by the certificate management server may include: the first device sending an order request to the certificate management server to create a digital certificate, the order request including the first domain name; the certificate management server receiving the order request sent by the first device and returning an order response to the first device, the order response indicating one or more challenges, which are used to indicate whether the first device has control over the domain name carried in the order request; the first device selecting one DNS-based challenge from the one or more challenges as the first task.

[0167] The detailed description of the process of the first device sending an order request to the certificate management server to create a digital certificate, and the certificate management server returning an order response to the first device, can be found in the description of steps S1 to S2 above, and will not be repeated here.

[0168] Step 102: The first device responds to the first task by sending a DNS update request to the domain name server. The DNS update request includes update operation information and first verification information.

[0169] The first verification information is used to verify whether the update operation indicated by the update operation information is allowed to be executed. The update operation is the operation of adding a target DNS record to the domain name server. The target DNS record is determined based on the parameters of the first task.

[0170] Since the first task can be any DNS-based challenge indicated in the order response returned by the certificate management server, for example, the first task could be a DNS-01 challenge, a DNS-02 challenge, or a DNS-ACCOUNT-01 challenge, etc. The first device can obtain the parameters of the first task through multiple interactions with the certificate management server, which will not be elaborated in this embodiment.

[0171] The parameters of the first task may include the task type and the token assigned to the challenge by the certificate management server. Based on the task type, the first domain name, and the parameters of the first task, the first device can generate a target DNS record corresponding to the task type of the first task.

[0172] In this context, the domain name of the target DNS record is denoted as the target subdomain. The target subdomain is the subdomain among the subdomains included in the first domain that corresponds to the task type of the first task. Here, the target subdomain can be determined based on the task type of the first task and the first domain. Taking example, if the first domain is example.com, in one example, if the type of the first task is DNS-01 challenge, then the target subdomain is "_acme-challenge.example.com". In another example, if the type of the first task is DNS-02 challenge, then the target subdomain could be "_acme-host-challenge.example.com", "_acme-wildcard-challenge.example.com", or "_acme-domain-challenge.example.com". In yet another example, if the type of the first task is DNS-ACCOUNT-01 challenge, then the target subdomain could be "_ <acme-acc>._acme-host-challenge.example.com”、"_ <acme-acc>._acme-wildcard-challenge.example.com” or "_ <acme-acc>._acme-domain-challenge.example.com".

[0173] The value of the target DNS record can be determined based on the parameters of the first task. For example, the value of the target DNS record can be, but is not limited to, the SHA-256 digest of the key authorization determined in step S2 above based on the token assigned to the challenge.

[0174] It can be seen that the target DNS record is actually a TXT record under the target subdomain.

[0175] Next, in response to the first task, the first device generates a DNS update request based on the target DNS record, including update operation information and first verification information, and sends the DNS update request to the domain name server. Optionally, the first device can send the DNS update request to the domain name server via the HTTP protocol.

[0176] The update operation information includes the type of update operation, the target subdomain, and the value of the target DNS record. In this embodiment, to verify the control of the first domain name, the type of update operation included in the update operation information is: adding a DNS record.

[0177] The first verification information includes a signature generated based on a first key and the ID of a second key. The signature generated based on the first key refers to the digital signature obtained by the first device after performing calculations on the information in the DNS update request other than the first verification information based on the first key. This digital signature can also be called the signature of the DNS update request generated based on the first key. Therefore, it can also be understood that the first key is used to generate the first verification information including this digital signature.

[0178] Here, the first key is the first private key mentioned above, and the second key is the first public key mentioned above. The process of configuring the first key and the second key ID on the first device can be referred to the description above, and will not be repeated here. In one example, verification information including digital signatures can also be recorded as a SIG(0) record.

[0179] It should be noted that in Embodiment 1, the second key is the public key in the asymmetric key, while in Embodiment 2 below, the second key used to verify the first verification information is the first symmetric key. For details, please refer to the description of Embodiment 2, which will not be repeated here.

[0180] Step 103: The domain name server receives the DNS update request sent by the first device and verifies the first verification information in the DNS update request to determine whether to allow the update operation indicated by the update operation information in the DNS update request.

[0181] After receiving a DNS update request from the first device, the domain name server (DNS server) queries its own configuration for the second key based on the ID of the second key carried in the first verification information in the DNS update request. Taking a domain name as an example, the DNS server can query its own zone file for a KEY record containing that domain name, based on the domain name used as the second key ID in the first verification information of the DNS update request. The value of the KEY record found by the DNS server is the second key, which is the first public key configured by the DNS server above. The second key is used to verify the first verification information. The process of pre-configuring the second key by the DNS server can be referred to the description above and will not be repeated here.

[0182] Next, the domain name server verifies the first verification information based on the found second key. For example, the domain name server performs calculations based on the second key in the found KEY record, other information in the DNS update request besides the first verification information, and the signature carried in the first verification information to complete the verification of the first verification information.

[0183] When the first verification information is verified, the domain name server can determine that the DNS update request containing the first verification information was sent by the device holding the first key, which belongs to the same key pair as the second key. Therefore, the identity of the first device that sent the DNS update request can be determined.

[0184] Subsequently, the domain name server, based on the operation permissions corresponding to the second key, determines whether to allow the update operation indicated by the update operation information in the DNS update request. If it is determined that the operation permissions corresponding to the second key allow the execution of the update operation indicated by the update operation information, the domain name server proceeds to step 104. If it is determined that the operations allowed by the operation permissions corresponding to the second key do not include the update operation indicated by the update operation information, the DNS update request is discarded or invalidated. For a detailed explanation of the operation permissions corresponding to the second key, please refer to the description above regarding configuring the operation permissions corresponding to the first public key; further details will not be repeated here.

[0185] Taking example where the first domain is example.com and the first task is DNS_01 challenge, the target subdomain included in the update operation information in the DNS update request is "_acme-challenge".<example.com> When the domain name server verifies the result of the first verification information in the DNS update request based on the second key and the domain name server determines that the allowed operations for the operation permissions corresponding to the second key include: adding the domain name "_acme-challenge".<example.com> If the operation of the TXT record is performed, the domain name server can determine whether to allow the update operation indicated by the update operation information in the DNS update request.

[0186] Step 104: If the domain name server determines that the above update operation is allowed, it adds the target DNS record.

[0187] If the domain name server determines that the above update operation is allowed, it records a target DNS record in the DNS system with the domain name as the target subdomain and the value of the target DNS record carried in the update operation information in the DNS update request.

[0188] Step 105: The first device sends a task response to the certificate management server. The task response is used to instruct the first device to query the target DNS record in the domain name server. The result of the query operation is used to indicate whether the first device has control over the first domain name.

[0189] In response, the certificate management server receives the task response sent by the first device and, in response to the task response, queries the target DNS record in the domain name server.

[0190] In one example, the certificate management server can send a DNS query request to a domain name server to retrieve the DNS records for a target subdomain. Upon receiving the DNS query request from the certificate management server, the domain name server responds by returning the DNS records for the target subdomain to the certificate management server. The certificate management server receives the returned DNS records for the target subdomain and queries them to determine whether the received DNS records include the target DNS record.

[0191] Furthermore, based on the query results, the certificate management server can determine whether the first device has control over the first domain name.

[0192] For example, if the result of the above query indicates that the DNS records received by the certificate management server include the target DNS record, then it is determined that the first device has control over the domain name carried in the order request. Conversely, if the result of the above query indicates that the DNS records received by the certificate management server do not include the target DNS record, then it cannot be determined whether the first device has control over the domain name carried in the order request.

[0193] It is understandable that the detailed implementation process of step 105 can be referred to the relevant explanations in S4 to S5 above, and will not be repeated here.

[0194] Through the processes described in steps 101 to 105, the verification of domain name control of the first device is achieved based on a DNS challenge task targeting the domain name. Furthermore, this embodiment of the application updates the DNS records used by the DCV using DNS update messages with authentication (based on asymmetric keys), enabling the first device to securely update the DNS records required by the DCV.

[0195] Subsequently, if the first device has control over the first domain name, the first device can also obtain a digital certificate from the certificate management server. For details, please refer to the process descriptions of steps S6 to S8 above, which will not be repeated here.

[0196] To deepen the understanding of Embodiment 1, a further description is provided below with specific examples.

[0197] Taking the example where the first device is an NF in a communication network, the network management system is an OAM system, the certificate management server is a CA server, and the OAM system is pre-authorized to modify the DNS records of the authoritative name server, refer to... Figure 7 , Figure 7 This illustration shows another flowchart of the domain name control verification method provided in an embodiment of this application. In this method, NF acts as an ACME client, and the CA server acts as an ACME server. The method includes the following steps 201 to 213.

[0198] Step 201: The OAM system creates the configuration required for NF. The configuration required for NF includes NF instance ID, NF IP address and domain name (denoted as NF domain name).

[0199] Step 202: The OAM system sends the above configuration to the network node so that the network node can create an NF according to the configuration.

[0200] Step 203: NF generates a key pair and stores the first private key in its own configuration information.

[0201] Step 204: NF sends the first public key of the key pair to the OAM system.

[0202] Step 205: Based on the configuration of the created NF and the received first public key, the OAM system sends the DNS record of the NF to the authoritative name server. The DNS record includes the A record / AAAA record of the NF's IP address and the KEY record containing the first public key, thereby enabling the authoritative name server to configure the DNS record of the NF and configure the corresponding operation permissions for the first public key.

[0203] In response, after receiving the DNS record sent by the OAM system, the authoritative name server adds an A record / AAAA record for the NF IP address and a KEY record containing the first public key to the zone file used to record NF domain names in the DNS system, and configures the corresponding operation permissions for the first public key, thereby completing the configuration of the NF DNS record. For detailed explanations, please refer to the relevant description of implementation method 12 above, which will not be repeated here.

[0204] Optionally, the DNS records sent by the OAM system to authoritative name servers can be included in the DNS update messages, and there are no restrictions on this.

[0205] It can be seen that steps 201 to 205 can be regarded as the process of configuring the key.

[0206] Step 206: The NF sends an order request to the CA server to create a digital certificate. The order request includes the NF domain name.

[0207] Step 207: The CA server returns an order response to the NF.

[0208] For detailed explanations of steps 206 and 207, please refer to the relevant descriptions in step 101 above, which will not be repeated here.

[0209] Step 208: In response to the first challenge indicated in the order response, NF sends a DNS update request to the authoritative domain name server. The DNS update request contains update operation information and first verification information.

[0210] The first challenge is any DNS-based challenge (i.e., the task mentioned above) issued by the CA server to verify control of the NF domain name. For a detailed explanation of this step, please refer to step 102 above, which will not be repeated here.

[0211] Step 209: The authoritative domain name server receives the DNS update request sent by NF and verifies the first verification information in the DNS update request to determine whether the update operation indicated by the update operation information in the DNS update request is allowed to be executed, and if it is determined that the update operation is allowed to be executed, the target DNS record is added.

[0212] For a detailed explanation of this step, please refer to steps 103 to 104 above, which will not be repeated here.

[0213] Step 210: NF sends a challenge response to the CA server. The challenge response is used to instruct the NF to query the target DNS record in the authoritative name server. The result of the query operation is used to indicate whether NF has control over the NF domain name.

[0214] Step 211: The CA server receives the challenge response sent by the NF and, in response to the challenge response, queries the target DNS record in the authoritative domain name server.

[0215] Step 212: Based on the query results, the CA server determines whether NF has control over the NF domain name.

[0216] For detailed explanations of steps 210 to 212, please refer to the description of step 105 above, which will not be repeated here.

[0217] Step 213: When NF has control over the NF domain name, NF obtains a digital certificate from the CA server.

[0218] For a detailed explanation of this step, please refer to the descriptions of steps S6 to S8 above, which will not be repeated here.

[0219] It can be seen that steps 206 to 213 can be regarded as the process of verifying domain name control and issuing digital certificates.

[0220] Example 2

[0221] In this embodiment, when the first device applying for a digital certificate performs a DNS-based challenge, it uses a symmetric key to prove its identity to the domain name server during the process of configuring specific DNS records in the domain name server. In this case, a first symmetric key needs to be configured for both the first device and the domain name server first. Specific configuration methods include, but are not limited to, the following implementation methods 21 to 23.

[0222] In implementation method 21, the network management system generates a first symmetric key and configures the ID of the first symmetric key (such as a domain name used to identify the first symmetric key). The description of the network management system can be found in the relevant description in implementation method 11 above, and will not be repeated here. The detailed process of the network management system generating the first symmetric key can be found in related technologies, and will not be elaborated upon in this embodiment.

[0223] Next, the network management system sends the first symmetric key and its ID to the first device. In response, the first device receives the first symmetric key and its ID, meaning the first device configures and obtains the first symmetric key.

[0224] The network management system also configures the first symmetric key with the domain name server. For example, the network management system can send a configuration message containing the first symmetric key and its ID to the domain name server. This configuration message may include a TKEY record for carrying the first symmetric key and its ID. Upon receiving the configuration message, the domain name server has thus configured the first symmetric key.

[0225] In implementation method 22, the first device generates a first symmetric key and configures the ID of the first symmetric key. Thus, the first device obtains the first symmetric key. The detailed process of the first device generating the first symmetric key can be found in related technologies, and will not be elaborated upon in this embodiment.

[0226] The first device also sends the configured first symmetric key and its ID to the network management system. Upon receiving the first symmetric key and its ID, the network management system configures the first symmetric key with the domain name server. The process by which the network management system configures the first symmetric key and its ID with the domain name server can be referred to the relevant description in implementation method 21, and will not be repeated here.

[0227] Since the first device lacks permission to update the domain name server and no trusted communication has been established between the first device and the domain name server, both implementations 21 and 22 configure the first symmetric key and its ID for the domain name server through the network management system. In this case, both implementations 21 and 22 require prior authorization for the network management system to modify the domain name server and thus configure the symmetric key thereon. Therefore, by granting the network management system permission to modify the configuration parameters in the domain name server, any device managed and maintained by the network management system that needs to obtain an array of certificates can configure the first symmetric key and its ID for the domain name server through the network management system.

[0228] In implementation method 23, the user generates the first symmetric key through any device or manually configures the first symmetric key. Then, the user inputs the first symmetric key and its ID into the first device via its input interface (such as a keyboard). In response, the first device receives the user-inputted first symmetric key and its ID. Alternatively, the user can also input the first symmetric key and its ID into the domain name server via its input interface (such as a keyboard). In response, the domain name server receives the user-inputted first symmetric key and its ID, meaning the domain name server has configured and obtained the first symmetric key and its ID.

[0229] In one example, when the device generating the first symmetric key is the first device, the user can obtain the first symmetric key and its ID through the first device's output interface (such as a display). In this case, the user can input the first symmetric key and its ID to the domain name server through its input interface (such as a keyboard), so that the domain name server can be configured to obtain the first symmetric key and its ID.

[0230] By configuring the first symmetric key for the first device and the domain name server respectively through implementation methods 21 and 23, the first device and the domain name server can establish an initial trust relationship.

[0231] Subsequently, the domain name server configures corresponding operation permissions for the obtained first symmetric key. These permissions include operations allowed after verifying information using the first symmetric key and upon successful verification. In the scenario of applying for a digital certificate, the operations allowed by the operation permissions corresponding to the first symmetric key include, but are not limited to: updating (adding / deleting, etc.) the DNS records corresponding to the DNS challenge. Detailed examples of DNS records corresponding to the DNS challenge can be found in the relevant descriptions above and will not be repeated here.

[0232] It should be noted that, when configuring the operation permissions corresponding to the first symmetric key, this embodiment of the application can realize the correspondence between the first symmetric key and its allowed operations by configuring the ID content of the first symmetric key, thereby realizing the configuration of the operation permissions corresponding to the first symmetric key. For example, when configuring the ID for the first symmetric key, this embodiment of the application makes the ID of the first symmetric key include the domain name to be verified.

[0233] For example, taking the domain name to be verified as "domain-to-validate" as an example, when verifying the first device's control over "domain-to-validate", this embodiment of the application can configure the ID of the first symmetric key as "_acme-dns-key". <domain-to-validate> . <tkey-domain> ”， <tkey-domain>This is the domain name suffix specified by the DNS server as the key ID. Thus, the ID is "_acme-dns-key". <domain-to-validate> . <tkey-domain>The operation permissions corresponding to the first symmetric key include, but are not limited to:

[0234] Allow adding the subdomain "_acme-challenge" of the domain to be verified. <domain-to-validate>"TXT records;

[0235] Allow adding the subdomain "_acme-host-challenge" of the domain to be verified. <domain-to-validate>"TXT records;

[0236] Allow adding the subdomain "_acme-wildcard-challenge" of the domain to be verified. <domain-to-validate>"TXT records;

[0237] Allow adding the subdomain "_acme-domain-challenge" of the domain to be verified. <domain-to-validate>"TXT records;

[0238] Allow adding subdomains of the domain to be verified. <acme-acc>._acme-host-challenge. <domain-to-validate>"TXT records;

[0239] Allow adding subdomains of the domain to be verified. <acme-acc>._acme-wildcard-challenge. <domain-to-validate>"TXT records;

[0240] Allow adding subdomains of the domain to be verified. <acme-acc>._acme-domain-challenge. <domain-to-validate>The TXT record of "".

[0241] It should be understood that by configuring operational permissions for the symmetric key shared with the first device in the domain name server, the first device can be given the minimum permissions required for DCV, thereby controlling the scope of influence of the shared key in the domain name server.

[0242] Thus, based on implementation methods 21 to 23, the first symmetric key is configured for the first device and the domain name server, and the operation permissions corresponding to the first symmetric key are subsequently configured for the first symmetric key. This enables the verification of the control rights of the domain name of the first device when the first device applies for a digital certificate.

[0243] It should be noted that, after configuring the first symmetric key for the first device and the domain name server through implementation methods 21 to 23 in this application embodiment, whenever the first device needs to perform a DNS-based challenge task to verify domain name control in order to apply for a digital certificate, the first symmetric key can be used for the authentication of the message sender. Of course, this application embodiment can also periodically or as needed use any of implementation methods 21 to 23 to update the symmetric key configured for the first device and the domain name server, so as to realize the update of the symmetric key configured for the first device and the domain name server, thereby ensuring that a secure and reliable symmetric key can be used to verify the identity of the message sender in the future.

[0244] Combination Figure 6 ,refer to Figure 8 , Figure 8 A flowchart illustrating another domain name control verification method provided in an embodiment of this application is shown. Optionally, this method can be applied to... Figure 4 or Figure 5 In the implementation environment shown, this is performed by any device in that environment that needs to obtain a digital certificate from the certificate management server (taking the first device as an example), the domain name server, and the certificate management server. Optionally, Figure 8 After completing step 101, the method shown executes steps 302 to 303.

[0245] Step 302: In response to the first task, the first device sends a DNS update request to the domain name server. The DNS update request includes update operation information and first verification information. The first verification information includes a MAC generated based on the first symmetric key.

[0246] For a detailed explanation of this step, please refer to the relevant description of step 102. The difference between this step and step 102 is as follows: Figure 6 In the method shown, the first key is replaced with a first symmetric key obtained by configuring the first device and the domain name server based on implementation methods 21 to 23. That is, when the first key is the first symmetric key, the first verification information included in the DNS update request in this step includes: a MAC generated based on the first symmetric key and the ID of the first symmetric key. The MAC generated based on the first symmetric key refers to the MAC obtained by the first device after performing calculations on all information in the DNS update request except for the first verification information based on the first symmetric key. This MAC can also be called the MAC of the DNS update request generated based on the first symmetric key. It can also be understood that the first symmetric key, as the first key, is used to generate the first verification information including this MAC. In one example, the verification information including the MAC can also be denoted as a TSIG record.

[0247] Step 303: The domain name server receives the DNS update request sent by the first device, finds the first symmetric key based on the key ID carried in the first verification information in the DNS update request, and uses the first symmetric key to verify the first verification information in the DNS update request to determine whether the update operation indicated by the update operation information in the DNS update request is allowed to be executed.

[0248] For a detailed explanation of this step, please refer to the description of step 103. The difference between this step and step 103 is that in step 303, after receiving the DNS update request sent by the first device, the domain name server queries its own configuration for the first symmetric key identified by the key ID carried in the first verification information in the DNS update request. Then, the domain name server verifies the first verification information containing the MAC address based on the found first symmetric key. For example, the domain name server performs calculations based on the found first symmetric key, other information in the DNS update request besides the first verification information, and the MAC address carried in the first verification information to complete the verification of the first verification information. It can be seen that when the second key mentioned in step 103 is the first symmetric key, the first verification information includes the MAC address of the DNS update request generated based on the first symmetric key.

[0249] Then, if the domain name server verifies the first verification information using the first symmetric key and the verification passes, the domain name server determines, based on the operation permissions corresponding to the first symmetric key, whether to allow the execution of the update operation indicated by the update operation information in the DNS update request. For a detailed explanation, please refer to the description above, "The domain name server determines whether to allow the execution of the update operation indicated by the update operation information in the DNS update request based on the operation permissions corresponding to the second key," which will not be repeated here.

[0250] Subsequently, Figure 8 The method shown can be used to perform steps 104 to 105.

[0251] Thus, through Figure 8 The process described herein verifies the domain name control of the first device based on a DNS challenge targeting the domain name. Furthermore, this embodiment of the application updates the DNS records used by the DCV using DNS update messages with authentication (symmetric key-based authentication), enabling the first device to securely update the DNS records required by the DCV.

[0252] Optionally, if the first device has control over the first domain name, the first device can also obtain a digital certificate from the certificate management server. For details, please refer to the process descriptions of steps S6 to S8 above, which will not be repeated here.

[0253] To deepen the understanding of Embodiment 2, a further description is provided below with specific examples.

[0254] Taking the example where the first device is an NF in a communication network, the network management system is an OAM system, the certificate management server is a CA server, and the OAM system is pre-authorized to modify the DNS records of authoritative name servers, combined with... Figure 7 and Figure 8 ,refer to Figure 9 , Figure 9 This illustration shows another flowchart of the domain name control verification method provided in an embodiment of this application. In this method, NF acts as an ACME client, and the CA server acts as an ACME server. The method includes the following steps 401 to 213.

[0255] Step 401: The OAM system creates the configuration required for NF. The configuration required for NF includes NF instance ID, NF IP address, domain name (denoted as NF domain name), first symmetric key, and ID of the first symmetric key.

[0256] Step 402: The OAM system sends the above configuration to the network node so that the network node can create an NF according to the configuration and the NF configuration obtains the first symmetric key.

[0257] Step 403: The OAM system sends the DNS record of NF to the authoritative domain name server. The DNS record includes the A record / AAAA record of the IP address of NF, the first symmetric key and the ID of the first symmetric key, so that the authoritative domain name server configures the DNS record of NF, the first symmetric key and the ID of the first symmetric key, and configures the corresponding operation permissions for the first symmetric key.

[0258] In response, after receiving the DNS record sent by the OAM system, the authoritative name server adds an A record / AAAA record for the NF IP address to the zone file used to record NF domain names in the DNS system, thus completing the configuration of the NF DNS record. In addition, the authoritative name server also adds configuration parameters containing the first symmetric key and its ID, as well as configuring the corresponding operation permissions for the first symmetric key.

[0259] Optionally, the DNS records sent by the OAM system to authoritative name servers can be included in the DNS update messages, and there are no restrictions on this.

[0260] It can be seen that steps 401 to 403 can be regarded as the process of configuring the key.

[0261] Step 404: The NF sends an order request to the CA server to create a digital certificate. The order request includes the NF domain name.

[0262] Step 405: The CA server returns an order response to the NF.

[0263] For detailed explanations of steps 404 to 405, please refer to the relevant descriptions in step 101 above, which will not be repeated here.

[0264] Step 406: In response to the first challenge indicated in the order response, NF sends a DNS update request to the authoritative domain name server. The DNS update request includes update operation information and first verification information, including a MAC generated based on the first symmetric key.

[0265] The first challenge is any DNS-based challenge (i.e., the task mentioned above) issued by the CA server to verify control of the NF domain name. For a detailed explanation of this step, please refer to step 302 above, which will not be repeated here.

[0266] Step 407: The authoritative domain name server receives the DNS update request sent by NF, finds the first symmetric key based on the key ID carried in the first verification information in the DNS update request, and uses the first symmetric key to verify the first verification information in the DNS update request to determine whether the update operation indicated by the update operation information in the DNS update request is allowed to be executed. If it is determined that the update operation is allowed to be executed, the target DNS record is added.

[0267] For a detailed explanation of this step, please refer to steps 303 and 104 above, which will not be repeated here.

[0268] after, Figure 9 The method executes steps 210 to 213 to enable the NF to obtain a digital certificate from the CA server.

[0269] It can be seen that steps 404 to 213 can be regarded as the process of verifying domain name control and issuing digital certificates.

[0270] Example 3

[0271] In this embodiment, when the first device applying for a digital certificate performs a DNS-based challenge, the key (such as an asymmetric key or a symmetric key) used by the first device to prove its identity to the domain name server during the process of configuring specific DNS records in the domain name server is configured using a key-based verification method. Specific configuration methods include, but are not limited to, the following implementation methods 31 to 32.

[0272] In implementation method 31, the first device generates a key pair, which includes a first private key and a first public key. Thus, the first device is configured to obtain the first private key and the first public key from the asymmetric key.

[0273] The first device sends a configuration message containing a first public key to the domain name server. This configuration message also includes second verification information used to verify whether the first public key is configured. Since public keys are typically stored in DNS KEY records, which include the public key's ID and value, this example, when the configuration message is implemented as a DNS update message, means: the first device sends a DNS update message to the domain name server. This DNS update message includes a KEY record and the second verification information. The DNS update message instructs the domain name server to add the KEY record, which includes the first public key's ID and value.

[0274] The second verification information includes a signature of a configuration message generated based on the second private key. In this case, the first device is pre-configured with a second private key. The configuration method can be found in the description of configuring the first private key for the first device in any of the implementations 11-13 and 31. Furthermore, the domain name server is pre-configured with a second public key belonging to the same key pair as the second private key. The specific configuration method can be found in the description of configuring the first public key for the domain name server in any of the implementations 11-13 and 31 above, and will not be repeated here. Thus, after receiving the DNS update message from the first device, the domain name server searches for the KEY record containing the key ID carried in the second verification information of the DNS update message. The value of this KEY record is the second public key configured by the domain name server. The domain name server uses the second public key to verify the signature in the second verification information and, if the signature verification passes, checks the operation permissions corresponding to the second public key to determine whether to allow the configuration of the first public key. When the domain name server determines that the operation permissions corresponding to the second public key allow the configuration of the first public key, the first public key is stored in the DNS system. For example, a KEY record containing the domain name as the ID of the first public key and the value of the first public key is added to the DNS system.

[0275] Alternatively, the second verification information includes the MAC address of a configuration message generated based on the second symmetric key. In this case, both the first device and the domain name server are pre-configured with the second symmetric key. The configuration method can be referred to the description of configuring the first symmetric key for the first device and the domain name server in any of the implementations 21 to 23 and 32 above, which will not be repeated here. In this case, after the domain name server receives the DNS update message sent by the first device, it looks up the symmetric key identified by the key ID carried in the second verification information in the DNS update message. This symmetric key is the second symmetric key configured by the domain name server. The domain name server uses the second symmetric key to verify the MAC address in the second verification information, and if the verification is successful, it checks the operation permissions corresponding to the second symmetric key to determine whether the configuration of the first public key is allowed. When the domain name server determines that the operation permissions corresponding to the second symmetric key allow the configuration of the first public key, it stores the first public key in the DNS system, for example, by adding a KEY record containing the ID and value of the first public key in the DNS system.

[0276] It should be noted that after the domain name server obtains the second public key and the second symmetric key (collectively referred to as the verification key), it configures the corresponding operation permissions for the verification key. These operation permissions include the operations that are allowed to be performed after the information is verified through the verification key and the verification is successful.

[0277] It is understood that when configuring operation permissions for verification keys in a domain name server, configuration can be done manually or out-of-band, and this application embodiment does not limit this.

[0278] It should be noted that when configuring the operation permissions corresponding to the verification key, this embodiment of the application can realize the correspondence between the verification key and its allowed operations by configuring the ID content of the verification key, thereby realizing the configuration of the operation permissions corresponding to the verification key. Since the verification key in this embodiment of the application is used to verify the message transmitted during the negotiation of the key, when configuring the ID of the verification key, this embodiment of the application can make the ID of the verification key include the domain name contained in the ID of the key to be negotiated, so as to establish the association between the verification key and the message used to negotiate the "key to be negotiated".

[0279] The domain name contained in the ID of the key to be negotiated is " <key-domain>For example, key-domain can be any valid domain name, usually specified by the party initiating key exchange. key-domain can be used as the ID of the "key to be negotiated" or as a prefix in the ID of the "key to be negotiated", without limitation. In one example, if the verification key is the public key in an asymmetric key, then in this embodiment of the application, the ID of the verification key can be configured as "_key-exchange-key". <key-domain>Thus, the ID is "_key-exchange-key". <key-domain>The operation permissions corresponding to the verification key include, but are not limited to: allowing the addition of domains containing "_acme-dns-key". <key-domain>The public key is recorded as a KEY. In another example, if the verification key is a symmetric key, the ID of the verification key can be configured as "_key-exchange-key". <key-domain> . <tkey-domain>",in," <tkey-domain>This is typically a suffix specified by the end receiving the key exchange message. Thus, the ID would be "_key-exchange-key". <key-domain> . <tkey-domain>The operation permissions corresponding to the verification key include, but are not limited to: allowing negotiation of the domain name "_acme-dns-key". <key-domain> . <tkey-domain>The symmetric key of "".

[0280] It is understandable that when " <key-domain>Replace with the domain name to be verified mentioned above. <domain-to-validate>In this case, the symmetric key negotiated here or the asymmetric key configured here can be used to verify the DNS update request sent by the first device when verifying domain name control as described above. Of course, the key negotiated by the verification key in this embodiment can also be applied to other scenarios / fields besides verifying domain name control, and this embodiment does not limit this.

[0281] In implementation method 32, the first device sends a negotiation message to the domain name server to negotiate the first symmetric key. The negotiation message carries relevant information for negotiating the first symmetric key. The negotiation message also includes third verification information, which verifies whether the operation of determining the first symmetric key based on the negotiation message has been performed.

[0282] The third verification information includes the signature of the negotiation message generated based on the second private key. The description of the second private key is referenced in Implementation 31 and will not be repeated here. In this way, after receiving the negotiation message from the first device, the domain name server looks up the KEY record containing the key ID carried in the third verification information of the negotiation message. The value of this KEY record is the second public key configured by the domain name server and belonging to the same key pair as the second private key. The domain name server uses the second public key to verify the signature in the third verification information and, if the signature verification is successful, checks the operation permissions corresponding to the second public key to determine whether to execute the operation of determining the first symmetric key based on the negotiation message. When the domain name server determines that the operation permissions corresponding to the second public key allow the operation of determining the first symmetric key based on the negotiation message, the domain name server determines the first symmetric key based on the information carried in the negotiation message. Thus, the domain name server obtains the first symmetric key. A detailed explanation of how the domain name server determines the first symmetric key based on the negotiation message sent by the first device can be found in related technologies, and will not be repeated here in this embodiment.

[0283] Alternatively, the third verification information includes the MAC address of the negotiation message generated based on the second symmetric key. The description of the second symmetric key is the same as described in implementation 31 and will not be repeated here. In this case, after receiving the negotiation message from the first device, the domain name server looks up the symmetric key identified by the key ID carried in the third verification information of the negotiation message. This symmetric key is the second symmetric key configured by the domain name server. The domain name server uses the second symmetric key to verify the MAC address in the third verification information, and if the verification is successful, checks the operation permissions corresponding to the second symmetric key to determine whether the operation to determine the first symmetric key based on the negotiation message is allowed. When the domain name server determines that the operation permissions corresponding to the second symmetric key allow the operation to determine the first symmetric key based on the negotiation message, the domain name server determines the first symmetric key based on the information carried in the negotiation message. Thus, the domain name server obtains the first symmetric key.

[0284] Subsequently, if the second verification information passes and it is determined that the operation of determining the first symmetric key based on the negotiation message is allowed, the domain name server sends a response message of the negotiation message to the first device. The response message includes fourth verification information, which is used to verify whether the operation of determining the first symmetric key based on the response message is performed.

[0285] The fourth verification information includes a signature of the response message generated based on the third private key. The third private key is a private key pre-configured in the asymmetric key set of the domain name server (DNS). The third private key can be obtained by the DNS itself generating a key pair including the third private key. In this case, the first device is configured with a third public key belonging to the same key pair as the third private key. In one example, after generating the key pair including the third private key and the third public key, the DNS sends the third public key to the network management system of the network to which the first device belongs. The network management system then configures the third public key in the first device. In this way, after determining the response content of the negotiation message, the DNS can generate a signature based on its own configured third private key and the response content, thereby obtaining the fourth verification information including the signature and the third public key ID. The DNS then sends a response message including the response content and the fourth verification information to the first device. After receiving the response message from the DNS, the first device searches its own configuration for the third public key identified by the key ID carried in the fourth verification information of the response message. The domain name server uses a third public key to verify the signature in the fourth verification information. If the signature verification passes, it checks the operation permissions corresponding to the third public key to determine whether to execute the operation of determining the first symmetric key based on the response message. When the first device determines that the operation permissions corresponding to the third public key allow the execution of the operation of determining the first symmetric key based on the response message, the first device determines the first symmetric key based on the information carried in the response message. Thus, the first device obtains the first symmetric key. For a detailed explanation of how the first device determines the first symmetric key based on the response message returned by the domain name server, please refer to relevant technologies; this embodiment will not elaborate further.

[0286] Alternatively, the fourth verification information includes the MAC of the response message generated based on the second symmetric key. The description of the second symmetric key is referenced in Implementation 31 and will not be repeated here. After determining the response content of the negotiation message, the domain name server can generate a MAC based on its own configured second symmetric key and the response content, thereby obtaining the fourth verification information including the MAC and the second symmetric key ID. Then, the domain name server sends a response message including the response content and the fourth verification information to the first device. After receiving the response message from the domain name server, the first device searches for the second symmetric key identified by the key ID carried in the fourth verification information in its own configuration. The domain name server uses the second symmetric key to verify the MAC in the fourth verification information, and if the verification is successful, checks the operation permissions corresponding to the second symmetric key to determine whether to execute the operation of determining the first symmetric key based on the response message. When the first device determines that the operation permissions corresponding to the second symmetric key allow the execution of the operation of determining the first symmetric key based on the response message, the first device determines the first symmetric key based on the information carried in the response message. In this way, the first device configures and obtains the first symmetric key.

[0287] It should be noted that after the first device obtains the third public key and the second symmetric key (collectively referred to as the verification key), it configures the corresponding operation permissions for the verification key. These operation permissions include the operations that are allowed to be performed after the information is verified through the verification key and the verification is successful. For a detailed description, please refer to the instructions on configuring the corresponding operation permissions for the verification key by the domain name server, which will not be repeated here.

[0288] It is understood that when configuring operation permissions for the verification key in the first device, configuration can be done manually or out-of-band, and this application embodiment does not limit this. It should be understood that by configuring operation permissions for the key configured above, the scope of influence of the key can be controlled.

[0289] It should be understood that, compared to the schemes based on the asymmetric keys configured in implementation methods 11 to 13 and the symmetric keys configured in implementation methods 21 to 23, the scheme provided by implementation method 31, which configures the public key of the asymmetric key for the domain name server based on either asymmetric or asymmetric keys, and the scheme provided by implementation method 32, which negotiates and configures the symmetric key between the first device and the domain name server based on either asymmetric or asymmetric keys, both enable the first device to update the DNS records required for DCV more securely.

[0290] Thus, based on implementation method 31, an asymmetric key is configured for the first device and the domain name server using a verification key-based method. Therefore, when the first device, which needs to apply for a digital certificate, performs a DNS-based challenge, it can use this asymmetric key to prove its identity to the domain name server during the process of configuring specific DNS records in the domain name server. After successful authentication, the verification of the first device's domain name control can be further performed based on the operation permissions corresponding to the public key in the asymmetric key. This process can be referred to... Figure 6 The method shown will not be elaborated further. For a detailed explanation of the operation permissions corresponding to the public key in asymmetric keys, please refer to the description of the operation permissions corresponding to the first public key above; it will not be repeated here.

[0291] It should be noted that after configuring the asymmetric key for the first device and the domain name server through implementation method 31 in this embodiment, the asymmetric key can be used to authenticate the message sender whenever the first device needs to perform a DNS-based challenge task to verify domain name control in order to apply for a digital certificate. Of course, this embodiment can also periodically or as needed update the asymmetric key configured for the first device and the domain name server using implementation method 31 to update the private and public keys of the same key pair configured for the first device and the domain name server, thereby ensuring that a secure and reliable public key and corresponding private key can be used to verify the identity of the message sender in the future.

[0292] For example, when the first device no longer needs to use the previously configured asymmetric key, it can delete its stored private key and send a DNS update message to the domain name server to delete the public key that belongs to the same key pair as the private key configured on the domain name server. Subsequently, when the first device needs to use the key to verify messages, it can reconfigure the asymmetric key for itself and the domain name server through implementation method 31. This makes the key configured by the first device and the domain name server time-sensitive, thus avoiding security problems caused by key leakage when using the same key to verify messages for a long time.

[0293] Based on implementation method 32, a symmetric key is configured for the first device and the domain name server using a verification key-based method. Therefore, when the first device, which needs to apply for a digital certificate, performs a DNS-based challenge, it can use this symmetric key to prove its identity to the domain name server during the process of configuring specific DNS records in the domain name server. After successful authentication, the verification of the first device's domain name control can be further performed based on the operation permissions corresponding to the symmetric key. This process can be referred to... Figure 8 The method shown will not be elaborated further. For a detailed explanation of the operation permissions corresponding to the symmetric key, please refer to the description of the operation permissions corresponding to the first symmetric key above; it will not be repeated here.

[0294] It should be noted that, after the symmetric key negotiated between the first device and the domain name server through implementation method 32 in this embodiment, this symmetric key can be used to authenticate the message sender whenever the first device needs to perform a DNS-based challenge task to verify domain name control in order to apply for a digital certificate. Of course, this embodiment can also periodically or as needed use implementation method 32 to update the symmetric key configured between the first device and the domain name server, thereby ensuring that a secure and reliable symmetric key can be used to verify the identity of the message sender in the future.

[0295] For example, when the first device no longer needs to use the previously configured asymmetric key, it can delete its stored symmetric key and send a TKEY request to the domain name server to request the deletion of the symmetric key. Subsequently, when the first device needs to use the key to verify messages, it can reconfigure the symmetric key for itself and the domain name server through implementation method 32. This makes the keys configured by the first device and the domain name server time-sensitive, thus avoiding security problems caused by key leakage when using the same key to verify messages for a long time.

[0296] To deepen the understanding of Embodiment 3, a further description is provided below with specific examples.

[0297] Taking the example where the first device is an NF in a communication network, the network management system is an OAM system, the certificate management server is a CA server, and the OAM system is pre-authorized to modify the DNS records of authoritative name servers, combined with... Figure 7 and Figure 9 ,refer to Figure 10 , Figure 10 This illustration shows another flowchart of a domain name control verification method provided in an embodiment of this application. In this method, NF acts as an ACME client, and the CA server acts as an ACME server. The method includes the following steps 501 to 213.

[0298] Step 501: The OAM system obtains the third public key of the authoritative domain name server and the configuration required to create the NF. The configuration includes the NF instanceID, the IP address of the NF, the domain name, and the second private key of the NF.

[0299] For detailed explanations of the third public key and the second private key, please refer to the relevant descriptions in Implementation Methods 31 and 32 above, which will not be repeated here.

[0300] Step 502: The OAM system sends the above configuration to the network node so that the network node can create an NF according to the configuration, and the NF configuration obtains the second private key and the third public key.

[0301] Step 503: The OAM system sends the DNS record of NF to the authoritative domain name server. The DNS record includes the A / AAAA record of the IP address of NF, the second public key and the ID of the second public key, so that the authoritative domain name server can configure the DNS record of NF, the second public key and the ID of the second public key, and configure the corresponding operation permissions for the second public key.

[0302] For a detailed explanation of the second public key, please refer to the relevant description in Implementation Method 31 above, which will not be repeated here.

[0303] Step 504: NF sends a negotiation message to the authoritative domain name server. The negotiation message contains the parameters required to negotiate the first symmetric key and the third verification information, which contains a signature generated based on the second private key.

[0304] The negotiation message can reuse the format of the DNS query message, and there are no restrictions on this.

[0305] Step 505: The authoritative domain name server receives the negotiation message, searches for the KEY record containing the key ID in the third verification information in the negotiation message, and verifies the third verification information based on the value of the KEY record (i.e. the second public key) to determine whether to perform the operation based on the first symmetric key in the negotiation message.

[0306] When the authoritative domain name server verifies the third verification information using the second public key and the verification is successful, it checks the operation permissions corresponding to the second public key to determine whether to perform the operation of determining the first symmetric key based on the negotiation message.

[0307] Step 506: When the authoritative domain name server determines that the operation of determining the first symmetric key based on the negotiation message is permitted, the domain name server determines the first symmetric key based on the information carried in the negotiation message, and returns a response message of the negotiation message to the NF, the response message including a signature generated based on the third private key.

[0308] The domain name server is configured with a third private key that belongs to the same key pair as the third private key described in step 501. The description of the domain name server configuring the third private key can be found in the relevant description in implementation method 32, and will not be repeated here.

[0309] Step 507: NF receives the response message, searches for the third public key identified by the key ID in its own configuration based on the key ID contained in the fourth verification information in the response message, and verifies the fourth verification information based on the third public key to determine whether to perform the operation of determining the first symmetric key based on the response message.

[0310] It can be seen that steps 501 to 507 can be regarded as the process of configuring the key.

[0311] after, Figure 10 The method described above executes steps 404 to 407, followed by steps 210 to 213, to enable the NF to obtain a digital certificate from the CA server. Steps 404 to 213 are the processes of verifying domain name control and issuing the digital certificate.

[0312] In summary, the methods described in Examples 1 to 3 can all verify the domain name control of the first device, filling the gap in the process of verifying the domain name control of the digital certificate requester by configuring a specific DNS record (i.e., the DNS record corresponding to the DNS-based challenge) in the domain name server.

[0313] The above mainly describes the solution provided by the embodiments of this application from a methodological perspective.

[0314] To achieve the above functions, refer to Figure 11 , Figure 11 This diagram illustrates the structure of a domain name control verification device according to an embodiment of this application. The domain name control verification device 1100 is applied to a network element in a communication network, such as a first device. The domain name control verification device 1100 is used to execute the domain name control verification method described above, for example, to execute... Figure 6 or Figure 8 The portion of the method shown that is executed by the first device, or executed as... Figure 7 , Figure 9 or Figure 10 The part executed by NF. The domain name control verification device 1100 may include an acquisition unit 1101 and a sending unit 1102.

[0315] The acquisition unit 1101 is used to acquire a first task, which is a task issued by the certificate management server when the first device applies for a digital certificate. The first task instructs the verification of whether the first device has control over a first domain name, where the first domain name is the domain name of the first device. The sending unit 1102 is used to respond to the first task by sending a DNS update request to the domain name server. The DNS update request includes update operation information and first verification information. The first verification information is used to verify whether the update operation indicated by the update operation information is allowed. The update operation is the addition of a target DNS record to the domain name server, and the target DNS record is determined based on the parameters of the first task. The sending unit 1102 is also used to send a task response to the certificate management server. The task response instructs the query of the target DNS record in the domain name server, and the result of the query operation is used to indicate whether the first device has control over the first domain name.

[0316] As an example, combined Figure 6 The acquisition unit 1101 can be used to execute step 101, and the sending unit 1102 can be used to execute step 102.

[0317] Optionally, the obtaining unit 1101 is further configured to obtain a first key before sending a DNS update request to the domain name server, the first key being used to generate first verification information. Wherein, if the first key is a first private key in an asymmetric key, the first verification information includes a signature of the DNS update request generated based on the first private key; or, if the first key is a first symmetric key, the first verification information includes a MAC address of the DNS update request generated based on the first symmetric key.

[0318] Optionally, the first key is a first private key, and the acquisition unit 1101 includes: a generation unit 1103, used to generate a key pair, the key pair including a first private key and a first public key, the first public key being used to verify the signature generated based on the first private key; or, a receiving unit 1104, used to receive the first private key.

[0319] Optionally, the first private key is generated by the first device, and the sending unit 1102 is further used to send a configuration message containing the first public key to the domain name server. The configuration message also includes second verification information, which is used to verify whether it is allowed to add a DNS record for storing the first public key. The second verification information includes a signature of the configuration message generated based on the second private key, or the second verification information includes the MAC of the configuration message generated based on the second symmetric key.

[0320] Optionally, the first key is a first symmetric key, and the acquisition unit 1101 includes: a generation unit 1103 for generating the first symmetric key; or a receiving unit 1104 for receiving the first symmetric key.

[0321] Alternatively, the sending unit 1102 is further configured to send a negotiation message for negotiating a first symmetric key to the domain name server. The negotiation message also includes third verification information, which is used to verify whether the operation of determining the first symmetric key based on the negotiation message is performed. The third verification information includes a signature of the negotiation message generated based on the second private key, or the third verification information includes the MAC of the negotiation message generated based on the second symmetric key. The receiving unit 1104 is further configured to receive a response message of the negotiation message returned by the domain name server. The response message includes fourth verification information, which is used to verify whether the operation of determining the first symmetric key based on the response message is performed. The fourth verification information includes a signature of the response message generated based on the third private key, or the fourth verification information includes the MAC of the response message generated based on the second symmetric key. The obtaining unit 1101 is specifically configured to determine the first symmetric key based on the response message if the fourth verification information is verified successfully.

[0322] Optionally, the target DNS record includes a record type, a target subdomain, and a value. Before sending a DNS update request to the domain name server, the domain name control verification device 1100 further includes: a determining unit 1105, configured to determine the record type and the target subdomain based on the task type of the first task and the first domain name, wherein the target subdomain is the subdomain among the subdomains included in the first domain name that corresponds to the task type of the first task; and to calculate the value of the target DNS record according to the parameters of the first task.

[0323] Optionally, the acquisition unit 1101 is also used to acquire a digital certificate from a certificate management server when the first device has control over the first domain name.

[0324] For a detailed description of the above-mentioned optional methods, please refer to the foregoing method embodiments, which will not be repeated here. Furthermore, the explanation of any of the domain name control verification devices 1100 provided above, as well as the description of their beneficial effects, can be found in the corresponding method embodiments described above, and will not be repeated here.

[0325] refer to Figure 12 , Figure 12 This illustration shows a schematic diagram of another domain name control verification device provided in an embodiment of this application. The domain name control verification device 1200 is applied to a domain name server and is used to execute the domain name control verification method described above, for example, to execute... Figure 6 or Figure 8 The part of the method shown that is executed by the domain name server, or executed as follows: Figure 7 , Figure 9 or Figure 10 The part executed by the authoritative domain name server. The domain name control verification device 1200 may include a receiving unit 1201, a verification unit 1202, and an adding unit 1203.

[0326] Receiving unit 1201 is used to receive a DNS update request sent by the first device. The DNS update request includes update operation information and first verification information. The update operation information indicates that the update operation is to add a target DNS record to the domain name server. The target DNS record is determined based on the parameters of a first task, which is a task issued by the certificate management server when the first device applies for a digital certificate. The first task indicates whether the first device has control over the first domain name. The first device is a network element in the communication network. Verification unit 1202 is used to verify the first verification information to determine whether the update operation is allowed. Adding unit 1203 is used to add the target DNS record if the update operation is allowed. The target DNS record is used to verify whether the first device has control over the first domain name.

[0327] As an example, combined Figure 6 The receiving unit 1201 and the verification unit 1202 can be used to perform step 103, and the adding unit 1203 can be used to perform step 104.

[0328] Optionally, the domain name control verification device 1200 further includes: an acquisition unit 1204, used to acquire a second key before verifying the first verification information; the second key is used to verify the first verification information; wherein, if the second key is a first public key, the first verification information includes a signature of a DNS update request generated based on a first private key, and the first private key and the first public key belong to the same key pair; or, if the second key is a first symmetric key, the first verification information includes a MAC of a DNS update request generated based on the first symmetric key.

[0329] Optionally, the domain name control verification device 1200 further includes a configuration unit 1205, used to configure the operation permissions corresponding to the second key, the operation permissions corresponding to the second key including the operations allowed to be performed after information verification is performed through the second key and the verification is successful.

[0330] Optionally, the second key is the first public key. The receiving unit 1201 is further configured to receive the first public key sent by the network management system, which manages and / or maintains the network where the first device resides. Alternatively, the receiving unit 1201 is further configured to receive a configuration message containing the first public key sent by the first device. The configuration message also includes second verification information, which includes a signature of the configuration message generated based on the second private key, or the second verification information includes a MAC address of the configuration message generated based on the second symmetric key. The verification unit 1202 is further configured to verify the second verification information using a verification key to determine whether the first public key is configured. The obtaining unit 1204 is specifically configured to store the first public key if it is determined that the first public key is configured.

[0331] Optionally, the second key is the first symmetric key. The receiving unit 1201 is further configured to receive the first symmetric key sent by the network management system, which manages and / or maintains the network where the first device resides. Alternatively, the receiving unit 1201 is further configured to receive a negotiation message sent by the first device for negotiating the first symmetric key. The negotiation message further includes third verification information, which includes a signature of the negotiation message generated based on the second private key, or the third verification information includes the MAC address of the negotiation message generated based on the second symmetric key. The verification unit 1202 is further configured to verify the third verification message using a verification key to determine whether to perform the operation of determining the first symmetric key based on the negotiation message. The obtaining unit 1204 is specifically configured to determine the first symmetric key based on the negotiation message if the third verification information passes verification.

[0332] Optionally, the domain name control verification device 1200 further includes: a sending unit 1206, configured to return a response message of the negotiation message to the first device, the response message including fourth verification information, the fourth verification information being used to verify whether the operation of determining the first symmetric key based on the response message is performed, the fourth verification information including a signature of the response message generated based on the third private key, or the fourth verification information including the MAC of the response message generated based on the second symmetric key.

[0333] Optionally, the acquisition unit 1204 is further configured to acquire the verification key before verifying the verification information using the verification key. The configuration unit 1205 is configured to configure the operation permissions corresponding to the verification key, which include operations allowed to be performed after the information is verified using the verification key and the verification is successful.

[0334] For a detailed description of the above-mentioned optional methods, please refer to the foregoing method embodiments, which will not be repeated here. Furthermore, the explanation of any of the domain name control verification devices 1200 provided above, as well as the description of their beneficial effects, can be found in the corresponding method embodiments described above, and will not be repeated here.

[0335] like Figure 13 As shown, Figure 13 This illustration shows a schematic diagram of another domain name control verification device provided in an embodiment of this application. The domain name control verification device 1300 can be applied to a first device (such as a network element in a communication network) that needs to apply for a digital certificate, and is used to execute the method described in the embodiments of this application (such as...). Figure 6 or Figure 8 The portion of the method shown is performed by the first device. The domain name control verification device 1300 can also be applied to a domain name server and used to perform the method described in the embodiments of this application. Figure 6 or Figure 8 The part of the method shown is executed by the domain name server.

[0336] The domain name control verification device 1300 may include a transceiver unit 1301 and a processing unit 1302. The transceiver unit 1301 is used to perform operations related to receiving and / or sending in the method provided in the embodiments of this application, while the processing unit 1302 is used to perform other operations besides those related to receiving and / or sending in the method of the embodiments of this application. Explanations of the domain name control verification device 1300 and descriptions of its beneficial effects can be found in the corresponding method embodiments described above, and will not be repeated here.

[0337] Those skilled in the art will readily recognize that, based on the units and algorithm steps described in conjunction with the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is implemented in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0338] It should be noted that, Figure 11 , Figure 12 as well as Figure 13 The module / unit division shown is illustrative and represents only one logical functional division; in actual implementation, other division methods are possible. For example, two or more functions can be integrated into a single processing module. The functions implemented by the integrated modules described above can be implemented either in hardware or as software functional modules.

[0339] This application also provides a computing device, which can be implemented as a network element (such as a first device, including physical network elements and / or virtualized network elements), a domain name server (such as an authoritative domain name server), or other network devices in a communication network, and is used to implement some or all of the functions in the method provided in this application.

[0340] refer to Figure 14 This application provides a schematic diagram of the hardware structure of a computing device. For example... Figure 14 As shown, the computing device 1400 includes a processor 1401, a memory 1402, a communication interface 1403, and a bus 1404. The processor 1401, memory 1402, and communication interface 1403 are interconnected via the bus 1404. The computing device 1400 also includes an input / output interface 1405, which is interconnected with the processor 1401, memory 1402, and communication interface 1403 via the bus 1404.

[0341] Processor 1401 may include a general-purpose processor and / or a dedicated hardware chip. A general-purpose processor may include a central processing unit (CPU), a microprocessor, or a graphics processing unit (GPU). The CPU may be a single-core processor or a multi-core processor. A dedicated hardware chip is a high-performance processing hardware module. Dedicated hardware chips include at least one of the following: digital signal processing (DSP), data processing unit (DPU), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, neural processing unit (NPU), tensor processing unit (TPU), artificial intelligence (AI) chip, or network processor (NP). Processor 1401 may also be an integrated circuit chip with signal processing capabilities. In the implementation process, some or all of the functions of the method provided in the embodiments of this application can be accomplished by the integrated logic circuit of the hardware in the processor 1401 or by instructions in the form of software.

[0342] Memory 1402 is used to store computer programs, including operating system 1402a and executable code (i.e., program instructions) 1402b. Memory 1402 is, for example, read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, or other types of static storage devices capable of storing static information and instructions; it is also such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), and synchronous linked dynamic random access memory (SDRAM). DRAM (SLDRAM) or other types of dynamic storage devices capable of storing information and instructions, such as read-only optical discs or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired executable code in the form of instructions or data structures and accessible by a computer, but not limited thereto. For example, memory 1402 is used to store DNS records, etc. Memory 1402 may exist independently and be connected to processor 1401 via bus 1404. Alternatively, memory 1402 and processor 1401 may be integrated together. Memory 1402 can store executable code. When the executable code stored in memory 1402 is executed by processor 1401, processor 1401 performs some or all of the functions of the method provided in the embodiments of this application. Please refer to the relevant descriptions in the foregoing embodiments for the implementation of the processor 1401 executing this process. Memory 1402 may also include software modules and data required by other running processes, such as operating systems.

[0343] Communication interface 1403 uses a transceiver module, such as, but not limited to, a transceiver, to enable communication with other devices or communication networks. For example, communication interface 1403 can be any one or any combination of the following devices: communication interfaces (such as Ethernet interfaces), wireless network cards, and other devices with network access capabilities. Communication interface 1403 includes a receiving unit for receiving data / messages and a sending unit for sending data / messages.

[0344] Bus 1404 is any type of communication bus used to interconnect internal devices (e.g., memory 1402, processor 1401, communication interface 1403) of computing device 1400. For example, a system bus. This embodiment illustrates the interconnection of the aforementioned devices within computing device 1400 via bus 1404. Optionally, the aforementioned devices within computing device 1400 can also communicate with each other using other connection methods besides bus 1404; for example, the aforementioned devices within computing device 1400 can be interconnected via internal logic interfaces.

[0345] Input / output interface 1405 is used to realize human-computer interaction between a user and computing device 1400. For example, it enables text or voice interaction between the user and computing device 1400. Input / output interface 1405 includes an input interface for the user to input information to computing device 1400, and an output interface for the computing device 1400 to output information to the user. As an example, the input interface includes, but is not limited to, a touchscreen, keyboard, mouse, or microphone, and the output interface includes, but is not limited to, a display screen, speaker, etc. The touchscreen, keyboard, or mouse is used to input text / image information, the microphone is used to input voice information, the display screen is used to output text / image information, and the speaker is used to output voice information. Exemplarily, in this embodiment, computing device 1400 receives a manually configured key from the user through the input interface in input / output interface 1405.

[0346] It should be noted that the aforementioned devices can be disposed on separate chips, or at least partially or entirely on the same chip. Whether to dispose of the devices independently on different chips or integrate them on one or more chips often depends on the needs of the product design. This application does not limit the specific implementation of the aforementioned devices. Furthermore, the descriptions of the processes corresponding to the various figures above each have their own emphasis; for parts of a process not described in detail in one figure, please refer to the relevant descriptions of other processes.

[0347] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented, in whole or in part, as a computer program product. The computer program product providing the program development platform includes one or more computer instructions, which, when loaded and executed on the computing device 1400, implement some or all of the functions of the methods provided in the embodiments of this application.

[0348] Furthermore, computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium stores computer program instructions that provide a program development platform.

[0349] As an example, combined Figure 11 , Figure 11 The functions implemented by the generation unit 1103 and the determination unit 1105 can be achieved through Figure 14 Processor 1401 in the middle executes Figure 14 The program code is implemented in memory 1402. Figure 11 The functions implemented by the transmitting unit 1102 and the receiving unit 1104 can be achieved through Figure 14 The communication interface 1403 is implemented in the system. Figure 11 The function implemented by the acquisition unit 1101 in the middle can be achieved through Figure 14 Processor 1401 in the middle executes Figure 14 The program code in memory 1402 is implemented, or through Figure 14 The communication interface 1403 is implemented in the system.

[0350] As another example, combined Figure 12 , Figure 11 The functions implemented by the receiving unit 1201 and the transmitting unit 1206 can be achieved through Figure 14 The communication interface 1403 is implemented in the system. Figure 12 The functions implemented by the verification unit 1202, the adding unit 1203, and the configuration unit 1205 can be achieved through... Figure 14 Processor 1401 in the middle executes Figure 14 The program code is implemented in memory 1402. Figure 12 The function implemented by the acquisition unit 1204 can be achieved through Figure 14 Processor 1401 in the middle executes Figure 14 The program code in memory 1402 is implemented, or through Figure 14 The communication interface 1403 is implemented in the system.

[0351] As yet another example, combined with Figure 13 , Figure 13 The functions implemented by the transceiver unit 1301 in the middle can be achieved through Figure 14 The communication interface 1403 is implemented in the system. Figure 13 The functions implemented by the processing unit 1302 in the middle can be achieved through Figure 14 Processor 1401 in the middle executes Figure 14 The program code is implemented in memory 1402.

[0352] This application also provides a domain name control verification system, which includes a first device, a domain name server, and a certificate management server. The first device executes the portion of the method provided in this application that is executed by the first device, and the domain name server executes the portion of the method provided in this application that is executed by the domain name server, enabling the first device to configure a target DNS record in the domain name server. The target DNS record is determined based on parameters of a first task, which is a task issued by the certificate management server when the first device applies for a digital certificate. The first task instructs verification of whether the first device has control over a first domain name, where the first domain name is the domain name of the first device. The certificate management server queries the target DNS record in the domain name server and determines whether the first device has control over the first domain name based on the query result. Detailed descriptions can be found in the relevant descriptions in the above method embodiments and will not be repeated here.

[0353] This application also provides a computer-readable storage medium, which is a non-volatile computer-readable storage medium. The computer-readable storage medium includes computer program instructions. When the computer program instructions are executed by a processor, a computing device including the processor, or a computer system, the processor, the computing device including the processor, or the computer system performs the domain name control verification method provided in this application.

[0354] This application also provides a computer program product containing instructions that, when executed by a processor, a computing device including a processor, or a computer system, cause the processor, the computing device including a processor, or the computer system to implement the domain name control verification method provided in this application.

[0355] A computer system is a system with computational processing capabilities. A computer system generally includes a processor and memory. The processor retrieves and executes instructions stored in memory to enable the computer system to implement the domain name control verification method described above. Optionally, a computer system may also include at least one of an input interface or an output interface. The processor, memory, input interface, and output interface of the computer system are interconnected through internal connection paths.

[0356] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware, or by a program instructing the relevant hardware to implement them. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0357] It should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, data stored, data displayed, etc.) and signals involved in this application are all authorized by the user or fully authorized by all parties, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0358] This application also provides a chip that includes a processor for running program instructions or code. The chip or a device containing the chip can be used to execute the domain name control verification method provided in this application. Exemplarily, the chip further includes an input interface, an output interface, and a memory. The chip's input interface, output interface, processor, and memory are connected via internal interconnection paths. The memory in the chip stores program instructions or code executed by the processor, and the input and output interfaces are used for communication between the chip and other chips or devices.

[0359] In the embodiments of this application, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance. The term "at least one" refers to one or more, and the term "multiple" refers to at least two, unless otherwise expressly defined.

[0360] In this application, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent three cases: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this document generally indicates that the preceding and following related objects have an "or" relationship.

[0361] It should be understood that the terminology used in the description of the various examples herein is for the purpose of describing particular examples only and is not intended to be limiting. As used in the description of the various examples and the appended claims, the singular forms "a" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise.

[0362] It should be understood that determining B based on A does not mean determining B solely based on A; B can also be determined based on A and / or other information.

[0363] It should be understood that the term "comprising" (also known as "includes", "including", "comprises" and / or "comprising") as used in this specification specifies the presence of the stated features, integers, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0364] It should also be understood that, in the various embodiments of this application, the sequence number of each process does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0365] The above description is merely an optional embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the concept and principles of this application should be included within the protection scope of this application.

[0366] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the protection scope of the technical solutions of the embodiments of the present invention. < / key-domain> < / key-domain> < / key-domain> < / domain-to-validate> < / tkey-domain> < / domain-to-validate> < / client-specified-domain>

Claims

1. A method of verifying control of a domain name, characterized by, Applied to a first device, which is a network element in a communication network, the method includes: Obtain the first task, which is a task issued by the certificate management server when the first device applies for a digital certificate. The first task indicates whether the first device has control over the first domain name, and the first domain name is the domain name of the first device. In response to the first task, a DNS update request is sent to the domain name server. The DNS update request includes update operation information and first verification information. The first verification information is used to verify whether the update operation indicated by the update operation information is allowed to be executed. The update operation is to add a target DNS record to the domain name server. The target DNS record is determined based on the parameters of the first task. A task response is sent to the certificate management server, the task response being used to instruct the query of the target DNS record in the domain name server, and the result of the query operation being used to indicate whether the first device has control over the first domain name.

2. The method of claim 1, wherein, Before sending the DNS update request to the domain name server, the method further includes: Obtain the first key, which is used to generate the first verification information; Wherein, if the first key is the first private key in an asymmetric key, then the first verification information includes the signature of the DNS update request generated based on the first private key; or, if the first key is the first symmetric key, then the first verification information includes the Message Verification Code (MAC) of the DNS update request generated based on the first symmetric key.

3. The method of claim 2, wherein, The first key is the first private key, and obtaining the first key includes: Generate a key pair, the key pair including the first private key and the first public key, the first public key being used to verify the signature generated based on the first private key; or... Receive the first private key.

4. The method of claim 3, wherein, The first private key is generated by the first device, and the method further includes: A configuration message containing the first public key is sent to the domain name server. The configuration message also includes second verification information, which is used to verify whether the first public key is configured. The second verification information includes a signature of the configuration message generated based on the second private key, or the second verification information includes the MAC of the configuration message generated based on the second symmetric key.

5. The method of claim 2, wherein, The first key is the first symmetric key, and obtaining the first key includes: Generate the first symmetric key; or, Receive the first symmetric key; or... Send a negotiation message to the domain name server for negotiating the first symmetric key. The negotiation message further includes third verification information, which is used to verify whether to perform the operation of determining the first symmetric key based on the negotiation message. The third verification information includes a signature of the negotiation message generated based on the second private key, or the third verification information includes the MAC of the negotiation message generated based on the second symmetric key. The system receives a response message to the negotiation message returned by the domain name server. The response message includes fourth verification information, which is used to verify whether the operation of determining the first symmetric key based on the response message is performed. The fourth verification information includes a signature of the response message generated based on a third private key, or the fourth verification information includes a MAC of the response message generated based on a second symmetric key. If the fourth verification information is verified successfully, the first symmetric key is determined based on the response message.

6. The method according to any one of claims 1 to 5, characterized in that, The target DNS record includes a record type, a target subdomain, and a value. Before sending the DNS update request to the domain name server, the method further includes: Based on the task type of the first task and the first domain name, the record type and the target subdomain are determined, wherein the target subdomain is the subdomain that corresponds to the task type of the first task among the subdomains included in the first domain name; The value of the target DNS record is calculated based on the parameters of the first task.

7. The method according to any one of claims 1 to 6, characterized in that, The method further includes: When the first device has control over the first domain name, the digital certificate is obtained from the certificate management server.

8. A method for verifying domain name control, characterized in that, Applied to a domain name server, the method includes: The system receives a DNS update request sent by a first device. The DNS update request includes update operation information and first verification information. The update operation information indicates that the update operation is to add a target DNS record to the domain name server. The target DNS record is determined based on the parameters of a first task. The first task is a task issued by the certificate management server when the first device applies for a digital certificate. The first task indicates whether the first device has control over the first domain name. The first device is a network element in the communication network. The first verification information is verified to determine whether the update operation is allowed. If it is determined that the update operation is permitted, the target DNS record is added, which is used to verify whether the first device has control over the first domain name.

9. The method according to claim 8, characterized in that, Before verifying the first verification information, the method further includes: Obtain the second key; the second key is used to verify the first verification information; Wherein, if the second key is the first public key, then the first verification information includes the signature of the DNS update request generated based on the first private key, wherein the first private key and the first public key belong to the same key pair; or, if the second key is the first symmetric key, then the first verification information includes the message verification code (MAC) of the DNS update request generated based on the first symmetric key.

10. The method according to claim 9, characterized in that, The method further includes: Configure the operation permissions corresponding to the second key. The operation permissions corresponding to the second key include the operations that are allowed to be performed after the information is verified by the second key and the verification is successful.

11. The method according to claim 9 or 10, characterized in that, The second key is the first public key, and obtaining the second key includes: The device receives the first public key sent by a network management system, which manages and / or maintains the network in which the first device resides; or... The system receives a configuration message containing the first public key sent by the first device. The configuration message further includes second verification information, which includes a signature of the configuration message generated based on the second private key, or the second verification information includes the MAC of the configuration message generated based on the second symmetric key. The second verification information is verified using a verification key to determine whether the first public key is configured. If the configuration of the first public key is determined, the first public key is stored.

12. The method according to claim 9 or 10, characterized in that, The second key is the first symmetric key, and obtaining the second key includes: The device receives the first symmetric key sent by a network management system, which manages and / or maintains the network in which the first device resides; or... The system receives a negotiation message sent by the first device for negotiating the first symmetric key. The negotiation message further includes third verification information, which includes a signature of the negotiation message generated based on the second private key, or the third verification information includes a MAC of the negotiation message generated based on the second symmetric key. The third verification message is verified by verifying the verification key to determine whether to perform the operation of determining the first symmetric key based on the negotiation message; If the third verification information passes the verification, the first symmetric key is determined based on the negotiation message.

13. The method according to claim 12, characterized in that, The method further includes: A response message to the first device is returned, the response message including fourth verification information, the fourth verification information being used to verify whether the operation of determining the first symmetric key based on the response message has been performed, the fourth verification information including a signature of the response message generated based on a third private key, or the fourth verification information including a MAC of the response message generated based on a second symmetric key.

14. The method according to any one of claims 11 to 13, characterized in that, Before verifying the verification information using the verification key, the method further includes: Obtain the verification key; Configure the operation permissions corresponding to the verification key. The operation permissions corresponding to the verification key include the operations that are allowed to be performed after the information is verified by the verification key and the verification is successful.

15. A domain name control verification device, characterized in that, Applied to a first device, which is a network element in a communication network, the device includes: The acquisition unit is used to acquire a first task, which is a task issued by the certificate management server when the first device applies for a digital certificate. The first task indicates whether the first device has control over a first domain name, and the first domain name is the domain name of the first device. The sending unit is configured to send a DNS update request to the domain name server in response to the first task. The DNS update request includes update operation information and first verification information. The first verification information is used to verify whether the update operation indicated by the update operation information is allowed to be executed. The update operation is to add a target DNS record to the domain name server. The target DNS record is determined based on the parameters of the first task. The sending unit is further configured to send a task response to the certificate management server, the task response being used to instruct the query of the target DNS record in the domain name server, and the result of the query operation being used to indicate whether the first device has control over the first domain name.

16. The apparatus according to claim 15, characterized in that, The acquisition unit is further configured to acquire a first key before sending the DNS update request to the domain name server, the first key being used to generate the first verification information; Wherein, if the first key is the first private key in an asymmetric key, then the first verification information includes the signature of the DNS update request generated based on the first private key; or, if the first key is the first symmetric key, then the first verification information includes the Message Verification Code (MAC) of the DNS update request generated based on the first symmetric key.

17. The apparatus according to claim 16, characterized in that, The first key is the first private key, and the acquisition unit includes: A generation unit is configured to generate a key pair, the key pair including a first private key and a first public key, wherein the first public key is used to verify a signature generated based on the first private key; or... A receiving unit is used to receive the first private key.

18. The apparatus according to claim 17, characterized in that, The first private key is generated by the first device. The sending unit is further configured to send a configuration message containing the first public key to the domain name server. The configuration message further includes second verification information, which is used to verify whether the first public key is configured. The second verification information includes a signature of the configuration message generated based on the second private key, or the second verification information includes the MAC of the configuration message generated based on the second symmetric key.

19. The apparatus according to claim 16, characterized in that, The first key is the first symmetric key, and the acquisition unit includes: A generation unit is used to generate the first symmetric key; or... A receiving unit is configured to receive the first symmetric key; or, The sending unit is further configured to send a negotiation message to the domain name server for negotiating the first symmetric key. The negotiation message further includes third verification information, which is used to verify whether the operation of determining the first symmetric key based on the negotiation message is performed. The third verification information includes a signature of the negotiation message generated based on the second private key, or the third verification information includes the MAC of the negotiation message generated based on the second symmetric key. The receiving unit is further configured to receive a response message of the negotiation message returned by the domain name server. The response message includes fourth verification information, which is used to verify whether to perform the operation of determining the first symmetric key based on the response message. The fourth verification information includes a signature of the response message generated based on a third private key, or the fourth verification information includes a MAC of the response message generated based on a second symmetric key. The acquisition unit is specifically used to determine the first symmetric key based on the response message when the fourth verification information is verified successfully.

20. The apparatus according to any one of claims 15 to 19, characterized in that, The target DNS record includes a record type, a target subdomain, and a value. Before sending the DNS update request to the domain name server, the apparatus further includes: The determining unit is configured to determine the record type and the target subdomain based on the task type of the first task and the first domain name, wherein the target subdomain is a subdomain among the subdomains included in the first domain name that corresponds to the task type of the first task; and to calculate the value of the target DNS record according to the parameters of the first task.

21. The apparatus according to any one of claims 15 to 20, characterized in that, The acquisition unit is further configured to acquire the digital certificate from the certificate management server when the first device has control over the first domain name.

22. A domain name control verification device, characterized in that, Applied to a domain name server, the device includes: The receiving unit is configured to receive a DNS update request sent by the first device. The DNS update request includes update operation information and first verification information. The update operation information indicates that the update operation is to add a target DNS record to the domain name server. The target DNS record is determined based on the parameters of a first task. The first task is a task issued by the certificate management server when the first device applies for a digital certificate. The first task indicates whether the first device has control over the first domain name. The first device is a network element in the communication network. A verification unit is configured to verify the first verification information to determine whether the update operation is permitted. An adding unit is configured to add the target DNS record when it is determined that the update operation is permitted, the target DNS record being used to verify whether the first device has control over the first domain name.

23. The apparatus according to claim 22, characterized in that, The device further includes: The acquisition unit is configured to acquire a second key before verifying the first verification information; the second key is used to verify the first verification information. Wherein, if the second key is the first public key, then the first verification information includes the signature of the DNS update request generated based on the first private key, wherein the first private key and the first public key belong to the same key pair; or, if the second key is the first symmetric key, then the first verification information includes the message verification code (MAC) of the DNS update request generated based on the first symmetric key.

24. The apparatus according to claim 23, characterized in that, The device further includes: The configuration unit is used to configure the operation permissions corresponding to the second key. The operation permissions corresponding to the second key include the operations that are allowed to be executed after the information is verified by the second key and the verification is successful.

25. The apparatus according to claim 23 or 24, characterized in that, The second key is the first public key. The receiving unit is further configured to receive the first public key sent by the network management system, wherein the network management system is configured to manage and / or maintain the network in which the first device resides; or, The receiving unit is further configured to receive a configuration message containing the first public key sent by the first device. The configuration message further includes second verification information, which includes a signature of the configuration message generated based on the second private key, or the second verification information includes a MAC of the configuration message generated based on the second symmetric key. The verification unit is further configured to verify the second verification information using a verification key to determine whether the first public key is configured. The acquisition unit is specifically used to store the first public key when it is determined that the first public key is configured.

26. The apparatus according to claim 23 or 24, characterized in that, The second key is the first symmetric key. The receiving unit is further configured to receive the first symmetric key sent by the network management system, wherein the network management system is configured to manage and / or maintain the network in which the first device resides; or... The receiving unit is further configured to receive a negotiation message sent by the first device for negotiating the first symmetric key, the negotiation message further including third verification information, the third verification information including a signature of the negotiation message generated based on the second private key, or the third verification information including a MAC of the negotiation message generated based on the second symmetric key; The verification unit is further configured to verify the third verification message using a verification key to determine whether to perform the operation of determining the first symmetric key based on the negotiation message; The acquisition unit is specifically used to determine the first symmetric key based on the negotiation message when the third verification information is verified successfully.

27. The apparatus according to claim 26, characterized in that, The device further includes: A sending unit is configured to return a response message of the negotiation message to the first device. The response message includes fourth verification information, which is used to verify whether the operation of determining the first symmetric key based on the response message has been performed. The fourth verification information includes a signature of the response message generated based on a third private key, or the fourth verification information includes a MAC of the response message generated based on a second symmetric key.

28. The apparatus according to any one of claims 22 to 27, characterized in that, The device also includes a configuration unit. The acquisition unit is further configured to acquire the verification key before verifying the verification information using the verification key; The configuration unit is used to configure the operation permissions corresponding to the verification key. The operation permissions corresponding to the verification key include operations that are allowed to be performed after information verification is performed through the verification key and the verification is successful.

29. A domain name control verification device, characterized in that, include: The device includes a memory, a communication interface, and one or more processors, the one or more processors receiving or transmitting data through the communication interface, the one or more processors being configured to read program instructions stored in the memory to perform the method as described in any one of claims 1 to 14.

30. A domain name control verification system, characterized in that, include: The first device, the domain name server, and the certificate management server; The first device adds a target domain name service DNS record by executing the method as described in any one of claims 1 to 7, and the domain name server adds a target domain name service DNS record by executing the method as described in any one of claims 8 to 14; the target DNS record is determined based on parameters of a first task, which is a task issued by the certificate management server when the first device applies for a digital certificate, and the first task instructs verification of whether the first device has control over a first domain name, where the first domain name is the domain name of the first device. The certificate management server is used to query the target DNS record in the domain name server and determine whether the first device has control over the first domain name based on the result of the query operation.

31. A computer program product containing instructions, characterized in that, When the instructions are executed by a processor, the processor or a device including the processor performs the method as described in any one of claims 1 to 14.

32. A computer-readable storage medium, characterized in that, It includes computer program instructions, which, when executed by a processor, cause the processor or a device including the processor to perform the method as described in any one of claims 1 to 14.

Images