Applications / .robot / NA2631T-T22456 · published by ICANN 7 October 2026 · snapshot 2026-10-08
.robot
StandardActiveRegistry Services, LLC, US Q1·Q25
Ultimately controlled by GoDaddy Inc. Q108 · ICANN record ↗
1. Existing Registry Operator and Affiliate of Registrars
2. Affiliated Registrars:
GoDaddy.com, LLC (IANA 146)
Bombora Technologies Pty Ltd (IANA 353)
Wild West Domains, LLC (IANA 440)
Blue Razor Domains, LLC (IANA 612)
Go China Domains, LLC (IANA 1149)
Go Canada Domains, LLC (IANA 1150)
Go Australia Domains, LLC (IANA 1151)
Go Montenegro Domains, LLC (IANA 1152)
Go France Domains, LLC (IANA 1153)
Mesh Digital Limited (IANA 1390)
123-Reg Limited (IANA 1515)
GoDaddy Online Services Cayman Islands Ltd (IANA 1659)
GoDaddy Corporate Domains, LLC (IANA 3786)
§ 1 — Meaning of the string Q118·Q120
A robot is a machine, often programmable, capable of carrying out physical tasks or sequences of actions automatically, either autonomously or under external control.
/ˈroʊbɒt/
§ 2 — Mission and purpose Q133
1. Describe the mission and purpose of the applied-for gTLD.
.robot helps robotics builders, suppliers, and research groups create a clear and memorable online presence for the machines they design, sell, and study, making it easier to be discovered and instantly understood by buyers, engineers, and the public. It turns a category everyone recognizes into a naming layer any robotics organization can claim. The result is an address that signals exactly what a site is about before a visitor reads a word.
Intended Registrants: Organizations and individuals active across the robotics ecosystem, including robotics manufacturers and hardware makers, industrial and service automation firms, robotics startups, research groups and university labs, component and sensor suppliers, and integrators who design or deploy robotic systems.
Intended Users: Engineers, buyers, procurement teams, researchers, students, hobbyists, and the general public seeking information about specific robots, robotic products, capabilities, documentation, or the companies that build and operate them.
Related Activities Supporting the Purpose:
• Awareness-building among robotics builders, suppliers, and integrators about a dedicated naming space aligned to their field.
• Registrar distribution to make the extension broadly available to interested registrants.
• Registrant education explaining how a category-specific address can clarify what an organization or product does.
• Community outreach to robotics associations, maker communities, research institutions, and industry events.
• Responsible registry operations consistent with standard obligations.
.robot gives the robotics field a naming layer that says what a site is about before a visitor reads a single line of copy. Where a generic address forces builders to explain their category, a .robot address names it directly, helping a manufacturer, lab, or product line establish a clear and memorable online presence for the machines they design, sell, or study.
The purpose is to organize identity around a single, widely understood word. A hardware maker can anchor a product family, a research group can publish a robotics platform, a component supplier can signal exactly which market it serves, and a service-robotics brand can present its offering in terms customers already recognize. In each case the address does double duty: it points to a destination and it communicates category membership.
2. Explain how this purpose is sustainable over time.
Robotics is a maturing branch of industrial and engineering practice with its own supply chains, standards bodies, degree programs, trade shows, and capital markets. That structural footprint is what makes the concept durable. Robots are built from motors, actuators, sensors, controllers, and software produced by thousands of specialized firms, and each of those firms needs to be located, compared, and integrated by the next party in the chain. The extension attaches itself to that ongoing coordination problem, which does not disappear as designs improve.
Physical machines that perform work occupy a permanent seat in modern economies. Factories, warehouses, hospitals, farms, and homes increasingly rely on them, and each deployment generates a long tail of activity that keeps a category name useful: specification, sourcing, documentation, servicing, replacement parts, and operator training. These are recurring functions tied to hardware that wears, upgrades, and gets superseded, so the demand for clear identification renews itself with every product generation rather than being satisfied once.
"Robot" has been in continuous industrial and public use for over a century and has absorbed each new wave of capability without losing its plain meaning. Whatever form the underlying machines take next, the term buyers, engineers, and regulators reach for stays the same. That linguistic constancy anchors the naming layer even as the machines it describes evolve.
§ 3 — Commitments and safeguards Q164–Q188
| More trustworthy, consumer risk, regulated sector, government reporting, harm, government function Q164–Q169 | No to each |
|---|---|
| Voluntary Safeguard PICs Q170·Q171 | None · 90 applications in the round offer some |
| Registry Voluntary Commitments Q172·Q173 | None · 5 do |
| Code of Conduct exemption requested Q185·Q188 | No |
§ 4 — All other published answers
Every other answer ICANN published for this application, in the order of the form. Contact details (Q17–Q24) are left to the ICANN record.
Q199Q2.2-1 - Provide the applying entity’s self-certification document, signed by the CEO, President, CFO, and/or equivalent officer of the applying entity. If financial statements are provided by a Qualified Parent Entity (QPE) of the applying entity, the CEO, President, CFO, and/or equivalent officer of the QPE must co-sign the certification document. The self-certification document must represent and warrant: SC2.2-1.1 - As of the submission date of the application, the applying entity is a current registry operator or an affiliated entity of a current registry operator with one or more active Registry Agreements (RA). SC2.2-1.2 - The applying entity and/or a QPE will fund the startup and long-term operation of all of the applying entity’s current gTLDs and applied-for gTLD strings. SC2.2-1.3 - The applying entity and/or its officers are bound by law in its jurisdiction to represent financial statements accurately and the applying entity is in good standing in that jurisdiction.
Q2.2-1 - Provide the applying entity’s self-certification document, signed by the CEO, President, CFO, and/or equivalent officer of the applying entity. If financial statements are provided by a Qualified Parent Entity (QPE) of the applying entity, the CEO, President, CFO, and/or equivalent officer of the QPE must co-sign the certification document. The self-certification document must represent and warrant: SC2.2-1.1 - As of the submission date of the application, the applying entity is a current registry operator or an affiliated entity of a current registry operator with one or more active Registry Agreements (RA). SC2.2-1.2 - The applying entity and/or a QPE will fund the startup and long-term operation of all of the applying entity’s current gTLDs and applied-for gTLD strings. SC2.2-1.3 - The applying entity and/or its officers are bound by law in its jurisdiction to represent financial statements accurately and the applying entity is in good standing in that jurisdiction.
Answered with a document. Attachments are not published by ICANN.
Q200Q2.3-1 - Provide a document with a list of all of the applying entity’s current gTLDs and a list of all gTLDs for entities affiliated with the applying entity (if applicable).
Q2.3-1 - Provide a document with a list of all of the applying entity’s current gTLDs and a list of all gTLDs for entities affiliated with the applying entity (if applicable).
Answered with a document. Attachments are not published by ICANN.
Q220Q5.1-1 - Provide the applying entity’s self-certification document, signed by the CEO, President, CFO and/or equivalent officer of the applying entity. The self-certification document must represent and warrant: SC5.1-1.1 - The applying entity will appropriately protect confidentiality of data and prevent unauthorized access to data and services. SC5.1-1.2 - The applying entity will maintain a mature, appropriately funded and staffed security program, following a recognized, modern security framework based on risk management (such as the ISO27000 series, COBIT, HITRUST CSF, legally required security frameworks, or equivalent). The security program must be in place prior to delegation, and exist through at least the period of the registry agreement. SC5.1-1.3 - The applying entity is aware of and has designed its systems and business to comply with the relevant privacy and security regulations for all countries in which it operates.
Q5.1-1 - Provide the applying entity’s self-certification document, signed by the CEO, President, CFO and/or equivalent officer of the applying entity. The self-certification document must represent and warrant: SC5.1-1.1 - The applying entity will appropriately protect confidentiality of data and prevent unauthorized access to data and services. SC5.1-1.2 - The applying entity will maintain a mature, appropriately funded and staffed security program, following a recognized, modern security framework based on risk management (such as the ISO27000 series, COBIT, HITRUST CSF, legally required security frameworks, or equivalent). The security program must be in place prior to delegation, and exist through at least the period of the registry agreement. SC5.1-1.3 - The applying entity is aware of and has designed its systems and business to comply with the relevant privacy and security regulations for all countries in which it operates.
Answered with a document. Attachments are not published by ICANN.
Q221Q5.2-1 - Provide the applying entity’s self-certification document, signed by the CEO, President, CFO and/or equivalent officer of the applying entity. The self-certification document must represent and warrant: SC5.2-1.1 - The applying entity will, no later than delegation of the Top Level Domain (TLD), establish a dedicated abuse point of contact responsible for addressing matters requiring expedited attention and providing a timely response to abuse complaints concerning any name registered in the TLD. SC5.2-1.2 - The applying entity will, no later than delegation of the TLD, establish, publish, and provide to ICANN the location of a mechanism for members of the public to submit reports of abuse in accordance with the current obligations of the Base RA and any Consensus Policies. SC5.2-1.3 - The applying entity has developed proposed measures for removal of orphan glue records for names removed from the zone when provided with evidence in written form that the glue is present in connection with malicious conduct (see Specification 6). SC5.2-1.4 - The applying entity has or will have at time of delegation, established policies for handling complaints regarding abuse. Such policies are to be maintained and posted publicly so that anyone can review the policies via the Internet and any other means deemed appropriate by the applying entity. The applying entity’s policies at a minimum should contain appropriate confirmation of the receipt of the abuse report, the process of review of the report, and actions that will be taken if the applying entity confirms the report is legitimate. SC5.2-1.5 - The applying entity understands that DNS Abuse is Phishing, Malware, Botnets, Pharming and Spam (when used to deliver other forms of DNS Abuse). The applying entity understands and is prepared to contribute to the mitigation or disruption of DNS Abuse in domains in the TLD zone. SC5.2-1.6 - The applying entity’s abuse response capabilities are resourced appropriately to ensure a timely and adequate investigation and response to reports of DNS Abuse. This includes capabilities to receive and evaluate evidence of DNS Abuse in reports, and to take action to stop or disrupt the DNS Abuse. SC5.2-1.7 - The applying entity is prepared to conduct periodic scans of its zone to identify if domains are being used to perpetrate DNS Abuse, and to maintain statistical reports of the scans, the findings, and actions taken.
Q5.2-1 - Provide the applying entity’s self-certification document, signed by the CEO, President, CFO and/or equivalent officer of the applying entity. The self-certification document must represent and warrant: SC5.2-1.1 - The applying entity will, no later than delegation of the Top Level Domain (TLD), establish a dedicated abuse point of contact responsible for addressing matters requiring expedited attention and providing a timely response to abuse complaints concerning any name registered in the TLD. SC5.2-1.2 - The applying entity will, no later than delegation of the TLD, establish, publish, and provide to ICANN the location of a mechanism for members of the public to submit reports of abuse in accordance with the current obligations of the Base RA and any Consensus Policies. SC5.2-1.3 - The applying entity has developed proposed measures for removal of orphan glue records for names removed from the zone when provided with evidence in written form that the glue is present in connection with malicious conduct (see Specification 6). SC5.2-1.4 - The applying entity has or will have at time of delegation, established policies for handling complaints regarding abuse. Such policies are to be maintained and posted publicly so that anyone can review the policies via the Internet and any other means deemed appropriate by the applying entity. The applying entity’s policies at a minimum should contain appropriate confirmation of the receipt of the abuse report, the process of review of the report, and actions that will be taken if the applying entity confirms the report is legitimate. SC5.2-1.5 - The applying entity understands that DNS Abuse is Phishing, Malware, Botnets, Pharming and Spam (when used to deliver other forms of DNS Abuse). The applying entity understands and is prepared to contribute to the mitigation or disruption of DNS Abuse in domains in the TLD zone. SC5.2-1.6 - The applying entity’s abuse response capabilities are resourced appropriately to ensure a timely and adequate investigation and response to reports of DNS Abuse. This includes capabilities to receive and evaluate evidence of DNS Abuse in reports, and to take action to stop or disrupt the DNS Abuse. SC5.2-1.7 - The applying entity is prepared to conduct periodic scans of its zone to identify if domains are being used to perpetrate DNS Abuse, and to maintain statistical reports of the scans, the findings, and actions taken.
Answered with a document. Attachments are not published by ICANN.
Q121As per Section 3(d) of Specification 11 of the Base Registry Agreement, a registry operator of a “generic string” may not impose eligibility criteria for registering names in the TLD that limit registrations exclusively to a single person or entity and/or that person’s or entity’s “Affiliates” (as defined in Section 2.9(c) of the Registry Agreement). “Generic String” means a string consisting of a word or term that denominates or describes a general class of goods, services, groups, organizations or things, as opposed to distinguishing a specific brand of goods, services, groups, organizations or things from those of others. Confirm that the applied-for string is not a “generic string” in which the applying entity intends to limit registrations exclusively to a single person or entity.
As per Section 3(d) of Specification 11 of the Base Registry Agreement, a registry operator of a “generic string” may not impose eligibility criteria for registering names in the TLD that limit registrations exclusively to a single person or entity and/or that person’s or entity’s “Affiliates” (as defined in Section 2.9(c) of the Registry Agreement). “Generic String” means a string consisting of a word or term that denominates or describes a general class of goods, services, groups, organizations or things, as opposed to distinguishing a specific brand of goods, services, groups, organizations or things from those of others. Confirm that the applied-for string is not a “generic string” in which the applying entity intends to limit registrations exclusively to a single person or entity.
true
Q223By submitting this Application, the applying entity confirms that it is submitting this Application with a good faith (“bona fide”) intent to operate the gTLD for which it has applied, and that the applying entity has read and understands the provisions of Section 5.2.3.1 Prohibited Communications and Activities of the Applicant Guidebook regarding the New gTLD Program rules prohibiting certain communications and activities to prevent parties from privately resolving string contention among themselves.
By submitting this Application, the applying entity confirms that it is submitting this Application with a good faith (“bona fide”) intent to operate the gTLD for which it has applied, and that the applying entity has read and understands the provisions of Section 5.2.3.1 Prohibited Communications and Activities of the Applicant Guidebook regarding the New gTLD Program rules prohibiting certain communications and activities to prevent parties from privately resolving string contention among themselves.
true
Q224By submitting this Application, the applying entity confirms that it has read and understands the provisions of Section 5.2.3.1 Prohibited Communications and Activities of the Applicant Guidebook regarding the New gTLD Program rules prohibiting certain communications and activities to prevent parties from privately resolving string contention among themselves.
By submitting this Application, the applying entity confirms that it has read and understands the provisions of Section 5.2.3.1 Prohibited Communications and Activities of the Applicant Guidebook regarding the New gTLD Program rules prohibiting certain communications and activities to prevent parties from privately resolving string contention among themselves.
true