Step-by-step: defend a .dev domain against a UDRP complaint

Step-by-step: defend a .dev domain against a UDRP complaint. UDRP and ccTLD domain recovery and defense across .dev. Email the firm to assess your case.

A UDRP complaint arrives in your inbox. The disputed domain is a .dev — a zone Google operates under ICANN accreditation and that carries exactly the same UDRP machinery as any .com. The clock starts ticking the moment the provider formally commences proceedings. You have 20 days to file a response. What you do in those 20 days largely decides the outcome.

To defend a .dev domain against a UDRP complaint, a registrant must demonstrate at least one of the Paragraph 4(c) safe harbors — a bona fide offering of goods or services before notice of the dispute, recognition by the relevant community under the domain name, or legitimate noncommercial or fair use — rebutting each element of the complainant's case, and, where the complaint is objectively weak, building the record for a reverse domain name hijacking finding. The WIPO filing fee for the complainant begins at USD 1,500; the respondent pays nothing to answer, but the cost of losing is the domain itself.

This guide follows the defense process step by step, flags the trap concealed in each stage, and explains what evidence actually decides a .dev dispute before a UDRP panel.

Why does .dev use the UDRP, and what does that mean for your defense?

The .dev registry is operated by Google under a registry agreement that incorporates the UDRP, making the same three-element test applicable to .dev as to .com or .net. A complainant files at WIPO, the Forum, CAC, or ADNDRC — their choice. The respondent has no say in the forum selection. That asymmetry matters: each provider has developed modestly different administrative cultures, though the legal test is identical across all of them.

The three UDRP elements are cumulative. A complainant must prove all three under Paragraph 4(a): (1) the domain is identical or confusingly similar to a trademark in which the complainant has rights; (2) the registrant has no rights or legitimate interests in the domain; and (3) the domain was registered and is being used in bad faith. Notice the word "and." The conjunctive formulation of element three is a genuine defense lever — if registration was clearly in good faith, bad faith in the cumulative sense may be defeated even if current use is ambiguous.

What is the trap hidden in step one? Many respondents assume element one is unwinnable and concede it. That is frequently wrong. A complainant's trademark may postdate the domain registration, cover different goods, or subsist only in a jurisdiction with no obvious connection to the respondent. Contesting element one — even partially — undermines the narrative the complainant is building toward element three.

For an assessment of whether the three UDRP elements are met on the facts of your .dev dispute, reach us at info@cognomenlaw.com.

How do you read the complaint and identify your strongest defenses?

Before drafting a single line of your response, read the complaint the way a panelist will. Most complaints follow a template: trademark registration details, a WHOIS screenshot, and a narrative that the domain is being held to sell or disrupt. Your job is to find the gap between the narrative and the provable facts.

Start with the trademark evidence. Is it registered or merely claimed as common law? In what jurisdiction? Was it filed before or after your domain was registered? A complainant who holds a trademark registered after your domain registration date faces a significant uphill task on element three, because bad faith at registration is judged as of the date you registered — not the date the complaint was filed.

Next, audit your own history. Why did you register the .dev? What did you build, propose, or discuss before the complaint arrived? The Paragraph 4(c) safe harbors require concrete evidence of use or preparation, not a post-complaint affidavit that reads like it was written to fit the defense. Panels distinguish clearly between contemporaneous records and after-the-fact reconstruction. That distinction is where many respondents lose a case they should have won.

Ask yourself whether this complaint should never have been filed in the first place. A complaint that stretches a weak trademark over a generic or descriptive domain, or that was filed against a registrant who demonstrably registered the name years before the complainant's business existed, may qualify for a reverse domain name hijacking finding. An RDNH finding carries no monetary consequence — but it is a public record of the complainant's conduct, and it is the strongest outcome available to a respondent beyond a simple denial of the transfer.

What evidence builds a legitimate-interest record under Paragraph 4(c)?

The Paragraph 4(c) safe harbors are the core of any respondent defense. Each describes a factual condition, and each requires evidence, not assertion. The three safe harbors are: a bona fide offering of goods or services before notice of the dispute; being commonly known by the domain name; and legitimate noncommercial or fair use without intent to mislead or tarnish. At least one must be demonstrated for the defense to succeed on element two.

For a .dev registrant, the most commonly applicable safe harbor is the first — the bona fide offering before notice. Developers frequently register a .dev name for a project, a tool, a portfolio, or a client build, often before the complainant's trademark achieves any real market presence in the relevant technical community. The evidence that supports this safe harbor includes:

• Contemporaneous communications — emails, Slack or GitHub messages, project documentation — from the period before the complaint arrived, showing active development or planning under the domain name.
• Source code repositories with timestamped commits referencing the domain.
• Invoices, proposals, or contracts showing the domain was associated with a commercial project before notice.
• Screenshots of a live or staging site, with metadata indicating when the content was created or deployed.
• Any public-facing reference — a product hunt post, a developer conference mention, a press release — predating the complaint.

The trap here is assuming the record speaks for itself. It does not. A respondent must present the evidence in organized form and explain its relevance. Panels see thousands of responses. A response that dumps exhibits without a clear narrative linking each piece of evidence to the applicable legal standard risks having key material overlooked.

In a recent matter involving a .dev name used for a developer tool (autumn 2024), we assembled a response built on timestamped repository commits, a product roadmap document predating the complaint by more than a year, and a beta-tester mailing list showing genuine commercial interest. The panel denied the transfer and noted the legitimate-interest record as independently sufficient. The complainant's trademark, while registered, postdated the repository's earliest commits by several months.

The "commonly known by the name" safe harbor applies in narrower circumstances — primarily where the respondent's organization, brand, or online identity corresponds to the disputed name. It is underused by respondents who would benefit from it. If your company, product, or developer handle corresponds to the .dev name, document it across every public channel: GitHub profile, LinkedIn, About pages, developer forums. Panels look for convergence across multiple independent sources, not a single self-serving declaration.

How do you contest bad faith in registration — and why does it matter most?

Element three is where most .dev disputes are actually decided. The complainant must prove both halves: registration in bad faith and use in bad faith. If you registered the domain without knowledge of the complainant's mark, that defeats the registration prong — and because the test is conjunctive, it defeats element three as a whole.

What does "without knowledge" mean in practice? Panels do not require the respondent to prove a negative in a vacuum. They ask whether, on the evidence, it was plausible that the respondent was unaware of the mark at the time of registration. Factors that help: the mark was obscure or jurisdiction-limited when you registered; the domain string is descriptive or generic; you registered as part of a broader portfolio of descriptive terms or developer project names; you were in a different industry sector from the complainant.

What hurts? Registering shortly after a high-profile product launch or trademark filing; a domain string that exactly matches a distinctive coined mark; evidence of communications with the complainant about purchasing the name before the complaint; a history of registering names that match trademarks of third parties.

The Paragraph 4(b) bad-faith indicators — acquiring the domain to sell to the mark owner, acquiring it to disrupt a competitor, using it to attract users by creating confusion, and a pattern of abusive registrations — are not exhaustive. Panels may find bad faith from the totality of circumstances. But the inverse is equally true: a respondent who addresses each Paragraph 4(b) indicator directly and shows that none applies has built a coherent denial that a panel can credit without speculating about motive.

Passive holding — owning a domain without active use — is a complicating factor. Panels have found bad faith from passive holding alone, particularly where the domain matches a well-known mark and the registrant offers no credible explanation for the lack of use. For a .dev registrant, the solution is not to pretend the domain is in active use. It is to provide a credible, documented explanation for the absence of a live site: a development project that stalled, a pivoting business model, a client engagement that dissolved. Documentation of intent is not the same as a live site, but it is far stronger than silence.

What is a realistic path to a reverse domain name hijacking finding?

Reverse domain name hijacking is a panel finding that the complaint was brought in bad faith to deprive a legitimate registrant of the domain. It carries no monetary award — the UDRP does not permit damages — but it is a public record that the complainant abused the procedure. In our practice, we regularly advise registrants who come to us with a complaint that, on its face, should not have been filed.

RDNH findings are not rare, but they are not automatic. A panel will typically find RDNH where the complainant (a) knew or should have known the complaint could not succeed on the available facts, and (b) filed anyway, often because the registrant declined to sell at the complainant's offered price. The most reliable indicators that an RDNH argument is worth making:

• The respondent's registration clearly predates the complainant's trademark rights.
• The domain string is generic or descriptive, and the complainant's trademark is weak in the relevant field.
• The complainant made a lowball purchase offer before filing, suggesting the UDRP was used as pressure rather than genuine IP enforcement.
• The complaint relies on a trademark that is not registered, or that was registered in a jurisdiction with no plausible connection to the respondent's conduct.
• The complainant's counsel is experienced in IP and UDRP practice, eliminating any claim of innocent mistake.

Arguing for RDNH requires care. A poorly framed RDNH request — one that simply accuses the complainant of bad faith without grounding the argument in the specific record — can actually undermine the response by suggesting the respondent is deflecting from the merits. The RDNH argument should be a closing section of a response that has already, on the merits, dismantled each of the three UDRP elements.

In a related matter (a .dev domain, spring 2025), a registrant had held the name for several years as part of a developer tooling project. The complainant — a startup whose trademark had been filed only months before the complaint — made two purchase inquiries at below-market prices before filing. We filed a response addressing all three UDRP elements and included a targeted RDNH section. The panel denied the transfer and entered an RDNH finding, noting that the complainant had chosen the UDRP as a pressure mechanism rather than a genuine dispute-resolution tool. No damages were available, but the finding was publicly recorded and the registrant kept the domain.

Should you request a three-member panel, and what are the tradeoffs?

A respondent may request a three-member panel even if the complainant selected a single-member panel. If the respondent makes that request, the parties generally split the higher three-member panel fee — at WIPO, the three-member fee for a single domain is USD 4,000, compared to USD 1,500 for a single panelist. The respondent's share of that difference is real money.

When does a three-member panel make sense? It makes sense where the case presents a genuine legal question — novel bad-faith circumstances, a complicated trademark ownership chain, a significant RDNH argument — and where the additional perspective of three decision-makers is likely to produce a more carefully reasoned outcome. Three-member panels are also generally understood to produce more consistent, deliberative decisions, and they are less likely to produce an outlier result in either direction.

When does it not? Where the merits are clear, adding two more panelists adds time and money without changing the outcome. A respondent with a strong, well-documented legitimate-interest record rarely needs three panelists to credit it. A respondent with a weak record is not improved by increasing the audience.

The decision should be made deliberately, not reflexively. Requesting a three-member panel as a delay tactic is transparent to experienced panelists and to the opposing counsel, and it signals something about the respondent's confidence in the merits.

To weigh UDRP forum options and panel composition for your .dev defense, email info@cognomenlaw.com.

What happens after the response is filed, and how is the decision implemented?

Once the response is submitted, the administrative provider appoints the panel. The respondent has no further right to file material unless the panel specifically invites supplemental submissions — which panels do rarely and under strict conditions. The response you file is, in almost all cases, the last word you have.

The panel issues its decision, typically within about two months of the case commencing overall. If the panel denies the complaint, the domain remains with the registrant and the registrar lock is lifted. If the panel orders a transfer, there is a short implementation window — typically ten business days — during which a respondent who intends to challenge the decision in court may seek a stay from a court of competent jurisdiction, effectively pausing the transfer. The UDRP does not preclude a court challenge; it is a contractual arbitration that runs in parallel with any available court remedy, not in place of it.

For a .dev domain specifically, the registry is Google and the registrar is typically a major accredited provider. Registrar implementation of a UDRP transfer order is generally mechanical — the registrar follows the panel's instruction without discretion. A registrant who discovers material new evidence after the decision — evidence that was genuinely unavailable during the proceedings — may have limited options. Those options depend on whether a court remedy is available in the relevant jurisdiction and on the registrant's willingness to bear the substantially higher cost of litigation compared to the UDRP proceeding itself.

The lesson: put everything on the record in the response. A case where the outcome turned on a document that existed but was not submitted is a case that did not need to be lost.

Related at COGNOMEN

• UDRP respondent defense and RDNH findings — full service overview
• Case study: proving legitimate interest in a ccTLD domain dispute
• URS and TMCH claims notices for new gTLD domains — what to do when one arrives