# Abuse handling in the DNS and onchain: who can stop a name
> In the DNS a registrar or registry can suspend a name. Onchain, the levers are different and fewer. A comparison for people who have to respond to abuse.
Source: https://hush.partners/abuse-handling-in-the-dns-and-onchain
Category: Market & ICANN
Published by Hush Partners.
---
When a name is being used to impersonate your organization, the first call to your abuse desk asks the same question wherever the name was registered: who can make it stop? In the DNS, the answer is well mapped. For an onchain name it is less so, and the difference between the two situations is what an abuse desk has to understand before it needs to act.
This article walks through the chain of responsibility in each system, identifies the levers that exist, and follows the same harmful use through both. The goal is practical. By the end, you should be able to say which actions are available in each system, who controls each one, and how far each one reaches.
Planning that response before an incident occurs is easier than constructing it under pressure, so the last sections turn the comparison into a plan.
## What counts as abuse for this comparison
The scope here is narrow on purpose. Phishing, impersonation and fraud are the categories that create immediate harm: a name that looks like your brand is used to make people believe that a page, a message or a payment request comes from you. These are the cases where speed of response matters most and where the structural differences between the DNS and onchain naming are sharpest.
Broader categories such as spam, malware distribution and content disputes overlap with these, but they often involve different actors and different response paths. They are left out so that the comparison stays on one kind of harm.
The surface is not the same in the two systems. A DNS name is mostly met in a browser address bar or an email address. An onchain name is mostly met where the supporting software is: in a wallet, where [a name stands in for a long address](/onchain-tld-wallets), or in a browser that has been given the means to resolve it. The harm you are guarding against is therefore weighted differently. In the DNS it is usually a page or a mailbox. Onchain it is more often a person who trusts a familiar-looking name when sending funds or connecting a wallet.
Trademark law is relevant in both systems, but the remedies it provides move slowly compared with an active impersonation. The levers described here are operational ones. Legal rights inform which of those levers you can ask someone to pull, and what evidence that party will expect. Rules vary by country, and your own counsel decides how your rights apply. The [glossary](/glossary) defines the terms used below.
## The DNS chain of responsibility, in outline
In the DNS, authority runs from ICANN through registry operators to registrars and then to registrants. Each layer is bound to the next by contract, and those contracts create duties around abuse.
A registrar is the company that sold the name to the registrant. Under its accreditation agreement with ICANN, it is expected to publish an abuse contact, to look into reports and to act on well-evidenced ones. A registry operator is the company that runs the TLD itself. It has parallel obligations and can act on a name within its TLD when the registrar does not. ICANN, in turn, can enforce its contracts against registrars and registries that do not meet those obligations.
Two more parties sit beside that chain. The hosting provider serves the content the name points to, and the DNS provider answers the queries for it. Either can act under its own terms, and experienced abuse desks report to them in parallel with the registrar.
The Uniform Domain-Name Dispute-Resolution Policy, the UDRP, sits alongside this operational chain. It is an administrative procedure that a trademark owner can bring against the registrant of a name registered and used in bad faith. It is slower than an abuse report, but it ends in transfer or cancellation of the name instead of a temporary measure, and it is the usual route when the name itself, and not only its use, is the problem.
The UDRP binds registrants because every registration agreement in the generic TLDs incorporates it. That is also the reason it does not reach onchain names: no such agreement stands behind them.
## What suspension actually does in the DNS
When a registrar puts a name on hold (the status is called `clientHold`; the registry's equivalent is `serverHold`), the name is taken out of the TLD's zone, the published list that tells the internet where each name points. A resolver that asks for it gets no answer. The name stops pointing to any web server or mail server. The page stops loading and mail to the address is no longer delivered.
Suspension is not deletion. The registration record persists and the name is not released for someone else to register. The registrant keeps the registration and loses the use of it. That distinction matters: the name is preserved for any proceedings that follow, and a registrant who believes the action was unjustified can take it up with the registrar.
The same blunt instrument that stops the abuse also stops anything legitimate that depends on the name. A hold applies to the whole name, including every address beneath it. This is why registrars weigh the evidence and the scope of harm before acting. A name with no use other than the harmful one is a straightforward case. A legitimate name that has been compromised is not, and it is often better handled by the hosting provider, which can remove one page without silencing everything else.
What makes suspension so effective is its reach. One party acts, in one place, and the result holds for every user of the DNS. Keep that property in mind, because it is the one that has no onchain counterpart.
## Onchain: why nothing can be suspended in the same way
Start from how Freename records a TLD: onchain, as a token that sits in a wallet. A token is an entry on a public ledger, and a wallet is the software that holds the keys controlling it. An abuse desk, like anyone else, can check that record on a block explorer, because the registry keeps it public.
The record is not a row in a database that a registrar or a registry operator edits. This gives the holder strong, portable control over the asset: there is no annual renewal fee on a Freename TLD, and no intermediary whose routine decision can take it away. It also means that the operational levers of the DNS do not carry over. No outside party stands in the position of a registrar, with a hold status it can apply to someone else's name.
There is no zone either. In the DNS, the zone is the single place where a name can be switched off for everyone. Onchain names resolve outside the ICANN DNS root, and each piece of supporting software reads the public record for itself. Nobody publishes one list that all of them depend on.
That is not the same as saying nothing can be done. It means the actions available sit at other layers: the software that turns a name into an answer, the platforms that display or handle names, and the decisions of the TLD holder about what is issued in the first place. The effect of each action is limited to whoever takes part in it.
The absence of a party that can override the holder is a deliberate property of the design. For abuse response it is also a real constraint, and on this point the DNS is simply better equipped. Acknowledging that is the starting point for a workable plan.
## The levers that exist onchain
Four points of control exist. None is a full substitute for suspension. Together they cover most of what an abuse desk needs.
### Resolution software
Without support, an onchain name does not open in an ordinary browser. For Freename names, that support exists today in Bitcoin.com Wallet, in MetaMask by means of Freename's resolver, and in desktop browsers that carry the Freename Web3 extension. Coverage is partial and changes; the page on [what is live](/whats-live) keeps the list with its sources.
Partial coverage cuts both ways. It limits what a legitimate holder can do with a name, and it limits who a harmful name can reach: only people using software that resolves it. In principle, any piece of resolution software can decline to answer for a name, or show a warning in front of it. Whether a given operator does so, on what evidence and through what channel, is a matter of its own policy. Find that out before you need it, and do not assume the answer is the same everywhere.
### Platforms
Marketplaces, wallets and applications that display names or let people act on them work under their own terms of use. A platform can stop displaying or handling a name that breaches those terms. The action does not change the token or how the name resolves elsewhere, and the holder can move to another platform. Its value is that it removes the name from a place where people would otherwise meet it, and that it leaves a record of your complaint.
The same reasoning applies to content. A website reached through an onchain name may be published to IPFS, a peer-to-peer network in which a file is addressed by a fingerprint of its content. Many readers reach such content through a gateway, a server that fetches it for an ordinary browser, and the operator of a gateway applies its own policy to what it serves.
### The TLD holder
Issuance on Freename has a single source: names under a TLD are issued by its holder and by nobody else. A name such as `pay.yourbrand` or `name.yoursector` exists because the holder of that TLD issued it, or set up the conditions under which it could be issued.
The holder's strongest lever is therefore upstream: deciding which names are issued, to whom and on what terms. What a holder can do about a name after it has been issued depends on the registry's terms and on the terms under which the name was issued. Do not assume that a withdrawal function exists. Ask the registry, and read the holder's published terms if it has any.
### Courts
A court can direct an order at any party it can reach: the operator of resolution software, a platform, a gateway, or the holder if the holder is identified. Whether an order can be enforced depends on where that party is established, and rules vary by country. This path is slower than an operational request and firmer in its result. It is the backstop when voluntary action does not come.
| Lever | Who controls it | Effect on the name | System |
| --- | --- | --- | --- |
| Registrar hold | Registrar | Out of the zone for everyone | DNS |
| Registry hold | Registry operator | Out of the zone for everyone | DNS |
| UDRP | Panel of an approved provider | Transfer or cancellation | DNS |
| Resolution filtering | Operator of the software | No answer in that software | Onchain |
| Platform action | Platform operator | Not shown or handled there | Onchain |
| Issuance policy | TLD holder | Decides what is issued | Onchain |
| Court order | National court | Binds the party it names | Both |
## The TLD holder's own responsibility
In the DNS, a registry operator has contractual duties for the names registered under its TLD. It must provide an abuse contact, look into reports and act. Those duties come from its contract with ICANN.
Onchain, the TLD holder occupies a comparable position by structure: it controls the namespace and determines which names exist under it. No contract with a body like ICANN requires it to publish abuse procedures. The consequences of ignoring harmful use under a TLD you control are real all the same, and a holder that issues names to other people should treat the responsibility as its own.
For [operators who run a TLD as a namespace](/operators) and issue names to third parties, this is sharper still. Who may take a name, what you ask of them, which names you hold back, what conduct breaches your terms and how a complaint reaches you are all choices you make. Making them deliberately, before a complaint arrives, is the difference between managing an incident and improvising one.
Three parts of such a policy do most of the work. The first is a reserved list: the names you will not issue to an unverified party, such as well-known marks and words like "support" or "pay" attached to someone else's brand. The second is a public route for complaints, on a page a brand protection team can find without knowing you. The third is a written statement of what you will do when a complaint is substantiated, within what the registry's terms allow. A holder that publishes these three things is easier to deal with, and easier to trust, than one that leaves an abuse desk guessing.
The position is different for an organization that holds the TLD matching its own name and issues names only to itself. There the upstream lever is complete: nothing exists under `.yourbrand` that the organization did not issue. Its residual task is internal, which is knowing who inside the organization may issue a name and keeping a record of what has been issued.
## The same incident in both systems, step by step
Take a scenario with an invented party. A mid-sized payments company learns that a name resembling its brand is being used to pose as its support desk. Follow the response twice.
### In the DNS
The abuse desk captures evidence: the name, what it shows, when, and how it was reported. It looks up the registrar in the public registration data and files a report with the registrar's abuse contact, and in parallel with the hosting provider. If the evidence is clear, one of them acts. If the registrar puts the name on hold, the name stops resolving for everyone, and the desk can confirm that from any network.
If neither acts, the desk escalates to the registry operator. Separately, counsel decides whether to bring a UDRP complaint, so that the name ends up with the company and cannot be used again later. The incident has a clear end: the name is out of the zone, and later it is transferred.
### Onchain
The desk captures the same evidence. Then it has to answer a question the DNS never asks: where does this name resolve at all? It tests the name in the software its customers are likely to use. The answer sets the priority. A name that resolves in an environment your customers use is a live problem; one that resolves almost nowhere is one to watch.
Next it reads the public record on a block explorer. The record shows which wallet holds the TLD and which holds the name. It shows a wallet, not necessarily who is behind it. If the TLD holder publishes a complaints route, the desk uses it. If not, it asks the registry what route exists.
In parallel, the desk reports the name to the operators of the software where it resolves and to any platform where it appears, with the trademark evidence each will expect. It warns customers through the company's own channels, because that is the one measure fully in its hands. Counsel assesses which of the parties involved a court could reach.
There is no single moment at which the name is down. The desk keeps a list of environments and marks each one as it stops answering. The incident closes when the remaining reach is small enough to move from response to monitoring, and that is a judgment the desk has to make and record.
## Speed and certainty compared
The two systems differ less in how fast the first action can come than in what that action settles.
In the DNS, a clear report to the right contact can lead to a hold, and the hold is complete. The formal route, the UDRP, takes longer and produces a documented result that the registrar must carry out. You know in advance who is obliged to respond, and you can escalate along the chain when they do not.
Onchain, an operator of resolution software or a platform may respond quickly, but each acts only on its own part. A name filtered in one piece of software still resolves in another. There is no onchain equivalent of the UDRP, so no procedure ends with the name being moved to the complainant. Short of a court order, nobody is obliged to answer you.
Onchain response therefore depends on voluntary action by several parties that do not coordinate with each other. In the DNS, one successful report takes the name down everywhere at once. Onchain, the same report may take it down in some places and leave it visible in others for a period you cannot predict.
Two things work in the other direction, and an honest comparison includes them. Reach is smaller: a harmful onchain name is met only by people using supporting software, where a DNS name is open to anyone with a browser. And the record is public: you can see when a name was created and which wallet holds it without asking anyone, whereas DNS registration data is often redacted and has to be requested.
| Dimension | DNS | Onchain |
| --- | --- | --- |
| Fastest operational lever | Registrar or registry hold | Filtering by one operator |
| Reach of that lever | Every user of the DNS | Users of that software only |
| Remedy over the name itself | UDRP transfer or cancellation | None outside the courts |
| Who must respond | Contracted parties | Nobody, absent a court order |
| Who can see the record | Often redacted, on request | Anyone, on a block explorer |
For [brand protection and legal teams](/brands-and-legal-teams) the conclusion is not that onchain names are to be avoided. It is that the response is assembled from several partial measures, so the work shifts toward early detection and toward knowing in advance whom to contact.
## Planning a response before it is needed
### Detection comes first
Neither system helps you respond to abuse you have not seen. In the DNS, a monitoring program watches for new registrations that resemble your marks across the TLDs that matter to you. Onchain, the equivalent program watches for names created on onchain registries that match the same terms.
The onchain task is different in kind, because there is no single authority with a single zone to watch. Names are issued by more than one registry, on more than one chain, and a program that covers one of them can miss another. Resolution matters here too: a name that most people cannot open may still be usable by those with supporting software.
The [Namespace Exposure Score](/namespace-exposure-score), a free tool on this site, scores how exposed a brand is onchain and gives you a baseline. [Namespace Watch](/namespace-watch) is the service that monitors the names of a brand onchain from then on.
### The plan itself
Preparing an onchain abuse response before an incident
Set your baselineRecord which onchain names match your brand terms, on which registries, and whether each one resolves anywhere. This is the list you will compare against later.
Read the public record for the relevant TLDsAnyone can check the registry's public record on a block explorer, so do it now, before an incident. Note the wallet that holds each TLD where your terms appear, and whether its holder publishes a complaints route. Where none exists, ask the registry what route it offers.
Map where names resolve for your audienceEstablish which supporting wallets and browsers your customers are likely to use, and what each operator asks for in a report. Review the map regularly, because coverage changes.
Keep your trademark evidence readyOperators and platforms will expect evidence of rights before they act. Have your counsel prepare a short summary of your registered marks and the countries they cover, and keep it up to date.
Agree who authorizes whatDecide in advance who signs off a report to an operator, a notice to customers, and a decision to go to court. A decision tree agreed beforehand removes delay when it matters.
Prepare to act in parallelNo single action covers every environment. Plan to contact the TLD holder or registry, the software operators and the platforms at the same time, and draft the template for each.
Know your legal backstopIdentify counsel in the countries where the parties you may need to reach are established. Your counsel decides whether and when that route is used.
Much of this plan is not specific to onchain names. Trademark evidence, sign-off and parallel action serve you equally well in the DNS. What onchain naming adds is the map of where names resolve and the reading of the public record, because those two things replace the registrar lookup that a DNS abuse desk does without thinking.
Add one more element that the DNS plan rarely needs: a rule for closing an incident. Since there is no single takedown, decide beforehand what remaining reach you will accept, who makes that call, and how often the name is rechecked afterwards.
## Where to start: a baseline and a contact map
The comparison is general. Your exposure is specific: it depends on which names exist, under which TLDs, on which registries, and whether they resolve where your customers are. So the first piece of work is small and concrete.
Produce two documents. The first is the baseline from step one of the plan: the onchain names that match your brand terms, with a note of where each resolves. The second is a contact map: for each TLD on that list, the route for a complaint, and for each piece of supporting software your customers use, the channel for a report. With those two documents an abuse desk can act in parallel within the first hour of an incident. Without them, that hour is spent finding out whom to ask.
If you hold a TLD and issue names under it, your first piece of work is the other side of the same map: publish the route by which a complaint reaches you, and the terms on which you issue names.
Hush Partners is a private desk for onchain TLDs. It is not an abuse desk and does not take names down. What it offers on this subject is limited to the two things mentioned above, the exposure score and the monitoring service, and to acting for an organization that decides it should hold the TLD matching its own brand. An organization in that last position reaches the desk through the site's contact form.
## Questions people ask
### Can a trademark owner bring a UDRP complaint against an onchain name?
No. The UDRP reaches registrants through the registration agreements of the DNS, and onchain names are issued outside that framework. A trademark owner relies on the levers described above and, where needed, on the courts. Whether an onchain name infringes a mark is a question of national law for your counsel.
### If one piece of software stops answering for a harmful name, is the problem solved?
Partly. The name no longer reaches the users of that software. People using other supporting software may still reach it. Treat each such action as one line closed on your list of environments, not as the end of the incident.
### What if the TLD holder is the one behaving badly?
Then the upstream lever is unavailable, and the remaining ones are the operators of resolution software, the platforms and the courts. The public record on a block explorer shows the wallet that holds the TLD and when names under it were created, which gives your counsel a factual starting point. Early detection matters most in this case, because every other lever is partial.
### Is there an onchain counterpart to the notices that warn a mark owner of a new registration?
Not in a standardized form. In the DNS, launches of new TLDs have come with mechanisms that tell a registered mark owner when a matching name is registered. Onchain, the practical counterpart is your own monitoring, which detects a new name and alerts your team in time to contact the right parties.
### Does holding the TLD that matches your brand prevent abuse?
It closes one avenue and only that one. Since only the holder of a Freename TLD can issue names under it, an organization that holds `.yourbrand` decides which names exist beneath it. It does not affect look-alike names under other TLDs or on other registries, so monitoring stays necessary. It is a structural measure, not an incident response, and [acquiring the TLD that matches a brand](/brand-namespace-recovery) is a decision to take calmly, outside any incident.