KR20120122979A - DNSSEC inline signing - Google Patents

Abstract

Systems and methods for performing increasing DNSSEC signatures in the registry of the present invention may perform digital signatures as part of a single transaction, including operations such as adding, updating, and / or deleting DNS. In an example method, the method includes receiving a domain command from the requester including an indicator of the domain. Received domain instructions are performed in terms of data stored by the registry for the domain. As part of a separate transaction involving the execution of domain instructions, the registry can sign DNSSEC records for the domain using the private server's private key. After the DNSSEC record is signed, the registry may incrementally publish the signed DNSSEC record on a separate server. Exemplary methods may include a 'look-side' operation for adding, updating and / or deleting operations for performing data stored in the registry database, for example, before requesting the requestor prior to applying a digital signature to DNSSEC data. Should be reported. After the performance instructions are reported, the registry can generate digital signatures based on additions, updates, and / or deletion changes and digitally sign the registry resolution database.

Description

DNSSEC inline signing {DNSSEC inline signing}

The present invention relates to Domain Name System Complementary Extension (DNSSEC) inline signatures.

Domain Name System (DNS) is part of the Internet infrastructure that translates human-readable domain names into Internet Protocol (IP) numbers needed to establish TCP / IP communications over the Internet. DNS uses user-friendly domain names such as "www.en.example.com" rather than the numerical IP address associated with "123.4.56.78", for example, that is assigned to computers on the Internet. Make it available to the user for reference.

Each domain name consists of a series of character strings (labels) separated by dots. The rightmost label in the domain name is known as the "top-level domain" (TLD). Examples of known TLDs include “com”; "net"; org. Each TLD supports the second-level domains listed just to the left of the TLD, such as for example at the "www.example.com" level. Each second level domain may include a number of third level domains located just to the left of the second level domain, such as, for example, the "en" level at "www.en.example.com". Domain level can also be added. For example, the domain of "www.landscape.photos.example.com" contains an additional domain level.

It should be noted that a single IP address, for example one address assigned to a single server, can support multiple domain names. That is, different domain names may be resolved to the same server, which may determine what content to provide based on the requested domain name and / or additional non-domain information. This is often referred to as virtual hosting.

The additional non-domain information may be included in a uniform resource identifier (hereinafter referred to as "URI") structure that includes the domain name. For example, "path" is the next segment separated by a forward slash ("/"). This information may be included immediately to the right of the domain name, such as "blog" in "www.example.com/blog/today.htm" and may be used by other receiving devices to identify specific content and deliver or execute specific code. It may be.

Other examples of non-domain information may include queries and fragments, the details of which may be understood by those skilled in the art and are not described in detail herein. This combination of information may be included in a webpage hyperlink that directs the user to another section of the same page or to another webpage.

Thus, as shown in the various embodiments provided above, in a second level domain such as, for example, "example.com", those skilled in the art can include various internet information accessible by different addresses and identification means.

The actual registration of a domain name is performed by a company referred to as a domain name registrar. The registrar registers the domain name in the registry. For example, the end user submits the domain name to the registrar for registration and provides the IP address to which the domain name should be translated. The registrar communicates with the registry to create a registry database record that can be used to translate the domain name into an IP address provided by the end user and recognizes the registrar's identity through domain name registration. Except for the expiration of the term of domain name registration in the registry, registrars whose domain name records are designated in the registry may modify or delete registry database information about the domain name. The end user may change the registrar by any of the following domain transfer procedures. The registrar may act as a hosting provider or the end user may have a domain hosted by a separate third party domain hosting service.

A zone file is a text file that describes a portion of DNS called a DNS zone. Zone files are created in the form of resource records (RRs) and contain information defining mappings between domain names, IP addresses, and other resources. The format of the zone file is defined by a standard where each line typically has a single resource record. The line starts with the domain name, but if the left side is blank, the previously defined domain name is the default. Following the domain name is the duration (live to TTL), the class (almost always "IN" for "internet" and rarely included), the type of resource record (A, MX, SOA, etc.), and A record. This is followed by format-specific data, such as an IPv4 address for. Comments can be included using semi-colons and lines can be continued using parentheses. There are also file directives marked with keywords starting with a dollar sign.

DNS distributes the authority to assign domain names and the authority to map these names to IP addresses by instructing an authoritative name server for their respective domains. The authorization name server is assigned responsibility for each particular domain and can assign that authorization to another authorization name server for its sub-domain. Such mechanisms are continuously consulted and updated, eliminating the need for a single central register. The DNS resolution process allows the user to point to the desired domain by means of a reverse lookup process, whereby the user connects to the desired domain and DNS returns the appropriate IP number.

The request for the domain name given by the DNS resolution process is routed from the resolver (eg stub resolver) to the appropriate server (eg recursive resolver) and retrieves the IP address. To improve efficiency, DNS supports DNS cache servers that reduce DNS traffic between the Internet, increase performance within end consumer applications, and store DNS queries. The DNS query then requests a period of time determined by the TTL of the domain name record in question. Such caching DNS servers are generally named DNS caches and also perform the recursive algorithms needed to resolve a given name starting with the DNS root through the authoritative name server of the queried domain. Internet service providers (ISPs) generally provide recursive and DNS server caching for their customers. In addition, the home network router may perform a proxy to increase efficiency in the DNS cache and the local network.

Although the distribution form of DNS offers significant advantages in terms of the efficiency of the overall system, it can also have some form of misbehavior and be attacked by various nodes in the system. One particular problem that can occur is DNS cache poisoning. DNS cache poisoning occurs when data is introduced into a DNS name server cache database and the cache database is not from an authoritative DNS source. This may result from sophisticated attacks on the name server or may be caused by unintended consequences, such as for example misbehaving DNS caches or inadequate software design of DNS applications. Thus, DNS cache poisoning can result in (1) failure of resolution requests, such as when incorrect or mistyped IP address information is provided, (2) illegal domain hijacking, and account passwords. A request for a direct user resolution request to a malicious site delivered to a user due to the availability of information or distribution of malicious content such as computer worms or viruses.

Domain Name System Complementary Extension (DNSSEC) is a type of appropriate Internet Engineering Task Force (IETF) specification for the protection of certain kinds of information provided by DNS used on IP networks. DNSSEC requires the signing of DNS-prepared zone files. It assures data purity and original authenticity for DNS data and also includes a true denial of existence. In general, the answers provided within DNSSEC are digitally signed and verify the digital signature, allowing the DNS resolver to check whether the information matches the information in the authoritative DNS server. DNSSEC uses public key cryptography for digital signatures and authentication. DNSKEY records begin with a set of authenticated public keys for third-party DNS root zones that are authenticated and trusted within the chain of trust.

To implement DNSSEC, several new DNS record types have to be created or modified to be suitable for use in DNSSEC, including RRSIG, DNSKEY, DS, NSEC, NSEC3, and NSEC3 PARAM. For example, when using DNSSEC, each authoritative response to a DNS lookup will include RRSIG DNS in addition to the requested record type. The RRSIG record is the digital signature of the answer of the DNS source record set. Digital signatures are authenticated by locating the correct public key found in the DNSKEY record. The DS record is used to authenticate DNSKEY in a lookup procedure using a chain of trust. NSEC and NSEC3 records can be used to provide a true fraudulent response to nonexistent DNS records.

The DNSSEC requirement requires the use of different keys stored in DNSKEY records and from different sources to form a reliable anchor. For example, the Key Signing Key (KSK) used to sign DNSKEY records and the Zone Signing Key (ZSK) used to sign other records. Since ZSK can be implemented within the use and control of specific DNS zones, they are simpler and more frequent to change. As a result, ZSKs are typically shorter in byte length than KSK. On the other hand, it can provide a sufficient level of protection.

Although there are more developed protocols required for the use of DNSSEC, including the use of KSK and ZSK, they are not specified in various aspects for the operation of domains that enable DNSSEC at the registrar and registry levels and thus do not meet optimal conditions for large-scale use. . For example, one might have the ability to process a larger number of signatures in a short period of time, but there is a limit to the normal enforcement of signatures for an entire zone based on a zone change. Therefore, improvements in efficient operation and efficient functionalization related to DNSSEC management have been required, and development of signature functions necessary for DNSSEC recording has been required.

Recently existing DNSSEC techniques are associated with the distribution of signatures of DNSSEC data, such as, for example, signature techniques distributed among DNS providers and various users. Specifically, users who want to adopt DNSSEC should have the following basic options:

1. Build your own DNSSEC solution that uses a combination of third-party and open source software with a set of software keys or hardware keys.

2. Requires the use of DNSSEC key management systems and signature appliances such as Secure64 DNS Signer, BlueCat Networks, Xelerance DNSX Secure, Signer, and Infoblox. The appliance is provided in terms of various key management and zone signatures. However, you must install the required hardware at the client site. Also, keep in mind that the signature appliance, with its DNSSEC key management and hardware installation required at the user's site, is not only available to a single user for manual management of more key materials.

3. Use of Managed DNS Solutions for the Update of DNSSEC Support. Managed DNS providers include zone management and zone publishing features. DNSSEC allows clients to 'turn on' DNSDNS to manage DNS zones, but users must either move or outsource DNS hosting by a DNS management provider.

The domain registry approach to adding support for DNSSEC can accept DNSSEC Delegation Signer (DS) information, create an unsigned zone, and sign the entire zone for publication. However, for the introduction of registries such as DNSSEC's .com and .net registries, it is not convenient in terms of various distributions, and another signing technique for DNSSEC data, especially in large zones, is to overcome existing problems such as delays and resolution failures. Cause. This problem can be decisive for e-commerce and other high traffic sites. The current problem is that by providing efficient signing of DNSSEC, it is possible to provide zones from authoritative sources such as registries that can be accountable to domains through various signature schemes.

For example, access to parts of the DNS or other entities within the DNS data that are aware of certain changes or translations can identify parts of the DNS data, such as add, change and / or delete functions, and the entire zone. Various rights and records may be signed without the need for re-signing. In this embodiment, signatures affecting DNS update behavior and DNSSEC records are referred to herein as 'inline signing' as part of a single transaction (e.g., automatic, continuous, separate, and sustainable unit of work). It can provide a side.

In another embodiment, DNSSEC inline signing includes performing DNSSEC inline signing with domain instructions. For example, a responsible registry can accept DNSSEC DS information, create a signed DNSSEC record within the same transaction, and subsequently incrementally publish the signed information out of DNS from one authorized source. Such authorized signatures offer advantages over other distributed signature techniques, but generally represent a challenge in scaling, which can now be addressed in another aspect of the subject technique. According to one aspect of the present invention, the registry database may enable all of the records published within the DNSSEC zone to act as a single source of authority through DNSSEC inline signatures.

As further described herein, a method and system for performing increasing DNSSEC signatures in another entity that is aware of certain changes or changes in the registry or DNS data is presented. That is, performing digital signatures as part of a single transaction that includes functionality such as DNS add, update, and / or delete operations. An exemplary method of the invention includes receiving a domain command from a requester, wherein the domain command includes a domain identifier. The received domain command is executed in terms of data stored by the registry for the domain. DNSSEC data changes can be verified under the domain command received. As part of each transaction involving the execution of domain instructions, the registry may sign DNSSEC records for the domain using a private key, for example, the private key of the authorization server.

Embodiments of the invention include transactions in a registry. As used herein, a transaction run will be understood as an operational run that applies to the manipulation of all data within the transaction range. This works for the database continuously. Embodiments of the invention include increasing transactional execution within the DNS infrastructure. In an embodiment of the invention, the registry may incrementally publish a signed DNSSEC record at each server.

According to one aspect of the invention, the invention includes a method and system for performing DNSSEC signatures in a registry comprising receiving domain instructions from a requestor. Domain instructions may include markers of the domain and may include, for example, additionally modify and / or delete at least one instruction relating to the domain. In an embodiment of the invention it involves executing the received domain instructions in terms of data stored by the registry for the domain. As part of each transaction involving the execution of domain instructions, DNSSEC records for the domain are digitally signed and performed by, for example, the private key of the authorization server. Signed DNSSEC records can be incrementally published to each separate server, for example a DNS server.

An embodiment of the present invention is characterized in that the domain instruction includes one or more DNSSEC Delegation Signer (DS) elements. In an embodiment of the invention, the domain command includes one or more DNSKEY elements that generate one or more related DNSSEC Delegation Signer (DS) records.

In an embodiment of the invention the requestor may be, for example, a registrar, DNS service provider or registrant. In an embodiment of the invention, the domain may be a second or higher level domain under the top level domain of the registry.

In an embodiment of the present invention, a method for performing domains from a plurality of registrars by an authorization server in a registry. In an embodiment of the invention, the signing of the DNS record may be performed by at least two domains from multiple registrars by an authorized server in the registry.

In an embodiment of the present invention, the signing of DNS records may be performed by multiple signing servers for the registry.

Embodiments of the present invention may include changing the implementation of NSEC or NSEC3 based on at least one add, update, delete instruction.

According to another aspect of the present invention, the present invention provides a method for receiving a first command to add, update, or delete at least one DNSSEC related domain name from a requestor, and for the first addition, update, and / or delete stored in a registry database. To perform instructions from a command. In the embodiments of the present invention, the execution of the instructions does not include applying digital signature data. In embodiments of the present invention, the registry or other service may report instructions to be performed to the requestor.

Individual execution of instructions from the first command is possible after performance reports, digital signatures can be generated based on additions, updates and / or deletion changes, and digital signatures are performed by the registry resolution database. Embodiments of the present invention include publishing non-DNSSEC changes and / or DNSSEC changes based on domain instructions to DNS. In embodiments of the present invention, non-DNSSEC changes and DNSSEC changes may be published by the system asynchronously with DNS.

According to another aspect of the invention an embodiment of the invention comprises receiving a first instruction from a requestor for at least one addition, update or deletion of a DNSSEC related domain name from or within a registry; Performing an add, update and / or delete data indication according to the first instruction in the registry database, wherein the performing does not include applying digital signature data; Creating a database entry indicating a pending DNSSEC change related to the first instruction; Generating a digital signature based on the addition, update and / or deletion change; And a system and method for performing DNSSEC signing in the registry, which comprises terminating the database entry. Embodiments of the present invention include publishing a database entry in DNS.

Additional forms, advantages, and embodiments of the present invention will be fully described to those skilled in the art through consideration of the following detailed description, drawings, and claims. It will also be fully understood by those skilled in the art through a summary of the invention and the following detailed description and examples of the invention, and such additional description is intended to limit the scope of the claims of the invention. The detailed description and examples of the present invention have been described only to illustrate preferred embodiments of the present invention. Various changes and modifications within the spirit and scope of the invention will be apparent to those skilled in the art by the detailed description of the invention.

The accompanying drawings, which are provided to explain the invention in more detail, constitute a part of this specification and illustrate embodiments of the invention. It is also provided to explain the spirit of the invention along with a detailed description of the invention. No more detailed attempts will be required to represent the detailed construction of the invention, and various methods may be used as a result of the fundamental understanding and conventional practice of the invention.
1 depicts an alignment relationship of an inline signature device according to one aspect of the present invention.
2 depicts exemplary process steps for DNSSEC data signing in accordance with an aspect of the present invention.
3 depicts more details of a DNSSEC-enabled signature system in accordance with an aspect of the present invention.
4 depicts another detail of a DNSSEC-enabled signature system in accordance with an aspect of the present invention.
Figure 5 illustrates the interrelationship of a downstream resolution database signature alignment device in accordance with another aspect of the present invention.
6 illustrates and illustrates the steps of the downstream resolution database signing process according to another aspect of the present invention.
Figure 7 illustrates the alignment interrelationship of a look-aside database signature device in accordance with another aspect of the present invention.
8 illustrates by way of illustration the steps of a look-aside database signing process according to another aspect of the present invention.
9 depicts an exemplary computer network configuration for use in embodiments of the present invention.

Certain methodologies and protocols described herein in the present specification are not intended to limit the present invention and may be modified to fully appreciate by those skilled in the art. Also, the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of the present invention. In addition, the singular forms "a", "an", and "the" used in the present specification and claims include plural forms unless specifically defined herein. Thus, for example, 'a server' will be understood by those skilled in the art as representing one or more or equivalent servers.

Unless defined otherwise, all technical terms used herein have the same meaning as commonly understood by one of ordinary skill in the art related to the present invention. Embodiments and various modifications and advantages of the present invention are not limited to the embodiments described herein, those shown in the accompanying drawings. In addition, the shape shown in the drawings is not limited to a specific scale and embodiments and features may be employed in other embodiments that those skilled in the art will recognize unless specified herein.

Descriptions of well-known components and processing techniques have not been described unless absolutely necessary for embodiments of the present invention. The embodiments in the present specification are written to facilitate understanding of the present invention, and other variations are possible for the practice of the embodiments of the present invention. Accordingly, the examples and embodiments herein are not intended to limit the scope of the invention, which may be defined only by the appended claims and related laws. Also, reference numerals refer to similar parts throughout the several views of the drawings.

Unless specifically limited, the term registrar as used herein refers to any entity or organization that is correlated with the domain name registry and allows the registrant to create and update domain-name resources.

Unless specifically limited, the term registrant as used herein refers to any person or organization that is correlated with the registrar to create and update domain name resources.

Unless specifically limited, the term 'DNS hosting provider' as used herein refers to content that includes the operation of a name server that can resolve, for example, IP address allocation and domain names managing IP addresses. This refers to any entity or organization that has content in the server for registrants that provides the ability to provision and resolve DNS.

Unless specifically limited, the term 'database' as used herein means carefully related information such as, for example, storage and access used by a computer system, and is written in various electronic storage applicable formats. Examples include local and / or distributed file systems, data files, data stores, structured databases, related databases, local and / or distributed databases, hybrid databases, discrete data structures, and / or schemas within databases. .

In one aspect of the invention, systems and methods for supporting domain sponsorship transfers within DNS hosting transfers include, for example, the following. As a domain transfer between registrars, this may be referred to as a 'domain-sponsorship transfer' and a transfer within DNS hosting may be referred to as a 'DNS hosting transfer'. In the case of domain transfers, two transfers are usually included because many registrars are DNS hosting providers. Registrants also typically benefit from DNS hosting by registrars. The next example illustrates the steps of including a domain-sponsored transfer between registrars that are identical to the registrar, including DNS hosting transfers.

An embodiment of the present invention is to provide a variety of inline signature schemes that are acceptable to large scale DNSSEC providers such as, for example, registries. It is a very efficient way to handle large numbers of DNS changes, including DNSSEC signature data.

Zone Signing Overview

As noted above, DNSSEC is designed to address DNS vulnerabilities, such as cache poisoning and unauthorized data corruption and attack within authorized servers. It aims to provide a pure and genuine way to protect DNS data. Public key infrastructure (PKI) is used as a means of distributing public keys. DNSSEC provides an authentication mechanism for DNS data, but it is not an encrypted mechanism. It is also a safety awareness resolver to verify that received zone data was signed by the administrator of the zone of the private key owner.

DNSKEY Resource Record

Zones have one or more key pairs. These include private keys and public keys. The private key is stored securely in the domain name database and is used for signing zone data. The public key is stored in a database and stored in signed zone data as a DNSKEY resource record. The public key is used to authenticate zone data. DNSKEY records usually have the following data elements:

Flag: 'Zone Key' and 'Secure Entry Point'

Protocol: Fixed value of 3 (for future conformance)

Algorithm: public key encryption algorithm

Public key: public key data

The DNSKEY resource record RR may be a zone signing key (ZSK) or a key signing key (KSK). The key signing key (KSK) has a set of SEP flags so that they are distinguished from the ZSK within the DNSKEY RR set. Key signing keys (KSK) are used to sign other DNSKEY resource records and to build a chain of authority for data that requires authentication.

RRSIG Resource Record

The RRSIG resource record carries the DNSSEC signature of the resource record set RR set (one or more DNS records of the same name class type). The DNSSEC-enabled resolver can verify the signature using the public key stored in the DNSKEY-record. RRSIG records have the following data elements:

Cover type: Signature covered DNS record type

Algorithm: An encrypted algorithm to generate a signature

Label: Label number in the original RRSIG record name (for wildcard authentication)

Original TTL: TTL value of covered record set

Signature Expiration: Upon signature expiration

Signature start: at signature creation

Key Tag: A simple numeric value that allows you to quickly verify the DNSKEY-record used to validate your signature.

Signer Name: The name of the DNSKEY-record used to validate the signature.

Signature: encrypted signature

DNSKEY RR is signed by a valid key signing key. The other RR set is only signed by a valid zone signing key.

NSEC Resource Record

NSEC resource records consist of two separate cases. Set of RR types that exist in the next owner name and NSEC RR owner name [RFC3845] in the canonical rank of the zone containing the authorized data or NS RR set delegation points. The complete set of NSEC RRs within a zone indicates where the privileged RR set exists in the zone and can form a chain of authorized owners within the zone. This record can be used by the resolver as part of the proof of absence of the record name and as part of DNSSEC authentication. NSEC-records have the following data elements:

Next Domain Name: Next record name in the zone (DNSSEC Salting Rank)

Record type: The DNS record type that exists for the name of this NSEC record.

NSEC3 Resource Record

NSEC3 resource record (RR) provides true denial of existence for DNS resource record sets. The NSEC3 RR has substantially the same function as the NSEC RR. However, NSEC3 uses encrypted hash record names to prevent the enumeration of record names in the zone. The NSEC3-record is associated with the next record name in the zone, which is in the hash name salting rank. The NSEC3-record also has a record type that exists for the name covered by the hash value within the first label of its name. Such a record may be used by the resolver to verify the absence of a record name or as part of DNSSEC validation. NSEC3-Record has the following data elements:

Hash Algorithm: Encrypted hash algorithm.

Flag: Indicates whether or not the signature of the "Opt-out" delegation.

Iteration: How many times the hash algorithm has been applied

Salt: Salt value for hash calculation

Next hash owner name: The next recorded name in the zone, present in the hash name salting order.

Record type: The record type that exists for the name covered by the hash value in the first label of its name.

As illustrated in FIG. 1, an alignment relationship of an example inline signature device may be illustrated. As shown in FIG. 1, requestor 100 is, for example, a registrar, registrar or DNS provider and may communicate with registry provisioning system 110. The requestor 100 can communicate instructions relating to existing or new domains. For example, requestor 100 may communicate instructions for changing DNS data managed by a registry, such as DNS data for a domain in a TLD (eg, .com). The registry provisioning system 110 may execute domain commands from the requestor 100 and perform change commands such as, for example, add, change or delete commands, verify DNSSEC data changes, verify appropriate keys, and apply digital signatures. Request the registry database 120 for DNSSEC changes and persistence of DNS.

In an embodiment of the invention, the data provided by the registry provisioning system 110 by the registry database 120 includes DNS information for the domain and signed DNSSEC data. In this embodiment, the DNS change and the DNSSEC change may be performed in one single transaction. If DNS information and signed DNSSEC data for the domain are maintained in the registry database 120, the interaction can be performed. After performing the transaction, the DNS information and signed DNSSEC data for the domain are published to the wide area DNS cloud 140 and the wide area DNS cloud may include other authorization server reciprocal DNS servers.

More detailed DNSSEC signing services are illustrated in FIGS. 2 and 3. This indicates that as an embodiment of the present invention, the modification of the signature service shown in FIGS. As shown in FIG. 2, the registry or other DNSSEC service provider may include any number of signing servers 342, 346. For example, multiple signature servers may be included in the provisioning system 110 shown in FIG. Signature servers 342 and 346 may include Hardware Security Modules (HSMs) 344 and 348, respectively, which include software with useful digital signature functionality including appropriate digital signature keys. Signature servers 342 and 346 communicate with each other and can exchange signed and unsigned DNS data with various application services and tools 310, 320, and 330. Each element of CAS 310, NCC Plugin Business Service 320 and Batch / Tool 330 would be connected to a set of signature servers, preferably signature servers. Signature servers 342 and 346 persist signature DNS data in database 350. Further details of the data flow can be obtained through the database and signature server HSM and its application as shown in FIG. 3.

As shown in FIG. 3, the client 510 is provided with the final service of the provisioning system 110 shown in FIG. 1, for example. This may request verification of the DNSSEC data signed by the signature server 512. Signed DNSSEC data is analyzed or verified based on domain instructions. It is provided to the signature server 512 as shown in link 541. Information on bytes, key types (ZSK, KSK) and TLD may be included. The signature server 512 may verify the HSM from the appropriate key information and / or transmission 541 and pass unsigned data through the appropriate HSM 514 as shown in link 542. This includes, for example, signature instructions such as bytes, keyAlias and signature algorithms.

Signature server 512 periodically checks and transforms database 520 for authoritative data. In this case, a key alias used to transmit data on the HSM 514 may be used on the authorized data. HSM 514 loads a number of keys (which may be ZSK and KSK) by the TLD upon initialization. Each key is known to HSM 514 by an alias such as KeyAlias. The client 510 can notify and transform the TLD and which one to use for the two types of keys (ZSK or KSK) used by the signing server 512, which the signing server 512 can communicate with the HSM for signing. It can be modified by checking the type and the current key alias name. The signing server 512 can request the database 520 to repeat the check for the current alias key. Such commands may be passed to the signature server 512 by the JMX management interface.

HSM 514 signs DNSSEC using the appropriate key. It is also possible to pass the signed data back to the signature server 512 as shown in link 543. The signing server passes the other data, such as signed DNSSEC data or transac- tion performance information, and notifies the client 510 back as shown in link 544.

An example of the operation of a related domain instruction for carrying out the procedure according to the invention is described as follows.

(Creation of domain for DNSSEC data)

While the domain is created in the place where the user is passed according to DNSSEC data, the data is the four fields of data that require the submission of each delegation signer (DS) record, the registry makes the following decisions and Take

Generate and archive digital signatures for DS records.

Determines whether the domain has the right to be published within the zone. If so, create an NSEC3 record and sign the NSEC3 record.

Identify the appropriate location within the NSEC3 chain (which is similar to the list of links stored in the database) and insert a new NSEC3 record with minimal changes to the chain. This involves identifying links very quickly within the chain and also requires the least number of changes and locks in them. Also insertions are made and re-linked to the calm and existing NSEC3 chain ends.

(Updating domains with new DS data)

During a domain update with new DS data, the registrar may include another change to the domain. Another change is a change in domain zone state. Therefore, the registry can generate or keep digital signatures for DS records.

Determines whether a domain is published in the zone and whether it already exists in the zone. If the domain did not exist in the zone but now exists in the zone, create an NSEC3 record and sign the NSEC3 record. Keep digital signatures for NSEC3 records.

Identify the appropriate location within the NSEC3 chain and insert a new NSEC3 record with minimal blocking of the chain. This involves identifying links very quickly within the chain and also requires the least number of changes and locks in them. Also insertions are made and re-linked to the calm and existing NSEC3 chain ends.

If the domain existed in the zone and does not currently need to exist in the zone, the domain record is placed in the NSEC3 chain.

Delete NSEC3 records with minimal blocking of the chain for another update. This involves identifying links very quickly within the chain and also requires the least number of changes and locks in them. Also insertions are made and re-linked to the calm and existing NSEC3 chain ends.

(Domain updates due to DS data deletion)

During a domain update following deletion of DS data, the registrar may include another change to the domain. Another change is a change in domain zone state. For example, if a domain does not need to leave any DS records after deletion, the domain no longer needs to be authorized from the zone. Thus, the registry:

Determines whether the domain will have a remaining DS record.

If no records are needed, the registry removes the domain from the NSEC3 chain (see below for steps). The registry can remove existing digital signatures from DS data that is deleted.

If a record is needed, the registry regenerates the digital signature for the remaining DS record. It also determines whether to authorize the publication of domains within a zone and whether such domains already exist within the zone.

If the domain did not exist in the zone but now exists in the zone, create an NSEC3 record and sign the NSEC3 record. Keep digital signatures for NSEC3 records.

Identify the appropriate location within the NSEC3 chain and insert a new NSEC3 record with minimal blocking of the chain. This involves identifying links very quickly within the chain and also requires the least number of changes and locks in them. Also insertions are made and re-linked to the calm and existing NSEC3 chain ends.

If the domain existed in the zone and does not currently need to exist in the zone, the domain record is placed in the NSEC3 chain.

Delete NSEC3 records with minimal blocking of the chain for another update. This involves identifying links very quickly within the chain and also requires the least number of changes and locks in them. Also insertions are made and re-linked to the calm and existing NSEC3 chain ends.

One aspect of the process of the invention described above is generally as shown in FIG. 4. This depicts an example inline signature step within this specification. This may be done before or after some of the steps depicted in FIG. 2, unless specifically noted, and therefore may be performed simultaneously without departing from the scope of the present invention.

The method of the present invention begins with step S1010 receiving a domain instruction, eg, an addition modification and / or deletion instruction. The domain command is analyzed at step S1020 and includes, for example, application of a certain domain command, applicable TLD, command type, and DNS change. This step proceeds to S1022.

In step S1022, the checked change is performed in the domain command. As mentioned herein, performing such a change may include a single transaction, such as, for example, T1021 and may include a number of different database operations, such as, for example, DNSSEC signature functionality. In the steps S1030 and S1040, the DNSSEC data can be verified through an example system such as the provisioning system 110 as shown in FIG. To add and / or change. This step may include, for example, parsing the instruction, operating and / or verifying DNSSEC related changes and signing and / or resigning DNSSEC data.

In step S1050, the appropriate DNSSEC key, signature protocol, and / or the appropriate HSM are verified on the data base requiring signature. Such a decision may be to create and maintain data based on various factors such as, for example, the domain and / or the TLD on the domain.

In step S1060, the DNSSEC data may be signed by one or more HSMs, for example, HSMs 344 and 348 shown in FIG. 2. In this case, the HSM included in the provisioning system 110 shown in FIG. 1 may be signed. Because DNSSEC data is signed, other DNS changes are made and the changes persist in a registry database or similar database. After the desired DNS change and DNSSEC signature for the transaction in step T1021 are made, the transaction is performed in step S1070.

The inventors have found that the longest time is required and therefore the optimization part of the DNSSEC transaction is the generation and archiving of the digital signature, so that the update of the NSEC3 chain is done. Updates to the NSEC3 chain occur when going into or out of the DNS zone file for the domain's TLD.

In order to qualify a TLD zone file, a domain must have a delegation name server defined for it. But this state should not be sustained. It should also not be deleted from the registry.

Any change to the DNSSEC-enabled domain can thus cause a change in zone state.

As mentioned above, DNSSEC signatures go inline at the same time as the transaction and persist in the authoritative registry database. DNS resolution implements each established transaction in the registry database and incrementally applies it to the DNS server.

According to one aspect of the present invention, DNSSEC signature inlining within domain instructions of a domain registry provides the advantage of maintaining the highest purity of data. This means, for example, that the registry database always appears as an authoritative source published in DNS. The advantage of data purity is that DNSSEC signature inlining effectively performs incremental updates. For example, only a portion of a zone is affected by individual domain commands, so domain command updates and additional DNSSEC updates are each published in DNS as separate units of work, for example as separate transactions. The inventors thus have been able to very quickly publish domain registry updates, including DNSSEC updates in DNS.

As part of performing DNSSEC inline signing, a network cluster operable by a high performance signature server as shown in FIGS. 2 and 3 may be provided for DNSSEC information signing. This is effective for large TLD capacities and can maintain SLA domain registry response time while maintaining DNS published SLAs while maintaining very high levels of data purity.

Note that the DNSSEC signature occurs after the domain update command and it does not involve registrar submission DS records. For example, if you remove all name servers from a DNSSEC-capable domain, the registrar may be a domain update command that passes no DNSSEC data. However, this may result in signature generation. Thus, in certain aspects of the invention, the present invention is not intended to limit such scenarios, even if there is a suitability for responding to requests from registrars including multiple registrars associated with a given registry.

In addition to the inline signature technique described above, the inventors have identified another method that can be performed in accordance with aspects of the present invention. For example, the inventors have developed a variety of 'downstream resolution databases' and 'look-side' techniques, which are applicable to DNSSEC signing operations, such as those performed by registries or other DNS service providers. A downstream resolution database system is illustrated with reference to FIG. 5.

As shown in FIG. 5, the downstream resolution database technique further includes a resolution database 222 and a resolution database process 333, which can communicate DNS changes with each other from registry database 122 or resolution database 222. As already mentioned, the term 'database' used herein is to be interpreted broadly and may include a discrete data schema or table in the database. In the downstream resolution database approach, the downstream resolution database 222 may be an authoritative database that provides gradual updates to the DNS 140. All of the standard domain data (eg non-DNSSEC data) can be written to the registry database 122 based on input from the registry client 111 without further DNS processing. Transactions can be published by the registry-resolution database process 333 from the registry database 122 to the resolution database 222 in this order. The registry-resolution database process 333 identifies the transactions impacting DNSSEC and records DNSSEC signatures and updates written to the resolution database 222. The resolution database 222 may thus be an authoritative database for the DNS server network. This proceeds in the direction of one arrow from resolution database 222 to DNS 140 because a DNS server in the cloud can indicate what is contained within resolution database 222 in memory state.

The advantage of this approach is that it degrades additional time or time dependence on the registry client for DNSSEC because the DNSSEC process is performed concurrently in separate transactions within the registry-resolution database process 333. In this regard, the inventors have found that any registry capable of accommodating DNSSEC data can provide a time procedure intensive method for digital signature generation. For this reason, the registry may choose to generate signatures outside of OLTP transactions. This generally involves the registry:

Step 1. Receiving instructions for adding, updating or deleting DNSSEC-related domain names from the registry.

Step 2. Run data from operations except digital signatures in the registry database.

Step 3. Generation of the required digital signature that reflects the change in DNSSEC data as a result of the OLTP transaction.

Step 4. Perform other DNSSEC data and digital signatures, such as alteration of NSEC or NSEC3 chains, into the registry / resolution database.

Because Step 3 and Step 4 are separate database transactions, the registry can send a quick response to the customer after Step 2 ends. Thus, only relatively late steps 3 and 4 remain and are performed simultaneously without affecting the customer's response time.

A general feature of the process of the present invention is shown in FIG. 6, which illustrates exemplary processing steps for the downstream resolution database herein. Unless specifically stated, the steps depicted in FIG. 6 before and after a particular step may proceed in various orders or simultaneously, without departing from the spirit of the invention.

The method of the present invention begins with step S2010 which receives a domain command, eg, an addition modify and / or delete command. Domain commands are analyzed in step S2020 and include, for example, application of a certain domain command, applicable TLD, command type, and DNS change. This step proceeds to S2022.

In step S2022, the change confirmed in the domain instruction is performed without processing the associated digital signature data. This is to perform a resolution database excluding the digital-signed data from the data caused for operation.

In step S2030, the registry may report change completion to the customer from step 2022, which may be performed regardless of any DNSSEC signature function.

At S2032 and S2040 steps, DNSSEC data can be verified through an example system, such as the provisioning system 110 as shown in FIG. To add and / or change. This step may include, for example, parsing the instruction, operating and / or verifying DNSSEC related changes and signing and / or resigning DNSSEC data.

In step S2050 the appropriate DNSSEC key, signature protocol, and / or the appropriate HSM are verified on the data foundation requiring signature. Such a decision may be to create and maintain data based on various factors such as, for example, the domain and / or the TLD on the domain.

In step S2060, DNSSEC data may be signed by, for example, one or more HSMs, for example, HSMs 344 and 348 shown in FIG. In this case, the HSM included in the provisioning system 110 shown in FIG. 1 may be signed. Since DNSSEC data is signed, the change persists in a resolution database such as, for example, the downstream resolution database 222.

In step S2070, the newly signed DNSSEC data is published in the DNS.

According to the 'look-side' approach already mentioned, the system and method of the present invention is as shown in FIG. As shown in FIG. 7, the look-side approach is performed by a synchronization process 335 with a single registry database 122, which is performed with a single registry database 122 (with DNSSEC data being incrementally published therefrom). Source of truth). The 'look-aside' approach involves modifying the application of additional rules, such as the holding of a particular pending transaction, to the DNS server and only performs an answer to the requested data in the registry database 122 after a pending DNSSEC change.

The look-aside approach does not require the addition of a new resolution database but must, for example, create a set of look-aside tables 124 in the registry of the registry database 122 and the DNS server. The registry service 335 must include additional logic necessary for the operation of the initial look-side for processing 335 to process pending information to be processed by DNSSEC. Processing 225 includes a procedure to sign-manage the DNSSEC records described against the registry database 122 for all pending look-side transactions. The DNS server must be modified to not answer client queries for pending DNS records of changes. The DNS server must recognize pending changes based on information in the lookaside table 124, for example, and back the data indicated by the look-aside record by, for example, information processing 335 and after the end of the operation. It should be recognized that look-side records should be removed.

One advantage of the look-side approach is that it does not require duplicate information in the second resolution database. In addition, since no DNSSEC transaction is affected by DNSSEC processing in the look-aside approach, it is published to the DNS server as before. For example, interruption of DNSSEC processing does not prevent any DNSSEC data updates.

The general features of the look-side approach of the present invention are as shown in FIG. 8, and unless specifically indicated, the steps depicted in FIG. 8 may proceed in various orders or concurrently, before and after a particular step, without departing from the spirit of the present invention. will be.

The method of the present invention begins with step S3010 receiving a domain instruction, eg, an addition modification and / or deletion instruction. The domain command is analyzed at step S3020 and may include, for example, application of a certain domain command, applicable TLD, command type, and DNS change. This step proceeds to S3022.

In step S3022, the change confirmed in the domain instruction is performed without processing the associated digital signature data. This is done by running a registry database that excludes digital-signed data from the data caused for operation.

In the steps S3030 and S3032, DNSSEC data can be verified through an exemplary system, such as the provisioning system 110 as shown in FIG. 5, and a signature or re-signature is required based on the changes to be made as a result of the domain instruction. To add and / or change. This step may include, for example, parsing the instruction, operating and / or verifying DNSSEC related changes and signing and / or resigning DNSSEC data.

In step S3040, for example, as part of a new or existing look-side table, a database entry representing a pending DNSSEC change associated with a domain command is created.

In step S3042, the database entry publishes, to the DNS, data that is part of a new or existing update or look-aside table, for example.

In step S3050 the appropriate DNSSEC key, signature protocol and / or the appropriate HSM is verified on the data base requiring signature. Such a decision may be to create and maintain data based on various factors such as, for example, the domain and / or the TLD on the domain.

In operation S3060, DNSSEC data may be signed by, for example, one or more HSMs, for example, HSMs 344 and 348 shown in FIG. 2. In this case, the HSM included in the provisioning system 110 shown in FIG. 1 may be signed. Since DNSSEC data is signed, the change persists in a resolution database such as, for example, the downstream resolution database 222.

In step 3070 the newly signed DNSSEC data is published in DNS. In addition, the database entry is terminated and for example removes an entry in the look-side table or deletes the look-side table. Changes to the look-side tables are published in DNS as well.

In an embodiment of the present invention, the DNSSEC engine should be transformed into a stable form for displaying resolution system data at any time, and additionally, for example, has sufficient functionality to handle domain DNSSEC events, meaning that the most recent event is deleted from the registry system. It is desirable to have an algorithm that can skip unprocessed events that are not needed by the most recent event.

A computer device required in an embodiment of the present invention is a system device capable of performing as well as performing instructions for performing the method described in the present invention in a computer readable storage medium. For example, a server system having servers 600, 610, and / or 620, including a processor, memory, and electronic communication device, as shown in FIG. 8, may perform, receive, confirm, and respond to the requests shown herein. It has a function of including a network 605 system such as the Internet. Any server of 600, 610, and / or 620 can be operated by the Internet hosting providers, registrars and / or registries described herein, which will communicate with the recursive DNS servers typically represented by any web device 630. It can be. As shown herein, the recursive server 630 is capable of caching domain related DNS data of hosting providers, registrars, and / or registries capable of operating the servers 600, 610, and 620.

For example, requests for updating domain DNS data originating from a registrar, DNS service provider or registrant may be operated via the system, which may be a computer (611, 612), mobile device (614), picocell network device ( 615, mobile computer 616 or other device that maintains the above functionality and has the capability to connect to the network is preferably capable of wireless communication.

Various communications, transmissions, and related functions may be accomplished through, for example, the network 605 and display, store, and / or display, in known techniques, the results performed by server systems such as servers 600, 610, and 620. Can be distributed. Network 605 includes a number of communication elements including wired, wireless, satellite, optical and / or other similar means of communication.

The servers 600, 610, and 620 and the computers 611, 612 include a plurality of processors, the first storage device (not shown but 'RAM' or random access memory type), the second storage device (not shown) ROM 'or read-only memory type). These devices and the like are all suitable forms for computer readable media and may include non-transitory storage devices such as optical or magneto-optical media such as flash drives, hard disks, floppy disks, magnetic tapes, CD-ROM disks. Mass storage devices can be used to store programs and data can generally be stored on a second storage medium, such as a hard disk, later than the first storage device. The information stored in the mass storage device may be incorporated in a standard way into a portion of the first storage device as virtual memory where appropriate. Certain mass storage devices, such as CD-ROMs, pass data directly to the processor.

Servers 600, 610, and 620 and computers 611, 612 are for example video monitors, trackballs, mice, keyboards, microphones, touchscreen displays, transducer card readers, magnetic or paper tape recorders, tablets, stylus, It may include an interface including one or more input / output devices, such as a voice or handwriting recognizer or other input device. Servers 600, 610, and 620 and computers 611, 612 may be coupled to another electronic communication network 605 via a computer or network connection. The network 605 is connected through various wireless, optical, electronic, and other networks such as servers 600, 610, and 620, computers 611, 612, individual servers 613, mobile devices 614, picocell network devices 615. ), The mobile computer 616, the recursive server 630, and other devices having similar functions. Through such a network connection, information may be received from the network 605 and transmitted to the network 605 through the servers 600, 610 and 620, the computers 611 and 612, and the processor, and thus the present invention. Is to follow the steps. The above described devices, materials and the like can be sufficiently understood by those skilled in computer hardware and software, and need not be individually described to those skilled in the art. The hardware elements disclosed herein may be modified with one or more modules to perform the tasks described herein.

In addition, embodiments of the present invention may further include a computer-readable storage medium that includes program instructions for performing various computer-implemented tasks described herein. The media may include singly or in combination with program instructions, data files, data structures, tables, and the like. The media and program instructions may be designed and structured in greater detail in light of the claims of the present invention. They can also be used by those skilled in the computer art using software. Computer-readable media including magnetic media include flash drives, hard disks, floppy disks, magnetic tape; Optical media such as CD-ROM disks; Magneto-optical media; Hardware devices specially modified to store and execute the program instructions of the present invention include, for example, read only memory (ROM) devices and random access memory (RAM) devices. Program instructions include files that contain machine code generated by the compiler and higher level code that can be executed by the computer through the interpreter.

The foregoing descriptions are merely exemplary and all possible embodiments, applications, and variations of the present invention are possible. Accordingly, various modifications and changes described in the methods and systems of the present invention will be apparent to those skilled in the art without departing from the scope and spirit of the present invention. Although the invention has been described in connection with specific embodiments, the invention is not to be limited to the specific embodiments as understood by the claims.

Claims (23)

1) receiving a domain command from the requester including a domain identifier;
2) performing a received domain command on the data stored by the registry for the domain;
3) confirming the DNSSEC data change;
4) signing DNSSEC records for the domain on the verified DNSSEC data change base using the private server's private key as part of a separate transaction involving performing domain instructions;
5) transacting the registry; And
6) publishing the transac- tions performed on the DNS infrastructure;
To perform DNSSSEC signatures on a registry consisting of:
2. The method of claim 1, wherein the domain command includes one or more DNSSEC delegation signer (DS) elements.
2. The method of claim 1, wherein the domain command includes one or more DNSKEY elements to generate one or more DNSSEC delegation signer (DS) records.
2. The method of claim 1, wherein the method of performing signatures further comprises incrementally publishing a signed DNSSEC record to an individual server.
5. The method of claim 4, wherein the signed DNSSEC record is incrementally published to a plurality of individual DNS servers.
The method of claim 1, wherein the domain is at least a second level domain by a top level domain of a registry.
2. The method of claim 1, wherein said signing method is performed for a domain from a plurality of registrars by an authorization server in a registry.
2. The method of claim 1, wherein the signing of the DNS record is performed for at least two domains from a plurality of registrars by an authorized server of the registry.
2. The method of claim 1, wherein said DNS record signing is performed by multiple signing servers for a registry.
The method of claim 1, wherein the domain command is at least one of an add, update, and delete command from a domain.
2. The method of claim 1, wherein the method of performing signatures further comprises performing a change of NSEC or NSEC3 chains based on at least one of add, update, and delete instructions.
1) a processor; And 2) a DNSSEC signature system for a registry comprising a storage device comprising computer readable code,
The system allows the signing server to act as an authorized server when executed by a processor.
Iii) an apparatus that receives a first command from a requester to add, update, and delete at least one DNSSEC-related domain name supported by the registry;
Ii) an apparatus for performing instructions by a first command regarding the addition, update and deletion of stored data in a registry database;
Iii) an apparatus for generating a digital signature based on additions, updates and deletion changes as part of a separate transaction comprising performing instructions from a first instruction; And
Iii) an apparatus for digitally signing the registry resolution database;
DNSSEC signature system for the registry, characterized in that it comprises a.
13. The system of claim 12, wherein said domain is at least a second level domain by a top level domain of a registry.
13. The system of claim 12, wherein the processor is adapted for signing DNS records for at least two domains from a plurality of registrars.
13. The system of claim 12, wherein the processor is further modified to incrementally publish a signed DNSSEC record to a plurality of separate DNS servers.
13. The system of claim 12, wherein the signature system further comprises a plurality of signature servers modified for DNS record signing for the registry.
13. The system of claim 12, wherein the processor is further modified to make changes to the NSEC or NSEC3 chain based on at least one of the add, update, and delete instructions.
1) a processor; And 2) a DNSSEC signature system for a registry comprising a storage device comprising computer readable code,
The system allows the signing server to act as an authorized server when executed by a processor.
Iii) an apparatus that receives a first command from a requester to add, update, and delete at least one DNSSEC-related domain name from or within the registry;
Ii) an apparatus for performing the instructions by the first instruction for adding, updating and deleting data stored in the registry database, the apparatus comprising no application of digital-signed data;
Iii) an apparatus for reporting the performed instructions to the requester;
Iii) an apparatus for generating a digital signature based on the addition, update and / or deletion change; And
Iii) an apparatus for digitally signing the registry resolution database;
DNSSEC signature system for the registry, characterized in that it comprises a.
19. The system of claim 18, wherein the non-DNSSEC change and the DNSSEC change are announced by the system simultaneously from the DNS.
20. The system of claim 19, wherein the processor is modified to make changes to the NSEC or NSEC3 chain based on additions, updates, and / or deletions.
1) a processor; And 2) a DNSSEC signature system for a registry comprising a storage device comprising computer readable code,
The system allows the signing server to act as an authorized server when executed by a processor.
Iii) an apparatus that receives a first command from a requester to add, update, and delete at least one DNSSEC-related domain name from or within the registry;
Ii) an apparatus for performing the instructions by the first instruction for adding, updating and deleting data stored in the registry database, the apparatus comprising no application of digital-signed data;
Iii) an apparatus for creating a database entry indicative of pending DNSSEC changes associated with the first command;
Iii) an apparatus for generating a digital signature based on the addition, update and / or deletion change; And
Iii) an apparatus for terminating the database entry;
DNSSEC signature system for the registry, characterized in that it comprises a.
22. The system of claim 21, wherein the processor is further modified to publish database entries in the DNS.
22. The system of claim 21, wherein the processor is adapted to modify the NSEC or NSEC3 chain based on addition, update and / or deletion changes.

Images