CN111953681A - DNS identity authentication method and terminal - Google Patents
DNS identity authentication method and terminal Download PDFInfo
- Publication number
- CN111953681A CN111953681A CN202010802713.5A CN202010802713A CN111953681A CN 111953681 A CN111953681 A CN 111953681A CN 202010802713 A CN202010802713 A CN 202010802713A CN 111953681 A CN111953681 A CN 111953681A
- Authority
- CN
- China
- Prior art keywords
- client
- dns
- executing
- target domain
- identity
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/45—Network directories; Name-to-address mapping
- H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
- H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0876—Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computer Security & Cryptography (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Power Engineering (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Information Transfer Between Computers (AREA)
Abstract
The invention provides a DNS identity authentication method and a terminal, which receive a DNS request based on HTTPS, wherein the DNS request comprises a client identity token and a target domain; judging whether the target domain is a local domain, if so, judging whether the client identity token meets a preset condition, if so, packing the DNS request, and issuing the packed DNS request to a target server corresponding to the target domain, so that the target server can authenticate the client or directly return to an actual address corresponding to the target domain; according to the DNS identity authentication method and the terminal, the right of identifying the client by the identity token is issued to the client, the identity of the client is verified when the target domain accessed by the client is a local domain, and the corresponding actual address is returned after verification, so that the safety of the local domain is improved.
Description
Technical Field
The invention relates to the field of webpage access security, in particular to a DNS identity authentication method and a terminal.
Background
The DNS is an internet-based service, which is a distributed database service that maps domain names and IP addresses to each other, and resolves domain names to corresponding IP addresses, so that people can access the internet more conveniently, DNS requests occur almost every moment, DNS security is more and more emphasized in this year, and secure DNS query methods such as DNS over HTTPS and DNS over TLS are becoming popular.
Most of the existing identity authentication methods employ account passwords, Time-based One-Time passwords (One-Time passwords based on a timestamp algorithm), hardware tokens or biometric features for login, and after the authentication is passed, cookies are stored in the client or Session sessions are temporarily stored in the client so as to achieve the purpose of identifying the corresponding identity of the user instance. Or after logging in, SSO (unified identity authentication system) shares the stored Cookie or Session with other trust systems.
Session and Cookie are based on the security of validity period, and expiration means that identity is invalid and needs to be re-authenticated, and in a system implementing zero trust security, the need to establish access means that trust needs to be realized. However, the system implementing zero trust security should not expose itself to authenticate the user before the user is not authenticated and trusted, but needs to authenticate the user by using an external authentication system, and the user needs to go to the external system to log in for authentication before accessing the target system. When a user accesses a plurality of target services, the user needs to jump between a target system and an authentication system repeatedly, the invasion to the user access flow is large, the operation is complicated, the user experience is torn, the account password is repeatedly typed in and logged in the authentication system, the risk of leakage of the account password in the social engineering safety sense is increased, the SSO (unified identity authentication system) solves the problem that identity authentication logging needs to be carried out repeatedly among a plurality of systems, the account password is still needed, and an additional logging flow is still added in the user access flow.
Disclosure of Invention
The technical problem to be solved by the invention is as follows: the DNS identity authentication method and the terminal are provided, so that the identity of a user can be verified when the user accesses a domain name, and the user is not sensitive.
In order to solve the technical problems, the invention adopts a technical scheme that:
a DNS identity authentication method comprises the following steps:
s1, receiving a DNS request based on HTTPS, wherein the DNS request comprises a client identity token and a target domain;
s2, judging whether the target domain is a local domain, if so, judging whether the client identity token meets a preset condition, if so, executing a step S3, otherwise, directly returning to an actual address corresponding to the target domain;
s3, packing the DNS request, and sending the packed DNS request to a target server corresponding to the target domain, so that the target server can authenticate the client.
In order to solve the technical problem, the invention adopts another technical scheme as follows:
a DNS identity authentication terminal comprising a memory, a processor and a computer program stored on the memory and executable on the processor, the processor implementing the following steps when executing the computer program:
s1, receiving a DNS request based on HTTPS, wherein the DNS request comprises a client identity token and a target domain;
s2, judging whether the target domain is a local domain, if so, judging whether the client identity token meets a preset condition, if so, executing a step S3, otherwise, directly returning to an actual address corresponding to the target domain;
s3, packing the DNS request, and sending the packed DNS request to a target server corresponding to the target domain, so that the target server can authenticate the client.
The invention has the beneficial effects that: when a client sends a DNS request based on HTTPS, a client identity token corresponding to the client identity token is carried in the DNS request, when the DNS over HTTPS server receives the DNS request, whether a target domain is a local domain corresponding to the client or not is judged, if yes, permission judgment is carried out on the client according to the identity token and preset conditions, only the DNS request of the client meeting the preset conditions is packaged and sent to the target server, the target server authenticates the client according to the packaged DNS request sent by the DNS over HTTPS server, the token is carried in the DNS request, a user using the client does not need to input a password by himself, the permission authentication process of the client is completely invisible to the user, the safety of DNS access is improved, and the use feeling of the user is not influenced.
Drawings
Fig. 1 is a flowchart illustrating steps of a DNS identity authentication method according to an embodiment of the present invention;
fig. 2 is a schematic structural diagram of a DNS identity authentication terminal according to an embodiment of the present invention;
FIG. 3 is a schematic diagram of setting a token at a client according to an embodiment of the present invention;
FIG. 4 is a schematic structural diagram of a DNS over HTTPS server according to an embodiment of the present invention;
FIG. 5 is a flow chart of DNS identity authentication according to an embodiment of the present invention;
description of reference numerals:
1. a DNS identity authentication terminal; 2. a processor; 3. a memory.
Detailed Description
In order to explain technical contents, achieved objects, and effects of the present invention in detail, the following description is made with reference to the accompanying drawings in combination with the embodiments.
Referring to fig. 1 and fig. 3 to 5, a DNS identity authentication method includes the steps of:
s1, receiving a DNS request based on HTTPS, wherein the DNS request comprises a client identity token and a target domain;
s2, judging whether the target domain is a local domain, if so, judging whether the client identity token meets a preset condition, if so, executing a step S3, otherwise, directly returning to an actual address corresponding to the target domain;
s3, packing the DNS request, and sending the packed DNS request to a target server corresponding to the target domain, so that the target server can authenticate the client.
From the above description, the beneficial effects of the present invention are: when a client sends a DNS request based on HTTPS, a client identity token corresponding to the client identity token is carried in the DNS request, when the DNS over HTTPS server receives the DNS request, whether a target domain is a local domain corresponding to the client or not is judged, if yes, permission judgment is carried out on the client according to the identity token and preset conditions, only the DNS request of the client meeting the preset conditions is packaged and sent to the target server, the target server authenticates the client according to the packaged DNS request sent by the DNS over HTTPS server, the token is carried in the DNS request, a user using the client does not need to input a password by himself, the permission authentication process of the client is completely invisible to the user, the safety of DNS access is improved, and the use feeling of the user is not influenced.
Further, the S1 is preceded by:
generating a unique identifier corresponding to a client, and storing the corresponding relation between the client and the unique identifier in a preset database;
and generating the client identity token according to the unique identifier, and issuing the client identity token to the client.
According to the above description, the identity token is generated and issued for each client, and the user only needs to perform corresponding setting on the client, so that the corresponding identity token is brought into the DNS request, and the DNS over HTTPS server can directly complete identity verification on the client according to the corresponding identity token, and does not need to input an account password by the user, thereby realizing an identity authentication process that is not sensible to the user.
Further, the S2 specifically includes:
s21, judging whether the target domain is a local domain, if so, judging whether the current mode is a blacklist mode or a white list mode, if so, executing S22, if so, executing S23, and if not, directly returning to the actual address corresponding to the target domain;
s22, judging whether the client identity token is in a preset blacklist, if so, executing S24, otherwise, executing S3;
s23, judging whether the client identity token is in a preset white list, if not, executing S24, otherwise, executing S3;
and S24, returning the access refusal prompt information.
As can be seen from the above description, for a corresponding request for accessing a local domain corresponding to a DNS over HTTPS server, that is, a DNS request in which a target domain in the DNS request is a local domain corresponding to the server, it is determined whether an identity token therein meets a preset condition, and a blacklist mode and a whitelist mode are set, and switching between the two modes can be performed according to specific situations, and when higher privacy is required, the whitelist mode is used, and only the corresponding identity token on the whitelist is allowed to be accessed, and when simple protection is required, the blacklist mode is used, a user with higher risk is not allowed to access, and access setting is more flexible.
Further, the S3 further includes:
according to the target domain, querying records stored in a local DNS authority source database to obtain an actual address corresponding to the target domain;
and returning the actual address.
According to the description, the DNS authoritative source database is locally set, the actual address corresponding to the local domain name is stored, and a safe and accurate access address can be quickly provided for the client.
Further, in S3, "enabling the target server to authenticate the client" specifically includes:
so that the target server can add Session, open corresponding port and open corresponding permission to the client.
According to the description, the DNS over HTTPS server completes the identity verification work of the DNS request, the pressure of the target server is reduced, the target server only needs to operate the corresponding client according to the authentication result, the DNS request which does not pass the authentication cannot reach the target server, the safety of the target server is guaranteed, the DNS over HTTPS server directly feeds the authentication result back to the target server, the user does not need to actively perform identity authentication again, the whole process is insensitive to the user, and the access experience of the user is guaranteed.
Referring to fig. 2, a DNS identity authentication terminal includes a memory, a processor, and a computer program stored in the memory and running on the processor, where the processor executes the computer program to implement the following steps:
s1, receiving a DNS request based on HTTPS, wherein the DNS request comprises a client identity token and a target domain;
s2, judging whether the target domain is a local domain, if so, judging whether the client identity token meets a preset condition, if so, executing a step S3, otherwise, directly returning to an actual address corresponding to the target domain;
s3, packing the DNS request, and sending the packed DNS request to a target server corresponding to the target domain, so that the target server can authenticate the client.
The invention has the beneficial effects that: when a client sends a DNS request based on HTTPS, a client identity token corresponding to the client identity token is carried in the DNS request, when the DNS over HTTPS server receives the DNS request, whether a target domain is a local domain corresponding to the client or not is judged, if yes, permission judgment is carried out on the client according to the identity token and preset conditions, only the DNS request of the client meeting the preset conditions is packaged and sent to the target server, the target server authenticates the client according to the packaged DNS request sent by the DNS over HTTPS server, the token is carried in the DNS request, a user using the client does not need to input a password by himself, the permission authentication process of the client is completely invisible to the user, the safety of DNS access is improved, and the use feeling of the user is not influenced.
Further, the S1 is preceded by:
generating a unique identifier corresponding to a client, and storing the corresponding relation between the client and the unique identifier in a preset database;
and generating the client identity token according to the unique identifier, and issuing the client identity token to the client.
According to the above description, the identity token is generated and issued for each client, and the user only needs to perform corresponding setting on the client, so that the corresponding identity token is brought into the DNS request, and the DNS over HTTPS server can directly complete identity verification on the client according to the corresponding identity token, and does not need to input an account password by the user, thereby realizing an identity authentication process that is not sensible to the user.
Further, the S2 specifically includes:
s21, judging whether the target domain is a local domain, if so, judging whether the current mode is a blacklist mode or a white list mode, if so, executing S22, if so, executing S23, and if not, directly returning to the actual address corresponding to the target domain;
s22, judging whether the client identity token is in a preset blacklist, if so, executing S24, otherwise, executing S3;
s23, judging whether the client identity token is in a preset white list, if not, executing S24, otherwise, executing S3;
and S24, returning the access refusal prompt information.
As can be seen from the above description, for a corresponding request for accessing a local domain corresponding to a DNS over HTTPS server, that is, a DNS request in which a target domain in the DNS request is a local domain corresponding to the server, it is determined whether an identity token therein meets a preset condition, and a blacklist mode and a whitelist mode are set, and switching between the two modes can be performed according to specific situations, and when higher privacy is required, the whitelist mode is used, and only the corresponding identity token on the whitelist is allowed to be accessed, and when simple protection is required, the blacklist mode is used, a user with higher risk is not allowed to access, and access setting is more flexible.
Further, the S3 further includes:
according to the target domain, querying records stored in a local DNS authority source database to obtain an actual address corresponding to the target domain;
and returning the actual address.
According to the description, the DNS authoritative source database is locally set, the actual address corresponding to the local domain name is stored, and a safe and accurate access address can be quickly provided for the client.
Further, in S3, "enabling the target server to authenticate the client" specifically includes:
so that the target server can add Session, open corresponding port and open corresponding permission to the client.
According to the description, the DNS over HTTPS server completes the identity verification work of the DNS request, the pressure of the target server is reduced, the target server only needs to operate the corresponding client according to the authentication result, the DNS request which does not pass the authentication cannot reach the target server, the safety of the target server is guaranteed, the DNS over HTTPS server directly feeds the authentication result back to the target server, the user does not need to actively perform identity authentication again, the whole process is insensitive to the user, and the access experience of the user is guaranteed.
Referring to fig. 1 and fig. 3 to 5, a first embodiment of the present invention is:
a DNS identity authentication method specifically comprises the following steps:
generating a unique identifier corresponding to a client, and storing the corresponding relation between the client and the unique identifier in a preset database;
generating the client identity Token according to the unique identifier, issuing the client identity Token to the client, referring to fig. 3, setting a local client by a user according to the issued identity Token "f 5835613ae 01", starting a corresponding function of DNS over HTTPS, and setting an identity Token (Token) in a URL path of a DNS over HTTPS server;
specifically, a randomly generated UUID can be used as a unique identifier of the client, the UUID is directly used, or a compressed code of the UUID is used, or a HMAC hash digest generated by the UUID is used as an identity token, the UUID is stored in a user identity authentication database, an access right is matched for the corresponding client, and the UUID and a user instance UID are stored in the user identity authentication database together and correspond to the identity token of the client;
the user instance UID is a remaining identifier corresponding to the unique identifier of the client, which can uniquely identify the user identity of the user using the client, such as a user name, a unique ID, and the like, and is used for issuing the identifier to the target server to identify the user identity.
S1, receiving a DNS request based on HTTPS, wherein the DNS request comprises a client identity token and a target domain;
in an optional implementation manner, if the UUID is directly used as the identity token, directly comparing whether the corresponding UUID exists in the user identity authentication database, and if the HMAC hash digest generated by the UUID is used as the identity token, performing hash check on the identity token in the received DNS request and the UUID stored in the user identity authentication database;
s2, judging whether the target domain is a local domain, if so, judging whether the client identity token meets a preset condition, if so, executing a step S3, otherwise, directly returning to an actual address corresponding to the target domain;
referring to fig. 5, the following steps are specifically performed:
s21, judging whether the target domain is a local domain, if so, judging whether the current mode is a blacklist mode or a white list mode, if so, executing S22, if so, executing S23, otherwise, executing S25;
s22, judging whether the client identity token is in a preset blacklist, if so, executing S24, otherwise, executing S3;
s23, judging whether the client identity token is in a preset white list, if not, executing S24, otherwise, executing S3;
s24, returning the prompt information of refusing to access, specifically, returning an error code NXDOMAIN;
s25, performing DNS standard recursive query, adding a corresponding DNS request into a recursive query queue by a scheduling module in a DNS over HTTPS server, polling a thread pool by the scheduling module, performing recursive query to obtain an actual address if a non-busy thread exists in the thread pool, and waiting for next polling if no non-busy thread exists in the thread pool;
s3, according to the target domain, inquiring records stored in a local DNS authoritative source database, obtaining an actual address corresponding to the target domain and returning the actual address to the client; and meanwhile, packing the DNS request, and sending the packed DNS request to a target server corresponding to the target domain, so that the target server can authenticate the client.
The second embodiment of the invention is as follows:
a DNS identity authentication method, which is different from the first embodiment in that:
the S3 is as follows:
the DNS request is delivered to a scheduling module, a local DNS authority source database is inquired and a record is returned, meanwhile, a sub-thread task is started, the DNS request is packaged, and the packaged DNS request is sent to a target server corresponding to the target domain, so that the target server can authenticate the client; specifically, the packaged DNS request includes a client source IP address, Token, and a user instance UID;
and the target server receives the packaged DNS request, and completes authentication operation on the client according to the packaged DNS request, such as Session addition, white list addition, corresponding port opening, connection establishment permission and the like.
Referring to fig. 2, a third embodiment of the present invention is:
a DNS identity authentication terminal 1, comprising a processor 2, a memory 3, and a computer program stored on the memory 3 and operable on the processor 2, wherein the processor 2 implements the steps of the first embodiment or the second embodiment when executing the computer program;
the DNS identity authentication terminal can be a DNS over HTTPS server.
In summary, the present invention provides a DNS identity authentication method and terminal, where an authority for identifying a client by an identity token is issued to the client, when a target domain accessed by the client is a local domain, the client is authenticated, and a corresponding actual address is returned through authentication, so that security of the local domain is improved; the user identity authentication is realized through DNS over HTTPS, the user only needs to use a DNS over HTTPS client or a system (iOS14, Android11 Beta and Windows 1019628 +) and a browser (Firefox, Edge80+ and Chrome80+) supporting the DNS over HTTPS, the user sets a DoH (DNS over HTTPS) once in a request path to configure and transmit an effective Token, the identity authentication configuration can be completed, the login system is not required to be repeatedly typed in to log in, the user identity authentication which is not perceived and invisible relative to the user side is realized, the invasion of an access step is small, the original access flow is not easily damaged, the split feeling on the user experience is not easily generated, the sustainable use only needs to be set once, the user learning and use cost is low, the user is enabled to be close to the authentication system without perception, and the user use experience is optimized. The identity authentication method is implemented by matching with a zero-trust security architecture, optimizes the identity authentication scene under the strict security policy of an enterprise, and implements an identity authentication scheme for the zero-trust security architecture which is painless to convert at a user side; from the perspective of a user, aiming at user experience optimization, a DNS request for accessing a webpage of the user comprises Token to help the user to perform invisible identity authentication, a DNS over HTTPS issues a corresponding authentication request to a target server, an authentication process is invisible to the user, the user does not need to manually log in the authentication repeatedly, but does not need to give up security, the service is not exposed, and balance between system security and user usability is realized.
The above description is only an embodiment of the present invention, and not intended to limit the scope of the present invention, and all equivalent changes made by using the contents of the present specification and the drawings, or applied directly or indirectly to the related technical fields, are included in the scope of the present invention.
Claims (10)
1. A DNS identity authentication method is characterized by comprising the following steps:
s1, receiving a DNS request based on HTTPS, wherein the DNS request comprises a client identity token and a target domain;
s2, judging whether the target domain is a local domain, if so, judging whether the client identity token meets a preset condition, if so, executing a step S3, otherwise, directly returning to an actual address corresponding to the target domain;
s3, packing the DNS request, and sending the packed DNS request to a target server corresponding to the target domain, so that the target server can authenticate the client.
2. The DNS identity authenticating method according to claim 1, wherein the S1 further includes, before the step of:
generating a unique identifier corresponding to a client, and storing the corresponding relation between the client and the unique identifier in a preset database;
and generating the client identity token according to the unique identifier, and issuing the client identity token to the client.
3. The DNS identity authentication method according to claim 1, wherein the S2 specifically is:
s21, judging whether the target domain is a local domain, if so, judging whether the current mode is a blacklist mode or a white list mode, if so, executing S22, if so, executing S23, and if not, directly returning to the actual address corresponding to the target domain;
s22, judging whether the client identity token is in a preset blacklist, if so, executing S24, otherwise, executing S3;
s23, judging whether the client identity token is in a preset white list, if not, executing S24, otherwise, executing S3;
and S24, returning the access refusal prompt information.
4. The DNS identity authenticating method according to claim 1, wherein the S3 further includes:
according to the target domain, querying records stored in a local DNS authority source database to obtain an actual address corresponding to the target domain;
and returning the actual address.
5. The DNS identity authentication method according to claim 1, wherein the step of enabling the target server to authenticate the client in S3 specifically includes:
so that the target server can add Session, open corresponding port and open corresponding permission to the client.
6. A DNS identity authentication terminal comprising a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the processor when executing the computer program implements the steps of:
s1, receiving a DNS request based on HTTPS, wherein the DNS request comprises a client identity token and a target domain;
s2, judging whether the target domain is a local domain, if so, judging whether the client identity token meets a preset condition, if so, executing a step S3, otherwise, directly returning to an actual address corresponding to the target domain;
s3, packing the DNS request, and sending the packed DNS request to a target server corresponding to the target domain, so that the target server can authenticate the client.
7. The DNS identity authenticating terminal according to claim 6, wherein the S1 further includes, before:
generating a unique identifier corresponding to a client, and storing the corresponding relation between the client and the unique identifier in a preset database;
and generating the client identity token according to the unique identifier, and issuing the client identity token to the client.
8. The DNS identity authentication terminal according to claim 6, wherein the S2 specifically is:
s21, judging whether the target domain is a local domain, if so, judging whether the current mode is a blacklist mode or a white list mode, if so, executing S22, if so, executing S23, and if not, directly returning to the actual address corresponding to the target domain;
s22, judging whether the client identity token is in a preset blacklist, if so, executing S24, otherwise, executing S3;
s23, judging whether the client identity token is in a preset white list, if not, executing S24, otherwise, executing S3;
and S24, returning the access refusal prompt information.
9. The DNS identity authenticating terminal according to claim 6, wherein the S3 further includes:
according to the target domain, querying records stored in a local DNS authority source database to obtain an actual address corresponding to the target domain;
and returning the actual address.
10. The DNS identity authentication terminal according to claim 6, wherein the step of enabling the target server to authenticate the client in S3 is specifically that:
so that the target server can add Session, open corresponding port and open corresponding permission to the client.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010802713.5A CN111953681B (en) | 2020-08-11 | 2020-08-11 | DNS identity authentication method and terminal |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010802713.5A CN111953681B (en) | 2020-08-11 | 2020-08-11 | DNS identity authentication method and terminal |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111953681A true CN111953681A (en) | 2020-11-17 |
| CN111953681B CN111953681B (en) | 2022-06-07 |
Family
ID=73331600
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010802713.5A Active CN111953681B (en) | 2020-08-11 | 2020-08-11 | DNS identity authentication method and terminal |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111953681B (en) |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112491909A (en) * | 2020-12-01 | 2021-03-12 | 北京鸿腾智能科技有限公司 | Flow identification method, device, equipment and storage medium based on DOH protocol |
| CN112671779A (en) * | 2020-12-25 | 2021-04-16 | 赛尔网络有限公司 | DoH server-based domain name query method, device, equipment and medium |
| CN113259394A (en) * | 2021-07-05 | 2021-08-13 | 北京小鸟科技股份有限公司 | Cross-domain user authentication method, system and equipment based on routing computation |
| CN113992402A (en) * | 2021-10-27 | 2022-01-28 | 北京房江湖科技有限公司 | Access control method, system and medium based on zero trust strategy |
| CN114826654A (en) * | 2022-03-11 | 2022-07-29 | 中国互联网络信息中心 | Client authentication method and system based on domain name system naming |
Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20140373107A1 (en) * | 2012-01-24 | 2014-12-18 | Ars Nova Systems | System and method for controlling a dns request |
| CN108173979A (en) * | 2017-12-25 | 2018-06-15 | 新华三信息安全技术有限公司 | A kind of message processing method, device, equipment and storage medium |
| US20180176176A1 (en) * | 2016-12-21 | 2018-06-21 | International Business Machines Corporation | Dns resolution of overlapping domains in a mutli-tenant computing environment |
| CN109474718A (en) * | 2018-12-29 | 2019-03-15 | 杭州迪普科技股份有限公司 | Domain name analytic method and device |
| CN109819061A (en) * | 2018-09-11 | 2019-05-28 | 华为技术有限公司 | A kind of method, apparatus and equipment handling cloud service in cloud system |
| CN109842566A (en) * | 2019-01-10 | 2019-06-04 | 杭州迪普科技股份有限公司 | A kind of dns resolution method and device |
| CN110521228A (en) * | 2017-06-16 | 2019-11-29 | 摩托罗拉移动有限责任公司 | Malice unit detection information |
| CN111431850A (en) * | 2020-02-18 | 2020-07-17 | 北京网聘咨询有限公司 | Cross-domain security authentication method in cloud computing |
-
2020
- 2020-08-11 CN CN202010802713.5A patent/CN111953681B/en active Active
Patent Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20140373107A1 (en) * | 2012-01-24 | 2014-12-18 | Ars Nova Systems | System and method for controlling a dns request |
| US20180176176A1 (en) * | 2016-12-21 | 2018-06-21 | International Business Machines Corporation | Dns resolution of overlapping domains in a mutli-tenant computing environment |
| CN110521228A (en) * | 2017-06-16 | 2019-11-29 | 摩托罗拉移动有限责任公司 | Malice unit detection information |
| CN108173979A (en) * | 2017-12-25 | 2018-06-15 | 新华三信息安全技术有限公司 | A kind of message processing method, device, equipment and storage medium |
| CN109819061A (en) * | 2018-09-11 | 2019-05-28 | 华为技术有限公司 | A kind of method, apparatus and equipment handling cloud service in cloud system |
| CN109474718A (en) * | 2018-12-29 | 2019-03-15 | 杭州迪普科技股份有限公司 | Domain name analytic method and device |
| CN109842566A (en) * | 2019-01-10 | 2019-06-04 | 杭州迪普科技股份有限公司 | A kind of dns resolution method and device |
| CN111431850A (en) * | 2020-02-18 | 2020-07-17 | 北京网聘咨询有限公司 | Cross-domain security authentication method in cloud computing |
Cited By (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112491909A (en) * | 2020-12-01 | 2021-03-12 | 北京鸿腾智能科技有限公司 | Flow identification method, device, equipment and storage medium based on DOH protocol |
| CN112491909B (en) * | 2020-12-01 | 2023-09-01 | 三六零数字安全科技集团有限公司 | DOH protocol-based traffic identification method, device, equipment and storage medium |
| CN112671779A (en) * | 2020-12-25 | 2021-04-16 | 赛尔网络有限公司 | DoH server-based domain name query method, device, equipment and medium |
| CN113259394A (en) * | 2021-07-05 | 2021-08-13 | 北京小鸟科技股份有限公司 | Cross-domain user authentication method, system and equipment based on routing computation |
| CN113259394B (en) * | 2021-07-05 | 2021-09-28 | 北京小鸟科技股份有限公司 | Cross-domain user authentication method, system and equipment based on routing computation |
| CN113992402A (en) * | 2021-10-27 | 2022-01-28 | 北京房江湖科技有限公司 | Access control method, system and medium based on zero trust strategy |
| CN113992402B (en) * | 2021-10-27 | 2023-11-21 | 贝壳找房(北京)科技有限公司 | Access control method, system and medium based on zero trust policy |
| CN114826654A (en) * | 2022-03-11 | 2022-07-29 | 中国互联网络信息中心 | Client authentication method and system based on domain name system naming |
| CN114826654B (en) * | 2022-03-11 | 2023-09-12 | 中国互联网络信息中心 | Client authentication method and system based on domain name system naming |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111953681B (en) | 2022-06-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111953681B (en) | DNS identity authentication method and terminal | |
| US10116644B1 (en) | Network access session detection to provide single-sign on (SSO) functionality for a network access control device | |
| KR102313859B1 (en) | Authority transfer system, control method therefor, and client | |
| US9762568B2 (en) | Consolidated authentication | |
| JP6170158B2 (en) | Mobile multi single sign-on authentication | |
| US9398001B1 (en) | System for and method of providing single sign-on (SSO) capability in an application publishing environment | |
| US8769655B2 (en) | Shared registration multi-factor authentication tokens | |
| US8800013B2 (en) | Devolved authentication | |
| US8863265B2 (en) | Remote sign-out of web based service sessions | |
| JP2015535984A5 (en) | ||
| US20080034412A1 (en) | System to prevent misuse of access rights in a single sign on environment | |
| KR960035299A (en) | A method for managing communication between a remote user and an application server, a subject authentication method for a remote user, a network and a program storage device providing a distributed computer environment | |
| US20120084844A1 (en) | Federation credential reset | |
| US20230336541A1 (en) | Method and device for two-factor authentication, computer device, and storage medium | |
| CN102710621B (en) | A kind of user authentication method and system | |
| CN112929388B (en) | Network identity cross-device application rapid authentication method and system, and user agent device | |
| JP2019040319A (en) | Proxy authentication system, proxy authentication method, and program | |
| US20100031332A1 (en) | Secure access | |
| CN110869928A (en) | Authentication system and method | |
| KR20180024746A (en) | Single Sign-On Authentication Method of Supporting Session Management by Server and Cookie Information Sharing Way | |
| JP6848275B2 (en) | Program, authentication system and authentication cooperation system | |
| Baker | OAuth2 | |
| Nenadic et al. | FAME: Adding multi-level authentication to shibboleth | |
| Makropodis | Integration of OpenID Connect with FIDO UAF for Android environments | |
| CN118337519A (en) | Authentication method, authentication device, server, medium and product |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |