Step-by-step: respond to a UDRP complaint within the deadlin… (.dev 2)

Step-by-step: respond to a UDRP complaint within the deadlin… (.dev 2). UDRP and ccTLD domain recovery and defense across .dev. Email the firm to assess your c…

A UDRP complaint lands in your inbox. The domain is a .dev registration you built a developer tool around, held legitimately, and never used to target anyone's brand. The complainant has filed at WIPO and the clock is already running. What you do in the next 20 days decides whether you keep the domain or lose it by default.

To respond to a UDRP complaint within the deadline for a .dev domain, a registrant must file a written response with the designated provider — typically WIPO, since .dev is a gTLD governed by the full UDRP — within 20 calendar days of formal commencement. The response must address all three elements of Paragraph 4(a): confusing similarity, legitimate interest, and bad faith. Missing the deadline does not automatically end the case, but a panel will decide on the complaint alone, and default outcomes strongly favor transfer.

This guide walks each step of the response process, names the trap each step hides, and explains when an RDNH finding is a realistic outcome worth pursuing.

Why does .dev follow the UDRP, and who administers the complaint?

.dev is a generic top-level domain operated by Google Registry; it is subject to the UDRP in the same way as .com, .net, or .org. A complainant filing against a .dev domain may choose any ICANN-accredited dispute-resolution provider — WIPO, the Forum, CAC, or ADNDRC — though the overwhelming majority of .dev cases land at WIPO. That choice belongs entirely to the complainant; the registrant cannot redirect the case to a different forum.

The UDRP Rules then govern what happens next. Commencement — the formal trigger that starts the response clock — is not the day the complaint was filed. It is the day the provider confirms the complaint is formally complete and notifies the registrant. Check your email and your registrar's WHOIS contact address carefully. Providers use the contact details in the public RDDS record. If those details are stale or behind a privacy layer, you may lose days before the notification even reaches you.

The critical early trap: many registrants calculate the deadline from the date they first saw the complaint email. That is wrong. The 20-day clock runs from formal commencement, and providers calculate it from the commencement notice, not from the moment you personally read it. Confirm the commencement date with the provider immediately.

What is the 20-day response deadline, and can it be extended?

The UDRP Rules give a respondent 20 calendar days from the date of formal commencement to file a response; no day falls off for weekends or public holidays. Extensions are rare. A provider may grant additional time if both parties agree, or in exceptional circumstances at the provider's discretion — but "I was busy" or "I only just found counsel" are not typically sufficient. In practice, we advise treating the deadline as immovable from the moment commencement is confirmed.

If you cannot file a complete response in time, file a short holding response asserting your legitimate interest and requesting additional time. An incomplete but timely response is substantially better than a default. A default does not automatically transfer the domain — the panel still decides the case — but the panel will have only the complaint to read, and well-drafted complaints are written to win that scenario.

One nuance specific to .dev: because the domain requires HSTS (HTTP Strict Transport Security) by default and is commonly used by developers and technology companies, complainants sometimes file against .dev registrations owned by individual developers or small teams who may not monitor registrar communications closely. If you have privacy or proxy registration enabled, contact your registrar immediately to confirm that the provider's commencement notice was delivered to the underlying registrant contact, not only to the proxy service.

If you have just received a UDRP complaint against a .dev domain and the deadline is pressing, contact info@cognomenlaw.com for an assessment of your response options before the window closes.

How do you build the legitimate-interest record under Paragraph 4(c)?

Paragraph 4(c) of the UDRP lists three safe harbors that, if any one is established, demonstrate legitimate interest and defeat the complaint on the second element. The three are: (1) a bona fide offering of goods or services using the domain name before notice of the dispute; (2) being commonly known by the domain name; and (3) legitimate noncommercial or fair use without intent to mislead or tarnish. For a .dev registrant, the first safe harbor is usually the most relevant — and the most evidence-intensive.

Building the bona fide use record means marshaling every document that shows real, good-faith activity before the complainant's notice reached you. That typically includes: screenshots of the domain resolving to an active developer project or tool, commit logs or code repositories with timestamps, user registrations or download counts, correspondence with collaborators, domain registration records showing the date of acquisition relative to the complainant's trademark filing, and any press or community mention predating the dispute. Collect everything; you cannot introduce new evidence after the response is filed without the panel's permission, and panels rarely grant supplemental submissions.

The trap in this step is selective omission. Respondents sometimes submit only the strongest evidence and skip anything that looks complicated. Panels notice gaps. If your project had a period of low activity, address it directly. Explain the development timeline. A credible, complete narrative beats a curated highlight reel.

The second safe harbor — being commonly known by the name — applies where the domain string matches the respondent's personal name, business name, or online identity. For .dev registrations, this is common among individual developers who registered a domain matching their GitHub handle or project name years before the complainant's brand expansion reached their sector. Produce the GitHub profile, the conference talk slides, the community forum history, the WHOIS registration date. The earlier the record, the stronger the argument.

How does the response structure an answer to bad faith?

Even if legitimate interest is firmly established, a thorough response addresses bad faith directly — because panels sometimes reach all three elements even when the second is dispositive. The bad-faith analysis under Paragraph 4(b) is the most fact-driven part of the case, and every affirmative fact you omit becomes an adverse inference the panel may draw.

Respond to each Paragraph 4(b) circumstance the complainant invokes. If the complaint alleges registration to sell the domain to the mark owner, produce evidence that no such offer was made and that registration had an independent business rationale. If it alleges a pattern of abusive registrations, address your portfolio: how many domains you hold, whether any relate to third-party marks, and why they do not. If it alleges you are attracting users for commercial gain through confusion, explain how your .dev project is distinguishable and how users would not mistake your site for the complainant's brand.

The chronology matters enormously. Panels consistently look at whether the complainant's trademark was well-known in your sector at the time of registration. If the mark was filed after your domain registration, say so plainly and provide the evidence. If it was filed before but had no reputation in your geographic market or industry, make that argument with specifics. Generic technology terms and developer-facing tools frequently generate UDRP complaints from complainants who hold trademarks in adjacent markets — panels have consistently held that registration of a descriptive or generic term, without targeting, does not constitute bad faith.

In a recent matter involving a .dev domain (spring 2025), we defended a solo developer who had held the name for several years as the identity for an open-source library. The complainant held a registered mark in a different technology category and argued confusion was inevitable. We produced the developer's GitHub repository history, community forum posts predating the complaint by years, and evidence that the complainant had not marketed in the developer tools space at the time of registration. The panel denied the transfer.

When is an RDNH finding realistic, and how do you pursue it?

Reverse Domain Name Hijacking — a panel finding that the complaint was brought in bad faith to deprive a legitimate registrant — is available under the UDRP and carries real reputational weight, even though it produces no monetary penalty. RDNH is not a remedy most panels reach for lightly, but in our practice we see a clear pattern of the fact combinations that make it realistic.

An RDNH finding is most achievable when: the complainant is a sophisticated brand owner or represented by experienced counsel who should have known the complaint could not succeed; the complainant's trademark postdates the domain registration; the domain was clearly registered for a purpose unrelated to the complainant's mark; and the complaint relies on speculative or legally thin bad-faith arguments. If the complainant can see all of this and files anyway, panels have been willing to make the finding.

To pursue RDNH affirmatively, the response must explicitly request it and make the argument. Do not leave it to the panel to notice. Draft a section that walks the elements of the complainant's theory, shows each one is contradicted by the record, and identifies why counsel for the complainant — if represented — should have identified the deficiency before filing. The argument should be measured, not combative. Panels respond better to a careful factual analysis than to an accusation of abuse.

What RDNH does not do: it does not result in damages, cost recovery, or any sanction on the complainant beyond the published finding. But a published RDNH finding is indexed and publicly searchable. It affects the complainant's credibility in future proceedings. For a registrant defending a legitimate .dev project, it is also a meaningful vindication of the record you built.

See our detailed analysis of UDRP respondent defense and RDNH practice for the full doctrinal background and the evidence architecture that supports these findings.

If the complaint against your .dev domain appears to rest on a weak or speculative theory, email info@cognomenlaw.com to assess whether an RDNH argument belongs in your response.

What evidence actually decides the outcome?

Panels decide UDRP cases on written submissions alone — there is no hearing, no cross-examination, and no opportunity to clarify evidence after the record closes. The quality and completeness of what you file with the response is effectively your entire case. This is the step where most self-represented respondents underinvest.

The evidence hierarchy, in rough order of decisiveness: (1) the domain registration date relative to the trademark filing date — this is the single most frequently dispositive fact; (2) documented use of the domain before the dispute notice — code repositories, live pages, user activity; (3) the registrant's identity and its connection to the domain string — personal name, project name, sector; (4) absence of commercial benefit directed at the complainant's brand — no pay-per-click ads pointing at the mark owner, no email traffic spoofing the complainant's domain; (5) affirmative evidence of good faith — contemporaneous business correspondence, public announcements, developer community engagement.

Each exhibit should be labeled, described in the text of the response, and connected to a specific element. A panel should not have to guess what an exhibit proves. Reference each item explicitly: "Exhibit R-3 is a screenshot of the domain resolving to the respondent's open-source project as of [month, year], more than [X] months before the complaint was filed." That sentence does more work than two paragraphs of argument with no exhibit attached.

Avoid submitting undifferentiated bulk evidence. A 200-page exhibit of domain parking revenue reports — if the domain was not parked — is both irrelevant and damaging to credibility. Precision beats volume.

Should you request a three-member panel, and what does it cost?

If the complainant selected a single-member panel, the respondent may request a three-member panel. That changes the cost structure: the parties generally split the three-member panel fee, which at WIPO is USD 4,000 — meaning the respondent contributes the difference between the complainant's single-member fee and half of the three-member fee. The mechanics are set out in the UDRP Supplemental Rules of the chosen provider.

When does a three-member panel add value? For a .dev respondent, the calculus is: is the case close enough that a single panelist's disposition toward one argument could swing the outcome? Three-member panels are statistically associated with a somewhat higher rate of respondent-favorable decisions and RDNH findings in the domain-disputes community — though no outcome can be predicted. If the case involves a genuinely novel issue, a contested trademark validity question, or a prominent brand with aggressive litigation history, the incremental cost of a three-member panel deserves serious consideration.

The request for a three-member panel must be made in the response itself. It cannot be added afterward. If you are uncertain, the decision must be made within the same 20-day window as the response filing — another reason early legal engagement matters.

What is the realistic next step after you file the response?

After the response is filed, the provider appoints a panel — typically within a few days — and the panel then has 14 days to issue a decision, though extensions are common and the overall case commonly concludes within roughly two months of filing. You will receive the decision by email from the provider, and the registrar will receive implementation instructions simultaneously if the domain is ordered transferred.

During the panel deliberation period, the record is closed. Do not contact the panel directly. If genuinely new evidence emerges — material that could not have been included in the response — you may request permission to file a supplemental submission, but providers set a high bar and grant these rarely. Plan the response as though the record closes the moment you file.

If the decision transfers the domain and you believe it is wrong, two options remain: (1) seek a court order staying the registrar's implementation within 10 business days of the decision, or (2) file a de novo court action in the appropriate jurisdiction. Both require moving quickly. Court action of that kind for a .dev domain would typically implicate US anticybersquatting litigation, handled with local litigation counsel in the relevant jurisdiction. For matters where the UDRP result was a denial and the complainant pursues follow-on litigation, the same approach applies.

In a second matter we handled, a software company received a UDRP complaint against its .dev domain in autumn 2024 — the complainant asserted confusing similarity to a mark it had registered only months earlier, after the respondent had been using the domain actively for over a year. We filed a complete response with detailed evidence, including code commit logs and a public product launch announcement predating the trademark filing by more than a year. The panel denied the transfer and declined to make an RDNH finding on the basis that the complainant's theory, while ultimately unsuccessful, was not frivolous on its face.

Related at COGNOMEN

• UDRP respondent defense and RDNH — full service overview for any gTLD zone
• Seeking an RDNH finding in .ca domain disputes — jurisdiction-specific guidance
• Domain escrow and transaction services for .jp and cross-border name transfers