US9715512B2 - Bulk management of registry objects - Google Patents

Bulk management of registry objects Download PDF

Info

Publication number
US9715512B2
US9715512B2 US13/871,440 US201313871440A US9715512B2 US 9715512 B2 US9715512 B2 US 9715512B2 US 201313871440 A US201313871440 A US 201313871440A US 9715512 B2 US9715512 B2 US 9715512B2
Authority
US
United States
Prior art keywords
bulk
registry
domain name
policies
domain names
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active, expires
Application number
US13/871,440
Other versions
US20130290269A1 (en
Inventor
Hui Griffiths
Srikanth Veeramachaneni
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Verisign Inc
Original Assignee
Verisign Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Verisign Inc filed Critical Verisign Inc
Priority to US13/871,440 priority Critical patent/US9715512B2/en
Assigned to VERISIGN, INC. reassignment VERISIGN, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: Griffiths, Hui, VEERAMACHANENI, SRIKANTH
Publication of US20130290269A1 publication Critical patent/US20130290269A1/en
Priority to US15/657,973 priority patent/US10061785B2/en
Application granted granted Critical
Publication of US9715512B2 publication Critical patent/US9715512B2/en
Priority to US16/106,624 priority patent/US11016950B2/en
Priority to US17/328,296 priority patent/US20210279211A1/en
Active legal-status Critical Current
Adjusted expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/21Design, administration or maintenance of databases
    • G06F17/30289
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/30Managing network names, e.g. use of aliases or nicknames
    • H04L61/3015Name registration, generation or assignment
    • H04L61/302Administrative registration, e.g. for domain names at internet corporation for assigned names and numbers [ICANN]

Definitions

  • the present disclosure relates to the field of managing domain names, and more particularly, to systems and methods for modifying domain names through bulk operations.
  • DNS Domain Name System
  • IP Internet Protocol
  • a generic top-level domain such as .COM or .NET
  • ccTLD country-code top-level domain
  • SLD second-level level domain
  • a subdomain of a TLD including gTLD and ccTLD
  • .COM is the TLD
  • EXAMPLE is the SLD for the domain name “www.example.com.”
  • Registries manage the domain names of each TLD.
  • Verisign is a well-known registry, and it manages the .COM and .NET TLDs.
  • the registry responsible for a TLD is required to maintain a certain minimum amount of information associated with the domain name to ensure proper identification, security features, ownership, operability, and other attributes associated with the domain name.
  • all domain registrants are required to make available to the registry or the registrar their current administrative contact information.
  • the registry in order for a domain name to work correctly, the registry must have nameserver information for the domain name to load into the registry's TLD DNS system to refer outside DNS requests to the proper authoritative DNS servers.
  • Other information encoded in the registry can include the registrar through which the domain name's registration took place, the registration date, the expiration date, and the status of the domain name.
  • Registries often need to modify a set of data encoded in their data stores on a large-scale bulk or batch basis. For example, registries may need to transfer a large number of registered domain names from one owner to another, for instance when corporate entities merge or otherwise change. Registries may need to update the records in their data stores to transfer domains from one registrar to another registrar. Registries may need to perform these and other update operations at once or concurrently. These operations can include updating the domain names' statuses, expiration dates, or associated nameservers. Registries may modify a bulk set of domain names for their own maintenance purposes, and/or may be required to do so by ICANN, a court order, or other third-party entity. In cases, the domain names themselves may be updated, and in cases, attributes associated with the domain names can in addition or instead be updated.
  • Modifying a bulk set of domain names typically involves a high level of coordination among multiple registry administrators, and typically requires manual checks to ensure that proper action is taken in handling the data update. In carrying out these update operations, the chance of introducing data faults or programmatic errors is high.
  • a registry administrative user must manually modify each domain name in a bulk request, with or without the assistance of a bulk tool, which could require the handling of thousands of domain names.
  • Successfully completing the various modifications, without making mistakes or causing other unintended impacts to related data demands someone with expertise in the data structures and content of the registry's system (e.g., a “super user”). Even with a highly experienced user, a great deal of time and care is required to perform large-scale update operations on a registry. And when those operations are carried out, it is not uncommon to discover that at least some of the updates to the registry could or have caused violations of underlying registry policy, data dependency problems, and/or other programmatic faults.
  • FIG. 1 illustrates an exemplary system for modifying domain names through bulk operations using the disclosed embodiments.
  • FIG. 2 illustrates an exemplary method for determining priority levels to employ for use cases for executing bulk operations using the disclosed embodiments.
  • FIG. 3 illustrates an exemplary list of use cases and priority levels for implementing the disclosed embodiments.
  • FIG. 4 illustrates an exemplary table of use cases for implementing the disclosed embodiments.
  • FIG. 5 illustrates an exemplary subsystem for modifying domain names through bulk operations, in which a bulk processing engine polls a job queue, modifies domain names in a domain name database, and generates a report using the disclosed embodiments.
  • FIG. 6 illustrates an exemplary method for modifying domain names in response to a request using the disclosed embodiments.
  • FIG. 1 illustrates a system 100 for managing a large number of domain names through bulk operations.
  • a user 102 may receive a request to modify information associated with a number of domain names (which can be referred to as a “bulk request”) from a requester 101 .
  • User 102 can be a user of a registry that manages the TLD of the subject domain names.
  • Requester 101 could include a third-party entity such as ICANN, a court submitting a court order requesting modification, a corporation, or another third-party.
  • third-party requester 101 may include the registry itself that manages the TLD of the domain names. Thus, registries may on their own decide to modify information associated with a large number of domain names, at once.
  • Bulk management user interface 103 may be configured to allow user 102 to define custom parameters for the pending job. Bulk management user interface 103 may also be configured to display to user 102 information related to the status of the job, such as whether the job is still pending, is executing, or has been completed. Bulk management user interface 103 may in implementations be or include a software application running on a server. In other embodiments, it may be or include a Web interface with access available only to qualified registry users.
  • Registry database 105 may contain one or more additional databases, such as a domain name database 107 , which stores administrative information and other data relating to each domain name in a particular TLD.
  • Registry database 105 may have an associated bulk processing engine 104 , which can be or include hardware, software, communications resources configured to assist in the management of update operations of the registry database 105 .
  • the bulk processing engine 104 can organize, maintain, and store data, software, and/or other resources to carry out update operations on the registry database 105 and associated data on an automated, scheduled, and/or otherwise programmatic basis.
  • Registry database 105 may store information that the bulk processing engine 104 may use to process the jobs in queue 106 .
  • Registry database 105 may likewise have an associated set of registry policies 115 which govern the operation of the registry database 105 , including to ensure data consistency, verify fault-fee data dependencies, maintain data privacy and/or security, and other desired features.
  • FIG. 2 illustrates a method 200 used by a registry for storing information that bulk processing engine 104 may use to process the jobs in queue 106 .
  • processing can begin in 202 .
  • a registry may define a particular action to be performed on information associated with a bulk set of domain names. Registries may, in cases, designate these actions as “use cases” or “bulk operations.” Each use case or bulk operation can have a unique set of parameters and built-in validation to enable user 102 to execute them safely.
  • FIG. 3 illustrates exemplary use cases 301 of bulk operations to be performed on information associated a bulk set of domain names. For example, in one embodiment a registry may determine the need to modify the expiration date of a large set of domain names.
  • a registry may designate this use case as a “BulkUpdate 302 .”
  • a registry may determine the need to transfer ownership of a bulk set of domain names from a first owner to a second owner, which task can be designated as a “BulkTransfer 303 .”
  • Other use cases or operations are possible.
  • the bulk processing engine 104 can validate or normalize the requested job or actions against the set of registry policies 115 . For instance, the bulk processing engine 104 can identify requested actions which would results in a change or update to a domain name and/or other record which has the status of “pending delete” or “pending transfer.” The bulk processing engine 104 can suspend or deny those operations, since those records are scheduled to be removed from or moved within the registry database 105 . The bulk processing engine 104 can test the requested job or actions against other types of status or attributes associated with the records of the registry database 105 , as well. Bulk processing engine 104 can likewise enforce other kinds of policies during bulk processing operations, such as for instance security policies involving privilege rights of users.
  • a registry may assign a priority for a particular use case.
  • the priority of a use case may determine when bulk processing engine 104 processes the job related to a bulk set of domain names.
  • FIG. 3 also illustrates exemplary priority levels 304 for any given use case (low/high), but it will be appreciated that other types of priorities may be used.
  • a priority level of HighPriority 305 indicates that the use case will always get processed at the immediate next available time.
  • a first job designated as HighPriority 305 will be processed after all other jobs designated as HighPriority 305 —that were created and entered into queue 106 before the first job—get processed.
  • a priority level of LowPriority 306 indicates that the use case will get processed, but not during a certain time interval and/or before high-priority tasks.
  • this time interval can reflect the time when the registry's servers are typically busiest (e.g., a “peak period”).
  • a registry may not want bulk processing engine 104 to make modifications to the registry's system during those peak periods, because it would overload the system, risking malfunction.
  • this time interval can be from 2:00 PM to 4:00 PM during weekdays or at other times, but will be appreciated that other intervals can be used to identify peak periods or other periods of interest.
  • a registry may store the use case and (and any assigned priority for that use case) in a local database.
  • FIG. 4 illustrates an exemplary table of stored use cases 401 .
  • a registry may store BulkUpdate 302 as one of the bulk operations to be performed on a bulk set of domain names and may assign it HighPriority 305 .
  • Table 401 also illustrates that a registry may store BulkTransfer 303 as a bulk operation, assigning it LowPriority 306 .
  • a registry may store one or more use cases and associated priority levels in registry database 105 or other storage, accessible by bulk processing engine 104 .
  • a registry may also from time to time modify its use cases and/or their priority levels. For example, a registry may add a new use case and assign it a priority level, or a registry may delete use cases.
  • a registry may change the stored or preassigned priority level of a particular use case. For example, in one embodiment, a registry may change the priority level of BulkUpdate 302 in table 401 ( FIG. 4 ) from HighPriority 305 to LowPriority 306 .
  • bulk processing engine 104 may store the use case and its priority in a local database or other data store.
  • a registry may then send updates to bulk processing engine 104 reflecting changes to the use cases or their priority levels.
  • Bulk processing engine 104 uses the use cases and their stored priorities in determining how and when to process each job created by user 102 .
  • the registry 105 can carry out the selected or scheduled use case and/or other action.
  • the registry 105 can generate a report and/or store results, for audit or other purposes.
  • processing can return to a prior processing point, jump to a further processing point, or end.
  • FIG. 5 illustrates aspects of a subsystem 500 for bulk processing engine 104 to perform bulk operations on information associated with a set of domain names.
  • bulk processing engine 104 may poll queue 106 in registry database 105 to determine whether any new jobs have been added to queue 106 . If bulk processing engine 104 determines that a new job exists, it may determine whether the job is ready to be executed, according to its priority level. For example, at 2:30 PM bulk processing engine 104 may determine that a new job has been created in queue 106 , whose use case is BulkTransfer 303 ( FIG. 4 ).
  • bulk processing engine 104 may then determine that BulkTransfer 303 has been assigned LowPriority 306 , meaning that this job cannot be executed from 2:00 PM to 4:00 PM or other peak period. In this case, bulk processing engine 104 will not immediately process this job and will wait until the job can be executed, according to its priority level. Bulk processing engine 104 can continue to poll queue 106 for jobs that are ready to be executed.
  • a job processor 501 in bulk processing engine 104 may process the job. For example, in one embodiment, if the job indicates BulkUpdate 302 is to be performed on 1,000 domain names, job processor 501 will update the expiration date of each of the 1,000 domain names in domain name database 107 . Thus, job processor 501 can operate asynchronously of user 102 and other registry system operations. In this manner, user 102 can schedule in advance multiple jobs to be processed by job processor 501 in bulk processing engine 104 .
  • bulk processing engine 104 can be configured to keep reports for purposes of an audit trail of the modifications performed on the information in domain name database 107 .
  • a report handler 502 in bulk processing engine 104 may track the modifications performed to registry data, and generate a report detailing the operations performed by job process 501 .
  • Report handler 502 may send the report to user 102 , for instance via an e-mail message and/or other messaging format. The report may deliver the results of the job, and can if desired be customized based on the use case.
  • report handler 502 in addition or instead may deliver the report to bulk management user interface 103 ( FIG. 1 ), which can be accessed and viewed by user 102 .
  • Report handler 502 may provide the current status of the job in bulk management user interface 103 .
  • report handler 502 may indicate that the job is waiting for execution, currently being executed, or completed.
  • registry database 105 will reflect the changes to the information associated with domain names that were requested in the user's job request. Those changes in registry database 105 and/or other data stores may be pushed to one or more resolution services.
  • the resolution services may include a DNS resolution server 110 for the Internet 111 , a WHOIS server 108 , a billing application 109 , and/or other server, application, or service.
  • DNS resolution server 110 may store a mapping of the modified domain names to IP addresses.
  • WHOIS server 108 may store administrative and contact data regarding the customers (e.g., registrants) that have created the domain names.
  • Billing application 109 may store and process financial information regarding the domain names. For example, in performing the bulk operation on information associated with a bulk set of domain names, the registrant who should be billed for the registration of the domain name may change as a result of the bulk operation. The new registrant's information may be propagated to billing application 109 and/or other application or services, so that it can bill the correct entity for the domain name registration.
  • FIG. 6 illustrates a method 600 for performing bulk operations on information associated with a bulk set of domain names.
  • processing can begin.
  • user 102 ( FIG. 1 ) may receive a request to modify information associated with a bulk set of domain names.
  • User 102 may receive the request from third-party requester 101 , from the registry itself, and/or from other sources.
  • user 102 may determine a use case of the request. For example, user 102 may determine that the request seeks for a registry to update the expiration dates of a set of domain names, in one operation. In that case, user 102 may determine that the use case of the request is BulkUpdate 302 ( FIG. 3 ) and the priority of BulkUpdate 302 is HighPriority 305 ( FIGS. 3-4 ).
  • user 102 may create a job for the request, for instance using bulk management user interface 103 .
  • user 102 may generate or specify customized policies or parameters for one or more of the domain names or other records in the subject set of domain names. For example, in embodiments, user 102 may want to skip domain names that have a particular status, such as “pending transfer” or “pending delete.” If a particular domain name is pending transfer to another owner, user 102 may not want bulk processing engine 104 to modify the expiration date of that domain name so that it can be transferred to the new owner, as is. Other situations may exist where user 102 may want customized policies for a particular domain name or based on other factors.
  • the customized policies specified by the user can be received, stored, modified, and/or applied by the policy engine 503 ( FIG. 5 ), and/or by other logic or services.
  • user 102 may prevent the bulk operation from being executed on a particular domain name or sets of domain names, by generating customized policies, when desired.
  • the policy engine 503 can, in general, validate or rectify any user-supplied policies against the set of registry policies 115 , to ensure that the parameters supplied by the user do not cause a conflict or fault in the data or the execution of the user's job. In this manner, even though the job created by user 102 will include every domain name in the bulk set, bulk processing engine 104 will only modify those domain names according to both the use case, the set of registry policies 115 , and the user-supplied customized policies.
  • user 102 may submit the job to queue 106 ( FIG. 1 ) to be processed.
  • the job may now contain the use case or other specification of the request, the priority of the job, and any customized policies for information related to domain names.
  • the job may indicate that the use case is BulkUpdate 302 , and the priority is HighPriority 305 ( FIGS. 3-4 ).
  • the job may contain user-supplied customized policies for domains that have a “pending transfer” or “pending delete” status, such that the BulkUpdate 302 operation does not get executed on those domain names.
  • the job may also indicate the bulk set of domain names on which BulkUpdate 302 should be executed.
  • bulk processing engine 104 can poll queue 106 to determine if the job is ready to be executed. In embodiments, bulk processing engine 104 can determine whether other jobs in queue 106 were created before the instant job, and if so, whether those other jobs have the same or different comparative priority as the instant job. Thus, in some embodiments, bulk processing engine 104 may first execute other jobs that have the same priority level but earlier queue entry time as the instant job. In other embodiments, bulk processing engine 104 may determine that the instant job's priority indicates that it should not yet be executed.
  • the instant job had a priority of LowPriority 306 , and bulk processing engine 104 polled queue 106 at 2:30 PM, it may determine that the instant job should not yet be executed. In that case, bulk processing engine 104 can continue to query queue 106 to determine if other jobs are ready to be executed.
  • bulk processing engine 104 may modify information related to the bulk set of domain names (indicated in the job) according to the use case or other update specifications or details, and the customized policies indicated in the job, if any.
  • bulk processing engine 104 may store information relating to the job in a local database or other data store.
  • Bulk processing engine 104 may execute the bulk operation of the job on each domain name in the bulk set of domain names. As a result, bulk processing engine 104 can modify information in the registry database 105 , and any of its constituent parts such as domain name database 107 , and/or other associated records.
  • user 102 may at times want to reverse the bulk operations performed on a bulk set of domain names.
  • user 102 may create a new job in step 603 ( FIG. 6 ) to be executed by bulk processing engine 104 ( FIG. 5 ).
  • the new job may indicate to bulk processing engine 104 to reverse the changes made in the previous job, such that the information associated with the subject domain names reverts back to their original state.
  • one bulk processing engine 104 operates to control one registry database 105
  • one bulk processing engine 104 can control and manage multiple databases for one or more registries.
  • the bulk processing engine 104 can be implemented as multiple servers, platforms, applications, and/or services, including applications, data, and/or services hosted in a cloud-based network.
  • Other resources described as singular or integrated can in embodiments be plural or distributed, and resources described as multiple or distributed can in embodiments be combined. The scope of the present teachings is accordingly intended to be limited only by the following claims.

Abstract

A system and method for modifying a bulk set of domain names through bulk operations. A request to modify a bulk set of data associated with domain names is received by a registry. A bulk processing engine associated with the registry can analyze the requested update job, and enforce compliance with a set of policies governing the operation of registry. A priority level can also be assigned to the requested job, so that it will be executed before or after other pending jobs. The user can likewise provide user-supplied policies, which can also be validated against the set of registry policies. Data faults can be reduced or eliminated, and update operations can be performed by comparatively inexperienced personnel.

Description

RELATED APPLICATIONS
This application is related, and claims priority, to U.S. Provisional Application No. 61/639,751, filed Apr. 27, 2012, entitled “Bulk Management of Registry Objects,” by the same inventors herein, assigned or under obligation of assignment to the same entity as this application, and which provisional application is incorporated by reference in its entirety.
FIELD
The present disclosure relates to the field of managing domain names, and more particularly, to systems and methods for modifying domain names through bulk operations.
BACKGROUND
The Domain Name System (DNS) allows people using the Internet to refer to domain names, rather than Internet Protocol (IP) addresses, when accessing websites and other online services. Domain names, which employ text characters, such as letters, numbers, and hyphens (e.g., “www.example.com”), will often be easier to remember than IP addresses, which are numerical and do not contain letters or hyphens (e.g., “128.1.0.0”).
Domains exist at various different levels within the DNS hierarchy. For example, a generic top-level domain (gTLD), such as .COM or .NET, is a domain at the highest level in the DNS hierarchy. Another type of TLD is a country-code top-level domain (ccTLD) such as, for example, .UK. A second-level level domain (SLD) is a subdomain of a TLD (including gTLD and ccTLD), which is directly below the TLD in the DNS hierarchy. For example, .COM is the TLD and EXAMPLE is the SLD for the domain name “www.example.com.”
Registries manage the domain names of each TLD. For example, Verisign is a well-known registry, and it manages the .COM and .NET TLDs. To maintain a domain name in accordance with current regulations mandated by Internet Corporation for Assigned Names and Numbers (ICANN), the registry responsible for a TLD is required to maintain a certain minimum amount of information associated with the domain name to ensure proper identification, security features, ownership, operability, and other attributes associated with the domain name. For example, all domain registrants are required to make available to the registry or the registrar their current administrative contact information. Also, in order for a domain name to work correctly, the registry must have nameserver information for the domain name to load into the registry's TLD DNS system to refer outside DNS requests to the proper authoritative DNS servers. Other information encoded in the registry can include the registrar through which the domain name's registration took place, the registration date, the expiration date, and the status of the domain name.
Registries often need to modify a set of data encoded in their data stores on a large-scale bulk or batch basis. For example, registries may need to transfer a large number of registered domain names from one owner to another, for instance when corporate entities merge or otherwise change. Registries may need to update the records in their data stores to transfer domains from one registrar to another registrar. Registries may need to perform these and other update operations at once or concurrently. These operations can include updating the domain names' statuses, expiration dates, or associated nameservers. Registries may modify a bulk set of domain names for their own maintenance purposes, and/or may be required to do so by ICANN, a court order, or other third-party entity. In cases, the domain names themselves may be updated, and in cases, attributes associated with the domain names can in addition or instead be updated.
Modifying a bulk set of domain names typically involves a high level of coordination among multiple registry administrators, and typically requires manual checks to ensure that proper action is taken in handling the data update. In carrying out these update operations, the chance of introducing data faults or programmatic errors is high. In general, in maintenance operations as known, a registry administrative user must manually modify each domain name in a bulk request, with or without the assistance of a bulk tool, which could require the handling of thousands of domain names. Successfully completing the various modifications, without making mistakes or causing other unintended impacts to related data, demands someone with expertise in the data structures and content of the registry's system (e.g., a “super user”). Even with a highly experienced user, a great deal of time and care is required to perform large-scale update operations on a registry. And when those operations are carried out, it is not uncommon to discover that at least some of the updates to the registry could or have caused violations of underlying registry policy, data dependency problems, and/or other programmatic faults.
There accordingly exists a need to enable bulk modifications and associated large-scale operations on DNS registries, while at the same time carrying out policy enforcement and other integrity checks to ensure a complete and correct modification process which reduces or eliminates programmatic update errors. Furthermore, registries may wish to schedule large-scale update operations during times which minimize the impact on regular DNS operations. Registries may likewise desire to track update operations and generate reports on update results, for purposes of later audits, version rollbacks, or other purposes.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 illustrates an exemplary system for modifying domain names through bulk operations using the disclosed embodiments.
FIG. 2 illustrates an exemplary method for determining priority levels to employ for use cases for executing bulk operations using the disclosed embodiments.
FIG. 3 illustrates an exemplary list of use cases and priority levels for implementing the disclosed embodiments.
FIG. 4 illustrates an exemplary table of use cases for implementing the disclosed embodiments.
FIG. 5 illustrates an exemplary subsystem for modifying domain names through bulk operations, in which a bulk processing engine polls a job queue, modifies domain names in a domain name database, and generates a report using the disclosed embodiments.
FIG. 6 illustrates an exemplary method for modifying domain names in response to a request using the disclosed embodiments.
DETAILED DESCRIPTION
Reference will now be made in detail to the present embodiments of the disclosure, certain examples of which are illustrated in the accompanying drawings.
FIG. 1 illustrates a system 100 for managing a large number of domain names through bulk operations. In system 100, a user 102 may receive a request to modify information associated with a number of domain names (which can be referred to as a “bulk request”) from a requester 101. User 102 can be a user of a registry that manages the TLD of the subject domain names. Requester 101 could include a third-party entity such as ICANN, a court submitting a court order requesting modification, a corporation, or another third-party. In embodiments, third-party requester 101 may include the registry itself that manages the TLD of the domain names. Thus, registries may on their own decide to modify information associated with a large number of domain names, at once.
In conventional DNS platforms, a user would receive the request and manually modify each domain name in a registry database. Because this requires a high level of expertise, registries typically employed highly skilled users to perform the necessary modifications. The system 100, however, provides a means for enabling any user 102, including a novice user, to process the requests directly.
Once user 102 receives the request, he or she may create a job for processing the request on a batch basis, using a bulk management user interface 103. Bulk management user interface 103 may be configured to allow user 102 to define custom parameters for the pending job. Bulk management user interface 103 may also be configured to display to user 102 information related to the status of the job, such as whether the job is still pending, is executing, or has been completed. Bulk management user interface 103 may in implementations be or include a software application running on a server. In other embodiments, it may be or include a Web interface with access available only to qualified registry users.
User 102 may submit the requested job to a queue 106 in a registry database 105. Registry database 105 may contain one or more additional databases, such as a domain name database 107, which stores administrative information and other data relating to each domain name in a particular TLD. Registry database 105 may have an associated bulk processing engine 104, which can be or include hardware, software, communications resources configured to assist in the management of update operations of the registry database 105. In aspects, the bulk processing engine 104 can organize, maintain, and store data, software, and/or other resources to carry out update operations on the registry database 105 and associated data on an automated, scheduled, and/or otherwise programmatic basis. Registry database 105 may store information that the bulk processing engine 104 may use to process the jobs in queue 106. Registry database 105 may likewise have an associated set of registry policies 115 which govern the operation of the registry database 105, including to ensure data consistency, verify fault-fee data dependencies, maintain data privacy and/or security, and other desired features.
For example, FIG. 2 illustrates a method 200 used by a registry for storing information that bulk processing engine 104 may use to process the jobs in queue 106. In one embodiment, processing can begin in 202. In 204, a registry may define a particular action to be performed on information associated with a bulk set of domain names. Registries may, in cases, designate these actions as “use cases” or “bulk operations.” Each use case or bulk operation can have a unique set of parameters and built-in validation to enable user 102 to execute them safely. FIG. 3 illustrates exemplary use cases 301 of bulk operations to be performed on information associated a bulk set of domain names. For example, in one embodiment a registry may determine the need to modify the expiration date of a large set of domain names. A registry may designate this use case as a “BulkUpdate 302.” In other embodiments, a registry may determine the need to transfer ownership of a bulk set of domain names from a first owner to a second owner, which task can be designated as a “BulkTransfer 303.” Other use cases or operations are possible.
Turning back to FIG. 2, in 206, the bulk processing engine 104 can validate or normalize the requested job or actions against the set of registry policies 115. For instance, the bulk processing engine 104 can identify requested actions which would results in a change or update to a domain name and/or other record which has the status of “pending delete” or “pending transfer.” The bulk processing engine 104 can suspend or deny those operations, since those records are scheduled to be removed from or moved within the registry database 105. The bulk processing engine 104 can test the requested job or actions against other types of status or attributes associated with the records of the registry database 105, as well. Bulk processing engine 104 can likewise enforce other kinds of policies during bulk processing operations, such as for instance security policies involving privilege rights of users.
In 208, a registry may assign a priority for a particular use case. The priority of a use case may determine when bulk processing engine 104 processes the job related to a bulk set of domain names.
FIG. 3 also illustrates exemplary priority levels 304 for any given use case (low/high), but it will be appreciated that other types of priorities may be used. In terms of order or schedule of execution, in embodiments as shown, a priority level of HighPriority 305 indicates that the use case will always get processed at the immediate next available time. In some embodiments, a first job designated as HighPriority 305 will be processed after all other jobs designated as HighPriority 305—that were created and entered into queue 106 before the first job—get processed. A priority level of LowPriority 306 indicates that the use case will get processed, but not during a certain time interval and/or before high-priority tasks. In some embodiments, this time interval can reflect the time when the registry's servers are typically busiest (e.g., a “peak period”). A registry may not want bulk processing engine 104 to make modifications to the registry's system during those peak periods, because it would overload the system, risking malfunction. In cases, this time interval can be from 2:00 PM to 4:00 PM during weekdays or at other times, but will be appreciated that other intervals can be used to identify peak periods or other periods of interest.
Referring again to FIG. 2, in 210, a registry may store the use case and (and any assigned priority for that use case) in a local database. FIG. 4 illustrates an exemplary table of stored use cases 401. In table 401, a registry may store BulkUpdate 302 as one of the bulk operations to be performed on a bulk set of domain names and may assign it HighPriority 305. Table 401 also illustrates that a registry may store BulkTransfer 303 as a bulk operation, assigning it LowPriority 306.
In embodiments shown in FIG. 2, in 210 a registry may store one or more use cases and associated priority levels in registry database 105 or other storage, accessible by bulk processing engine 104. A registry may also from time to time modify its use cases and/or their priority levels. For example, a registry may add a new use case and assign it a priority level, or a registry may delete use cases. Additionally, a registry may change the stored or preassigned priority level of a particular use case. For example, in one embodiment, a registry may change the priority level of BulkUpdate 302 in table 401 (FIG. 4) from HighPriority 305 to LowPriority 306. In other embodiments, bulk processing engine 104 may store the use case and its priority in a local database or other data store. A registry may then send updates to bulk processing engine 104 reflecting changes to the use cases or their priority levels. Bulk processing engine 104 uses the use cases and their stored priorities in determining how and when to process each job created by user 102. In 212, the registry 105 can carry out the selected or scheduled use case and/or other action. In 214, the registry 105 can generate a report and/or store results, for audit or other purposes. In 216, processing can return to a prior processing point, jump to a further processing point, or end.
Referring again to FIG. 1, once user 102 submits a job to queue 106, bulk processing engine 104 will process the job according to the priority level indicated by the job's use case. FIG. 5 illustrates aspects of a subsystem 500 for bulk processing engine 104 to perform bulk operations on information associated with a set of domain names. In embodiments, bulk processing engine 104 may poll queue 106 in registry database 105 to determine whether any new jobs have been added to queue 106. If bulk processing engine 104 determines that a new job exists, it may determine whether the job is ready to be executed, according to its priority level. For example, at 2:30 PM bulk processing engine 104 may determine that a new job has been created in queue 106, whose use case is BulkTransfer 303 (FIG. 4). In embodiments, bulk processing engine 104 may then determine that BulkTransfer 303 has been assigned LowPriority 306, meaning that this job cannot be executed from 2:00 PM to 4:00 PM or other peak period. In this case, bulk processing engine 104 will not immediately process this job and will wait until the job can be executed, according to its priority level. Bulk processing engine 104 can continue to poll queue 106 for jobs that are ready to be executed.
In FIG. 5, if a job is ready to be executed, a job processor 501 in bulk processing engine 104 may process the job. For example, in one embodiment, if the job indicates BulkUpdate 302 is to be performed on 1,000 domain names, job processor 501 will update the expiration date of each of the 1,000 domain names in domain name database 107. Thus, job processor 501 can operate asynchronously of user 102 and other registry system operations. In this manner, user 102 can schedule in advance multiple jobs to be processed by job processor 501 in bulk processing engine 104.
In executing the job for a bulk set of domain names, bulk processing engine 104 can be configured to keep reports for purposes of an audit trail of the modifications performed on the information in domain name database 107. For example, if a court ordered the bulk operation on the information associated with a bulk set of domain names, a registry may want to provide a report after completing the operation to verify that it satisfied the court order. In one embodiment, a report handler 502 in bulk processing engine 104 may track the modifications performed to registry data, and generate a report detailing the operations performed by job process 501. Report handler 502 may send the report to user 102, for instance via an e-mail message and/or other messaging format. The report may deliver the results of the job, and can if desired be customized based on the use case.
In further embodiments, report handler 502 in addition or instead may deliver the report to bulk management user interface 103 (FIG. 1), which can be accessed and viewed by user 102. Report handler 502 may provide the current status of the job in bulk management user interface 103. For example, report handler 502 may indicate that the job is waiting for execution, currently being executed, or completed.
Returning to FIG. 1, once bulk processing engine 104 has executed a job in queue 106, registry database 105, potentially including domain name database 107 and/or other data stores, will reflect the changes to the information associated with domain names that were requested in the user's job request. Those changes in registry database 105 and/or other data stores may be pushed to one or more resolution services. The resolution services may include a DNS resolution server 110 for the Internet 111, a WHOIS server 108, a billing application 109, and/or other server, application, or service. DNS resolution server 110 may store a mapping of the modified domain names to IP addresses. WHOIS server 108 may store administrative and contact data regarding the customers (e.g., registrants) that have created the domain names. Billing application 109 may store and process financial information regarding the domain names. For example, in performing the bulk operation on information associated with a bulk set of domain names, the registrant who should be billed for the registration of the domain name may change as a result of the bulk operation. The new registrant's information may be propagated to billing application 109 and/or other application or services, so that it can bill the correct entity for the domain name registration.
FIG. 6 illustrates a method 600 for performing bulk operations on information associated with a bulk set of domain names. In 602, processing can begin. In 602, user 102 (FIG. 1) may receive a request to modify information associated with a bulk set of domain names. User 102 may receive the request from third-party requester 101, from the registry itself, and/or from other sources. In step 604, user 102 may determine a use case of the request. For example, user 102 may determine that the request seeks for a registry to update the expiration dates of a set of domain names, in one operation. In that case, user 102 may determine that the use case of the request is BulkUpdate 302 (FIG. 3) and the priority of BulkUpdate 302 is HighPriority 305 (FIGS. 3-4).
In step 608, user 102 may create a job for the request, for instance using bulk management user interface 103. In embodiments, user 102 may generate or specify customized policies or parameters for one or more of the domain names or other records in the subject set of domain names. For example, in embodiments, user 102 may want to skip domain names that have a particular status, such as “pending transfer” or “pending delete.” If a particular domain name is pending transfer to another owner, user 102 may not want bulk processing engine 104 to modify the expiration date of that domain name so that it can be transferred to the new owner, as is. Other situations may exist where user 102 may want customized policies for a particular domain name or based on other factors. The customized policies specified by the user can be received, stored, modified, and/or applied by the policy engine 503 (FIG. 5), and/or by other logic or services.
Thus, user 102 may prevent the bulk operation from being executed on a particular domain name or sets of domain names, by generating customized policies, when desired. The policy engine 503 can, in general, validate or rectify any user-supplied policies against the set of registry policies 115, to ensure that the parameters supplied by the user do not cause a conflict or fault in the data or the execution of the user's job. In this manner, even though the job created by user 102 will include every domain name in the bulk set, bulk processing engine 104 will only modify those domain names according to both the use case, the set of registry policies 115, and the user-supplied customized policies.
In 610, user 102 may submit the job to queue 106 (FIG. 1) to be processed. The job may now contain the use case or other specification of the request, the priority of the job, and any customized policies for information related to domain names. For example, the job may indicate that the use case is BulkUpdate 302, and the priority is HighPriority 305 (FIGS. 3-4). Further, the job may contain user-supplied customized policies for domains that have a “pending transfer” or “pending delete” status, such that the BulkUpdate 302 operation does not get executed on those domain names. The job may also indicate the bulk set of domain names on which BulkUpdate 302 should be executed.
In 612, bulk processing engine 104 (FIGS. 1 and 5) can poll queue 106 to determine if the job is ready to be executed. In embodiments, bulk processing engine 104 can determine whether other jobs in queue 106 were created before the instant job, and if so, whether those other jobs have the same or different comparative priority as the instant job. Thus, in some embodiments, bulk processing engine 104 may first execute other jobs that have the same priority level but earlier queue entry time as the instant job. In other embodiments, bulk processing engine 104 may determine that the instant job's priority indicates that it should not yet be executed. For example, if the instant job had a priority of LowPriority 306, and bulk processing engine 104 polled queue 106 at 2:30 PM, it may determine that the instant job should not yet be executed. In that case, bulk processing engine 104 can continue to query queue 106 to determine if other jobs are ready to be executed.
Once bulk processing engine 104 determines that the instant job is ready to be executed, it may modify information related to the bulk set of domain names (indicated in the job) according to the use case or other update specifications or details, and the customized policies indicated in the job, if any. In embodiments, bulk processing engine 104 may store information relating to the job in a local database or other data store. Bulk processing engine 104 may execute the bulk operation of the job on each domain name in the bulk set of domain names. As a result, bulk processing engine 104 can modify information in the registry database 105, and any of its constituent parts such as domain name database 107, and/or other associated records.
In embodiments, user 102 may at times want to reverse the bulk operations performed on a bulk set of domain names. By referencing the report generated by report handler 502 (FIG. 5), user 102 may create a new job in step 603 (FIG. 6) to be executed by bulk processing engine 104 (FIG. 5). The new job may indicate to bulk processing engine 104 to reverse the changes made in the previous job, such that the information associated with the subject domain names reverts back to their original state.
The foregoing description is illustrative, and variations in configuration and implementation may occur to persons skilled in the art. For example, while embodiments have been described in which one bulk processing engine 104 operates to control one registry database 105, in embodiments, one bulk processing engine 104 can control and manage multiple databases for one or more registries. Similarly, while embodiments have been described in which bulk processing engine 104 is configured as a single device or service, in embodiments, the bulk processing engine 104 can be implemented as multiple servers, platforms, applications, and/or services, including applications, data, and/or services hosted in a cloud-based network. Other resources described as singular or integrated can in embodiments be plural or distributed, and resources described as multiple or distributed can in embodiments be combined. The scope of the present teachings is accordingly intended to be limited only by the following claims.

Claims (20)

The invention claimed is:
1. A method of managing a domain name system, comprising:
receiving, at a domain name registry, a request for bulk modification of a set of records in the domain name registry, wherein the set of records comprises one or more records for a bulk set of domain names managed by different registrars;
designating a use case for the request for bulk modification, wherein the use case indicates that each modification of a plurality of modifications in the request for bulk modification is associated with a same type of action, and wherein the use case is associated with a set of parameters;
accessing a set of registry policies governing data stored in the domain name registry;
verifying the request for bulk modification of the set of records against the set of registry policies;
removing one or more domain names from the bulk set of domain names in response to identifying that a first requested action associated with the one or more domain names would result in a violation of a parameter of the set of parameters;
removing, based at least partially on the verification, at least one domain name from the bulk set of domain names in response to identifying that a second requested action associated with the at least one domain name would result in a violation of a registry policy of the set of registry policies; and
scheduling the programmatic execution of the bulk modification to the set of records which satisfy the set of registry policies and the set of parameters.
2. The method of claim 1, wherein the set of records further comprises attributes associated with the bulk set of domain names.
3. The method of claim 2, wherein the attributes comprise at least one of—
domain name inception data,
domain name expiration data,
domain name ownership data, or
zone data related to a domain name.
4. The method of claim 1, wherein the execution of the bulk modification comprises executing the bulk modification at a time based on a priority level associated with the use case.
5. The method of claim 4, wherein the execution of the bulk modification comprises executing the bulk modification on a batch basis.
6. The method of claim 5, wherein the execution of the bulk modification comprises executing the bulk modification at an off-peak period of the domain name registry.
7. The method of claim 1, wherein the set of registry policies comprises at least one of—
a set of security policies,
a set of data consistency policies,
a set of privacy policies, or
a set of data dependency policies.
8. The method of claim 1, further comprising generating a report of auditable results of the execution of the bulk modification.
9. The method of claim 1, further comprising performing a rollback operation on the bulk modification based on a validated user request.
10. The method of claim 1, wherein the same type of action associated with the request for bulk modification is at least one of:
an update action and the use case is a bulk update use case, or
a transfer action and the use case is a bulk transfer use case.
11. The method of claim 1, further comprising validating the set of parameters against the set of registry polices, wherein removing the one or more domain names from the set of domain names is based at least partially on the validating.
12. A system, comprising:
an interface to a registry database;
a memory storing one or more instructions; and
a processor coupled to the memory and communicating with the registry database via the interface, the processor executing the one or more instructions to perform a method comprising:
receive a request for bulk modification a set of records in a domain name registry, wherein the set of records comprises one or more records for a bulk set of domain names managed by different registrars,
designate a use case for the request for bulk modification, wherein the use case indicates that each modification of a plurality of modifications in the request for bulk modification is associated with a same type of action, and wherein the use case is associated with a set of parameters,
access a set of registry policies governing data stored in the domain name registry,
verify the request for bulk modification of the set of records against the set of registry policies,
remove one or more domain names from the bulk set of domain names in response to identifying that a first requested action associated with the one or more domain names would result in a violation of a parameter of the set of parameters,
remove, based at least partially on the verification, at least one domain name from the bulk set of domain names in response to identifying that a second requested action associated with the at least one domain name would result in a violation of a registry policy of the set of registry policies, and
schedule the programmatic execution of the bulk modification to the set of records which satisfy the set of registry policies and the set of parameters.
13. The system of claim 12, wherein the set of records further comprises attributes associated with the bulk set of domain names.
14. The system of claim 13, wherein the attributes comprise at least one of—
domain name inception data,
domain name expiration data,
domain name ownership data, or
zone data related to a domain name.
15. The system of claim 12, wherein the execution of the bulk modification comprises executing the bulk modification at a time based on a priority level associated with the use case.
16. The system of claim 15, wherein the execution of the bulk modification comprises executing the bulk modification on a batch basis.
17. The system of claim 16, wherein the execution of the bulk modification comprises executing the bulk modification at an off-peak period of the domain name registry.
18. The system of claim 12, wherein the set of registry policies comprises at least one of—
a set of security policies,
a set of data consistency policies,
a set of privacy policies, or
a set of data dependency policies.
19. The system of claim 12, wherein the processor is further configured to generate a report of auditable results of the execution of the bulk modification.
20. The system of claim 12, the method further comprising perform a rollback operation on the bulk modification based on a validated user request.
US13/871,440 2012-04-27 2013-04-26 Bulk management of registry objects Active 2034-03-07 US9715512B2 (en)

Priority Applications (4)

Application Number Priority Date Filing Date Title
US13/871,440 US9715512B2 (en) 2012-04-27 2013-04-26 Bulk management of registry objects
US15/657,973 US10061785B2 (en) 2012-04-27 2017-07-24 Bulk management of registry objects
US16/106,624 US11016950B2 (en) 2012-04-27 2018-08-21 Bulk management of registry objects
US17/328,296 US20210279211A1 (en) 2012-04-27 2021-05-24 Bulk management of registry objects

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201261639751P 2012-04-27 2012-04-27
US13/871,440 US9715512B2 (en) 2012-04-27 2013-04-26 Bulk management of registry objects

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US15/657,973 Continuation US10061785B2 (en) 2012-04-27 2017-07-24 Bulk management of registry objects

Publications (2)

Publication Number Publication Date
US20130290269A1 US20130290269A1 (en) 2013-10-31
US9715512B2 true US9715512B2 (en) 2017-07-25

Family

ID=48236685

Family Applications (4)

Application Number Title Priority Date Filing Date
US13/871,440 Active 2034-03-07 US9715512B2 (en) 2012-04-27 2013-04-26 Bulk management of registry objects
US15/657,973 Active US10061785B2 (en) 2012-04-27 2017-07-24 Bulk management of registry objects
US16/106,624 Active 2033-07-27 US11016950B2 (en) 2012-04-27 2018-08-21 Bulk management of registry objects
US17/328,296 Pending US20210279211A1 (en) 2012-04-27 2021-05-24 Bulk management of registry objects

Family Applications After (3)

Application Number Title Priority Date Filing Date
US15/657,973 Active US10061785B2 (en) 2012-04-27 2017-07-24 Bulk management of registry objects
US16/106,624 Active 2033-07-27 US11016950B2 (en) 2012-04-27 2018-08-21 Bulk management of registry objects
US17/328,296 Pending US20210279211A1 (en) 2012-04-27 2021-05-24 Bulk management of registry objects

Country Status (2)

Country Link
US (4) US9715512B2 (en)
EP (1) EP2658218A1 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11016950B2 (en) 2012-04-27 2021-05-25 Verisign, Inc. Bulk management of registry objects

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10565666B2 (en) 2011-09-26 2020-02-18 Verisign, Inc. Protect intellectual property (IP) rights across namespaces
US10237231B2 (en) 2011-09-26 2019-03-19 Verisign, Inc. Multiple provisioning object operation
US8769480B1 (en) * 2013-07-11 2014-07-01 Crossflow Systems, Inc. Integrated environment for developing information exchanges
US9380019B2 (en) * 2013-08-26 2016-06-28 Verisign, Inc. Command performance monitoring
JP2015095903A (en) * 2013-11-12 2015-05-18 ベリサイン・インコーポレイテッド Operation of multiple provisioning objects
CN112887445B (en) * 2021-01-22 2023-04-07 北京金山云网络技术有限公司 Method and device for updating domain name information and domain name server
CN116107572A (en) * 2023-04-07 2023-05-12 苏州万店掌网络科技有限公司 Batch operation persistent object method, device, computer equipment and medium

Citations (33)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020052771A1 (en) * 1998-04-30 2002-05-02 Enterworks Workflow management system, method, and medium with personal sublows
US6496855B1 (en) * 1999-03-02 2002-12-17 America Online, Inc. Web site registration proxy system
US6557169B1 (en) * 1998-10-11 2003-04-29 International Business Machines Corporation Method and system for changing the operating system of a workstation connected to a data transmission network
US6880007B1 (en) * 1999-06-07 2005-04-12 Register Com, Inc. Domain manager and method of use
US6895430B1 (en) 1999-10-01 2005-05-17 Eric Schneider Method and apparatus for integrating resolution services, registration services, and search services
US6901436B1 (en) 1999-03-22 2005-05-31 Eric Schneider Method, product, and apparatus for determining the availability of similar identifiers and registering these identifiers across multiple naming systems
US20050182781A1 (en) 2002-06-14 2005-08-18 Bertrand Bouvet System for consulting and/or updating dns servers and/or ldap directories
US6973505B1 (en) 1999-09-01 2005-12-06 Eric Schneider Network resource access method, product, and apparatus
US20060080437A1 (en) * 2004-10-13 2006-04-13 International Busines Machines Corporation Fake web addresses and hyperlinks
US7188138B1 (en) 1999-03-22 2007-03-06 Eric Schneider Method, product, and apparatus for resource identifier registration and aftermarket services
US7194552B1 (en) 1999-03-22 2007-03-20 Eric Schneider Method, product, and apparatus for requesting a network resource
US7299299B2 (en) 1999-04-22 2007-11-20 Network Solutions, Inc. Shared registration system for registering domain names
US20080016233A1 (en) 1999-03-22 2008-01-17 Eric Schneider Methods, systems, products, and devices for processing dns friendly identifiers
US20080059607A1 (en) 1999-09-01 2008-03-06 Eric Schneider Method, product, and apparatus for processing a data request
US20080071823A1 (en) * 1999-12-01 2008-03-20 Barry Fellman System with user interface for efficiently checking availability statuses of, and selecting, muliple items such as domain names
US7539774B2 (en) 2005-12-05 2009-05-26 Demand Media, Inc. Method for domain name registration and a corresponding apparatus
US7565402B2 (en) 2002-01-05 2009-07-21 Eric Schneider Sitemap access method, product, and apparatus
US7600042B2 (en) 2004-11-05 2009-10-06 Microsoft Corporation Dynamic IP address update
US7634808B1 (en) 2004-08-20 2009-12-15 Symantec Corporation Method and apparatus to block fast-spreading computer worms that use DNS MX record queries
US20100036946A1 (en) 2007-07-13 2010-02-11 Von Arx Kim System and process for providing online services
US7904898B2 (en) 2002-08-13 2011-03-08 Snapnames. Com, Inc. Pathway-specific, registry-integrated domain name registration system
US20110060950A1 (en) 2009-09-09 2011-03-10 Verisign, Inc. Method and system for recovery of a failed registry
US8015244B2 (en) 2000-11-01 2011-09-06 Snapnames.Com, Inc. Domain name acquisition and management system and method
US8037168B2 (en) 1999-07-15 2011-10-11 Esdr Network Solutions Llc Method, product, and apparatus for enhancing resolution services, registration services, and search services
US20120226606A1 (en) 2000-06-09 2012-09-06 Brown Charles P Method and system for protecting domain names
USRE43690E1 (en) 1999-03-22 2012-09-25 Esdr Network Solutions Llc Search engine request method, product, and apparatus
US8312125B1 (en) * 2010-03-12 2012-11-13 Local Corporation System and method for bulk web domain generation and management
US20120296948A1 (en) 2005-09-21 2012-11-22 Infoblox Inc. Provisional authority in a distributed database
US20120303733A1 (en) 1999-09-07 2012-11-29 Thomas C Douglass Method and System for Monitoring Domain Name Registrations
US20120304004A1 (en) 2011-05-27 2012-11-29 Verisign, Inc. Recovery of a failed registry
US20120303808A1 (en) 2011-05-24 2012-11-29 Palo Alto Networks, Inc. Using dns communications to filter domain names
US8369357B2 (en) 2006-02-28 2013-02-05 Cisco Technology, Inc. System and method for providing simultaneous handling of layer-2 and layer-3 mobility in an internet protocol network environment
USRE44207E1 (en) 1999-09-01 2013-05-07 Esdr Network Solutions Llc Network resource access method, product, and apparatus

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6895431B1 (en) * 2000-09-29 2005-05-17 Interland, Inc. Providing user access to dynamic updating of remote configuration information
US7174363B1 (en) * 2001-02-22 2007-02-06 Charles Schwab & Co., Inc. Distributed computing system architecture
US6832280B2 (en) * 2001-08-10 2004-12-14 Freescale Semiconductor, Inc. Data processing system having an adaptive priority controller
US7386633B2 (en) * 2005-04-21 2008-06-10 International Business Machines Corporation Priority based differentiated DNS processing
US7958091B2 (en) * 2006-02-16 2011-06-07 Ingrian Networks, Inc. Method for fast bulk loading data into a database while bypassing exit routines
US8473956B2 (en) * 2008-01-15 2013-06-25 Microsoft Corporation Priority based scheduling system for server
US8775381B1 (en) * 2011-05-14 2014-07-08 Pivotal Software, Inc. Parallel database mirroring
US9715512B2 (en) 2012-04-27 2017-07-25 Verisign, Inc. Bulk management of registry objects

Patent Citations (37)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020052771A1 (en) * 1998-04-30 2002-05-02 Enterworks Workflow management system, method, and medium with personal sublows
US6557169B1 (en) * 1998-10-11 2003-04-29 International Business Machines Corporation Method and system for changing the operating system of a workstation connected to a data transmission network
US6496855B1 (en) * 1999-03-02 2002-12-17 America Online, Inc. Web site registration proxy system
US20080016233A1 (en) 1999-03-22 2008-01-17 Eric Schneider Methods, systems, products, and devices for processing dns friendly identifiers
US8612565B2 (en) 1999-03-22 2013-12-17 Esdr Network Solutions Llc Fictitious domain name method, system, product, and apparatus
US6901436B1 (en) 1999-03-22 2005-05-31 Eric Schneider Method, product, and apparatus for determining the availability of similar identifiers and registering these identifiers across multiple naming systems
US8224994B1 (en) 1999-03-22 2012-07-17 Esdr Network Solutions Llc Fictitious domain name method, system, product, and apparatus
US8635340B1 (en) 1999-03-22 2014-01-21 Esdr Network Solutions Llc Method, product, and apparatus for requesting a network resource
US7188138B1 (en) 1999-03-22 2007-03-06 Eric Schneider Method, product, and apparatus for resource identifier registration and aftermarket services
US7194552B1 (en) 1999-03-22 2007-03-20 Eric Schneider Method, product, and apparatus for requesting a network resource
USRE43690E1 (en) 1999-03-22 2012-09-25 Esdr Network Solutions Llc Search engine request method, product, and apparatus
US8458161B2 (en) 1999-03-22 2013-06-04 Esdr Network Solutions Llc Method, product, and apparatus for enhancing resolution services, registration services, and search services
US7299299B2 (en) 1999-04-22 2007-11-20 Network Solutions, Inc. Shared registration system for registering domain names
US6880007B1 (en) * 1999-06-07 2005-04-12 Register Com, Inc. Domain manager and method of use
US8037168B2 (en) 1999-07-15 2011-10-11 Esdr Network Solutions Llc Method, product, and apparatus for enhancing resolution services, registration services, and search services
USRE44207E1 (en) 1999-09-01 2013-05-07 Esdr Network Solutions Llc Network resource access method, product, and apparatus
US20080059607A1 (en) 1999-09-01 2008-03-06 Eric Schneider Method, product, and apparatus for processing a data request
US6973505B1 (en) 1999-09-01 2005-12-06 Eric Schneider Network resource access method, product, and apparatus
US20120303733A1 (en) 1999-09-07 2012-11-29 Thomas C Douglass Method and System for Monitoring Domain Name Registrations
US6895430B1 (en) 1999-10-01 2005-05-17 Eric Schneider Method and apparatus for integrating resolution services, registration services, and search services
US20080071823A1 (en) * 1999-12-01 2008-03-20 Barry Fellman System with user interface for efficiently checking availability statuses of, and selecting, muliple items such as domain names
US20120226606A1 (en) 2000-06-09 2012-09-06 Brown Charles P Method and system for protecting domain names
US8015244B2 (en) 2000-11-01 2011-09-06 Snapnames.Com, Inc. Domain name acquisition and management system and method
US7565402B2 (en) 2002-01-05 2009-07-21 Eric Schneider Sitemap access method, product, and apparatus
US20050182781A1 (en) 2002-06-14 2005-08-18 Bertrand Bouvet System for consulting and/or updating dns servers and/or ldap directories
US7904898B2 (en) 2002-08-13 2011-03-08 Snapnames. Com, Inc. Pathway-specific, registry-integrated domain name registration system
US7634808B1 (en) 2004-08-20 2009-12-15 Symantec Corporation Method and apparatus to block fast-spreading computer worms that use DNS MX record queries
US20060080437A1 (en) * 2004-10-13 2006-04-13 International Busines Machines Corporation Fake web addresses and hyperlinks
US7600042B2 (en) 2004-11-05 2009-10-06 Microsoft Corporation Dynamic IP address update
US20120296948A1 (en) 2005-09-21 2012-11-22 Infoblox Inc. Provisional authority in a distributed database
US7539774B2 (en) 2005-12-05 2009-05-26 Demand Media, Inc. Method for domain name registration and a corresponding apparatus
US8369357B2 (en) 2006-02-28 2013-02-05 Cisco Technology, Inc. System and method for providing simultaneous handling of layer-2 and layer-3 mobility in an internet protocol network environment
US20100036946A1 (en) 2007-07-13 2010-02-11 Von Arx Kim System and process for providing online services
US20110060950A1 (en) 2009-09-09 2011-03-10 Verisign, Inc. Method and system for recovery of a failed registry
US8312125B1 (en) * 2010-03-12 2012-11-13 Local Corporation System and method for bulk web domain generation and management
US20120303808A1 (en) 2011-05-24 2012-11-29 Palo Alto Networks, Inc. Using dns communications to filter domain names
US20120304004A1 (en) 2011-05-27 2012-11-29 Verisign, Inc. Recovery of a failed registry

Non-Patent Citations (6)

* Cited by examiner, † Cited by third party
Title
Extended European Search Report dated Jul. 16, 2013, European Application No. EP 13165656, filed Apr. 26, 2013, pp. 1-7.
Gianpaolo Cugola et al., Processing Flows of Information: From Data Stream to Complex Event Processing, ACM Computing Surveys, vol. 44, No. 3, Article 15, Jun. 2012, pp. 1-62.
Hollenbeck et al., "Extensible Provisioning Protocol (EPP) Domain Name Mapping; rfc5731.txt", Internet Engineering Task Force, IETF; Standard, Internet Society (ISOC) 4, Rue Des Falaises CH-1205 Geneva, Switzerland, Aug. 1, 2009, pp. 1-67.
Hollenbeck et al., "Extensible Provisioning Protocol (EPP); rfc5730.txt", Internet Engineering Task Force, IETF; Standard, Internet Society (ISOC) 4, Rue Des Falaises CH-1205 Geneva, Switzerland, Aug. 1, 2009, pages.
McMillan et al., "Shared Registry System-Technical Architecture", Jan. 1, 2002, http://dnc.org.nz/content/srs-tech-architecture-v.1.2.pdf, accessed Dec. 4, 2012, pp. 1-56.
McMillan et al., "Shared Registry System—Technical Architecture", Jan. 1, 2002, http://dnc.org.nz/content/srs—tech—architecture-v.1.2.pdf, accessed Dec. 4, 2012, pp. 1-56.

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11016950B2 (en) 2012-04-27 2021-05-25 Verisign, Inc. Bulk management of registry objects

Also Published As

Publication number Publication date
US11016950B2 (en) 2021-05-25
US10061785B2 (en) 2018-08-28
US20210279211A1 (en) 2021-09-09
US20180357260A1 (en) 2018-12-13
US20130290269A1 (en) 2013-10-31
EP2658218A1 (en) 2013-10-30
US20170322953A1 (en) 2017-11-09

Similar Documents

Publication Publication Date Title
US20210279211A1 (en) Bulk management of registry objects
CN108781212B (en) White list domain name registration system
US11528250B2 (en) Verification of domain events
US9794221B2 (en) Recovery of a failed registry
US11637804B2 (en) Domain name operation verification code generation and/or verification
EP2370928B1 (en) Access control
US9613330B2 (en) Identity and access management
US8255507B2 (en) Active directory object management methods and systems
KR20090079198A (en) System and method for facilitating distribution of limited resources
US8473735B1 (en) Systems and methods for managing digital certificates
EP2587447A2 (en) Protecting intellectual property rights across namespaces
US11216423B2 (en) Granular analytics for software license management
JP2015079343A (en) Information processing system, information processing method and program
US20210182363A1 (en) Software license manager
US11522863B2 (en) Method and system for managing resource access permissions within a computing environment
US11593463B2 (en) Execution type software license management
US20040186838A1 (en) System for acquiring and managing digital records
Whited Extensible In-Band Registration
JP2008287616A (en) File access management system, access control management server, user terminal unit, and access control program

Legal Events

Date Code Title Description
AS Assignment

Owner name: VERISIGN, INC., VIRGINIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:GRIFFITHS, HUI;VEERAMACHANENI, SRIKANTH;REEL/FRAME:030297/0920

Effective date: 20130426

FEPP Fee payment procedure

Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

STCF Information on status: patent grant

Free format text: PATENTED CASE

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1551); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 4