Applicant Information

Does or will this RSP have a publicly verifiable, third-party certification (e.g. ISO 27001) held directly by the organization and relevant to the registry services under application?

Yes

Does or will this RSP have processes and controls to manage physical access to infrastructure and systems, including building access controls, security cameras and/or other sensors, physical environmental monitoring and safety equipment, and alarm systems related to the physical infrastructure?

Yes

Does or will this RSP have processes and controls to manage non-physical access to infrastructure, including network access from both internal systems and external Internet systems, intrusion detection systems, security information and event management systems, network firewalls, network segmentation and isolation, user identification and authentication, and authorization schemes?

Yes

Does or will this RSP have processes and controls pertaining to the selection of vendors and equipment suppliers, management and maintenance of assets while in use, procurement of assets, and safe disposal of assets?

Yes

Does or will this RSP routinely renew and keep safe all cryptographic material necessary for the operation of the RSP?

Yes

Does or will this RSP secure (e.g. encryption, tamper detection, etc…) at-rest data relevant to the operation of the RSP, including but not limited to DNSSEC if applicable?

Yes

Does or will this RSP secure (e.g. encryption, tamper detection, etc…) in-transit data relevant to the operation of the RSP, including but not limited to DNSSEC if applicable?

Yes

If applicable, does or will this RSP have security controls for data in virtualized environments, including controls relevant to both on-premises or private virtualization environments as well as public clouds, network isolation, memory isolation, process isolation, and hypervisor access controls?

Yes

Does or will this RSP have a senior executive primarily in charge of and responsible for security?

Yes

Does or will this RSP conduct background checks, both initial and on-going, of personnel and vendors relevant to the registry services under application?

Yes

Does or will this RSP implement BCP 38?

Yes

Does or will this RSP implement routing security of some nature, such as automated route filters, RPKI route origin validation, or other operational practices defined by the Internet Society and Global Cyber Alliance's Mutually Agreed Norms for Routing Security (MANRS)?

Yes

Describe the processes and procedures to be used to practice and ensure a successful KSK rollover for both emergency and non-emergency situations, including coordination with the DNSSEC RSP and IANA.

The main actions for a KSK roll will lie with DNSSEC RSP. The actions required for a main RSP in relation to a KSK rollover are limited to a few key areas: 1, Updating the registry database with any DS records for any in-bailiwick domains used as nameservers such that the registry generated zone is also updated, and; 2. If the main RSP is one of the IANA authorisers, then submitting and/or approving updates to the IANA root zone management system. Nominet does not routinely roll keys but ensures all operational staff are trained in the process for both emergency and non-emergency situations. Nominet regularly practise the documented process in a non-production environment and review the policy on rolling keys. DNS and DNSSEC training are periodically reviewed with all Nominet operational DNS staff.  A key difference between an emergency and non-emergency situation is the timing required for pre-publication and post-publication keys. This is decided on a case-by-case basis, taking into consideration the risks involved, and the reason for the emergency change. Nominet’s standard key rollover process will be fully automated and will follow the timing recommendations in RFC 7583. Nominet will have an emergency tested DNSSEC Policy in place that could be used to reduce the timings of that process if it was considered necessary and appropriate. Updating the registry database and generated zone: When in-bailiwick nameservers are utilised for a TLD, under the registry agreement the in-bailiwick domain must also be DNSSEC signed with a valid chain of trust. In this scenario the DNSSEC RSP must provide to Nominet any new DS records for the applicable subdomain as well as the proposed timing of when they will be added and which old records removed including the removal timings. Nominet will review the records supplied and the proposed timings in relation to the current configuration of time-to-live and confirm Nominet’s agreement or alternative proposal. Where the DNSSEC RSP and Nominet disagree on a course of action being wise the sign off will be subject to the contractual instructions from the Registry Operator at their risk. Once agreed Nominet will add or remove DS records from the registry database at the agreed times which will update the registry system generated zone. Authorising actions in IANA: One of the authorising contacts for the root zone management system will be supplied with instructions on which DS records to add for the TLD zone in the root on a requested day. The other authorising contacts will also be supplied with the instructions and asked to confirm once requested by IANA.

Does or will this RSP have documented, regular, and active practices for the maintenance of hardware relevant to the registry services under application?

Yes

Does or will this RSP have documented, regular, and active practices for the maintenance, upgrading, and patching of software relevant to the registry services under application?

Yes

Does or will this RSP have documented, regular, and active practices for the lifecycle of hardware relevant to the registry services under application?

Yes

Does or will this RSP have documented, regular, and active practices for the secure development of software?

Yes

Does or will this RSP have documented contingency plans for extraordinary scenarios regarding the maintenance of hardware relevant to the registry services under application?

Yes

Does or will this RSP have documented contingency plans for extraordinary scenarios regarding the maintenance, upgrading, and patching of software relevant to the registry services under application?

Yes

Does or will this RSP have documented contingency plans for extraordinary scenarios regarding the lifecycle of hardware relevant to the registry services under application?

Yes

Does or will this RSP have documented contingency plans for extraordinary scenarios regarding the development of software?

Yes

Does or will this RSP use Infrastructure-as-Code (IaC) to manage all systems relevant to operation of the registry services under application?

Yes

Does or will this RSP use automated orchestration to manage all systems relevant to the operation of the registry services under application?

Yes

Does or will this RSP have at least two Tier III (as defined here: https://uptimeinstitute.com/tiers) or equivalent data centers having no inter-dependencies?

Yes

Does or will this RSP have on-site backups of registration data?

Yes

Does or will this RSP have off-site backups of registration data?

Yes

Does or will this RSP practice data retention policies with regard to backups of registration data?

Yes

Does or will this RSP practice documented standards regarding media and data backups for registration data?

Yes

Does or will this RSP practice regularly scheduled validation of registration data backups, separately from recovery practices?

Yes

Does or will this RSP practice regularly scheduled recovery of registration data backups?

Yes

Does or will this RSP forbid the use of production data in testing and/or development environments?

Yes

Does or will this RSP encrypt registration data at-rest in the data store?

Yes

Does or will this RSP encrypt registration data in-transit to and from the data store?

Yes

Does or will this RSP regularly and frequently renew the cryptographic material used for the encryption of registration data both at-rest and in-transit with regard to the data store in accordance with industry best common practices?

Yes

Does or will this RSP keep safe the cryptographic material used for the encryption of registration data both at-rest and in-transit with regard to the data store in accordance with industry best common practices?

Yes

Does or will this RSP use modern and known-secure cryptographic algorithms for the encryption of registration data at-rest and in-transit with regard to the data store?

Yes

Does or will this RSP implement RFC 5730 (“Extensible Provisioning Protocol (EPP)”)?

Yes

Does or will this RSP implement RFC 5731 (“Extensible Provisioning Protocol (EPP) Domain Name Mapping”)?

Yes

Does or will this RSP implement RFC 5734 (“Extensible Provisioning Protocol (EPP) Transport over TCP”)?

Yes

Does or will this RSP implement RFC 5910 (“Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)”)?

Yes

If applicable, does or will this RSP implement RFC 5732 (“Extensible Provisioning Protocol (EPP) Host Mapping”)?

Yes

If applicable, does or will this RSP implement RFC 5733 (“Extensible Provisioning Protocol (EPP) Contact Mapping”)?

Yes

Does or will this RSP implement RFC 8334 (“Launch Phase Mapping for the Extensible Provisioning Protocol (EPP)”)?

Yes

If applicable, does or will this RSP implement RFC 8748 (“Registry Fee Extension for the Extensible Provisioning Protocol (EPP)”)?

Yes

Does or will this RSP forbid access to contacts via EPP to registrars other than the sponsoring registrar?

Yes

Provide a list of all EPP extensions to be used that are registered in the IANA EPP extensions registry, and an attestation that all EPP extensions to be used are registered with the IANA as per RFC 7451 (“Extension Registry for the Extensible Provisioning Protocol”).

The following Extensible Provisioning Protocol (EPP) extensions are registered in the IANA EPP Extensions registry and will be utilised in Nominet’s platform: - RFC 8334 Launch Phase Mapping - RFC 5910 Domain Name System Security Extensions (DNSSEC) - RFC 3915 Domain Registry Grace Period - RFC 8748 Registry Fee Extension - RFC 8495 Allocation Token Extension - Common Object Attribute (COA) Extension - RFC 8543 Organisation mapping - RFC 8544 Organisation extension - RFC 9154 Extensible Provisioning Protocol (EPP) Secure Authorization Information for Transfer Nominet can confirm that all EPP extensions used on its platform will be registered in the IANA EPP extensions registry.

Does or will this RSP forgo the use of any EPP extensions which are not registered with the IANA as per RFC 7451 (“Extension Registry for the Extensible Provisioning Protocol”)?

Yes

Does or will this RSP implement and operate EPP according to the performance requirements defined in the standards established in Specification 10 of the ICANN Registry Agreement (version 2024)?

Yes

Does or will this RSP have controls to prevent EPP misuse and ensure all registrars have fair and equal access to EPP per the standards established in Specification 9 of the ICANN Registry Agreement (version 2024)?

Yes

Does or will this RSP implement RFC 9325 (“Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)”) notwithstanding RFC 5734 (“Extensible Provisioning Protocol (EPP) Transport over TCP”)? Note: while RFC 9325 covers TLS and DTLS, EPP only uses TLS.

Yes

Does or will this RSP regularly and frequently renew the cryptographic material used to secure EPP communications in accordance with industry best common practices?

Yes

Does or will this RSP keep safe the cryptographic material used to secure EPP communication in accordance with industry best common practices?

Yes

Does or will this RSP meet the standards established in Specification 3 of the ICANN Registry Agreement (version 2024) with respect to EPP?

Yes

Does or will this RSP compartmentalize (e.g. virtualization) the EPP service in such a manner that each compartment (e.g. containers, virtual machines, physical machines) is dedicated to EPP (excluding system services such as monitoring, remote access and NTP)?

Yes

Does or will this RSP implement RFC 7480 (“HTTP Usage in the Registration Data Access Protocol (RDAP)”)?

Yes

Does or will this RSP implement RFC 7481 (“Security Services for the Registration Data Access Protocol (RDAP)”)?

Yes

Does or will this RSP implement RFC 8521 (“Registration Data Access Protocol (RDAP) Object Tagging”) for all currently operated gTLDs?

Yes

Does this RSP plan to continue to implement RFC 8521 (“Registration Data Access Protocol (RDAP) Object Tagging”) for all gTLDs operated in the future?

Yes

Does or will this RSP implement RFC 9082 (“Registration Data Access Protocol (RDAP) Query Format”)?

Yes

Does or will this RSP implement RFC 9083 (“JSON Responses for the Registration Data Access Protocol (RDAP)”)?

Yes

Does or will this RSP implement RFC 9224 (“Finding the Authoritative Registration Data Access Protocol (RDAP) Service”) for all currently operated gTLDs?

Yes

Will this RSP implement RFC 9224 (“Finding the Authoritative Registration Data Access Protocol (RDAP) Service”) for all gTLDs operated in the future?

Yes

Does or will this RSP implement the ICANN gTLD RDAP Technical Implementation Guide?

Yes

Does or will this RSP implement the ICANN gTLD RDAP Response Profile?

Yes

Provide a list of all RDAP extensions to be used.

Nominet’s RDAP implementation is compliant with the RDAP RFCs and the ICANN policy mandated gTLD RDAP profile and as such, the following published RDAP extensions will be used: - Redacted - Icann_rdap_technical_implementation_guide_1 - Icann_rdap_response_profile_1 For registry operators wishing to utilise additional extensions, we can support bespoke requests subject to the ICANN authorised usage of RDAP extension.

Does or will this RSP forgo the use of any RDAP extensions which are not registered with the IANA as per RFC 7480 (“HTTP Usage in the Registration Data Access Protocol (RDAP)”)?

Yes

Does or will this RSP meet the standards established in the Service Level Agreements specified in Specification 10 of the ICANN Registry Agreement (version 2024) with regard to RDAP?

Yes

Does or will this RSP implement methods to prevent mining of registration data via RDAP?

Yes

Does or will this RSP implement RFC 9325 (“Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)”) with respect to RDAP?

Yes

Does or will this RSP regularly and frequently renew the cryptographic material used to secure RDAP communications in accordance with industry best common practices?

Yes

Does or will this RSP keep safe the cryptographic material used to secure RDAP communication in accordance with industry best common practices?

Yes

Does or will this RSP meet the standards established in Specification 3 of the ICANN Registry Agreement (version 2024) with respect to RDAP?

Yes

Does or will this RSP compartmentalize (e.g. virtualization) the RDAP service in such a manner that each compartment (e.g. containers, virtual machines, physical machines) is dedicated to RDAP (excluding system services such as monitoring, remote access and NTP)?

Yes

Does or will this RSP meet the standards established in Specification 10 of the ICANN Registry Agreement (version 2024) with regard to RDAP and IPv4?

Yes

Does or will this RSP meet the standards established in Specification 10 of the ICANN Registry Agreement (version 2024) with regard to EPP and IPv4?

Yes

Does or will this RSP meet the standards established in Specification 10 of the ICANN Registry Agreement (version 2024) with regard to RDAP and IPv6?

Yes

Will this RSP meet the standards established in Specification 10 of the ICANN Registry Agreement (version 2024) with regard to EPP and IPv6 if requested by a registrar?

Yes

Will this RSP provide tools and mechanisms to Registry Operators for the purposes of automated processing and identification of abusive domain registrations.

Yes

Describe the EPP and RDAP status values as they relate to domain name registrations considered to be abusive registrations and those not considered to be abusive registrations.

For domain name registrations, the following EPP and RDAP server status values can be applied: 1. clientHold (EPP Status Code) / client hold (RDAP Status Mapping) The sponsoring registrar can apply this status to request that the DNS delegation information must not be published for the domain object, with the consequence that the domain name will no longer resolve on the public internet. This status is available to registrars for application when an abusive domain registration is reasonably determined based on actionable evidence. Registrars are free to offer the option of using this status to registrants for non-abuse disablement of the domain. 2. serverHold (EPP Status Code) / server hold (RDAP Status Mapping) This status removes the domain name from the TLD zone file, with the consequence that the domain name will no longer resolve on the public internet. This status code can be applied by the Registry Operator when an abusive domain registration is reasonably determined based on actionable evidence. 3. clientRenewProhibited (EPP Status Code) / client renew prohibited (RDAP Status Mapping) The sponsoring registrar can apply this status to prohibit the manual renewal of a domain whilst managing an abuse case. Some registrars may utilise this status through the normal lifecycle of a domain to prevent revenue leakage and then remove it during their renewals process. 4. serverRenewProhibited (EPP Status Code) / server renew prohibited (RDAP Status Mapping) The Registry Operator can utilise this status to prevent the manual renewal of a domain whilst managing an abuse case. 5. clientTransferProhibited (EPP Status Code) / client transfer prohibited (RDAP Status Mapping) The sponsoring registrar can apply this status to ensure that any requests to transfer the domain object must be rejected. The registrar may decide to apply this status to the abusive domain to prevent the registrant from attempting to evade the mitigation action and resume using the domain name for DNS abuse. In this instance, the registrar must comply with the applicable requirements in ICANN's Transfer Policy. Registrars should utilise this status as a matter of good practice in agreement with their registrants in securing their domain names when transfer is not required. 6. serverTransferProhibited (EPP Status Code) / server transfer prohibited (RDAP Status Mapping) The Registry Operator can apply these statuses so that requests to transfer the object must be rejected. The Registry Operator may decide to apply this status to the abusive domain to prevent the registrant from attempting to evade the mitigation or investigation action and resume using the domain name for DNS abuse. Registrants may choose to add a ‘Registry Lock’ service that adds this status for security of their domains. 7. serverDeleteProhibited (EPP Status Code) / server delete prohibited (RDAP Status Mapping) and serverUpdateProhibited (EPP Status Code) / server update prohibited (RDAP Status Mapping) Although rarely used for mitigating abusive domain registrations, the Registry Operator may opt for applying these lock statuses so that a domain cannot be deleted (serverDeleteProhibited) or have its details modified (serverUpdateProhibited). The server update prohibition should only be applied with legitimate reasons as that may hinder mitigation of abuse and/or security issues by third parties as the status blocks update to the domain object. Registrants may choose to add a ‘Registry Lock’ service that adds any of these statuses for security of their domains. Detailed descriptions can also be found in our response to question MAIN.10.2.

Describe the EPP and RDAP status values and their applicability to Uniform Rapid Suspension (URS).

Nominet will adhere to the Uniform Rapid Suspension (URS) procedure when applying EPP and RDAP status values. URS Lock: Within 24 hours of receipt of the notification by email from the URS Provider Nominet will lock the domain name by applying the following EPP and RDAP status values: - serverUpdateProhibited (EPP status code) / server update prohibited (RDAP Status Mapping) - serverTransferProhibited (EPP status code) / server transfer prohibited (RDAP Status Mapping) - serverDeleteProhibited (EPP status code) / server delete prohibited (RDAP Status Mapping) This lock will prevent all changes to the registration data of the domain, including transfer and deletion of the domain name. The domain name will continue to resolve. Nominet will deactivate the serverDeleteProhibited EPP status and it’s RDAP Status Mapping status at expiration of a URS Locked domain name. URS Suspension: In the event of a URS determination in favour of the Complainant, within 24 hours of Nominet’s receipt of notification of the determination, Nominet will ensure that the following EPP and RDAP status values are applied where the Registration Data Directory Services (RDDS) information will reflect that the domain name is not able to be transferred, deleted or modified for the life of the registration: - serverUpdateProhibited (EPP status code) / server update prohibited (RDAP Status Mapping) - serverTransferProhibited (EPP status code) / server transfer prohibited (RDAP Status Mapping) - serverDeleteProhibited (EPP status code) / server delete prohibited (RDAP Status Mapping) Domain nameservers and DNSSEC records will be configured as per determination by the URS provider. Nominet will deactivate the serverDeleteProhibited EPP status and its RDAP Status Mapping status value at expiration of a URS Suspended domain name. URS Rollback: Within 24 hours of receipt of notification by email from the URS Provider, Nominet will restore the original information of the domain name.

Does or will this RSP implement the Registry Operator-related elements of RFC9361

Yes

Describe all potential registration lifecycle(s) of domain names supported in the system.

Nominet’s platform is fully configurable and enables all registration lifecycle parameters to be configured, including the length of time of the grace period. The supporting diagrams show the overall lifecycle process. The lifecycle begins when a domain name is registered. This happens when a domain create request is received via EPP or Nominet’s Domain Manager tool. The domain name will be registered for the length of time requested by the registrar in the create request and its expiry date set accordingly. Top Level Domains (TLDs) on Nominet’s platform can be configured for registrations to complete immediately or to require approval. In this process, domain names have a pending create status until the application is approved or rejected. After a configured amount of time without approval or rejection, the application will be automatically approved or rejected depending upon the TLD configuration. During this application process, domain names are not present in the DNS. The supporting diagram demonstrates this process. Upon registration, the domain is placed in the add grace period for five days. If a domain delete request is received in this time, then the registrar receives a credit for the registration fee. The domain name remains registered until its expiry date during which time the registrar may extend the expiry date by requesting a renewal. Following a renewal, the domain is placed in the renewal grace period for five days. If a domain delete request is received during this time, then the registrar receives a credit for the renewal fee. If the domain name reaches its expiry date, then the expiry date is extended by one year and the domain is placed in the auto-renew grace period, typically for 45 days. During this time the registrar may delete the domain name and receive a credit for the auto-renewal. The registrar may also choose to convert the auto-renew grace period into the shorter renew grace period by submitting a renewal request with the pre auto-renewal expiry date during the auto renew grace period. If a delete request is received for a domain, the domain name will either be purged immediately if it is still in the add grace period, or it will be placed in a pending delete with redemption status, typically for 30 days. During this time, domain names are not present in the DNS and no registry operations will function. The domain name may be restored back to the full registered status by submitting a restore request. A registrar can request that a domain name is transferred to them. Provided that the correct authentication is completed upon such a request, the domain name is placed in a transfer pending status typically for five days. Both the requesting and current registrars are notified, and the current registrar may accept or reject the transfer in that time. Nominet’s platform can be configured to accept or reject transfers automatically when the five days expire. A successful transfer will include extending the expiry date by one year, or a longer period if the registrar requests it.

Describe the registration lifecycle(s) of domain names with respect to EPP status values and RDAP status values.

Nominet’s EPP interface is compliant with Request for Comments (RFCs) 3915, 5910, 5730, 5731, 5732, 5733 and 5734 and our RDAP service adheres to RFC 7480, RFC 7481, RFC 7482, RFC 7483, RFC 7484, RFC 8056, RFC 8605. Nominet's registry platform supports the extended registration lifecycle described in RFC 3915. Domain names have lifecycle statuses added and removed as they move through the lifecycle. The length of time that each status is added to a domain for is configurable on an individual TLD basis. The provided diagram shows how lifecycle statuses change on a domain as it moves through the registration lifecycle. Registration: The lifecycle begins when a domain is registered. TLDs on Nominet’s platform can be configured for registrations to complete immediately or to require approval. When a domain does not require approval, it is added to the registry with the addPeriod status at the point of registration, typically for five days. For TLDs that are configured to require approval, a domain is added with the pendingCreate status set. Registry Operators then either approve or a reject a domain using Nominet’s Domain Manager tool, Dragon. After a configured amount of time without approval or rejection, the application will be automatically approved or rejected depending upon the TLD configuration. If the create operation is accepted, then the domain has the pendingCreate status removed and the addPeriod status added. If the create operation is rejected, then the domain is removed from the registry and returns to the unregistered state. Expiry: If a domain reaches the end of its registration period without being renewed, then it is auto-renewed for one year and the autoRenewPeriod status is added, typically for 45 days. Renewal: When a domain is renewed by a registrar, the renewPeriod status is added replacing any other statuses, typically for five days. Renewal requests are prevented if the clientRenewProhibited or serverRenewProhibited status fields are present on the domain. Delete: A domain can be deleted by its registrar or the Registry Operator as part of lifecycle operations. If a domain is deleted when the Redemption Grace Period (RGP) addPeriod status is set, then it is purged immediately and returns to the unregistered state. If a domain is deleted after the addPeriod status has been removed then the redemptionPeriod status is added to the domain, typically for 30 days. The pendingDelete status (RFC 5731) is also added to the domain. The redemptionPeriod status remains on the domain typically for 30 days and is replaced by the pendingDelete status (RFC 3915). When the RFC 3915 pendingDelete status expires the domain is purged from the registry and returns to the unregistered state making it possible to re-register. Registrars may remove the redemptionPeriod status by submitting a restore request. This replaces the redemptionPeriod status with the pendingRestore status. On submitting a restore request the pendingRestore status is removed and the domain enters the regular lifecycle as it was prior to the redemptionPeriod being added. Delete requests are prevented if the clientDeleteProhibited or serverDeleteProhibited status fields are present on the domain. Transfers: Nominet’s supporting diagram depicts the behaviour of transfers. When a transfer request is received with a valid transfer authorisation code, the pendingTransfer status is placed on the domain, typically for five days. While this status is on the domain, the transfer may be accepted or rejected by the current registrar, or the requesting registrar may cancel it. If this is not done before the pendingTransfer status expires, then the transfer is either automatically accepted or rejected depending upon the TLD configuration. When the transfer completes the pendingTransfer status is removed and the transferPeriod status added. Transfer requests are prevented if EPP statuses clientTransferProhibited or serverTransferProhibited are set.

Describe the nameserver host lifecycle, including relevance to EPP and RDAP status values, with respect to the lifecycle of domain names. This should include a description of nameservers as either attributes of domains or as host objects.

Nameservers are represented as host objects in Nominet’s registry system. The host lifecycle starts when a host object is registered in the system. If a nameserver is in-bailiwick to the registry, then it may only be registered if the request is made by the registrar of the superordinate domain name. Host objects that are not in-bailiwick to the registry may be registered by any registrar. Once the host object has been registered then it may be associated with any domain names and its fields may be updated by the registrar that registered the object. Out-of-bailiwick host objects which are linked as nameservers of a domain controlled by another registrar cannot be renamed. When a domain name is transferred to a new registrar, all host objects that are subordinate to the domain name are also transferred to that same new registrar. A domain name cannot be deleted unless all of its sub-ordinate host objects have already been deleted. Host objects which are in-bailiwick can be renamed by the sponsoring registrar to enable the deletion of the parent domain. Host objects may only be deleted if there are no links to any registered domain names. The serverDeleteProhibited and clientDeleteProhibited EPP status fields may be set on a host object to prevent the host from being deleted. These status fields are shown in Registration Data Access Protocol (RDAP) as ‘server delete prohibited’ and ‘client delete prohibited’ respectfully. The serverUpdateProhibited and clientUpdateProhibited EPP status fields may be set on a host to prevent the host from being updated. These status fields are shown in RDAP as ‘server update prohibited’ and ‘client update prohibited’ respectfully.

If applicable, describe the contact lifecycle, including relevance to EPP and RDAP status values, with respect to the lifecycle of domain names and nameservers. Include a description of the deletion of orphaned contacts.

Nominet’s registry platform is configurable to enable contacts to be included on an individual TLD basis. The contact lifecycle starts when a contact is registered. Once a contact is registered then it can be linked to domain names. If a TLD does not include contacts in its registry then it will not be possible to create contacts. The serverDeleteProhibited and clientDeleteProhibited EPP status fields may be set on a contact to prevent the contact from being deleted. These status fields are shown in Registration Data Access Protocol (RDAP) as ‘server delete prohibited’ and ‘client delete prohibited’ respectfully. The serverUpdateProhibited and clientUpdateProhibited EPP status fields may be set on a contact to prevent the contact from being updated. These status fields are shown in RDAP as ‘server update prohibited’ and ‘client update prohibited’ respectfully. The serverTransferProhibited and clientTransferProhibited EPP status fields may be set on a contact to prevent the contact from being transferred. Contacts that have been linked to domain names remain in the data store for audit purposes in line with Nominet’s data retention policy. They are marked as ‘deleted’ one month after all links to domain names are removed and do not appear to registrars at this point. All contacts which have been registered for more than three months and have never been linked to a domain name are removed from the data store.

Does or will this RSP be capable of removing orphaned glue in accordance with the standards established in Specification 6 of the ICANN Registry Agreement (version 2024)?

Yes

Describe how this RSP will meet the standards established in Specification 2 of the ICANN Registry Agreement (version 2024), and describe any other data escrow processes. This includes escrow extensions for data related additional registry services.

Nominet will meet all requirements listed in Specification 2 of the ICANN Registry Agreement. Nominet is capable of integrating with any Escrow Agent chosen by each Registry Operator for TLDs on the Nominet platform. Each day at midnight UTC, a copy of the data required to generate the escrow deposit will be obtained. This data copy is used to generate a full escrow deposit for each TLD on the platform using the format described in RFCs 8909 and 9022. The escrow deposit includes all domain, host, contact and registrar objects in the TLD along with EPP parameters, reserved names and blocked IDN variants as described in RFC 9022. Once the deposit is complete, it is checked to ensure accuracy and completeness, that all elements are valid, and that generation did not terminate early or fail. The deposit is then compressed and encrypted as specified in Specification 2 of the ICANN Registry Agreement. A digital signature file is then generated. The encrypted data and digital signature files are then uploaded to the escrow agent using a secure channel. On successful upload, ICANN is notified of the deposit using the Registry Reporting Interfaces (RRI) system as described in Specification 2 of the ICANN Registry Agreement. If additional registry services requiring submission of additional data are required in the future, then escrow extensions will be agreed with ICANN and included in deposits.

Does or will this RSP regularly exercise registry continuity actions?

Yes

Does or will this RSP be capable of transferring all applicable operations to another RSP as defined by the Material Subcontracting Arrangement Technical Questions?

Yes

Does or will this RSP participate in coordinated Emergency Back-end Registry Operator (EBERO) transitions, including but not limited to maintaining the DNSSEC chain of trust, of hosted gTLDs when the business relationship of this RSP and the Registry Operator is not in good standing?

Yes

Does or will this RSP monitor for faults inside its own network?

Yes

Does or will this RSP monitor for faults from a point outside any of its own networks?

Yes

Does or will this RSP have documented processes for aggregation and triage of faults?

Yes

Does or will this RSP have documented processes to mitigate faults once detected?

Yes

Does or will this RSP have processes to minimize faults during maintenance of systems, including both automated processes and manual change control processes?

Yes

Does or will this RSP have personnel capable of reacting to and mitigating faults 24 hours per day of every day of every year of service?

Yes

Provide documentation regarding any RSP functions currently being served for any gTLD, the domain names of the gTLDs, and all service disruptions for each gTLD in the past six months, where a service disruption is defined by Specification 10 of the ICANN Registry Agreement (version 2024).

For over 25 years Nominet has been operating at the heart of the internet as proud guardians of the .UK domain name registry. Ensuring our registry is secure and resilient is at the heart of what we do. Maintaining 100% DNS uptime since inception, our critical national infrastructure supports the UK’s online economy, connecting .uk, .cymru, .wales and client gTLDs that utilise Nominet’s platform. Nominet can confirm that in the past six months it has not experienced any service disruptions as defined by Specification 10 of the ICANN Registry Agreement (version 2024) for any of the gTLDs on its platform. Currently Nominet provides the gTLDs listed below with the Registry Services functions as specified in Specification 10 of the ICANN Registry Agreement (version 2024). These functions include DNS, Registration Data Access Protocol (RDAP), Registration Data Directory Services (RDDS), WHOIS-RDDS, and Extensible Provisioning Protocol (EPP): .abbvie .amazon .audible .author .aws .azure .bbc .bbva .bentley .bing .book .bot .broadway .buy .call .career .circle .cymru .deal .desi .fairwinds .fast .fire .free .gop .got .gucci .hot .hotmail .ieee .imdb .jobs .jot .joy .kindle .like .locus .med .microsoft .moi .mtn .now .nowruz .office .omega .pars .pay .pharmacy .pin .pioneer .pn .prime .read .realestate .realtor .room .safe .save .secure .shell .shia .silk .sky .skype .smile .spot .swatch .talk .tci .tunes .tushu .uk .virgin .wales .wanggou .wed .windows .wow .xbox .yamaxun .you .zappos .همراه .アマゾン .亚马逊