KR20120124044A - DNSSEC signing server - Google Patents

Abstract

PURPOSE: A DNSSEC(domain name system security extensions) signature server is provided to increase efficiency in a DNS(domain name service) cache and a local area network by performing proxy. CONSTITUTION: A registry or a DNSSEC service provider comprises signature servers(142,146) having any number. The signature server includes hardware security modules(HSM)(144,148). The signature server includes software which has a useful digital signature including a valid digital signature key. The signature server can exchange signed data and non-signed DNS data with various application services and tools. Each of a CAS(context aware service)(110), a NCC(network control center) plugin business service(120), and a batch/tool(130) is connected to a set of the signature server. The signature server maintains the signature DNS data within a database(150). [Reference numerals] (120) NCC business service; (130) Batch/tool; (142) Signature server 1; (146) Signature server.. n; (150) Database

Description

DNSSEC signing server {DNSSEC signing server}

The present invention relates to a Domain Name System Complementary Extension (DNSSEC) signature server.

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 addresses associated with "123.4.56.78", for example, to assign computers to the Internet, allowing users to access Web sites and other resources. 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.

In order 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 may have the ability to process a greater number of signatures in a short period of time, but there are limitations to the normal use of the entire zone signature and stand-alone signature system based on zone changes. Also, the solution is only applicable to individual users or to a certain number of domains, which are managed by specific DNS providers. 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.

However, for the introduction of DNSSEC through various registries such as .com and .net, the inefficiency of various signature schemes for DNSSEC data, especially in large zones, creates the potential for resolution problems including delays and resolution failures. This problem significantly reduces the effect on e-commerce or other high traffic sites.

Accordingly, the present invention is intended to provide an efficient signing advantage within a DNSSEC-capable zone through the use of a signature server accessible network that enables remote application for signature management, which is also required for the remote signature portion of the zone. According to aspects of the present invention the use of a signature server accessible network may provide zone management and de-coupling of zone serving applications from a signature mechanism, for example a technique or specific of a name server to perform signatures. It can be compared with other techniques that are essentially combined with other functions, such as the signature technique of the zone management organization.

For example, as the use through extension, network access, signature server, and example modifications is reduced or eliminated, modifications for various functions of the signature server may be required over other known techniques. Network-accessible signing servers can be provided to increase the scope of DNSSEC enforcement without the need for cross-variants such as:

1. Inline signature of source records in high volume DNSSEC applications, such as, for example, a TLD registry.

2. Use of keys to create breakthrough keys using multiple keys and zones, loading keys, unloading keys, and signing zone data in DNSSEC applications.

3. Signature of the entire zone within an offline / batch DNSSEC application, for example a ROOT zone.

In embodiments of the present invention, the system and method of performing DNSSEC signatures may be performed by a signature server that has been modified to interact with individual client applications. An example method may include receiving a signing request from a client application to a signing server to sign first data. Determine the appropriate signing key and / or protocol for the first data. The first data is sent by the signature server to a digital signature module which includes, for example, a hardware support module or a software signature application. The signature server receives the digitized signature of the first data from the digital signature module and provides the client application with the signature of the first data.

According to the first aspect of the present invention, the DNSSEC signature server may be modified to interact with at least one DNSSEC client application and the digital signature module. The DNSSEC signature server consists of a storage device that includes, for example, a processor and computer readable code, and when executed by the processor, the signature server can receive a signature request to sign the first data from at least one client application. Allows you to act as a modified privileged signing server. The first data may include DNS data, for example.

In an embodiment of the present invention, the signature server may determine for the first data a suitable signature key, for example at least one active KSK and an active ZSK. For example, an appropriate key such as at least one active KSK and an active ZSK may be determined based on a TLD identifier that includes a signature request, for example. The signature server may also be modified to be able to determine at least one active signature key and / or active signature algorithm for the first data. It is also possible to request a number of different signatures for the first data based on one or more active signature keys and / or active signature algorithms.

In an embodiment of the present invention, the signature server may send the first data to one of the plurality of digital signature modules and may also receive a digital signature copy of the first data from the digital signature module. The signature server may be modified to provide the first data signed to the client application.

In an embodiment of the present invention, the signature server may be modified to distinguish the requested signature function from a plurality of different digital signature functions based on the service type identifier included in the signature request, which is based on the non-DNSSEC based service type identifier. It is for routing non-DNSSEC signature requests to the digital signature module.

According to another aspect of the invention, the signature server may be modified to receive a request to sign the second data as part of the same signature request. The second data can be DNS or other data, for example. The signature server may determine, for example, an appropriate signing key for the second data, such as at least one active KSK and an active ZSK, which is different from the key used for the first data. For example, the signature server can determine the first set of keys for the first data and the second set of keys for the second data.

In an embodiment of the invention, the signature server may send the second data to one of the plurality of digital signature modules and receive a second digitally signed copy of the data from the digital signature module. The signature server can be modified to supply the second data signed to the client application.

Embodiments of the present invention may be modified such that a signature server may receive multiple signature requests as part of a single request packet, and the requested packet may be signed with at least one different active KSK, active ZSK, and other signature protocols. Can be analyzed to identify the distinction.

In an embodiment of the present invention, the digital signature module may be modified to sign a portion of DNS data according to the DNSSEC protocol without signing the entire zone.

In embodiments of the present invention, the signature server may be modified to provide additional non-DNSSEC digital signature functionality.

In an embodiment of the present invention, each digital signature module may have a Hardware Support Module (HSM), which is physically separate from the processor of the signature server and is adapted to digitize the signature provided by the signature server.

In an embodiment of the invention, the HSM has a number of keys that can be identified by alias markers. The signature server may be modified, for example, to pass the alias markers by appropriate keys such as at least one KSK and ZSK for DNS data to the digital signature module, but not at least one KSK and ZSK to the digital signature module.

In an embodiment of the present invention, the signature server may be modified to periodically check the active KSK and ZSK in a database, for example, and determine which alias markers are active at any given time based on information received from the database. have. Also, the alias marker passed to the digital signature module is the active alias marker.

In embodiments of the present invention, the signature server may be modified to identify a particular HSM for the first data transmission based on at least one active KSK and / or ZSK.

In an embodiment of the present invention, the signature server may be modified to make requests for domains in different TLDs.

In embodiments of the present invention, the signature server may be modified to handle requests for at least two domains managed by multiple registrars.

In an embodiment of the invention the communication between the client and the signature server may be performed by, for example, two-way SSL.

As mentioned herein, an exemplary signing server may be supported for various DNS signing operations, which may include, for example, DNSSEC signing functionality and other DNS management services, remote signing, root zone signing, and the like. It may also be performed by different myriad systems. The signature server can be modified, for example, for signatures that affect DNSSEC records as part of a single transaction, wherein the single transaction performs functions such as atomic, continuous, separation during work units, and the like. Is referred to as an "inline signature."

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 show the detailed arrangements of the invention, and various methods may be used as a result of the fundamental understanding and practice of the present invention.
1 shows details of an exemplary DNSSEC-enabled signature system in accordance with the present invention.
2 shows another detail of a DNSSEC-enabled signature system in accordance with the present invention.
3 illustrates an exemplary signature request protocol in accordance with the present invention.
4 illustrates an exemplary signature request data protocol in accordance with the present invention.
5 illustrates another example of an exemplary signature request data protocol in accordance with the present invention.
6 illustrates an exemplary signature response protocol in accordance with the present invention.
7 illustrates an exemplary signature response data protocol in accordance with the present invention.
8 illustrates another exemplary signature response data protocol in accordance with the present invention.
9 illustrates the relationship between an exemplary request, data request, response and data response in accordance with the present invention.
10 illustrates in more detail an exemplary DNSSEC-enabled signature system that includes a signature service client pool manager in accordance with the present invention.
11 schematically depicts a system alignment for an example inline signature scheme for DNSSEC signatures constructed in accordance with the present invention.
12 illustrates an exemplary computer network architecture used 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.

Embodiments of the present invention provide a network that can be accessed from a variety of sources in an efficient and practical way to enable large DNSSEC providers, such as registries, to allow large volumes of DNS changes, including DNSSEC signature data. It is.

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: A record type that exists for a name covered by a hash value within the first label of its name.

An exemplary signature server directive form is shown in FIG. 1. As shown in FIG. 1, the registry or other DNSSEC service provider may include any number of signing servers 142, 146. For example, multiple signature servers can be included in the provisioning system. Signature servers 142 and 146 may include Hardware Security Modules (HSMs) 144 and 148, respectively, including software with useful digital signature functionality, including appropriate digital signature keys. Signature servers 142 and 146 communicate with each other and can exchange signed and unsigned DNS data with various application services and tools 110, 120, and 130. Each element of CAS 110, NCC Plugin Business Service 120 and Batch / Tool 130 would be connected to a set of signature servers, preferably a signature server. Signature servers 142 and 146 persist signature DNS data in database 150. Further details of the data flow can be obtained through the database and signature server HSM and its application as shown in FIG. 2.

As shown in Fig. 2, the client 210 is provided with the final service of the provisioning system, for example. This may request verification of the DNSSEC data signed by the signature server 212. Signed DNSSEC data is analyzed or verified based on domain instructions. It is provided to the signature server 212 as shown in link 241. Information on bytes, key types (ZSK, KSK) and TLD may be included. The signing server 212 may verify the HSM from the appropriate key information and / or transmission 241 and pass unsigned data through the appropriate HSM 214 as shown in link 242. This includes, for example, signature instructions such as bytes, keyAlias and signature algorithms.

In an embodiment of the invention, the signature server 212 may receive another data signing request as part of the same signing request. Signature server 212 may determine appropriate key information for other data. In another embodiment, as described herein, key information for other data may be different from key information for first data containing the same signature request.

The request 241 from the client 210 to the signing server 212 may be formatted by the signing server protocol (SSP). Exemplary protocols in an embodiment may include a 'boxcar', which packages multiple signature requests into a single protocol request, with a band width suitable for performance as a result of reduced network round trips. In addition, the SSP may include built-in diagnostic features with the following service modules: This allows the client to determine the available service state and recent problems. In an embodiment of the present invention, the protocol in this specification is to allow a simple flag of new data transfer packet information requested by a new service module added to a signature server between different objects without changing the protocol itself. An example SSP is as shown in FIG. 3, which may be described in more detail as follows.

As shown in FIG. 3, the signature server request protocol 300 from a client includes the following fields.

Packet length: int (total length of packet)

Protocol version: byte (protocol version)

Service type: byte (e.g. simple DNSSEC for DNSSEC signing; public key search (alias key provision, public key retrieval))

Translation Id: Long (specific Id to recognize the request)

Flag: int (field that allows requests to pass the flag)

Session Id: Long (Session Id for sending request can be used for accounting purposes)

Account Id: Long (Account Id for sending request can be used for accounting purposes)

Number of records: byte (for example, the number of request data such as the number of packets containing the overall request of the service required to perform)

Signature request data1 ... n-service based data packet requiring action; Typically this includes signed data.

Clients 210 can send signature request data as payloads inside their request 300. In an embodiment of the invention, the signature server 212 may be modified to recognize and act on different service requests and to interpret the data payload based on the associated codecs. In an embodiment of the present invention, the data may be structured in various formats, which may be referred to as a signature request data protocol including, for example, the following simple signature request data, RRSig signature request data or public key inquiry request data.

4 illustrates a simple signature request data protocol. As shown in FIG. 4, the simple signature request 310 includes the following items.

Length: int (length of data)

Algorithm: String (Signature Algorithm)

Key alias: string (key alias required for signature use)

Request data length: int (length of request data field)

Request data: byte (data required to be signed by signature server)

As mentioned above, the client 210, signature server 212, and HSM 214 can use the alias keys to verify each key. This eliminates the need for multiple elements for the exchange of active keys, which has the advantage of maintaining the safety of the key material, in particular the keys are inherently inaccessible (i.e. to the network), for example HSM 214. Inaccessible).

The RRSig signature request data as shown in FIG. 5 is used to perform the signature request data, which is performed in a similar manner to the simple signature request. The RRSig signature request data is, for example, a data bean distributed to clients that holds information about the RRSIG record that needs to be signed. As described in greater detail below, each class of request is returned by the signature server 212 as a corresponding response 244. When the signing server 212 receives the request 241, the DNSSEC-related data, or other data or its own request data, is incremented.

The RRSig signature request data 320 includes the following elements.

Length: int (length of data)

RRSIG ID: Long (Unique ID of RRSig signature request data)

Domain Name: String (Domain Name)

Domain Id: Long (Id of Domain)

Parent domain: String (parent domain)

Cover type: int (resource recording type)

Number of labels: int (the number of labels in the domain name)

Orig TTL: Long (data that needs to be signed by the signature server)

TTL: Long (data that needs to be signed by the signing server)

RR start time: Long (epoch time of RRSIG start time)

RR set byte length: int (length of RR set byte)

RR set byte: byte (data that needs to be signed by the signature server)

Therefore, considering the combination of the signature server request protocol 300 as shown in FIG. 3, the simple signature request data 310 shown in FIG. 4 and the RRSig signature request data 320 shown in FIG. Each signature request data, having a signature algorithm such as an alias key, must be modified so that it can be processed into a single signature request (e.g., by the signature server request protocol 300) among multiple signature request data. . Described in more detail herein, in the case of RR signature data, an appropriate algorithm and / or key should be prepared such that it can be based, for example, on a domain marker and / or on an associated TLD on request. In embodiments of the present invention, the signature server must be modified to handle requests for domains in different TLDs, and the processing of requests for at least two domains managed by such multiple registrars can It must be modified to be processed into analysis and data packages.

The signature request data protocol includes public key request data in the following fields.

Length: int (length of data)

Key alias: string (key alias from which the public key can be queried)

The signature server 212 may be modified to periodically check the database 220 with authorized data through an alias key for use in transmitting data to the HSM 214. The signature server 212 may be modified to identify a specific HSM for sending data packages on an active KSK and / or active ZSK basis. The HSM 214 can load multiple keys (some ZSK, some KSK) via the TLD at initialization time and each key is known to the HSM 214 by an alias, such as a key alias. The client 210 can be modified to notify the signing server 212 of the two types of keys (ZSK or KSK) used. The signature server 212 may be modified to verify the existing alias key name for the key type in communication with the HSM for signature. The signature server 212 may request a recursive check of the database 220 through the existing alias key. Instructions may be passed to the signature server 212 by, for example, the JMX management interface. Thus, signature server 212 is understood as 'DNSSEC-aware'.

One advantage of manufacturing a DNSSEC-aware signature server is that it can reduce marshalling and non-marshaling of data, if the non-marshalized data is passed by the client with almost all signing requests, even if this data has not changed. Would have done. That is, data that does not change often need not be recognized by the client 210 and need not be sent to the client 210 with the individual request 241. On the other hand, these data can be cached and announced by the signature server 212 itself.

Signature server 212 may also be modified to provide general signature capabilities. Examples include variants of signing servers for the use of managed DNS services, which include multiple keys and zones (thousands or millions) capable of generating various signatures, root zone signatures, and the like for managed DNS services. It can have In an embodiment of the present invention, the client may be modified to provide a signature parameter with the ability to dynamically load or unload the key used for signing. 'Generic signing' is what allows a signing server that can perform various types of signature transac- tions, for example, to provide a flexible application for use with large, versatile, and managed DNS services. Thus, the signing server 212 is DNSSEC-aware and capable of performing tasks for other signing purposes, for example via a runtime-modifying plug-in (service), which will affect the handling of incoming requests. According to aspects of the present invention, the signature server framework as shown in FIG. 2 may allow various parties to record service modules with different parameters and keys, which uses various brands of hardware and software for signature applications. Can communicate. It is possible to add supported protocols in a new form without the interface of the client with additional functionality. Modifications of the signature server and signature server protocols are permitted, for example DNSSEC applications that include a variety of other end-user interfaces (eg Web services, EPP, REST) without impacting existing signatures.

Embodiments of the invention may include a signature server code base with a service module and the service module may provide a caching and non-caching combination of signature-modification parameters. The service module can either reuse this caching or have a non-cached property as per its own needs. Caching can be used to increase the performance of service modules with relatively stable key and signature variations. Non-caching, on the other hand, facilitates loading of the required key and signature parameters only if they require a high volume of keys and parameters that are stored off-line and only activated upon signing. In addition, the signature server allows itself to remain robust and continue service requests to other modules, as generated by other protocols and keys when a separate service module malfunctions or becomes unavailable. This flexibility provides, for example, Myriad options that cannot be achieved by existing stand-alone DNSSEC signature applications.

Another advantage of the non-caching approach is that a digitally wrapped key can be stored in a more accessible repository at a lower cost, even if all applicable keys are not cached within the HSM or other signature module, for example. It's like a database that can be easily transcribed through data. Thus, HSMs and other signature modules can query the keys needed to sign data. The loading required for separate storage of such activation keys has been found by the inventors to enable overall signing services, as described herein, without sacrificing a number of HSMs without sacrificing the capabilities of the HSM or the usefulness of the database used. It can be scaled using keys. This can be useful within the context of the various large DNS services provided by the registry and allows access of keys for thousands to millions of zones.

In an embodiment of the present invention, the HSM or other signature module may encrypt the associated key stored in the database along with the HSM's private key or other signature module. As described below, each key can be verified by a key alias and can be decrypted by the HSM or other signature module using the private key in the query.

As shown in FIG. 2, the HSM 214 can sign the received DNSSEC data and return it to the signing server 212, as indicated by the link 243 in the request 242, for example, using the appropriate key. You can pass signature data. In an embodiment of the present invention, the signature is based on confirmation and request of an appropriate key and / or protocol, for example from an alias key. HSMs and other software signing applications, on the other hand, have predetermined keys and / or parameters to apply to the signature request sent to them. In accordance with aspects of the present invention it may be possible to have individual acknowledgment data packets contained within a signature request and such packets may be processed concurrently to allow the client to continue working without barriers for signature responses. A single signing server can also receive and enforce requests to sign mixed applications and data in mixed zones at the same time. This is because the signature server can receive within a single request packet instruction requesting the signature of uncorrelated data for staggered zones and / or applications.

Additionally, signature server 212 can be modified to request multiple signatures for a single data packet. For example, signature server 212 may be aware of multiple activation keys and / or algorithms that apply to specific data and may perform multiple signing requests from an HSM or other signature module based on one or more activation keys and / or algorithms. Can be. In an embodiment of the present invention, the signature server 212 may be modified, for example, for requesting and reporting the signature of the first data with the first key by the first algorithm and the first data by the second algorithm. May be performed by a second key. Multiple activation keys and signatures may be applied and are effective for performing algorithm rolls (e.g. SHA-1 to SHA-2) within the context of key rollover and / or DNSSEC, for example depending on the requirements of the user.

The HSM 214 is physically separate from the processor of the signature server 212 and securely stores the stored key, for example with an additional complementary protocol stored within the HSM 214. For example, the HSM 214 can be modified to exchange key information only through the physical loading procedure of the security key stored therein, especially for long service durations and wide applicability mechanisms such as, for example, KSK. Use In an embodiment of the present invention, the HSM may include one or more keys and one or more alias identifiers that confirm that the keys are stored.

The signature server 212 may pass, for example, signed data, such as DNSSEC or other digitally signed data, or data such as transaction performance information, and send back to the client 210 as shown in link 244. have.

As noted above, each request may be returned by the signature server 212 as a corresponding response 244. The response 244 returned by the signature server 212 may be modified as appropriate by the signature server response protocol as shown in FIG. 6.

As shown in FIG. 6, the signature server response protocol 400 includes, for example, the following.

Packet length: int (total length of packet)

Protocol version: byte (same as sent in request)

Service type: byte (same as sent in request)

Transaction Id: long (same as sent in request)

Flags: int (fields that allow pass requests within the flag)

Response code: byte (response code after request processing. See below for response codes that may be returned by the signing server.)

Response message length: int (length of the detailed response message for the response returned by the server)

Response message property: char (response message property)

Number of records: byte (response data (e.g. the number of packets included in the overall request requiring the service to be performed))

Signature Response Data 1 ... n

Exemplary signature response codes are shown in Table 1.

Response code Response details 0 success One Request failed 2 Request failed due to database failure 3 Request failed due to signing engine failure 4 Request Failed Due to Unsupported Service Request 5 Failed to find public key for alias key

The signature response data may include, for example, simple signature response data, RRSig signature response data, or public key query response data corresponding to a request such as, for example, simple signature request data, RRSig signature request data, or public key lookup request data. have. In an embodiment of the invention, there is one response data object for each request-data packet sent in the request.

An example of simple signature response data 410 is as shown in FIG. 7 and is returned by signature server 212 in response to a simple signature request as shown in FIG. 4, for example. As shown in FIG. 7, the field of simple signature response data 410 includes the following.

Length: int (length of data)

Signature data length: int (length of signature data field)

Signature data: byte (data that needs to be signed by the signature server)

8 shows an example of RRSig signature response data 420. This is to use for each response-data packet resulting from an RRSIG related request as shown in FIG.

Length: int (length of data)

RRSIG ID: Long (unique ID of RRSig signature request data)

Domain Name: String (Domain Name)

Domain Id: Long (Id of Domain)

Parent Domain: String (parent domain)

Cover type: int (resource recording type)

Number of labels: int (the number of labels in the domain name)

Orig TTL: Long (data that needs to be signed by the signature server)

TTL: Long (data required by the signature server)

RR start time: Long (Epoch time of RRSIG start time)

Key tag: int (key tag of the key used to sign the request)

Algorithm Id: int (Id of the algorithm used to sign the request)

Signature: String (base 64 cryptographic signature generated by signing request)

RR end time: Long (epoch time for RRSIG end time)

The signature response data may include public key response data (not shown) including the following fields.

Length: int (length of data)

Alias key: String (alias key sent by request)

Public key: String (base 64 encrypted public key for keys retrieved using alias keys)

When the signed data is returned to the client 210, the client distributes the signed data requesting to DNS or other services, for example, or sends the requested confirmation message. In an embodiment of the present invention, the client 210 can be transformed into a DNSSEC application to verify behavior such as a DNS change, and can also determine the appropriate DNSSEC function that needs to be performed. Thus, signature server 212 can coordinate functionality with multiple DNSSEC-specific application programming. For example, client 210 does not require DNSSEC application details of the signature parameters and does not require the signature server 212 to handle network costs by passing and combining additional information, without requiring DNSSEC business logic (what resources should be signed). Whether it is a record). Similarly, as described above, various request and response protocols may allow DNSSEC applications to combine all relevant small signature requests (without various DNSSEC signature parameters and key information) into one packet. Thus, this causes a great reduction in network load and overhead. Finally, the client 210 can query any HSM interface details.

9 graphically depicts the relationship between the example request described above and the response protocol shared between the client and server. The above protocol is merely illustrative of the form and does not limit the scope of the present invention to a specific protocol. For example, other protocols may be performed centrally by the capabilities of the intelligent signature server, for example where the key schedule is loaded on the signature server, and the client may automatically select the appropriate indicator for the signature server to select the correct key. Include whether or not you can pass the data to be signed.

In accordance with one aspect of the present invention, a cluster of clients and a signature server may be managed to improve load balancing and response of the signature system as described herein. For example, as shown in FIG. 10, a signature server client 810 for coordinating a request for a particular signature server for each signature server 801-801n in an embodiment of the present invention is an example. The signature server client 810 may have a signature service client pool 820 for managing the signature server client. The signing service client pool 820 can be connected to any number of signing server clients, for example in a round robin fashion, performing load balancing requests to various signing servers and, if the signing server is disconnected, Allow them to drive out of rotation.

Each signature server client 810 can be modified to maintain a pool of socket connections 812 with the signature server and notify the signature service client pool 820 if this service is terminated and also connect to the signature server. Attempt to continue and may notify the signature service client pool 820 that the service is rotated back after the signature server returns.

Thus the overall system can be controlled by client-side and server-side failures. For example, a client-side service might keep a list of signing servers and enable them to check for "fatals" about exceptions / errors. On the client side, such a deadly signing server can be removed from the round-robin rotation, which will be attempted to continue to recognize when the server comes back online. The signature server can be modified to support a 'ping' so that the client can check its health.

If the client-side signing service confirms that all signing servers are down, it immediately switches to an exception when it receives a request to sign. The client will be able to persist until at least one signature server is available.

On the signing server side, failure scenarios include the inability to leverage one dependency tool such as an HSM or key database. If the HSM is not available, the signing server reports an error response indicating this. The signature server can alert you to this state, for example, via JMX and log entries. The signature server is also constantly trying to detect whether the HSM is back online. If the key database is not available for refreshing the key data, the signing server can be modified to reject the signing request for the data, for example because of the risk of signing due to an invalid key. The signature server may be modified to report such an error in the signature response, which will continue to attempt to return to the key database.

Another option that the signature server provides as a variant is to suspend client connections and listening for new connections for specific services when the services are not functioning properly. Such a variant provides the client with the advantage of accepting service requests directly, for example only if the signing server is currently operating to perform the service. It can also monitor the status of the signature server network, reduce the number of errors reported from the client, and improve the overall efficiency of the client. Such a modification is to maintain an operational service that relieves the burden of error reporting and receipt by faulty functional services until the signature server publishes a resolve. Similar variations are possible between a signature server and multiple supporting HSMs or other signature modules.

The arrangement depicted in Figures 1, 2 and 10 allows a client, such as client 210, to adopt aspects of the request and response protocols through a client-utility library that employs load balancing and high availability features. For example, client-utility libraries can work with each other on the signing server, regardless of which internal service modules the server is using. The client-utility library is automatically reconnected and provides a quick failure (if the service is not available) as part of its characteristics. The load-balancing characteristics of the client-utility library automatically load evenly among the active servers regardless of whether multiple signing servers are available or not, or how many clients are connected to this server at any given time. It is to provide a function to distribute the.

In an embodiment of the present invention, the service module plug for the signature server may include a module for one or more TLDs, such as, for example, .com, .net, .edu, and the like. In an embodiment of the present invention, multiple TLDs are supported by a single service module that is aware of various key schedules and / or protocols for different TLDs. The service module may be used, for example, to generate which digital signatures are requested by which ZSK for application of which signatures to a given TLD and responsibility for key rollover; Which hardware or software signature can generate a signature for such a TLD; The TLD-specific parameters used in generating a signature, including salt, hashing algorithm, signature algorithm, signature duration, etc., may be modified to provide information about which one. In embodiments of the present invention, the signature server may be modified to automatically perform reloading of settings for the database periodically to pick up changes during normal operation periods without re-starting.

A distinctive advantage of this approach is that it can provide an authoritative transformation that can assure continuous signature generation per TLD. It also means that the registry application for the TLD itself does not need to be aware of such a policy directly, but only when requesting a data signature from the TLD base to the signature server when enforcing it, and for applying the appropriate duties and parameters in the enforcement. You need a response on the server. This approach can reduce the risk of the registry as a whole, which makes it possible to remove data in the form of signature-modified data upon such data changes within the normal operating period and can be performed by, for example, far fewer signature servers than registry applications. Because there is. In addition, additional variations and applications related to TLD-specific signature parameter loading, such as increased application complexity and increased risk of false alterations that cause digital signatures to fail, require the client to not provide the signature server. In conclusion, the client does not need to pass the signature server of the TLD specific signature parameter with each request, which reduces network load and enables more realization.

In general, in accordance with aspects of the present invention, the signature server can be modified to allow developers to plug-in 'smart' services, which have knowledge of the activation key, which is what algorithms are used on the context basis of the signature request. You may have knowledge, such as cognition or whether it contains this information at all. This is desirable for certain contexts, where it means that the client persists as 'dumb' as possible. This can be used, for example, to reduce the chance of a client operating on information that has already elapsed over time, or the opportunity not to operate at the same time with a key state, to perform smaller packets.

As already mentioned, the signature server method and apparatus of the present invention is adaptable to be compatible with large DNS arrays and other signing services. It is supported to be performed by, for example, providing network access, modifications, signature servers, various remote signature protocols and modifications. One non-limiting embodiment is supported, including 'inline signature' alignment, which is used for the DNSSEC signature function in this specification, the details of which are shown in FIG. As shown in FIG. 11, the requestor 1000, such as, for example, a registrar, registrar or DNS provider, may communicate with the registry provisioning system 1100. The requestor 1000 may communicate instructions relating to an existing or new domain. For example, the requestor 1000 may communicate instructions for changing DNS data managed by the registry, such as DNS data for a domain, under a TLD (eg, .com) managed by the registry. The registry provisioning system 1100 may process domain commands from the requestor 1000 to perform change commands, such as add, modify, or delete commands, for example, in various ways, and may also verify appropriate keys, apply digital signatures, DNS data changes, such as checking the persistence of DNS and DNSSEC changes, can be seen on the registry database 1200.

The data provided by the registry provisioning system 1100 to the registry database 1200 may include DNS information for the domain and signed DNSSEC data. In an embodiment of the present invention, an exemplary signature server may be supported, for example, capable of performing DNS changes and DNSSEC changes in a single transaction.

As mentioned above, DNSSEC signing is performed by the signing server inline simultaneously with the transaction. A separate service can be used to perform transactions within the registry database, which can be incrementally applied to DNS servers.

DNSSEC inline signatures, including domain instructions in the domain registry, provide the best advantage of maintaining data purity, for example, to ensure that the registry database always represents an authoritative server for publishing in DNS.

A network cluster and a high performance signature server that can be utilized as one of DNSSEC inline signing methods are shown in FIGS. 1 and 2 and may be provided for signing DNSSEC information. It can be found to be effective even within the context of very large TLDs, and can not only sustain domain registry response time SLAs, but also maintain DNS publishing SLAs with a very high level of purity, which can simultaneously hold more than 1,000 from clients requiring digital signatures. It can be connected and serviced.

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. 12, 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 (32)

Iii) a processor; And
Ii) a storage device comprising computer readable code;
In the modified DNSSEC signature server for interaction between at least one DNSSEC client application and a plurality of digital signature modules,
The server acts as an authoritative server when run by a process
Iii) receiving a signature request from at least one client application for signing first data;
Ii) determining at least one of an active KSK and an active ZSK for the first data;
Iii) sending the first data to one of the plurality of digital signature modules;
Iii) receiving a digital signature version of the first data from the digital signature module; And
Iii) providing the first data signed to the client application;
DNSSEC signing server, characterized by.
The method of claim 1, wherein the signature server
Iii) receiving a signature request of the second data as part of the same signature request;
Ii) determining at least one active KSK and active ZSK for the second data and determining what is different from the at least one active KSK and / or active ZSK for the first data;
Iii) sending second data to one of the plurality of digital signature modules;
Iii) receiving a digital signature version of the second data from the digital signature module; And
Iii) providing the second data signed to the client application;
The signature server further modified to have a signature server.
2. The signature server of claim 1, wherein the first data includes DNS data and the digital signature module is adapted to be signed with a particular portion of DNS data according to the DNSSEC protocol without signature of the entire zone.
4. The signature server of claim 3, wherein the signature server is further modified to provide additional non-DNSSEC digital signature functionality.
The method of claim 1, wherein the signature server
Iii) receiving multiple signature requests as part of a single request packet; And
Ii) analyzing a request packet capable of identifying different signature requests having at least one different active KSK, an active ZSK and a different signature protocol;
And further modified to have a signature server.
The signature server of claim 1, wherein the at least one active KSK and the active ZSK are determined based on a TLD indicator included in a signature request.
7. The method of claim 6, wherein the signature server distinguishes the requested signature function from a plurality of different digital signature functions by means of a service type identifier included in a signature request and based on the non-service type indicator. A signature server further modified to route non-DNSSEC signing requests to the DNSSEC digital signature module.
2. The digital signature module of claim 1, wherein each digital signature module includes a hardware security module (HSM) that is physically separate from the processor of the signature server and modified to digitally sign data provided by the signature server. Signing server.
9. The HSM of claim 8, wherein the HSM includes a plurality of keys identified by an alias marker, and the signature server sends DNS data to the digital signature module without passing at least one KSK and ZSK to the digital signature module. And further modified to pass at least one KSK for and an alias marker for ZSK.
10. The system of claim 9, wherein the signature server periodically checks a database of active KSKs or ZSKs and determines which alias markers have been active for a period of time based on information received from the database, passing the digital signature module. Signature server, characterized in that the alias marker is an active alias marker.
10. The signature server of claim 9, wherein the server is further modified to identify a specific HSM for transmitting first data based on at least one active KSK and / or active ZSK.
2. The signature server of claim 1, wherein the signature server is further modified to handle requests for domains under different top level domains.
The signature server of claim 1, wherein the signature server is further modified to handle requests regarding at least two domains managed by multiple registrars.
2. The signature server of claim 1, wherein the communication between the client and the signature server is performed via bidirectional SSL.
The method of claim 1, wherein the signature server
Iii) determining at least one activation key and / or activation algorithm for the first data;
Ii) sending an indicator for at least one activation key and / or activation algorithm to the digital signature module;
Iii) receiving a plurality of digital signature versions of the first data from the digital signature module; And
Iii) providing the client application with multiple digital signatures of the first data;
A signature server, characterized in that it is modified to perform.
The signature server of claim 1, wherein the digital signature module dynamically loads at least one of an active KSK and an active ZSK for the first data from a database in response to receiving the first data.
A method of encrypting DNS information by a modified DNSSEC signature server for interaction between at least one DNSSEC client application and multiple digital signature modules, the method comprising:
The method
Iii) receiving a signature request from at least one client application for signing the first data;
Ii) determining at least one of an active KSK and an active ZSK for the first data;
Iii) transmitting the first data to one of the plurality of digital signature modules;
Iii) receiving a digital signature version of the first data from the digital signature module; And
Iii) providing first signed data to the client application;
Encryption method of DNS information, characterized in that consisting of.
18. The method of claim 17, wherein the method is
Iii) receiving a signature request of the second data as part of the same signature request;
Ii) determining at least one active KSK and active ZSK for the second data and determining what is different from the at least one active KSK and / or active ZSK for the first data;
Iii) sending second data to one of the plurality of digital signature modules;
Iii) receiving a digital signature version of the second data from the digital signature module; And
Iii) providing signed second data to the client application;
Encryption method characterized in that it further comprises.

18. The method of claim 17, wherein the first data includes DNS data and the digital signature module is modified to be signed with a particular portion of DNS data according to the DNSSEC protocol without signing the entire zone.
20. The method of claim 19, wherein the signature server is further modified to provide additional non-DNSSEC digital signature functionality.
18. The method of claim 17, wherein the method comprises receiving multiple signing requests as part of a single request packet, wherein the method is capable of identifying different signing requests with at least one different active KSK, an active ZSK, and a different signature protocol. Encrypting the request packet.
18. The method of claim 17, wherein the at least one active KSK and the active ZSK are determined based on a TLD indicator included in a signature request.
23. The method of claim 22, wherein the method distinguishes a requested signature function from a plurality of different digital signature functions by means of a service type identifier included in a signature request and based on the service type indicator. And routing the non-DNSSEC signature request to the DNSSEC digital signature module.
18. The system of claim 17, wherein each digital signature module comprises a hardware security module (HSM) that is physically separate from the processor of the signature server and modified to digitally sign data provided by the signature server. Encryption method.
25. The method of claim 24, wherein the HSM includes a plurality of keys identified by alias markers, the method for DNS data in a digital signature module without passing at least one KSK and ZSK through the digital signature module. And passing the alias markers for at least one KSK and ZSK.
27. The digital signature module of claim 25, further comprising periodically checking a database of active KSKs or ZSKs and determining which alias markers have been active for a period of time based on information received from the database. And wherein the alias marker passed in is an active alias marker.
27. The method of claim 25, wherein the method further comprises identifying a particular HSM for transmitting the first data based on at least one active KSK and / or active ZSK.
18. The method of claim 17, further comprising processing requests for domains under different Top Level Domains.
18. The method of claim 17, further comprising processing a request for at least two domains managed by a plurality of registrars.
18. The method of claim 17, wherein communication between the client and the signing server is performed via two-way SSL.
18. The method of claim 17, wherein the method is
Iii) determining at least one activation key and / or activation algorithm for the first data;
Ii) sending an indicator for at least one activation key and / or activation algorithm to the digital signature module;
Iii) receiving a plurality of digital signature versions of the first data from the digital signature module; And
Iii) providing a plurality of digital signature copies of the first data to the client application;
Encryption method characterized in that it further comprises.
18. The method of claim 17, wherein the method further comprises dynamically loading at least one of an active KSK and an active ZSK for the first data from the database in response to receiving the first data.

Images