Applicant Information

Does or will this RSP have a publicly verifiable, 3rd 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

Describe the solutions and mitigations to be used to thwart Distributed Denial of Service (DDOS) attacks against the authoritative DNS services.

Nominet employs a defence-in-depth approach to DNS operations, aligned to ISO 27001 controls, with authoritative DNS services specifically engineered to withstand volumetric and protocol-level DDoS attacks. Platform architecture and capacity: • Authoritative DNS is delivered via a global anycast network, with multiple nodes geographically distributed such that any mutli-origin DDoS would be absorbed across the entire anycast footprint. • Each node is over-provisioned commodity compute well in excess of expected traffic loads, with current typical traffic consuming less than 2% of compute capacity, leaving plenty of headroom for any DDoS event. • Both network equipment and DNS servers are deliberately over-provisioned in terms of packet-forwarding rate and compute resources, ensuring significant headroom to absorb abnormal traffic surges. Transit and upstream protections: • All authoritative DNS prefixes are announced through diverse Tier-1 IP transit providers (NTT, GTT, Arelion). Each carrier includes integrated DDoS scrubbing, engaged automatically using provider-specific signalling (typically BGP communities). • This ensures malicious or malformed traffic is dropped upstream, leaving only well-formed DNS queries reaching our infrastructure. • We intentionally avoid third-party tunnelled scrubbing services, to reduce complexity and avoid introducing a single point of failure. Peering strategy: • To improve reach and resilience, we peer at multiple IXPs including LINX (both LANs and Manchester), LINX NoVA, LONAP, AMS-IX, and SFMIX. Additional peering points are planned globally to further enhance coverage. • While IXPs themselves do not provide scrubbing, we continuously monitor traffic (using our own tooling and IXP-provided statistics) to detect anomalies. • If a peer is observed to be the source of abusive traffic, we engage directly with the peer to resolve the issue, or, if necessary, de-peer, forcing traffic to reroute via our Tier-1 providers and their scrubbing capacity. Operational assurance: • Providers notify us when scrubbing is active, and our NOC monitors traffic flows globally to confirm DNS availability across all nodes. • Because mitigation is automatic once configured, manual intervention is rarely required, ensuring authoritative DNS services remain consistently reachable even under large-scale attack conditions. • This layered strategy — combining anycast distribution, over-provisioned infrastructure, integrated Tier-1 scrubbing, and operational controls at multiple peering points — ensures Nominet’s authoritative DNS services remain highly resilient to DDoS attacks.

Does or will this RSP comply with 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

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

Describe the methods resiliency for DNS, including the use of anycast, primary and secondary DNS authoritative servers, and hidden DNS zone transfer servers.

Nominet’s DNS infrastructure is designed for scalability and reliability, powered by two independent, globally diverse Anycast networks operating on IPv4 and IPv6 ensuring 100% DNS uptime. The Anycast network is provisioned to boost global geographic coverage, adds software and hardware diversity and additional DDoS mitigation and protection. All nodes are over-provisioned with bandwidth from Tier 1 IP transit providers, and where possible, include DDoS scrubbing protections. Anycast is employed to advertise the nameserver IP prefixes to the internet ensuring that traffic is distributed across the nodes whilst also routing any given Internet endpoint automatically to the closest node to the originating client resolver. In the event of failure or maintenance of a node, traffic is seamlessly diverted to alternate nodes minimising latency to the client resolvers and mitigating DDoS attacks. For any distributed attack against a given nameserver IP, the attack traffic is distributed automatically to all nodes advertising that IP prefix dependent on the geographical and network distribution of the attack sources. No single node advertises all four prefixes. The nodes each have an IP transit connection connected to a Tier 1 IP transit provider and the prefix announcements are configured to ensure that no individual provider receives all four prefixes for either address family. To minimise the impact of issues with any given node a client resolver endpoint will be routed to at least two different nodes for the four nameserver records that Nominet host via at least two different Tier 1 IP transit providers. Nominet do not operate unicast nodes, enabling our customers to benefit from the efficiencies of Anycast. Analysis is performed to review the location of the nodes to ensure that they are strategically placed to reduce latency to consumer networks. Traffic engineering techniques may be employed if traffic is not optimal for a given client endpoint. When changes are made within the database that need to result in a change to DNS, Nominet updates the zone dynamically by pushing it into the unsigned zone master in compliance with RFC2136. The zone is then transferred to the hardened DNSSEC signer, which in turn transfers the then signed zone to a distribution server until it reaches the internet facing edge node servers. Transfers are made between trusted servers and are protected by both an IP ACL as well as transaction signatures (TSIG, RFC8945). TSIG not only adds a second layer of shared key authentication of the endpoints involved in the transfer, but also ensures that updates are not tampered with nor corrupted between servers. If the SOA serial number for a zone is identical on any two servers, then the remaining zone contents are also identical. This is used to monitor that zone file changes are successfully propagated out to all servers. Nominet monitoring systems flags and escalates anomalies for: - DNSSEC signature validity and validation against published keys - DNSSEC signature expiry - NSEC chain validity - Zone age / zone synchronisation across the server estate - DNS changes requested by the registry service are corrected and uploaded to the primary nameserver. At the point of distribution, validity, integrity and accuracy checks are run on the zone being distributed. If any changes are made, all relevant components and changes are fully tested in non-production environments before being rolled to production. Staged rollouts are deployed for changes to the DNS constellation, with updates being made and confirmed as successful to each node in turn. Changes to the DNS provisioning service are deployed to one data centre and then to the other only once confirmed as successful. At all times every change replicated through the stack in the active data centre is replicated in real time to an identical application stack in the standby data centre. Service can be switched to the other data centre with no data loss.

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 for DNS zone distribution?

Yes

Does or will this RSP have at least two Tier III or equivalent data centers having no inter-dependencies for global DNS anycast service?

Yes

Does or will this RSP have enough coverage of DNS service to accommodate failures of any DNS point-of-presence to maintain minimum Service Level Requirements?

Yes

Does or will this RSP implement RFC 1034 (“DOMAIN NAMES - CONCEPTS AND FACILITIES”)?

Yes

Does or will this RSP implement RFC 1035 (“DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION”)?

Yes

Does or will this RSP implement RFC 1123 (“Requirements for Internet Hosts -- Application and Support”)?

Yes

Does or will this RSP implement RFC 1982 (“Serial Number Arithmetic”)?

Yes

Does or will this RSP implement RFC 2181 (“Clarifications to the DNS Specification”)?

Yes

Does or will this RSP implement RFC 3226 (“DNSSEC and IPv6 A6 aware server/resolver message size requirements”)?

Yes

Does or will this RSP implement RFC 3596 (“DNS Extensions to Support IP Version 6”)?

Yes

Does or will this RSP implement RFC 3597 (“Handling of Unknown DNS Resource Record (RR) Types”)?

Yes

Does or will this RSP implement RFC 4343 (“Domain Name System (DNS) Case Insensitivity Clarification”)?

Yes

Does or will this RSP implement RFC 6891 (“Extension Mechanisms for DNS (EDNS(0)))”?

Yes

Does or will this RSP implement RFC 7766 (“DNS Transport over TCP - Implementation Requirements”)?

Yes

Does or will this RSP implement RFC 5001 (“DNS Name Server Identifier (NSID) Option”)?

Yes

Does or will this RSP operate DNS service according to RFC 6168 (“Requirements for Management of Name Servers for the DNS”)?

Yes

Does or will this RSP operate DNS service according to RFC 8906 (“A Common Operational Problem in DNS Servers: Failure to Communicate”)?

Yes

Does or will this RSP operate DNS service according to RFC 9199 (“Considerations for Large Authoritative DNS Server Operators”)?

Yes

Does or will this RSP operate DNS service according to RFC 9210 (“DNS Transport over TCP - Operational Requirements”)?

Yes

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

Yes

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

Yes

Does or will this RSP monitor all unique DNS servers of all anycast nodes?

Yes

Does or will this RSP operate authoritative DNS servers according to the IANA Technical Requirements for Authoritative Name Servers (https://www.iana.org/help/nameserver-requirements)?

Yes

Does or will this RSP meet the standards established in Specification 10 of the ICANN Registry Agreement (version 2024) with regard to DNS 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 DNS and IPv6?

Yes

Does or will this RSP regularly exercise DNS Service 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 (2024).

For over 25 years Nominet has been operating at the heart of the internet infrastructure 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 .همراه .アマゾン .亚马逊