CN115378908A - DNS (Domain name Server) identification analysis method and system based on NDN (named data networking) - Google Patents

Abstract

A DNS identifier resolution method and system based on NDN relates to the technical field of identifier resolution. The invention aims to provide a DNS identifier analysis method and system which can realize a DNS identifier analysis function based on an NDN network, prevent the problem of single-point failure or power abuse of a central node and ensure a credible user analysis result. The method comprises the steps of identification name design, identification data design, identification server deployment and identification analysis. The user and the DNS iterative resolver communicate with each other through a DNS protocol in an IP network, the iterative resolver and the authoritative server communicate through an NDN network, the iterative resolver generates a series of NDN Interest packets in order to acquire DNS Data items in the process of processing a DNS request, the NDN Interest packets are sent to the NDN network, the authoritative server provides a response to the Interest packets, the NDN Data packets containing identification information are sent, and finally the NDN network forwards the Data packets to the iterative resolver which sends out the Interest packets, so that the iterative resolver finally acquires the needed DNS Data items. The invention can reduce the problems caused by the failure or the tampering of the central node.

Description

DNS (Domain name Server) identification analysis method and system based on NDN (named data networking)

Technical Field

The invention relates to the technical field of identification resolution, in particular to a DNS identification resolution method and system based on NDN.

Background

The DNS (Domain Name System) associates Domain names and IP addresses, and one of the most important functions is to resolve corresponding IP addresses according to Domain names. The domain name is a string of characters separated by dots, the separated small segments are called labels (labels), and the labels are basic units in the domain name. The name space of the domain name forms a tree structure, each label represents a node, and the nodes are arranged from a leaf (a node far away from the root) to a root (a node near the root) (the label of the root node is a null character string and is generally omitted). If a domain name B can be tagged by domain name a in a direction away from the root, then domain name a is a sub-domain name of domain name B. Authoritative DNS servers divide authorizations by zones (zones), one zone being a contiguous sub-graph of the domain name tree, which can be viewed as the result of removing zero to more subtrees from a subtree, and one authoritative DNS server may be responsible for resolving one or more DNS zones. In the resolution process, the resolution is carried out hierarchically from the root, authority servers of all levels are found in sequence from the root, and the information (such as IP addresses) of the domain name is inquired on the authority servers which have the inquired domain name.

The NDN is a content-centric network architecture, the communication model of the NDN does not pay attention to end-to-end information such as equipment addresses in communication, but pays attention to content data of communication, and the core of communication is based on the name of the data. The NDN communication process can be briefly described as requesting certain Data from the network and receiving corresponding Data from the network, i.e., sending an Interest packet and retrieving a corresponding Data packet. NDN requires a hierarchical naming of each piece of data passed in the network, the basic unit of the name being a Component (Component), the data type of the Component being determined by metadata, the most common type being a string, corresponding to metadata 0x08, with a slash ("/") generally used to separate the different components. An NDN name is represented as a concatenation of several name components, such as "/DNS/com/baidu/www/A", which is an NDN name, wherein the components at each level from root to leaf are sequentially "DNS", "com", "baidu", "www" and "A".

NDN is a new network layer scheme, and relies on a generalized "link layer" (e.g., ethernet, IP, UDP, etc.) to work, providing data transmission services to application layer programs. The NDN-based identification switching system is designed and implemented on the basis of part of the existing work of the NDN. The NFD (NDN Forwarding Daemon) is an open-source NDN repeater, and can be used to deploy NDN nodes. NFD is the most sophisticated implementation of NDN presently disclosed and is adopted by a number of NDN studies.

Secure Namespace Mapping (SNAMP) is an extension of NDN, and a Forwarding Hint (Forwarding Hint) mechanism is introduced to make NDN route scalable. NFD implements this mechanism. The forwarding hint may be viewed as an alias, and the Interest packet containing the forwarding hint can be forwarded according to the forwarding hint, which allows for smaller routing tables to be stored on the router.

The NDNS is a distributed search system on the NDN, can search and acquire data stored in different NDNS servers for NDN users, and can be used for distributing public keys or forwarding prompts and other data. NDNS can ensure the integrity and authenticity of origin of data, providing an automated data security validation mechanism.

NDNS follows the design of a DNS system, applies a scheme of DNS management hierarchical domain name to a hierarchical namespace of NDN, organizes the namespace into a tree, and divides continuous subtrees on the tree into zones (zones) for management. The zone in which a name is located may delegate names prefixed to the name to other zones, each zone corresponding to an NDNS server prefixed by "/zone name/NDNS".

The defects of the prior art are as follows:

in the DNS identification system, non-central nodes can only work independently, but cannot realize identification data exchange between nodes, and cannot escape from the cooperative work of a central node (root server). This leads to the following problems:

(1) The system availability is poor. The central node has a single point failure problem, and if the central node cannot provide correct service, the analysis function of the whole identification system is paralyzed.

(2) There is a central node entitlement abuse risk. The central node may infringe the rights of subordinate nodes and users by enforcing unfair service policies. For example ^[1] If the root node does not provide the resolution service of a certain top-level domain, all users cannot resolve the data under the top-level domain (i.e., "the risk of disappearing"); if the root node does not provide resolution services for certain users, these users cannot resolve all domain name data (i.e., "blindness risk").

[1] Zhang Yu, xia Chongda, fang Bin, et al, an autonomous open internet root domain name resolution system [ J ]. Information security bulletin, 2017,2 (04): 57-69.

Disclosure of Invention

The technical problem to be solved by the invention is as follows: the invention aims to provide a DNS identifier analysis method and system based on NDN, which can realize the DNS identifier analysis function based on the NDN, prevent the problem of single-point failure or power abuse of a central node and ensure that the analysis result of a user is credible.

The technical scheme adopted by the invention for solving the technical problems is as follows:

a DNS identification resolving method based on NDN is realized by IRN, the IRN is an identification data searching system based on a named data network, the IRN comprises an NDN network and a plurality of IRN sites, each IRN site comprises a plurality of IRN applications based on NDN (the IRN sites are centrally deployed IRN application groups and are basic deployment units of the IRN),

the IRNA is used as an application program and runs on a node of an NDN network, and comprises an iteration resolver and an authority server, wherein the authority server is responsible for converting identification Data into an NDN Data packet, the NDN network is used as a Producer (Producer) to provide the Data packet corresponding to the identification Data for the network, the iteration resolver is responsible for converting the requirement of a user for acquiring the identification Data into an NDN Interest packet, the NDN network is used as a Consumer (Consumer) to send the corresponding Interest packet to the network, and the identification Data acquisition result is fed back to the user after the Data packet containing the corresponding identification Data is returned by the network (or after the time is exceeded);

the specific implementation process of the DNS identifier resolution method is as follows:

step one, an identification name design process: defining identification names processed by an identification resolution network, wherein the identification names need to conform to naming standards of NDN and NDNS, each identification name is divided into five parts of DNS root prefix, node prefix, separator, path and type, the format is "/< DNS root prefix >/< node prefix >/< separator >/< path >/< type >, and the subsequent"/"is omitted when the node prefix or the path is empty; the node prefix and the path commonly store domain names in the DNS identification, all labels of the domain names are sequentially arranged from the top-level domain name and are divided from a certain label in the middle, the part containing the top-level domain name is used as the node prefix, and the other part (the part not containing the top-level domain name) is used as the path.

Step two, designing identification data: defining identification Data which is sent to an analyzer by an authoritative server processed by an identification analysis network, wherein the identification Data is stored in the format of an NDN Data packet, a content field corresponds to specific Data content, and the NDN Data packet is signed by using an asymmetric key;

step three, deployment of the identification server:

step three (one), defining a deployment mode of an authoritative server and an iterative resolver:

deploying one or more authoritative servers in the NDN, wherein each authoritative server is used for resolving all identification names taking "/< DNS root prefix >/< node prefix >/< separator >/" as prefixes and public KEY names taking KEY type identification names as prefixes based on a node prefix which is called an authoritative zone name of the authoritative server;

the authoritative servers are divided into direct authoritative servers which can be directly accessed from the full NDN network and conditional authoritative servers which can be directly accessed from the full NDN network only through access information (Forwarding Hint) provided by other authoritative servers;

the direct authoritative server needs to broadcast the forwarding rule to the whole network, and the setting strategy of the authoritative zone name of the direct authoritative server ensures that the authoritative zone name of the direct authoritative server can cover all legal identifications (the coverage ranges of the direct authoritative servers can be mutually overlapped), so that the server which is not configured to be the direct authoritative server automatically becomes a conditional authoritative server;

when the iterative resolver sends a resolution request to the DNS authoritative server, the DNS authoritative server provides the requested identification resolution service in two ways:

one way is that: the DNS authority server returns the identified data directly to the requesting iterative resolver,

the other mode is as follows: a certain iterative resolver sends a request to a DNS authority server A, the DNS authority server A returns access information (Forwarding Hint) pointing to a DNS authority server B, and the authority area name of the DNS authority server B is obtained by adding a path field of an identification name to the authority area name of the DNS authority server A.

The parsing provided above is the final result of a series of requests;

step three (two), determining an authoritative server corresponding to the final identification analysis data:

the identifier is finally resolved by an authoritative server which has the longest authoritative zone name and can resolve the identifier, namely the data of the identifier is directly returned,

for SIGPOST identification: the authoritative server with the longest or next longest authoritative zone name in the authoritative servers capable of analyzing the identification can be analyzed finally;

public KEY with KEY identification name as name prefix: the authoritative server taking the node prefix as an authoritative zone name finally resolves the data; step three, determining the identification data correspondingly stored by each authoritative server

The identification data that an authoritative server can directly provide should include the following parts:

(1) SIGPOST identification pointing to other authoritative servers, wherein FORWARDING _ HINT type data is contained;

(2) The DNS data and SIGNAPOST identification directly belonging to the authoritative server, namely the identification which can be analyzed by the authoritative server but can not be analyzed by other authoritative servers in the step 1;

(3) All KEY type identifications analyzed by the appointed authority server;

step three (four), configuring signature and key

The method comprises the steps that a public KEY corresponding to a KEY generated by an authoritative server is issued, the public KEY data use a KEY type identification name as a name prefix, and meanwhile, an additional field is added behind the KEY type identification name to distinguish different public KEYs; the public key Data is issued in the format of an NDN Data packet, and the signature of the public key Data requires a corresponding secret key and the public key Data, and finally recursively comes to a root secret key, namely the secret key which is not signed by other secret keys; the root key may or may not be issued with itself as the signing key;

step four, label analysis:

the user communicates with the DNS iterative resolver in a DNS protocol in an IP network, the iterative resolver communicates with the authoritative server in an NDN network, and the first layer resolution process is (DNSE user and iterative resolver): the user informs the DNS iterative resolver of the query request by using a DNS query request message, the iterative resolver analyzes and processes the request and informs the user of the query response by using a DNS query response message; the second layer of parsing process is (iterative parser and authoritative server): the iterative resolver generates a series of NDN Interest packets in order to acquire DNS Data items in the process of processing the DNS request, sends the NDN Interest packets to the NDN network, an authoritative server provides a response to the Interest packets, the NDN Data packets containing identification information are sent, and finally the NDN network forwards the Data packets to the iterative resolver which sends out the Interest packets, so that the iterative resolver finally acquires the required DNS Data items.

In the identification parsing process, the iterative parser may use caching techniques to temporarily store identification data, forwarding Hint, public keys, and other cacheable content. Therefore, the network request times are reduced, and the efficiency is improved.

Further, in the first step, the division position of the middle label is determined according to the requirement without influencing the identifier corresponding to the identifier name; each label of < node prefix > and < path > (domain name) uses lowercase and < type > uses uppercase.

Further, in step two, the format of the content field may use protobuf design structured data format.

Further, in step three (one), the specific implementation that the authoritative zone name can cover all legal identifiers is as follows: and setting an identification root authority server, wherein the prefix of the identification root authority server is a null character string, or setting a top-level node authority server for each top-level node name, wherein the prefix of the top-level node authority server is the top-level node name.

Further, in step three (or three), the implementation manner when the authoritative server provides the identification data includes: data hosting and analysis agents;

the data hosting method is that the identification data analysis and storage functions meeting the requirements of an identification system are realized in an authoritative server, and the identification data are directly loaded into the authoritative server, and the authoritative server does not directly interact with an analysis node. At this time, the authoritative server can search the identification Data stored by the authoritative server and create an NDN Data packet according to the identification Data set expected by the analysis requirement;

the resolution proxy method is to implement a resolution request function meeting the requirement of an identification system in an authoritative server, and the authoritative server is used as a user of the identification system to interact with a resolution node (other data sources capable of resolving a DNS identifier, such as a DNS server in an IP network) of the identification system. At this time, the authoritative server can generate a corresponding identification analysis request according to the identification Data set expected by the analysis requirement, and interacts with the analysis node of the identification system to acquire the identification Data and create the NDN Data packet.

Further, in step three (four), the iterative resolver needs to formulate a trust policy of itself when deployed, select a key trusted by itself as a trust anchor, and store it locally.

Further, in the second layer parsing process of the identifier parsing in step four, the specific workflow of the parser and the authoritative server is iterated:

step1, preprocessing before iterative analysis:

1.1 the iterative resolver translates the identification name in the DNS protocol into the identification name used in the IRN after receiving the query request, and the identification name is used as the identification name to be queried;

1.2 querying the identification data according to the following procedure: the iterative resolver firstly finds a starting point of an iterative query identifier, wherein the starting point is a direct authoritative server (generally, the authoritative zone name is the node prefix of one identifier name) capable of resolving the name of the identifier to be checked (namely, the authoritative zone name is the node prefix of one identifier name), and the authoritative zone name is called a standard identifier name to be checked;

the iterative resolver firstly reserves at most one component for a path part in the identification name, omits other components, sets the type of query as a SIGNAPOST type, and generates an iterative query name;

step2, iterative query, including the steps of querying iterative query names and analyzing query results:

the steps of analyzing the query result specifically include:

2.1 if the query is of the SIGNAPOST identification type, further analyzing the data type of the SIGNAPOST identification type;

2.2 if the inquired type is corresponding to the identification name to be inquired, the following process is carried out:

2.2.1 if the response contains data, the iterative resolver receives the data and writes the response;

2.2.2 if the response is NACK (NACK represents that corresponding data does not exist), setting the path as a null character string, inquiring the SOA record of the authoritative server, namely the identification data with the format of "/< DNS root prefix >/< node prefix >/< separator >/SOA", and writing a response message according to the identification data;

step3: and analyzing and verifying the received NDN Data packet in the process of inquiring the iterative query name and the process of inquiring the SOA record of the authoritative server.

Further, in step 2.1, if the queried SIGNPOST identifier type, the data type of the SIGNPOST identifier type is further analyzed, specifically as follows:

2.1.1.Forwarding declaration type, where the type data contains access information (Forwarding Hint) needed by an access authority server, the iterative resolver takes the node prefix of an iterative query name plus a path as the node prefix of a new standard identifier name to be checked, under the condition that an original key name is undefined, a first component is reserved for a path part in the standard identifier name to be checked, the subsequent component is omitted, the type of the query is set to be the SIGNAPT type, and if the path part of the standard identifier name to be checked is null, the type is set to be the type of the identifier name to be checked, and an iterative query name is generated; under the condition of defining the original key name, if the node prefix of the original key name is the same as the node prefix of the standard identifier name to be checked, replacing the iterative query name with the original key name; restarting to query the iterative query name;

2.1.2.Proceed type, the type data only contains type identifier, the iterative resolver, under the condition that original key name is not defined, keeps the front n +1 components of path part in standard identifier name to be checked, n is the number of path part components in iterative query name, omits the latter components, and sets the type of query as SIGNPOST type, if the path part of standard identifier name to be checked and iterative query name is the same, sets it as the type of identifier name to be checked, generates iterative query name; under the condition of defining the original key name, if the node prefix of the original key name is the same as the node prefix of the standard identifier name to be checked, replacing the iterative query name with the original key name; restarting to query the iterative query name;

2.1.3.IP _ONLYtype, the data of the type comprises NS record and glue A record, the iterative resolver should stop resolving and write response message after receiving the type or continue resolving by using the original resolving mode of DNS;

2.1.4.CNAME type, the type data contains a DNS domain name, if the iterative query name is the same as the standard identifier name to be checked, the CNAME data is added into the query result as a part of the query result, the domain name provided by the CNAME data and the type of the identifier name to be checked are used for reconstructing the identifier name to be checked, and Step1.2 is restarted; otherwise, the type is the same as the PROCEED type;

2.1.5. "no corresponding data present" response (NACK), which does not contain data, if the original key name is not defined, the iterative resolver queries the standard to-be-looked up identity name; if the original key name is defined, the iterative resolver queries the original key name.

Further, in Step3, the received NDN Data packet needs to be analyzed and verified in the process of querying the iterative query name and in the process of querying the SOA record of the authoritative server, specifically:

in the process of verifying the Data packet, if a corresponding public KEY is required to be acquired according to an NDN name, the NDN name should have the following format "/< DNS root prefix >/< node prefix >/< delimiter >/< path >/< type >/< suffix >", wherein the field value of the < type > is KEY, the delimiter and the path are combined to form a domain name, the domain name and the KEY type are used to generate an identification name to be searched, the query is performed from step1.2, and the final result obtained by the query is analyzed to be a secret KEY; in the query process, the NDN name is recorded as the original key name.

A DNS identifier resolution system based on NDN is provided with program modules corresponding to the steps, and the steps in the DNS identifier resolution method based on NDN are executed during running.

The invention has the following beneficial technical effects:

the method comprises the steps of designing an identification name, designing identification data, deploying an identification server and analyzing an identification. The user communicates with the DNS iterative resolver through a DNS protocol in an IP network, the iterative resolver communicates with the authoritative server through an NDN network, the iterative resolver generates a series of NDN Interest packets in order to obtain DNS Data items in the process of processing a DNS request, the NDN Interest packets are sent to the NDN network, the authoritative server provides a response to the Interest packets, the NDN Data packets containing identification information are sent, and finally the NDN network forwards the Data packets to the iterative resolver sending the Interest packets, so that the iterative resolver finally obtains the needed DNS Data items. The invention can prevent the single point failure or the power abuse of the central node and ensure the credibility of the analysis result of the user.

The DNS identification analysis method based on the NDN can solve the problems of single point failure or power abuse of a central node in the existing DNS analysis. In the identification analysis process, the iterative analyzer can configure a plurality of direct authority servers as analysis starting points instead of completely analyzing from the central node, and the central node can only influence domain names which are not covered by other direct authority servers, so that the problem caused by the failure or tampering of the central node can be reduced.

The DNS identifier analysis method and system based on the NDN are based on the NDN to realize the DNS identifier analysis function, and can effectively prevent the problems of single point failure or power abuse of a central node and ensure that the analysis result of a user is credible by verification.

Drawings

FIG. 1 is a diagram of an identification resolution network architecture, FIG. 2 is a diagram of an identification data lookup system based on NDN, FIG. 3 is a diagram of a DNS resolution process based on NDN, FIG. 4 is a diagram of an IRN and identification system node interaction pattern,

FIG. 5 is an interface screenshot of a trust anchor stored locally, with a name on the left and a data packet containing a public key on the right;

fig. 6 is a diagram of an experimental environment authority server and DNS record data.

FIG. 7 is a diagram of a dig program used to query www.example.com A identification record to obtain a result screenshot.

Detailed Description

The DNS Identification resolving process according to the present invention is implemented by an Identification Resolving Network (IRN), which is an Identification Data searching system based on a Named Data Network (NDN), and includes an NDN Network and a plurality of IRN sites, each of which includes a plurality of IRN Application programs (IRNA) based on the NDN, as shown in fig. 1 and 2.

The IRN site is a centrally deployed IRN application group, and is a basic deployment unit of the IRN. IRN sites are usually of practical significance, such as multiple identity resolution service sites (including iterative resolvers with multiple identity systems) and country root sites (including top-level domain authority servers with multiple identity systems associated with a national network space initiative), but the deployment of the number and combination of IRNAs in an IRN site is not required from a technical point of view.

The IRNA is used as an application program and runs on a node of an NDN network, and is divided into an iterative resolver and an authoritative server. The authoritative server is responsible for converting the identification Data into the NDN Data packet and serving as a Producer (Producer) in the NDN network to provide the Data packet corresponding to the identification Data to the network. The iterative parser is responsible for converting the requirement of the user for acquiring the identification Data into an NDN Interest packet, sending the corresponding Interest packet to the network as a Consumer (Consumer) in the NDN network, and feeding back the identification Data acquisition result to the user after the Data packet containing the corresponding identification Data is returned by the network (or after the time is out).

The NDN network requires support for Secure Namespace Mapping (SNAMP) extension mechanisms and Forwarding Hint (Forwarding Hint) distributed lookup mechanisms.

The basic working process of IRN is shown in fig. 3, where a user communicates with an iterative DNS resolver in DNS protocol in an IP network, and the iterative resolver communicates with an authoritative server in an NDN network. The first layer of the analysis process is as follows: the user informs the DNS iterative resolver of the query request by using a DNS query request message, the iterative resolver analyzes and processes the request and informs the user of the query response by using a DNS query response message; the second layer of the analysis process is as follows: the iterative resolver generates a series of NDN Interest packets in order to acquire DNS Data items in the process of processing the DNS request, sends the NDN Interest packets to the NDN network, an authoritative server provides a response to the Interest packets, the NDN Data packets containing identification information are sent, and finally the NDN network forwards the Data packets to the iterative resolver which sends out the Interest packets, so that the iterative resolver finally acquires the required DNS Data items.

Wherein communication between the DNS user and the iterative resolver may be implemented using an existing DNS resolver program or software library.

The technical scheme is divided into four parts of introduction, namely an identification name design scheme, an identification data design scheme, an identification server deployment scheme and an identification analysis scheme.

The identity name design defines the identity name that is handled by the identity resolution network. The identification name needs to conform to the naming standards of NDN and NDNS. An identification name is divided into five parts of a DNS root prefix, a node prefix, a separator, a path and a type, and the format is '/< DNS root prefix >/< node prefix >/< separator >/< path >/< type >'. The DNS root prefix is to avoid confusion with other protocols on the same network, and "DNS" may be used as the DNS root prefix; the delimiter is exemplified below by "NDNS". The node prefix and the path commonly store the domain name in the DNS identifier, all labels of the domain name are sequentially arranged from the root to the leaves and are divided from the middle, the part close to the root is used as the node prefix, and the part far away from the root is used as the path. The same identifier may correspond to a plurality of identifier names with different separator positions, and the identifier name is determined to be selected according to the authority server, and the specific selection mode is introduced in the identifier resolution scheme in detail. The corresponding portion is omitted when the node prefix or path is empty. Each label of the domain name uses lowercase, and the type uses uppercase. Some data is sometimes named by adding a name of a field after identifying the name according to needs, the added field has no unified rule, and the complete name of the data is obtained by placing the name of the added field in data of other sources. For example, the node prefix of the identification name is "com/example", the path is "www", the domain name is "www.example.com", and the type is "a"; the/DNS/com/example/NDNS/A is also an identification name, the node prefix of the identification name is "com/example", the path is empty, the domain name is "example. Com", and the type is "A"; the node prefix of the identification name is net, the path is root-servers/a, the domain name is a root-servers.net, and the type is NS; the/DNS/net/root-servers/NDNS/KEY is an identification name, the node prefix of the identification name is net/root-servers, the path is empty, the domain name is root-servers.net, and the type is KEY; the/DNS/net/root-servers/NDNS/KEY/a/CERT/b is not an identification name, but more fields are added after the identification name, but the name of the added fields after the identification name can also correspond to data. In discussing identification names, we define the concept of "prefix" as a prefix at the component level, i.e., one identification name gets another identification name after removing the last n components, and the latter is called the prefix of the former. Part of the type name is reserved by the identity resolution network, such as SIGPOST type, KEY type, etc. These reserved type names may conflict with the name space in which the name is identified, and we may avoid the conflict by using escape characters or renaming names with conflicts, or by using components in the NDN naming convention that are different from the normal string (e.g., using the key component of metadata 0x 20).

The identification data design defines identification data that is processed by the identification resolution network. The identification Data is encapsulated within the NDN Data packet, which includes an identification name, data content (binary Data), a signature (information including a signature value, a signature algorithm, and a key used by the signature). The identification name is stored according to the identification node of the identification data, and an NDNS component is arranged between the prefix of the identification node and the rest part of the identification name. The format of the data content may use a protobuf design structured data format. In order to generate an identification data, we need a key for signing the data, and the scheme of generation and management of the key is described in detail in the following identification server deployment scheme.

The identity server deployment scheme defines the deployment modes of the authoritative servers and the iterative resolvers. The authoritative server needs to deploy one or more authoritative servers in the NDN network, and each authoritative server provides all identification names with "/< DNS root prefix >/< node prefix >/< separator >/" as prefixes based on a node prefix called authoritative zone name of the authoritative server, and comprises identifications of all access identification systems and SIGPOST (SIGNPOST) identifications and KEY (KEY) identifications required for identifying and resolving the operation of the network.

The authoritative servers can be divided into direct authoritative servers which can be directly accessed from the full NDN network and conditional authoritative servers which can be directly accessed from the full NDN network only through access information (Forwarding Hint) provided by other authoritative servers, and the direct authoritative servers need to broadcast Forwarding rules thereof to the full NDN network, so that the deployment cost is high. The strategy for setting the authoritative zone name of the authoritative server is to ensure that the authoritative zone name directly reaching the authoritative server can cover all legal identifications. The policy meeting such requirements is, for example, to set up a root authority server with a prefix of an empty string, or to set up a top-level node authority server for each top-level node name with a prefix of a top-level node name. The ranges covered by the direct authoritative servers may overlap with each other.

The authoritative server can provide the requested identification resolving service in two ways, one is to directly return the data of the identification, and the other is to provide the access information (Forwarding Hint) of the other authoritative server, and the authoritative zone name of the new authoritative server can be obtained by prolonging the authoritative zone name (namely the node prefix in the identification name) of the original authoritative server by using the label of the path field in the identification name.

An identity should be finally resolved (i.e. data returned directly to the identity) by an authoritative server that has the longest authoritative zone name and is able to resolve the identity, except for two special cases: (1) The data of the forward _ hit type in the signalpost identifier is an identifier for providing access information of the authoritative server, and therefore cannot be provided by the authoritative server itself, but should be finally resolved by the authoritative server which has the longest authoritative zone name and can resolve the identifier except the authoritative server. (2) The KEY identifier is used for proving the authenticity of the KEY information, and a complete identifier name including a node prefix and a path should be given before access, so that the position of the separator is fixed and must be finally resolved by an authority server taking the node prefix as an authority area name.

In general, the identification data that an authoritative server can directly provide should include the following parts:

1. SIGPOST identification pointing to other authoritative servers, which contains FORWARDING _ HINT type data.

2. The DNS data and SIGNPOST identities that directly belong to the authoritative server, i.e. the identities that the authoritative server can resolve but that the other authoritative servers described in 1 cannot resolve.

3. All KEY type identifications analyzed by the authority server are appointed.

The implementation manners when the authoritative server provides the identification data can be divided into at least the following two types: data hosting, parsing agent, as in fig. 4.

The data hosting method is that the identification data analysis and storage functions meeting the requirements of an identification system are realized in an authoritative server, and the identification data are directly loaded into the authoritative server, and the authoritative server does not directly interact with an analysis node. At this time, the authoritative server can search the identification Data stored by the authoritative server according to the identification Data set expected by the analysis requirement and create the NDN Data packet. The resolution proxy method is to implement a resolution request function meeting the requirement of an identification system in an authoritative server, and the authoritative server is used as a user of the identification system to interact with a resolution node (other data sources capable of resolving a DNS identifier, such as a DNS server in an IP network) of the identification system. At this time, the authoritative server can generate a corresponding identification analysis request according to the identification Data set expected by the analysis requirement, and interacts with the analysis node of the identification system to acquire the identification Data and create the NDN Data packet.

We also need to publish the public key corresponding to the key generated by the authoritative server in the form of identification data. This type of identification data uses the KEY type to avoid confusion with other types of identification data, while some extra fields may be added behind the KEY to distinguish between different public KEYs. This identification data also requires corresponding key and public key identification data, eventually recursively going to the root key, i.e. the key not signed by the other keys. The root key may or may not be issued itself as the signing key.

A more stringent trust model may require the following rules: a key under an authoritative zone name can only sign off the key under the authoritative zone name or the authoritative zone name prefixed to it. The rules may or may not be used as desired.

When the iterative resolver is deployed, a trust policy of the iterative resolver needs to be formulated, and some self-trusted keys can be selected as trust anchors and stored locally. The trust anchor may or may not be the root key.

The identity resolution scheme defines a workflow for iterating the resolver and the authoritative server when performing identity resolution. The authoritative server can provide the requested identification resolving service in two ways, one is to directly return the data of the identification, and the other is the access information of the other authoritative server, and the authoritative zone name of the new authoritative server can be obtained by prolonging the authoritative zone name (namely the node prefix in the identification name) of the original authoritative server by using the label of the path field in the identification name. The iterative resolver plays a role similar to a DNS recursive resolver in a DNS system, and provides recursive resolution service for DNS users. After receiving the query request, the iterative resolver translates the identification name in the DNS protocol into the identification name used in the IRN (that is, the identification name defined by the identification name design scheme described in this patent, such identification name may be generated in multiple numbers, and only the positions of separators are different from each other, and these identification names are referred to as the identification names to be looked up in the following process), and queries the identification data according to the following procedure: the iterative resolver first finds a starting point of an iterative query identifier, which must be a direct authoritative server (generally, the one with the longest authoritative zone name) capable of resolving the name of the identifier to be queried (that is, the authoritative zone name is the node prefix of one of the identifier names), and starts the query with the identifier name as a reference. If the authoritative server returns the identified data directly, the iterative resolver receives the data and writes a response (if the data is not of the CNAME type) or makes a redirect query (if the data is of the CNAME type); if the authoritative server returns the access information of another authoritative server, the iterative resolver queries the authoritative server in turn, and the process is repeated until the authoritative server directly returning the identified data is found. When the iterative resolver queries the authoritative server for the identifier, the target identifier name should take the authoritative zone name of the authoritative server as the node prefix in the identifier name, and the rest part is taken as a path. In the iterative query process, the iterative resolver firstly reserves a first component of a path part in the identification name, omits a subsequent component, and queries the authority server for SIGPOST type identification data. And after the SIGNAPOST identification data is obtained, executing operation according to the SIGNAPOST identification data, and performing the next iterative query process until an authoritative server directly returning the identification data is found. This case can be classified into the following three cases: (1) If the iterative resolver queries an identifier of a KEY type, when the authoritative server corresponding to the node prefix of the identifier name can be accessed (including two cases that the authoritative server is a direct authoritative server and obtains access information of the authoritative server), the iterative query process can be terminated, and final query is performed (detailed later, the same is the same); (2) If the authoritative server directly provides the identification data through the SIGPOST data, the iterative query process can be terminated; (3) When the iterative resolver requests that the path field in the SIGNAPOST identification name is consistent with the node prefix and the path field in a certain identification name to be searched and data is obtained, the iterative query process can be terminated; (4) When a certain SIGPOST data requested by the iterative resolver does not exist (a NACK response is received), the iterative query process can be terminated.

In the final query process, if the authority server does not directly provide the identification data through the SIGPOST data, the name of the identifier to be searched is queried (if the name of the identifier to be searched is the result of adding other fields after the name of the identifier, the resolution also comprises other fields). If the final query receives a NACK response indicating that the identification data does not exist, setting the path as a null character string, querying the SOA record of the authoritative server, namely the identification data in the format of "/< DNS root prefix >/< node prefix >/< separator >/SOA", and writing a response message according to the identification data.

In the series of queries, the iterative parser will decide the subsequent queries according to the contents of SIGPOST. The contents of the signalpost data include a type field and some data fields depending on the type. Types of SIGPOST data include the following:

1.forward _ hit type, identifying that the path is a node prefix of another authoritative server, accompanied by data needed to access the authoritative server (FORWARDING HINT). After receiving the type, the iterative resolver should turn to the authoritative server to inquire, and modify the node prefix correspondingly.

2. A PROTECTED type identifying that the path belongs to the direct resolution scope of the authoritative server node. The iterative parser should un-hide the next component in the path after receiving the type.

3. An IP _ ONLY type identifying that the path node and its children are not present within the identified data network, but may be present in the IP network and capable of parsing in a native parsing manner. The information of the resolution server in the native resolution mode is generally attached, such as the NS record and the glue a record of the authoritative server corresponding to the domain name in the DNS system. After receiving the type, the iterative resolver should stop resolving or continue resolving by using the native resolving mode of the identification system. This type is a way of providing identification data through the signalpost data.

4.CNAME type, generated by DNS system requirements, identifies that the path is an alias of another path, with another path name attached. If the path happens to be the path that needs to be queried (no hidden components), then the CNAME data is added to the query result as part of the query result and the query continues on to this path, in this case in a manner that provides identification data via SIGPOST data; otherwise, the type is considered to be the same as the PROCEED type.

5. A "no corresponding data exists" response (NACK) identifying the path does not require further iterative queries for SIGNPOST information, terminating the iterative query process.

In the parsing process, the iterative parser needs to perform a redirection query on a response packet containing identification data (i.e., a query of an identification name to be searched, an IP _ ONLY type, and a CNAME type) and a response packet containing a public KEY (i.e., identification data of a KEY type), and the rest of the response packets may or may not be verified. The method of validating the response message follows the NDN specification, wherein if a corresponding public key needs to be obtained according to the NDN name, the aforementioned identifier parsing process can be used to recursively parse and validate the response message.

In the parsing process, the iterative parser may use a caching technology to temporarily store the identification data, forwarding Hint, public key, and other cacheable content, so as to reduce the number of network requests and improve efficiency.

Example (b):

1. building an available NDN network supporting Forwarding Hint

2. And deploying an iterative resolver and an authoritative server in the network as required, and setting an authoritative zone name for each authoritative server according to the node prefix. For example, in an experimental environment, only five IRNA are provided, namely an identification root (authority area name is an empty character string) authority server, a com/example2 authority server and an iterative parser.

3. The iterative resolver selects some keys as trust anchors to be stored in the local of the iterative resolver, and the trust anchors can select keys which are directly reaching an authoritative server, but can also customize the trust anchors. In the experiment we chose to keep the keys identifying the root authority server and the com authority server locally by name and NDN packet containing the public key. As shown in fig. 5.

4. Selecting some appropriate authoritative servers as direct authoritative servers (such as selecting identification root authoritative servers and com authoritative servers, and node prefixes are/DNS and/DNS/com respectively), and broadcasting forwarding rules of the direct authoritative servers to the whole NDN network. This broadcast process can be manually configured on each machine in an experimental environment.

5. Each authority server generates a KEY of the authority server, generates a KEY identification record for the public KEY, submits the KEY identification record to an upstream authority server for signing, and issues the KEY identification record by the upstream authority server. The upstream authoritative server may be the authoritative server itself that generated the key, or may be another authoritative server. In the process of generating the KEY, each authority server generates a KEY (KSK) for issuing the KEY by using a KEY separation technology, the KEY (DSK) for signing specific data is issued by using the KSK, the KSK for issuing the authority servers at the sub-level also needs to use a separate proxy KEY (D-KEY), and each KSK at the authority side at the sub-level needs to use a separate D-KEY for issuing. The public key of the KSK needs to be issued by an authoritative server which has a shorter authoritative zone name and covers the resolution range of the authoritative server, and the rest of the public keys can be issued by the authoritative server generating the key. In this example, the root authority server issues the KSK public key of the com authority server, the com authority server issues the KSK public keys of the com/example and the com/example2 authority server. These key generation, signing and publishing processes may be done automatically by the NDNS, but the process of submitting the key to the parent authority server by the child authority server needs to be done manually. As shown in fig. 6.

6. The DNS record data is imported into authority servers at all levels, and the authority servers can provide services on the basis of NDNS. This process may be implemented by writing a DNS zone file and converting the DNS zone file to an NDNS import command to import the NDNS.

7. DNS user initiates DNS request to iterative resolver, iterative resolver analyzes request to obtain identification name, and NDN network analyzes the identification

8. The iterative resolver searches for a direct authoritative server as a resolution starting point, continuously and iteratively requests SIGNAPOST records, finally finds an authoritative server of the target identification domain name, and requests the authoritative server for the identification to be resolved

9. The iterative resolver carries out signature verification operation on each response message in the iterative request process and when the final request needs the resolved identification, requests the key name attached to each response message to obtain the corresponding public key, carries out the iterative request SIGNAPOST record and the public key corresponding to the key name attached to the recursive request public key response message in the process, and finally reaches the built-in trust anchor of the iterative resolver to terminate the recursive process.

10. The iterative parser will cache the public key, SIGNPOST data and identification data in the above process to avoid a large number of repeated requests and verifications in one query.

11. The iterative resolver combines the identification data (possibly including CNAME and other records in the iterative process) into a DNS response message, and returns the DNS response message to the user

The following explains why a central node failure occurs in the existing DNS system

1. DNS users initiate requests to DNS recursive resolvers, e.g.www.example.comA (meaning www.example.com domain name A record)

2. The DNS recursive resolver sends a request to a DNS root server to inquire the problems requested by DNS users (the problems of subsequent inquiry are all the problems, the following description is omitted)

3. Not stored in DNS root serverwww.example.comThe A record of (c) is only the record of the com authority server, so the NS record of com and the corresponding glue record (i.e. the address of the com authority server) are returned to the recursive resolver

4. The DNS recursive resolver sends a request to the com authority server, and the com authority server only has the records of the example

5. Com authority server sends out request to DNS recursive resolver, and examplewww.example.comSo that the record is returned to the recursive parser

6. And the recursive resolver returns the record to the DNS user, and the resolution is completed.

7. When the central node fails or returns error information, such as the root node fails, the recursive resolver cannot know the NS record and the corresponding glue record of the com authoritative server, so that the flow cannot be continued, and the DNS system fails.

The above is the process of parsing www.example.com a, using the dig program to query www.example.com a for identifying records, and the result is shown in fig. 7 (final result of parsing).

The following explains how the analysis method proposed by the present invention prevents the central node failure:

1. DNS users initiate requests to iterative resolvers, e.g.www.example.com A

2. The iterative resolver initiates a request to a direct authority server, such as a com authority server (assuming the com authority server is the direct authority server), requesting SIGNAPOST data (/ DNS/com/NDNS/example/SIGNAPOST) with the content of a path example

3. The com authority server returns SIGNAPT data, the type of the SIGNAPT data is FORWARDING _ HINT, the content of the SIGNAPT data is information (FORWARDING HINT) pointing to the com/example authority server, and the iterative analyzer carries out signature verification (in the following outline) on the information after receiving the information

4. The iterative resolver requests SIGNAPOST data with a path of www from the com/example authoritative server (/ DNS/com/example/NDNS/www/SIGNAPOST) to obtain a PROCEED response, and meanwhile, the authoritative server can be determined to be the authoritative server capable of directly returning the identification data to be searched, and the name of the identification to be searched can be searched.

5. The iterative resolver inquires the identification name to be looked up, requests A data (/ DNS/com/example/NDNS/www/A) with the path of www from the com/example authoritative server, and the com/example authoritative server returns the corresponding A record

6. And the iterative resolver returns the record to the DNS user, and the resolution is completed.

7. When a central node (root node) fails, the resolution method is not influenced by the failure of the identification root authority server because the resolution method directly accesses the com authority server and does not access the identification root authority server. Further, if a domain name and its child domain name are desired to be protected, the authority server of the domain name can be made to directly reach the authority server, so that the resolution function of the domain name is prevented from being influenced when the parent domain name of the domain name fails.

Claims (10)

1. A DNS identification resolution method based on NDN is characterized in that the DNS identification resolution method is realized by IRN, the IRN is an identification data search system based on a named data network, the IRN comprises an NDN network and a plurality of IRN sites, each IRN site comprises a plurality of IRN application programs based on NDN,

the IRNA is used as an application program and runs on a node of an NDN network, and comprises an iteration resolver and an authority server, wherein the authority server is responsible for converting identification Data into an NDN Data packet and providing the Data packet corresponding to the identification Data to the network as a producer in the NDN network, the iteration resolver is responsible for converting the requirement of a user for obtaining the identification Data into an NDN Interest packet, the NDN network is used as a consumer to send the corresponding Interest packet to the network, and the Data packet containing the corresponding identification Data is returned by the network and then the identification Data obtaining result is fed back to the user;

the specific implementation process of the DNS identifier resolution method comprises the following steps:

step one, an identification name design process: defining identification names processed by an identification resolution network, wherein the identification names need to conform to naming standards of NDN and NDNS, each identification name is divided into five parts of DNS root prefix, node prefix, separator, path and type, the format is "/< DNS root prefix >/< node prefix >/< separator >/< path >/< type >, and the subsequent"/"is omitted when the node prefix or the path is empty; the node prefix and the path commonly store the domain name in the DNS identifier, all labels of the domain name are sequentially arranged from the top level domain name and are divided from a certain label in the middle, the part containing the top level domain name is used as the node prefix, and the other part, namely the part not containing the top level domain name, is used as the path.

Step two, designing identification data: defining identification Data which is sent to an analyzer by an authoritative server processed by an identification analysis network, wherein the identification Data is stored in the format of an NDN Data packet, a content field corresponds to specific Data content, and the NDN Data packet is signed by using an asymmetric key;

step three, deployment of the identification server:

step three (one), defining a deployment mode of an authoritative server and an iterative resolver:

deploying one or more authoritative servers in the NDN, wherein each authoritative server is used for resolving all identification names taking "/< DNS root prefix >/< node prefix >/< separator >/" as prefixes and public KEY names taking KEY type identification names as prefixes based on a node prefix which is called an authoritative zone name of the authoritative server;

the authoritative server is divided into a direct authoritative server which can be directly accessed from the full NDN network and a conditional authoritative server which can be directly accessed from the full NDN network only through access information provided by other authoritative servers;

the direct authoritative server needs to broadcast the forwarding rule to the whole network, the setting strategy of the authoritative zone name of the direct authoritative server ensures that the authoritative zone name of the direct authoritative server can cover all legal identifications, and the server which is not configured to be the direct authoritative server automatically becomes a conditional authoritative server;

when the iterative resolver sends a resolution request to the DNS authoritative server, the DNS authoritative server provides the requested identification resolution service in two ways:

one way is that: the DNS authority server returns the identified data directly to the requesting iterative resolver,

the other mode is as follows: and sending a request to a DNS authoritative server A by a certain iterative resolver, returning access information pointing to the DNS authoritative server B by the DNS authoritative server A, and obtaining the authoritative zone name of the DNS authoritative server B by adding a path field of the identification name to the authoritative zone name of the DNS authoritative server A.

The parsing provided above is the final result of a series of requests;

step three (two), determining an authoritative server corresponding to the final identification analysis data:

the identifier is finally resolved by an authoritative server which has the longest authoritative zone name and can resolve the identifier, namely the data of the identifier is directly returned,

for signalpost labeling: the authoritative server with the longest or next longest authoritative zone name in the authoritative servers capable of analyzing the identification can be finally analyzed;

public KEY with KEY identification name as name prefix: the authoritative server which takes the node prefix as the authoritative zone name finally resolves the data;

step three, determining identification data correspondingly stored by each authoritative server

The identification data that an authoritative server can directly provide should include the following parts:

(1) SIGPOST identification pointing to other authoritative servers, wherein FORWARDING _ HINT type data is contained;

(2) DNS data and SIGNPOST identity that are directly owned by the authoritative server, i.e. the authoritative server can resolve 1.

The identification which cannot be resolved by the other authoritative servers;

(3) All KEY type identifications analyzed by the appointed authoritative server;

step three (four), configuring signature and key

The method comprises the steps that a public KEY corresponding to a KEY generated by an authoritative server is issued, the public KEY data use a KEY type identification name as a name prefix, and meanwhile, an additional field is added behind the KEY type identification name to distinguish different public KEYs; the public key Data is issued in the format of an NDN Data packet, and the signature of the public key Data requires a corresponding secret key and the public key Data, and finally recursively comes to a root secret key, namely the secret key which is not signed by other secret keys; the root key may or may not be issued with itself as the signing key;

step four, label analysis:

the user communicates with the DNS iterative resolver by a DNS protocol in an IP network, the iterative resolver communicates with an authoritative server by an NDN network, and the first layer of resolution process is the DNSE user and the iterative resolver: the user informs the DNS iterative resolver of the query request by using a DNS query request message, the iterative resolver analyzes and processes the request and informs the user of the query response by using a DNS query response message; the second layer of parsing process is an iterative parser and an authoritative server: the iterative resolver generates a series of NDN Interest packets in order to acquire DNS Data items in the process of processing the DNS request, sends the NDN Interest packets to the NDN network, an authoritative server provides a response to the Interest packets, the NDN Data packets containing identification information are sent, and finally the NDN network forwards the Data packets to the iterative resolver which sends out the Interest packets, so that the iterative resolver finally acquires the required DNS Data items.

2. The DNS identifier resolution method according to claim 1, wherein in step one, the division position selected for division at a certain middle tag is determined as required without affecting the identifier corresponding to the identifier name; each label of < node prefix > and < path > (domain name) uses lowercase and < type > uses uppercase.

3. The NDN-based DNS identity resolution method according to claim 1 or 2, wherein in step two, the format of the content field may use protobuf design structured data format.

4. The DNS identifier resolution method according to claim 3, wherein in step three (one), the specific implementation that the authoritative zone name can cover all legal identifiers is as follows: and setting an identification root authority server, wherein the prefix of the identification root authority server is a null character string, or setting a top-level node authority server for each top-level node name, wherein the prefix of the top-level node authority server is the top-level node name.

5. The NDN-based DNS identifier resolution method according to claim 4, wherein in step three (III), the authoritative server provides the identification data in an implementation manner that includes: data hosting and analyzing agents;

the data hosting method is that the identification data analysis and storage functions meeting the requirements of an identification system are realized in an authoritative server, and the identification data are directly loaded into the authoritative server, and the authoritative server does not directly interact with an analysis node. At the moment, the authoritative server can search the identification Data stored by the authoritative server according to the identification Data set expected by the analysis requirement and create an NDN Data packet;

the analysis agent method is that an analysis request function meeting the requirement of an identification system is realized in an authoritative server, and the authoritative server is used as a user of the identification system to interact with an analysis node of the identification system; at this time, the authoritative server can generate a corresponding identification analysis request according to the identification Data set expected by the analysis requirement, and interacts with the analysis node of the identification system to acquire the identification Data and create the NDN Data packet.

6. The NDN-based DNS identification resolution method according to claim 5, wherein in step three (fourth), the iterative resolver needs to formulate its own trust policy when deployed, and selects its own trusted key as a trust anchor and stores it locally.

7. The NDN-based DNS identity resolution method of claim 1, 2, 4, 5 or 6,

in the second layer of resolution process of the identifier resolution, the specific work flow of the resolver and the authoritative server is iterated:

step1, preprocessing before iterative analysis:

1.1 the iterative resolver translates the identification name in the DNS protocol into the identification name used in the IRN after receiving the query request, and the identification name is used as the identification name to be queried;

1.2 query identification data according to the following procedure: the iterative resolver firstly searches a starting point of an iterative query identifier, wherein the starting point is a direct authoritative server capable of resolving the name of the identifier to be checked and is called a standard identifier name to be checked;

the iterative resolver firstly reserves at most one component for a path part in the identification name, omits other components, sets the type of query as a SIGNAPOST type, and generates an iterative query name;

step2, iterative query, including the steps of querying iterative query names and analyzing query results:

the steps of analyzing the query result specifically include:

2.1 if the query is of the SIGNAPOST identification type, further analyzing the data type of the SIGNAPOST identification type;

2.2 if the inquired type is corresponding to the identification name to be inquired, the following process is carried out:

2.2.1 if the response contains data, the iterative parser receives the data and compiles a response;

2.2.2 if the response is NACK, setting the path as a null character string, inquiring the SOA record of the authoritative server, namely the identification data with the format of "/< DNS root prefix >/< node prefix >/< separator >/SOA", and writing a response message according to the identification data;

step3: and analyzing and verifying the received NDN Data packet in the process of inquiring the iterative query name and the process of inquiring the SOA record of the authoritative server.

8. The NDN-based DNS identification resolution method of claim 7,

in the step 2.1, if the queried SIGNPOST identifier type, the data type of the SIGNPOST identifier type is further analyzed, specifically as follows:

2.1.1.Forwarding _HINTtype, data of the type comprises access information required by an access authority server, an iterative resolver takes a node prefix and a path of an iterative query name as a node prefix of a new standard identifier name to be checked, under the condition that an original key name is undefined, a path part in the standard identifier name to be checked is reserved as a first component, a rear component is omitted, the query type is set as SIGNAPT type, if the path part of the standard identifier name to be checked is empty, the path part is set as the type of the identifier name to be checked, and an iterative query name is generated; under the condition of defining the original key name, if the node prefix of the original key name is the same as the node prefix of the standard identifier name to be checked, replacing the iterative query name with the original key name; restarting to query the iterative query name;

2.1.2.Proceed type, the type data only contains type identifier, the iterative resolver, under the condition that original key name is not defined, keeps the front n +1 components of path part in standard identifier name to be checked, n is the number of path part components in iterative query name, omits the latter components, and sets the type of query as SIGNPOST type, if the path part of standard identifier name to be checked and iterative query name is the same, sets it as the type of identifier name to be checked, generates iterative query name; under the condition of defining original key name, if the node prefix of the original key name is identical to the node prefix of the standard identifier name to be checked, replacing the iterative query name with the original key name; restarting to query the iterative query name;

2.1.3.IP _ONLYtype, the data of the type comprises NS record and glue A record, the iterative resolver should stop resolving and write response message after receiving the type or continue resolving by using the original resolving mode of DNS;

2.1.4.CNAME type, the data of this type includes a DNS domain name, if the iterative query name is the same as the standard identifier name to be looked up, add the CNAME data to the query result as a part of the query result, use the domain name and type of identifier name to be looked up that CNAME data provide to rebuild the identifier name to be looked up, restart Step1.2; otherwise, the type is the same as the PROCEED type;

2.1.5 response that "corresponding data does not exist", the case does not contain data, if the original key name is not defined, the iterative resolver queries the standard identifier name to be checked; if the original key name is defined, the iterative parser queries the original key name.

9. The method according to claim 8, wherein in Step3, the received NDN Data packets need to be analyzed and verified in the process of querying iterative names and querying SOA records of the authoritative server, and the method specifically comprises:

in the process of verifying the Data packet, if a corresponding public KEY is required to be acquired according to an NDN name, the NDN name should have the following format "/< DNS root prefix >/< node prefix >/< delimiter >/< path >/< type >/< suffix >", wherein the field value of the < type > is KEY, the delimiter and the path are combined to form a domain name, the domain name and the KEY type are used to generate an identification name to be searched, the query is performed from step1.2, and the final result obtained by the query is analyzed to be a secret KEY; in the query process, the NDN name is recorded as the original key name.

10. A DNS identity resolution system based on NDN, characterized in that the system has program modules corresponding to the steps of any of the claims 1-9, which when run perform the steps of the DNS identity resolution method based on NDN.

Images