WO2010033126A1

WO2010033126A1 - Certificate based dns name space control

Info

Publication number: WO2010033126A1
Application number: PCT/US2008/077197
Authority: WO
Inventors: Juha Hietasarka
Original assignee: Nokia Corporation; Nokia, Inc
Priority date: 2008-09-22
Filing date: 2008-09-22
Publication date: 2010-03-25

Abstract

A user may desire to register a fully qualified domain name with a domain name system (DNS). A user computer may transmit a certificate signing request (CSR) to a certificate authority (CA). The CSR may include a reference to the fully qualified domain name. The CA may validate the user computer's credentials and may verify that the fully qualified domain name is unique or authorized to be modified by the user. The CA may transmit a signed certificate to the user computer, the certificate including authorization for the user to adopt or modify the fully qualified domain name. Thereafter, the user computer may transmit a request to register/modify the fully qualified domain name with the DNS.

Description

CERTIFICATE BASED DNS NAME SPACE CONTROL

FIELD

[0001] Aspects of the invention generally relate to computer networking. More specifically, an apparatus, method and system are described that allow certificate authorities to provide credentials for and manage the registration of fully qualified domain names (FQDN).

BACKGROUND

[0002] Improvements in computing technologies have changed the way people accomplish various tasks. For example, some estimates indicate that between the years 1996 and 2007, the fraction of the world's population that uses the Internet grew from approximately 1% to approximately 22%. Irrespective of the actual percentages, trends suggest that the Internet will continue to grow.

[0003] A Domain Name System (DNS) associates IP addresses with domain names. In terms of accessing the Internet, a user of a client computing device typically enters into a browser's address bar a web address composed of a top-level domain name (TLD), one or more subdomain names, and a host name. The web address may be a fully qualified domain name (FQDN), uniquely representing an exact location in a DNS tree hierarchy. A resolution or mapping function is undertaken to convert the web address or FQDN into an IP address. A dynamic DNS (DDNS) system may also be used to allow users to dynamically update DNS entries for unique hosts, to update host IP addresses "on the fly," or to allow a different computing entity to reuse a specific FQDN.

[0004] Security also plays a role in one's ability to access the Internet. In addition to a FQDN in DNS, a corresponding certificate is needed to operate a transport layer security (TLS) or a secure sockets layer (SSL) based server properly. The certificate must include a FQDN that the server uses as a connection address for others and be signed by a trustworthy certificate authority (CA). As such, in order to obtain access to the Internet, two parties (DNS and CA) are required to maintain corresponding information, and all parties involved must sufficiently trust one another. Moreover, a sequence of steps is required such that one first reserves a FQDN with a DNS provider, and thereafter initiates communication with a security provider (e.g., a CA) to obtain a certificate for the FQDN. The certificate, however, does not prove that one owns the FQDN, but rather merely suggests that one is connected to the FQDN the certificate claims.

BRIEF SUMMARY

[0005] The following presents a simplified summary of aspects of the invention in order to provide a basic understanding of some aspects of the invention. This summary is not an extensive overview, and is not intended to identify key or critical elements or to delineate the scope of the claims. The following summary merely presents some concepts and aspects in a simplified form as a prelude to the more detailed description provided below.

[0006] To overcome limitations in the prior art described above, and to overcome other limitations that will be apparent upon reading and understanding the present specification, aspects of the present disclosure are directed to an apparatus, method and system for verifying a FQDN. More specifically, a FQDN may be verified by a CA as part of a signature process. A verified FQDN may be added to a signed certificate. Thereafter, the certificate may be presented to a DDNS, allowing FQDN registration to take place with respect to the DDNS.

[0007] Various aspects of the disclosure may, alone or in combination with each other, provide for FQDN verification and registration. Other various aspects may relate to a device requesting that a CA sign a certificate for a selected FQDN, receiving at the device the signed certificate including the FQDN, and requesting a DNS to add the certified FQDN to the DNS.

[0008] These and other aspects of the invention generally relate to allocating control of DNS name space(s) to a CA, thereby streamlining verification and registration processes. Authentication at a CA can utilize a device's key pair such that username and password verifications can be avoided.

BRIEF DESCRIPTION OF THE DRAWINGS

[0009] A more complete understanding of the present invention and the advantages thereof may be acquired by referring to the following description in consideration of the accompanying drawings, in which like reference numbers indicate like features, and wherein:

[0010] Figure 1 illustrates a network computing environment suitable for carrying out one or more illustrative aspects of the invention. [0011] Figure 2 illustrates a data processing architecture suitable for carrying out one or more illustrative aspects of the invention.

[0012] Figure 3 illustrates a computing architecture suitable for carrying out one or more aspects of the invention.

[0013] Figure 4 illustrates a method of practicing one or more illustrative aspects of the invention.

DETAILED DESCRIPTION

[0014] In the following description of the various embodiments, reference is made to the accompanying drawings, which form a part hereof, and in which is shown by way of illustration various embodiments in which one or more aspects of the invention may be practiced. It is to be understood that other embodiments may be utilized and structural and functional modifications may be made without departing from the scope of the present invention.

[0015] A fully qualified domain name (FQDN) is one that uniquely identifies a host (or server) on the Internet, and includes at least a host name, a second level domain name, and a top-level domain name. While a FQDN, by definition, must end with a period, most services do not require the trailing period, or instead add on a trailing period when it is otherwise missing. An example of a FQDN would be foohost.mydomain.com., where "foohost" is the name of the host server, "mydomain" is the second-level domain name, ".com" is the top- level domain name, and the trailing period indicates the end, or root, of the FQDN.

[0016] Dynamic Domain Name Systems (DDNS) provide a method, protocol, or network service capabilities for a networked device using an Internet Protocol (IP) suite to notify a domain name server to change, in real-time, an active DNS configuration of configured hostnames, addresses, or other information stored in DNS. DDNS provides for efficient use of domain name spaces, by helping to conserve and reuse addresses.

[0017] Conventional FQDN allocation takes place in accordance with a two-step process. In the first step, a domain name registrant contacts a DNS provider in order to reserve a fully qualified domain name for a specific host computer. Thereafter, in step two, the registrant contacts a security provider to obtain a certificate for the FQDN. As demonstrated herein, however, according to one aspect of the invention certificates may be used as one basis to obtain a FQDN in the first place, thereby alleviating the need to hastily acquire a domain name from a DNS before anyone else, as well as alleviating the DNS from having to undertake many of the tasks associated with verification and registration.

[0018] Figure 1 illustrates a network computing environment 100 suitable for carrying out one or more aspects of the present invention. For example, Figure 1 illustrates a first device DEVI 110 (e.g., device 212, Fig. 2) connected to a network 130 via a connection 120. Network 130 may include the Internet, an intranet, wired or wireless networks, or any other mechanism suitable for facilitating communication between computing platforms in general. Figure 1 also depicts a second device DEV2 140 (e.g., a server) connected to network 130 via a connection 150. By virtue of the connectivity as shown, DEVI 110 and DEV2 140 may communicate with one another. Such communications may enable the exchange of various types of information. For example, the communications may include data to be exchanged between DEVI 110 and DEV2 140. Such data may include images, files, and the like. The communications may further include additional information such as control information.

[0019] Connections 120 and 150 illustrate interconnections for communication purposes. The actual connections represented by connections 120 and 150 may be embodied in various forms. For example, connections 120 and 150 may be hardwired/wireline connections. Alternatively, connections 120 and 150 may be wireless connections. Connections 120 and 150 are shown in Figure 1 as supporting bi-directional communications (via the dual arrow heads on each of connections 120 and 150). Alternatively, or additionally, computing environment 100 may be structured to support separate forward (160a and 160b) and reverse (170a and 170b) channel connections to facilitate the communication.

[0020] Computing environment 100 may be carried out as part of a larger network consisting of more than two devices. For example, DEV2 140 may exchange communications with a plurality of other devices (not shown) in addition to DEVI 110. The communications may be conducted using one or more communication protocols. Furthermore, computing environment 100 may include one or more intermediary nodes (not shown) that may buffer, store, or route communications between the various devices.

[0021] Figure 2 illustrates a generic computing device 212, e.g., a desktop computer, laptop computer, notebook computer, network server, portable computing device, personal digital assistant, smart phone, mobile telephone, cellular telephone (cell phone), terminal, distributed computing network device, mobile media device, or any other device having the requisite components or abilities to operate as described herein. As shown in Figure 2, device 212 may include processor 228 connected to user interface 230, memory 234 and/or other storage, and display 236. Device 212 may also include battery 250, speaker 252 and antennas 254. User interface 230 may further include a keypad, touch screen, voice interface, four arrow keys, joy-stick, stylus, data glove, mouse, roller ball, touch screen, or the like. In addition, user interface 230 may include the entirety of or portion of display 236.

[0022] Computer executable instructions and data used by processor 228 and other components within device 212 may be stored in a computer readable memory 234. The memory may be implemented with any combination of read only memory modules or random access memory modules, optionally including both volatile and nonvolatile memory. Software 240 may be stored within memory 234 and/or storage to provide instructions to processor 228 for enabling device 212 to perform various functions. Alternatively, some or all of the computer executable instructions may be embodied in hardware or firmware (not shown).

[0023] Furthermore, the computing device 212 may include additional hardware, software and/or firmware to support one or more aspects of the invention as described herein. Device 212 may be configured to receive, decode and process digital broadband broadcast transmissions that are based, for example, on the Digital Video Broadcast (DVB) standard, such as DVB-H, DVB-T or DVB-MHP, through a specific DVB receiver 241. Digital Audio Broadcasting/Digital Multimedia Broadcasting (DAB/DMB) may also be used to convey television, video, radio, and data. The mobile device may also include other types of receivers for digital broadband broadcast transmissions. Additionally, device 212 may also be configured to receive, decode and process transmissions through FM/ AM Radio receiver 242, WLAN transceiver 243, and telecommunications transceiver 244. In at least one embodiment of the invention, device 212 may receive radio data stream (RDS) messages.

[0024] Device 212 may use computer program product implementations including a series of computer instructions fixed either on a tangible medium, such as a computer readable storage medium {e.g., a diskette, CD-ROM, ROM, DVD, fixed disk, etc.) or transmittable to computer device 212, via a modem or other interface device, such as a communications adapter connected to a network over a medium, which is either tangible (e.g., optical or analog communication lines) or implemented wirelessly (e.g., microwave, infrared, radio, or other transmission techniques). The series of computer instructions may embody all or part of the functionality with respect to the computer system, and can be written in a number of programming languages for use with many different computer architectures and/or operating systems, as would be readily appreciated by one of ordinary skill. The computer instructions may be stored in any memory device (e.g., memory 234), such as a semiconductor, magnetic, optical, or other memory device, and may be transmitted using any communications technology, such as optical infrared, microwave, or other transmission technology. Such a computer program product may be distributed as a removable storage medium with accompanying printed or electronic documentation (e.g., shrink wrapped software), preloaded with a computer system (e.g., on system ROM or fixed disk), or distributed from a server or electronic bulletin board over a network (e.g., the Internet or World Wide Web). Various embodiments of the invention may also be implemented as hardware, firmware or any combination of software (e.g., a computer program product), hardware and firmware. Moreover, the functionality as depicted may be located on a single physical computing entity, or may be divided between multiple computing entities.

[0025] In at least one embodiment, device 212 may include a mobile client implemented in a C-based, Java-based, Python-based, Flash-based or any other programming language for the Nokia® S60/S40 platform, or in Linux for the Nokia® Internet Tablets, such as N800 and N810, and/or other implementations. Device 212 may communicate with one or more servers over Wi-Fi, GSM, 3 G, or other types of wired and/or wireless connections. Mobile and non-mobile operating systems (OS) may be used, such as Windows Mobile®, Palm® OS, Windows Vista® and the like. Other mobile and non-mobile devices and/or operating systems may also be used.

[0026] By way of introduction, aspects of the disclosure provide a domain name registrant device an ability to register a certified domain name with a DNS. The registrant device may contact a CA with a selected domain name and credentials. The CA, upon receipt of the selected domain name and credentials, may sign a certificate and return the signed certificate to the registrant device. The registrant device may transmit the signed certificate (which may include the domain name) to a DNS. The DNS, upon receipt of the signed certificate, may verify the signed certificate against a stored CA certificate. After verifying the signed certificate, the DNS may add the domain name to (a listing maintained at) the DNS with an IP address the registrant device is using (or communicated in a Uniform Resource Locator (URL)). Alternatively, if the domain name already exists, the DNS may simply update the IP address.

[0027] Figure 3 depicts a computing architecture suitable for carrying out one or more aspects of the invention. As shown in Figure 3, a personal computer (PC) 305 communicates (as shown via arrow 305A) with a CA 310. Responsive to communication 305 A, CA 310 may in turn communicate (as shown via arrow 310A) with PC 305. Responsive to receipt of communication 310A from CA 310, PC 305 may communicate (as shown by arrow 305B) with DNS 315. The nature of communications 305 A, 310A, and 305B and the interactions between PC 305, CA 310, and DNS 315 will be described more fully below with respect to Figure 4. It is understood that the computer architecture of Figure 3 is merely illustrative, and that additional computing devices may be used, or substitute computing devices may be used in place of PC 305, CA 310, and DNS 315. For example, and as more fully described below, several DNSs or DDNSs may be arranged to accept certificate(s) from one CA, or multiple CAs maybe arranged to transmit certificate(s) to a single DNS or DDNS.

[0028] Figure 4 illustrates a method wherein one or more illustrative aspects of the invention may be practiced. In particular, the method of Figure 4 is described below based on the computer architecture discussed above in relation to Figure 3. It is understood that the method of Figure 4 may be adapted to accommodate modifications to the computer architecture of Figure 3 without departing from the scope and spirit of the instant disclosure.

[0029] In step 405, PC 305 may generate a key pair. In particular, PC 305 may generate a private key and a public key. The public key may be included/transmitted in a certificate signing request (CSR) as described below with respect to step 410, and the private key may be kept a secret by PC 305 and used to digitally sign the entire CSR.

[0030] In step 410, PC 305 may communicate 305 A with CA 310. The nature of communication 305 A may include a CSR. Communication 305 A may include a selected or desired FQDN, as well as a username, a password, and/or other proof(s) of identity. Communication 305A is effectively a request by PC 305 for a specific FQDN.

[0031] In step 415, CA 310 may validate the username, password, or other proof(s) of identity provided by PC 305 by way of communication 305 A (as described above in step 410). If PC 305 failed to include information required by CA 310 to perform validation, CA 310 may issue a request (not shown in Figures 3 or 4) that PC 305 provide such information. In regards to the validation, in some embodiments CA 310 may utilize PC 305' s key pair so that a username and password can be completely eliminated. Specifically, CA 310 may decrypt a submission using the public key, and may therefore know that PC 305 signed the submission with the corresponding private key. Hash values may also be used to confirm that data has not been manipulated.

[0032] In step 420, CA 310 may verify that the FQDN selected by PC 305 (and communicated to CA 310 by virtue of communication 305 A and step 410) is unique. In some embodiments, CA 310 may have its own (DNS) name database for purposes of maintaining a listing of allocated FQDNs, and the operational DNS 315 may be used to maintain DNS names that subscribers have registered with certificates as more fully described below. In alternative embodiments, CA 310 may access DNS 315 to check address records (A-Records), mail exchange records (MX-Records), canonical name records (CName Records) and the like. CA 310 may engage in a DNS query to determine if an FQDN is in use. If the FQDN is not in use, the CA may sign the certificate as more fully described below. An agreement may be arranged between CA 310 and DNS 315 as to one or more domains, e.g., *. mydomain.com. managed by DNS 315.

[0033] As part of step 420, CA 310 may also verify that a username or password (or other credentials) match with an original creator of the selected FQDN, if the desired FQDN has already been established (e.g., a user desires to change a FQDN as opposed to establish a new one).

[0034] In step 425, after confirming that the FQDN can be assigned or modified as requested, CA 310 may sign a certificate using a private key belonging to CA 310. The signed certificate may include information indicating that the FQDN has been assigned to a user associated with PC 305. The certificate may further include the public key of the entity to whom the FQDN has been assigned or on whose behalf the FQDN has been modified. For example, the FQDN may be added to the common name (CN) and/or alternateSubjectName fields of the certificate, and may include the public key of a user associated with PC 305. The signed certificate thereby acts as authorization for the user to whom the certificate is given to register or modify the desired FQDN. As such, CA 310 may provide for namespace control by utilizing certificates as primary permissions for DNS services. [0035] In step 430, CA 310 transmits the signed certificate to PC 305 by way of communication 310A. As described above with respect to step 425, the signed certificate may include a reference to or information regarding the FQDN.

[0036] In step 435, PC 305 receives and stores the signed certificate. PC 305 may use the signed certificate in subsequent operations with a DNS (e.g., DNS 315) as more fully described below.

[0037] In step 440, PC 305 communicates (by way of communication 305B) with DNS 315. Communication 305B may entail a request to register the FQDN that was selected by PC 305 (in step 410) and signed by CA 310 (in step 425). As such, communication 305B may include the signed certificate received and stored by PC 305 in step 435. Communication 3O5B may also include an IP address that PC 305 is using for FQDN, or alternatively an IP address with which the desired FQDN should be associated.

[0038] In step 445, DNS 315 may compare the signed certificate included in communication 305B against one or more CA certificates stored at DNS 315, for example, using a public key associated with the CA. If a match is found, DNS 315 may be assured that the credentials of PC 305 have been validated (e.g., in accordance with step 415) by a CA that DNS 315 trusts (e.g., that the signed certificate is from a trusted source), and that the FQDN included/referenced in the signed certificate is unique and authorized to be established/modified as requested (e.g., in accordance with the verification of step 420).

[0039] In step 450, DNS 315 may check to see if the FQDN included/referenced in the signed certificate already exists in DNS 315. If the FQDN already exists, DNS 315 may update a registration table relating the FQDN to a corresponding IP address based on an IP address included in communication 305B (as described above with respect to step 440). If the FQDN does not already exist, DNS 315 may create an entry in the registration table to add the FQDN and the IP address that PC 305 is using. As such, step 450 may result in a registration of an FQDN (and an IP address) or an update to an already existing registration.

[0040] It is understood that in some embodiments, one or more steps of the method described above and illustrated in Figure 4 may be optional. Additionally, steps not shown may be added without departing from the scope and spirit of the instant disclosure. [0041] Based on the foregoing description, it is understood that CAs may control namespace allocation. DNSs may assist in this control by only registering FQDNs that are included/referenced in a certificate signed by a CA. Computing resources at DNSs may be conserved because DNSs are no longer required to determine whether an FQDN selected by a device (e.g., PC 305) has already been selected by another party/computing entity. Moreover, the DNSs are not required to maintain a database related to usernames or user accounts. Accordingly, DNS implementations may be simplified by virtue of the management performed by the CAs.

[0042] Additionally, the need for backup DNS resources is mitigated because one may simply present a previously signed CA certificate to a second DNS following a failure of a first DNS. Stated in a slightly different way, the computer architecture of Figure 3 (and the method of Figure 4) distributes the risk of failure relative to traditional architectures and techniques, thereby improving overall reliability. Updates to DNSs can more readily take place in parallel, e.g., by making use of a common hardware, software, or firmware update, relative to traditional architectures.

[0043] Furthermore, additional control over FQDNs may be realized based on the method of Figure 4. For example, a validity time of a certificate can specify a time for which an FQDN registration is valid in a DNS. As such, a CA can assign ownership of an FQDN to a particular entity and control how long that entity owns the FQDN. The time of ownership may be assigned on an absolute basis (e.g., ownership expires on August 22, 2020), or alternatively, ownership may expire on a relative basis (e.g., ownership of a second FQDN expires four hours after the expiration of a first FQDN). When the ownership time expires, the DNS may delete the FQDN from an associated database. Alternatively, the DNS may do nothing responsive to the expiration. If the entity that had initially registered the FQDN with the DNS desires to renew the FQDN following expiration, that entity may be required to communicate (again) with the CA to renew the corresponding certificate, referencing the same FQDN. The CA may be able to reassign ownership rights of the FQDN to another entity after the initial entity's time has expired.

[0044] In some embodiments the CA is able to terminate ownership rights prior to the expiration of the set time that a FQDN is initially declared valid. For example, the CA may assign a previously registered FQDN to a new entity via a newly signed CA certificate. The new entity may then register the FQDN in the DNS, which may have the effect of terminating ownership rights of the FQDN with respect to the initial entity. In some embodiments, synchronization may be established between the CA and DNS to terminate ownership rights at the time that the newly signed CA certificate is assigned to the new entity. In those embodiments where synchronization between the CA and the DNS might not be present, the entity that had the initial ownership rights of the FQDN may retain the ownership rights until the new entity completes a DNS registration process. In other embodiments, the CA may maintain a revocation list where the CA can specify, via a serial number identification or the like, one or more certificates or FQDNs to revoke. The revocation list may be communicated to, e.g., a DNS, and the DNS may check to see if any entries at the DNS correspond to any entries in the revocation list. If there are any matches, the DNS may de-register the associated entries. By virtue of any of the termination schemes described above, the CA may be able to exercise control over the initial assignee of the FQDN, thereby discouraging the initial assignee from engaging in abusive or questionable practices.

[0045] Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

What is claimed is:

1. A method comprising: transmitting a certificate signing request to a certificate authority, the certificate signing request including a request for a fully qualified domain name; receiving a signed certificate from the certificate authority, the signed certificate including authorization for the fully qualified domain name; and transmitting a registration request to a domain name system, the registration request including the signed certificate.

2. The method of claim 1, further comprising: generating a key pair including a private key and a public key; and including the public key in the certificate signing request.

3. The method of claim 1, wherein the certificate signing request includes at least one of a username and password.

4. The method of claim 1, further comprising: verifying at the certificate authority that the fully qualified domain name is unique.

5. The method of claim 1, wherein the signed certificate is signed by the certificate authority using a private key belonging to the certificate authority.

6. The method of claim 1, wherein the signed certificate includes information indicating that the fully qualified domain name has been assigned to an entity receiving the signed certificate.

7. The method of claim 1, wherein the registration request includes an IP address associated with the fully qualified domain name.

8. The method of claim 1, further comprising: creating a new registration entry responsive to the registration request.

9. The method of claim 1, further comprising: updating an existing registration entry responsive to the registration request.

10. The method of claim 1, wherein the domain name system is a dynamic domain name system.

11. An apparatus comprising: a processor; and a memory having stored thereon computer executable instructions that, when executed by the processor, cause the apparatus to perform: transmitting a certificate signing request to a certificate authority, the certificate signing request including a request for a fully qualified domain name; receiving a signed certificate from the certificate authority, the signed certificate including authorization for the fully qualified domain name; and transmitting a registration request to a domain name system, the registration request including the signed certificate.

12. The apparatus of claim 11, wherein the computer executable instructions include at least one instruction that, when executed by the processor, causes the apparatus to perform: generating a key pair including a private key and a public key; and including the public key in the certificate signing request.

13. The apparatus of claim 11, wherein the signed certificate includes an indication that the fully qualified domain name is unique.

14. The apparatus of claim 11, wherein the signed certificate is signed by the certificate authority using a private key belonging to the certificate authority.

15. The apparatus of claim 11, wherein the registration request includes an IP address associated with the fully qualified domain name.

16. The apparatus of claim 11, wherein a new registration entry is generated at the domain name system responsive to the registration request.

17. The apparatus of claim 11, wherein an existing registration entry is updated at the domain name system responsive to the registration request.

18. The apparatus of claim 11, wherein the domain name system is a dynamic domain name system.

19. A computer readable storage medium having stored thereon computer executable instructions that, when executed, perform: transmitting a certificate signing request to a certificate authority, the certificate signing request including a request for a fully qualified domain name; receiving a signed certificate from the certificate authority, the signed certificate including authorization for the fully qualified domain name; and transmitting a registration request to a domain name system, the registration request including the signed certificate.

20. The computer readable storage medium of claim 19, wherein the registration request includes an IP address associated with the fully qualified domain name.

21. The computer readable storage medium of claim 19, wherein a new registration entry is generated at the domain name system responsive to the registration request.

22. The computer readable storage medium of claim 19, wherein an existing registration entry is updated at the domain name system responsive to the registration request.

23. A method comprising: receiving a certificate signing request, the certificate signing request including a request for a fully qualified domain name; validating a credential of a first entity associated with the certificate signing request; and subsequent to validating the credential, transmitting a signed certificate, the signed certificate including authorization for the fully qualified domain name.

24. The method of claim 23, wherein the signed certificate includes an indication that the fully qualified domain name is unique.

25. The method of claim 23, wherein the signed certificate includes a time duration that the first entity owns the fully qualified domain name.

26. The method of claim 25, further comprising: reassigning ownership rights of the fully qualified domain name to a second entity after an expiration of the time duration that the first entity owns the fully qualified domain name.

27. The method of claim 25, further comprising: reassigning ownership rights of the fully qualified domain name to a second entity prior to an expiration of the time duration that the first entity owns the fully qualified domain name.

28. An apparatus comprising: a processor; and a memory having stored thereon computer executable instructions that, when executed by the processor, cause the apparatus to perform: receiving a certificate signing request, the certificate signing request including a request for a fully qualified domain name; validating a credential of a first entity associated with the certificate signing request; and subsequent to validating the credential, transmitting a signed certificate, the signed certificate including authorization for the fully qualified domain name.

29. The apparatus of claim 28, wherein the signed certificate includes an indication that the fully qualified domain name is unique.

30. The apparatus of claim 28, wherein the signed certificate includes a time duration that the first entity owns the fully qualified domain name.

31. The apparatus of claim 30, wherein the computer executable instructions include at least one instruction that, when executed by the processor, cause the apparatus to perform: reassigning ownership rights of the fully qualified domain name to a second entity after an expiration of the time duration that the first entity owns the fully qualified domain name.

32. A computer readable storage medium having stored thereon computer executable instructions that, when executed, perform: receiving a certificate signing request, the certificate signing request including a request for a fully qualified domain name; validating a credential of a first entity associated with the certificate signing request; and subsequent to validating the credential, transmitting a signed certificate, the signed certificate including authorization for the fully qualified domain name.

33. The computer readable storage medium of claim 32, wherein the signed certificate includes an indication that the fully qualified domain name is unique.

34. The computer readable storage medium of claim 32, wherein the signed certificate includes a time duration that the first entity owns the fully qualified domain name.

35. The computer readable storage medium of claim 34, wherein the computer executable instructions include at least one instruction that, when executed, performs: reassigning ownership rights of the fully qualified domain name to a second entity after an expiration of the time duration that the first entity owns the fully qualified domain name.

36. The computer readable storage medium of claim 32, wherein the computer executable instructions include at least one instruction that, when executed, performs: subsequent to transmitting the signed certificate, transmitting a revocation list including the fully qualified domain name as an entry.

37. An apparatus comprising: a processor; and a memory having stored thereon computer executable instructions that, when executed by the processor, cause the apparatus to perform: receiving a signed certificate and a registration request to register a fully qualified domain name; determining that the signed certificate is from a trusted source; and modifying a registration table based on the fully qualified domain name responsive to determining that the signed certificate is from a trusted source.

38. The apparatus of claim 37, wherein the modifying of the registration table includes at least one of: creating a new entry in the registration table and updating an existing entry in the registration table.