# Browser extensions that resolve onchain names: what to ask
> A browser does not open an onchain name without help. What a resolving extension does, what it can see, and the questions an IT team should ask.
Source: https://hush.partners/browser-extensions-that-resolve-onchain-names
Category: Onchain today
Published by Hush Partners.
---
Consider an IT security lead at a mid-sized professional services firm who receives a request: a colleague wants to install a browser extension so that staff can reach the firm's newly acquired onchain TLD in a desktop browser. The question lands on the security team's desk not because onchain names are exotic, but because browser extensions are software, and software installed on managed endpoints needs a proper assessment.
This article explains what a resolving extension does, what any extension in that position can see inside a browser, and what questions to put to a candidate extension before approving it for organizational use. It also covers the deployment options available to IT teams, the alternatives to extensions, and what the dependency on an extension means for anyone publishing content or services on an onchain name. After reading, you should be able to assess a resolving extension against your own organization's standards and make a reasoned recommendation.
## Why a standard browser cannot open an onchain name
The DNS, the Domain Name System coordinated under ICANN, is the mechanism a browser uses when you type a name into the address bar. The browser asks a resolver, the resolver walks a hierarchy of authoritative servers, and the answer eventually returns an IP address or a set of records the browser can act on. That chain works because every TLD delegated by ICANN is recorded in the DNS root, and every resolver on the public internet knows to start there.
Onchain TLDs exist outside that hierarchy. On Freename, for instance, a TLD is recorded onchain as a token held in a wallet, and the records of a name such as `store.yourbrand` are kept by a smart contract, a program that runs on a blockchain. There is no entry for `.yourbrand` in the DNS root, so a standard resolver returns nothing. The name does not exist from the DNS's point of view. A user in a mainstream browser therefore needs some form of support: a browser extension, a browser with built-in support, or a gateway.
This is a consequence of architecture, not a defect. The records that matter live on a blockchain, not in a DNS zone file. Any resolution mechanism that can read those records can resolve the name; the DNS is simply not that mechanism. On the desktop, the path for Freename names is the Freename Web3 extension; they are also supported in Bitcoin.com Wallet and in MetaMask through Freename's resolver. Coverage is partial and it changes: no resolution path reaches every user, and anyone publishing on an onchain name should understand that before going live. The page on [what is live](/whats-live) sets out which capabilities work and with what support.
## What a resolving extension does, step by step
A browser extension is a small program that runs inside the browser and can observe, modify or augment what the browser does. A resolving extension acts on navigation, the moment you press Enter after typing a name, and substitutes its own lookup for the browser's default DNS query. Implementations differ in their details; the outline below describes the general pattern.
How an extension resolves an onchain name
Intercept the navigationThe extension watches what is entered in the address bar. When the typed string ends in a TLD the extension knows about, such as .yourbrand, it catches the request before the browser hands it to the ordinary DNS resolver.
Query the onchain registryThe extension sends a read request to a smart contract on the relevant blockchain. That contract is the registry: it maps names to records. The request travels through an RPC endpoint, a service that relays calls to a blockchain node, which the extension is configured to use.
Read the recordsThe contract returns the records the holder of the name has set: commonly a content identifier pointing to files on IPFS (a distributed file-storage network), a wallet address or a conventional web address. The extension reads them and decides what to do next.
Fetch the contentIf the record points to IPFS, the extension typically sends the browser to an IPFS gateway, an ordinary web server that fetches IPFS content and returns it over HTTP. If the record is a conventional address or a redirect, the browser navigates there as normal.
Display the resultThe browser loads the page. To the user it resembles any other navigation, although the path ran through a blockchain query and, often, a distributed storage network instead of a DNS lookup and a single web server.
The RPC endpoint in the second step deserves a closer look. That endpoint receives the name being queried and, like any server, the network address of the caller. Some implementations place a proxy between the user and the endpoint, so that the provider cannot link an IP address to the names a user looks up; others do not. Whether a candidate extension does this, and how, is a concrete question an IT team can put to the publisher.
The same reasoning applies to the gateway in the fourth step. The gateway operator serves the content and therefore sees which content is requested, from where. An extension that resolves a name thus introduces up to two outside services into a navigation that would otherwise involve the organization's own DNS resolver and the destination site. Neither is unusual in itself. Both belong in the data-flow description that your assessment produces.
## What an extension can see inside the browser
Before evaluating any particular resolving extension, an IT team needs a clear picture of what any extension can access by running inside the browser, whatever its stated purpose.
In the common extension model, a manifest file declares the permissions the extension asks for when it is installed. A background component handles events, network requests and communication with external servers. Content scripts can be injected into pages, which gives an extension access to what is rendered there.
That architecture makes permissions the operative control. An extension granted access to all sites can read and change every page the browser loads, including authenticated sessions, form inputs and the content of internal tools. A resolving extension needs to act on navigation to the TLDs it handles; that is a narrow and legitimate need. An extension that asks for much broader access than its function requires should be asked why.
The update model matters as much as the permissions. Extensions generally update automatically and without a prompt. In most browsers the user is asked again only when a new version requests permissions beyond those already granted. The build your team reviewed is therefore not necessarily the build running a few weeks later, and an extension can change publisher without the user being told. A review that stops at installation covers one version of the software, not the software.
There is also a question of position. The extension lives inside the browser that employees already use for email, business applications, finance systems and internal tools. An over-privileged extension, or one whose behavior changes after an update, has access that conventional endpoint tooling does not always observe well, because the activity looks like ordinary browsing by an authenticated user.
None of this is specific to resolving extensions. It applies equally to ad blockers, productivity tools and password helpers. The point is that a resolving extension is assessed by the same standard as any other browser software, and is not waved through because its stated purpose, reading a public record on a blockchain, sounds harmless.
## The questions to ask before approving an extension
The table sets out the questions to put to a candidate resolving extension and to its publisher.
| Question | Why it matters |
|---|---|
| Who publishes it, and can the publisher be verified independently? | An accountable, identifiable publisher is the basis of every other assurance, especially if behavior changes after an update. |
| Which permissions does it declare, and are they the minimum needed for resolution? | Access to all sites is disproportionate for a tool that acts on navigation to specific TLDs. Narrow host permissions are a positive sign. |
| Which RPC endpoint and gateway does it use, and can they be changed? | Those services learn which names and content a user requests. The organization should know who operates them. |
| How are updates delivered, and can the organization pin a version? | Automatic updates replace a reviewed build without notice. A managed deployment should be able to hold a reviewed version. |
| What does the extension log or transmit, and for how long is it kept? | Navigation events, resolved names and timing are potentially sensitive. The privacy policy should address them specifically. |
| Is the source code available for review? | Open code can be inspected. Closed code is not unsafe for that reason, but it raises the bar for other assurances. |
| Is it distributed through the browser's official store, and what is its record there? | Store review is not a security guarantee, but a removal for a policy violation is a signal worth checking. |
Two of these questions carry more weight than the others for a resolving extension.
### Publisher
The natural publisher of a resolving extension is the registry whose names it resolves, or a party working with that registry. That gives you a simple test of provenance: the registry's own documentation should point to the extension, and the store entry should point back to the registry. An extension that claims to resolve a registry's names but is not acknowledged by that registry needs a much stronger justification. Ask as well who to contact about a security finding and how quickly the publisher commits to respond.
### Permissions
An extension that asks to read and change data on all websites, or to access cookies, history, downloads or applications on the endpoint, holds more power than name resolution requires. Some designs do need to observe every navigation in order to recognize a TLD they handle; that is a reason, and the publisher should be able to state it. A resolving extension that confines its host permissions to what resolution needs shows that the publisher has thought about scope. Record the permissions of the version you review, so that a later change is visible.
## Managed deployment across an organization
Approving an extension for one person is one thing; deploying it consistently across a managed fleet is another. Enterprise browser management, whether through the browser vendor's own management console, directory policies or a device management platform, generally offers three relevant controls. The names and details vary by browser and by tool.
**Force installation.** Installing an extension by policy means it appears on every managed endpoint without user action, and users cannot remove it. That removes the variability of self-installation. It also concentrates the dependency: whatever a new version of the extension does, it does on every endpoint at once.
**Allowlisting.** An organization that does not want to force-install the extension can add its identifier to an allowlist, so that users who need it can install it while extensions not on the list are blocked. Where an allowlist already governs browser extensions, the resolving extension is one more entry and the request fits an existing process. Where there is none, the request is a good occasion to ask whether there should be.
**Version pinning.** Some management tools can hold an extension at a specific version. For a resolving extension, pinning the reviewed version means no update is applied until IT has assessed the new build. The trade-off is that fixes in the new version are held back too, so the review cycle needs to be prompt.
The three controls can be combined: install a reviewed version by policy, update on a managed schedule, and review again whenever a new version asks for additional permissions. That is a defensible posture. It is also more operational effort than a single approval, so deploying a resolving extension at scale warrants a deliberate policy decision and not the quiet approval of a one-off request.
### Scope the deployment to the need
Not every member of staff needs to open onchain names. A team that manages the organization's TLD, issues names under it or tests the pages published on it has a daily need. Most other staff have none, or an occasional one that a gateway link can meet. Limiting the extension to the organizational units that use it keeps the review proportionate and reduces the number of endpoints affected by any later change. It also gives you a small group of informed users who will notice when resolution stops working.
## Alternatives to an extension: gateways and native support
An extension is not the only way to reach an onchain name in a browser. Two alternatives are worth understanding in outline, each with different trade-offs.
### Gateways
A gateway is a web service that does the lookup on the user's behalf and returns the content over ordinary HTTP. The user opens a conventional web address, operated by the gateway, that leads to the content behind the onchain name. Nothing is installed, nothing is deployed, and no permissions are granted in the browser.
The cost is twofold. The gateway operator is an intermediary who sees every request and on whose availability you depend. And the experience of typing an onchain name into the address bar does not exist: the user sees the gateway's address, not yours. For delivering content to colleagues on a known link, a gateway is often simpler than an extension. For public use where the onchain name itself is meant to be the recognizable address, a gateway link is a workaround, not an answer. Whether a gateway is available for a given registry is a question to check with that registry.
### Native support
Some browsers and wallet applications build resolution in, so that the lookup against the registry contract happens inside the application with no extension. Native support removes one piece of third-party software from the endpoint and places the resolving code under the application vendor's own release process. It also ties resolution to a specific application. An organization that standardizes on a browser without native support cannot rely on it there. Coverage is partial, and it changes as applications add or alter their support.
For most organizations the practical answer is a combination: an approved extension for the staff who work with onchain names daily, gateway links for occasional access where a gateway exists, and a line in the deployment record saying that the decision should be reviewed if the organization's standard browser gains native support.
| Path | Installed on the endpoint | Who sees the lookup | Address the user sees |
|---|---|---|---|
| Extension | The extension | RPC and gateway operators | The onchain name |
| Gateway link | Nothing | The gateway operator | The gateway's address |
| Native support | A supporting browser or wallet | The services that application uses | The onchain name |
## What your customers will and will not have installed
An organization that publishes a website, a payment address or a service endpoint on an onchain name is not only solving an internal problem. It is making a choice about who can reach that content. Staff on managed endpoints can be given an approved extension. Customers cannot be assumed to have anything.
No figure is offered here for how many people have a resolving extension installed, and none is needed to plan correctly. An ordinary browser does not open an onchain name without support, and the general public does not install software in order to visit one address. The safe planning assumption is that a visitor from the general public has nothing installed, and that the exceptions are identifiable groups.
Those groups are worth naming. People who already use a wallet that supports the registry's names can use those names where the wallet uses them, since [names resolve in wallets](/onchain-tld-wallets) without any browser being involved. Communities that have adopted the registry's tooling, including its extension, can open the name directly. Your own staff, if you deploy the extension, are a third group. Everyone else arrives through a conventional address.
A parallel path can take several forms. It may be a DNS domain that sits alongside the onchain name and opens in every browser, with the onchain name serving the users who have the tooling to reach it directly. It may be gateway links in communications, so that a customer who clicks arrives at the content with nothing installed. It may be a wallet-first use of the name, where the browser is not part of the journey at all.
This is not a reason to wait for universal support before publishing. Publishing on an onchain name is useful for specific audiences and uses, particularly payments, wallet interactions and communities that already have compatible tooling. It is a reason to be precise about who that audience is and to provide a fallback for everyone else. The page on [websites published on an onchain TLD](/onchain-tld-websites) covers what publishing involves and what it requires of the person trying to reach the content. Where the DNS is simply the better tool, as it is for an address that every member of the public must be able to open, say so in your own planning.
## What the extension question means for how you publish
The dependency on an extension shapes not only who can reach onchain content, but how a publisher should design that content and the ways into it.
### An internal audience
If your audience is internal, with teams using a TLD that matches the organization to reach tools, directories or payment endpoints, managed deployment solves the access problem cleanly. You control the endpoints and the browsers, and you can install the approved extension as part of onboarding. The limits are the ones already described: contractors, personal devices and mobile browsers fall outside the managed fleet and need a fallback.
### An external, mixed audience
If your audience is external and mixed, with some users on wallets and extensions and others on unmodified browsers, design for both from the start. Freename's website builder lets a holder build pages and publish them to IPFS; the site is then reached through the holder's onchain name in browsers that support it. Visitors whose browsers do not support it need a second, conventional way to the same content, and that second way should not be an afterthought. The [Launch Roadmap](/activation-roadmap) tool helps set out which access paths to build, and in what order, for the intended use of the TLD.
### Where the name is written down
Every place the name appears is a place where someone may type it into a browser. On a printed document, an invoice or a slide, an onchain name written alone will fail for most readers, and they will not know why. Write the conventional address next to it, or say where the name works: in a supporting wallet, or in a browser with the registry's extension. Your support team should know the answer to "the address does not open" before the first customer asks.
### Uses that do not involve a browser
A name such as `pay.yourbrand` shows how the dependency varies with the use. When a payer enters the name in a supporting wallet, the wallet resolves it; no browser and no extension are involved. When the payer is sent to a web page published on the name, the browser must reach that page, and the extension question returns. The page on [payments to a name](/onchain-tld-payments) outlines how names are used in payment contexts. As a rule, the more a use relies on wallets and the less on address bars, the less the extension matters.
## Running the assessment and deciding
Evaluating a resolving extension is not a specialized exercise. It follows the structure of any software assessment: establish who is accountable for it, understand what it can do with the permissions it requests, verify that those permissions are proportionate to its function, and confirm that its update and data-handling practices meet your standards.
The onchain element adds one particular point: the outbound calls. Every lookup of an onchain name is a read against a blockchain node, made on the user's behalf, and it carries information: the name being resolved, the time and the network address. A well-designed extension limits what is exposed. Ask the publisher to confirm in writing which services receive those calls and what they retain.
A workable sequence is short. Start from the request and write down who needs the extension and for what. Obtain the answers to the table above from the publisher's documentation and, where the documentation is silent, from the publisher. Review the declared permissions of one specific version. Decide between force installation, an allowlist entry and a refusal with a gateway link as the alternative. Record the reviewed version, the permissions and the date of the next review. If the answer is a refusal, state what would change it, so that the requester can go back to the publisher with a precise question.
The assessment also has a neighbor outside IT. An organization that holds the TLD matching its brand has an interest in which names exist under it and around it, and in whether its onchain presence is consistent with its conventional domain names. That is a brand protection matter, and [monitoring a brand's names onchain](/namespace-watch) is the corresponding service. Legal questions that arise from it are for the organization's own counsel.
If your organization has acquired a TLD and is deciding how to put it to work, the access paths described here are part of that plan. Hush Partners offers [post-transfer activation](/post-transfer-activation), the service for putting a TLD to work after the transfer, and is reached through the [contact form](/contact) on the site. The [glossary](/glossary) defines the terms used in this article.
## Questions people ask
### Does a resolving extension need to be always on?
Most resolving extensions work by watching address bar navigation and acting only when a TLD they handle appears. Some let the user switch the extension off, for specific sites or altogether. In an organizational deployment, a configuration managed by policy is more consistent than relying on users to activate the extension when needed, but it also means the extension is present for all browsing, not only for navigation to onchain names. Confirm this in the permissions review: an extension that is active only for specific TLD patterns holds narrower effective access than one that processes every navigation.
### Can an organization use its own RPC endpoint instead of the default?
In principle, yes. The RPC endpoint is the address the extension queries when it needs to read records from the blockchain. An organization able to run a blockchain node, or to contract for one, could point the extension at it, which removes the dependency on a third-party provider and keeps the query logs in its own hands. Whether a given extension exposes that setting is a question for its publisher. For organizations with strict requirements on where data is processed, it is worth asking early.
### Is a resolving extension subject to the same management controls as other extensions?
Yes. Enterprise browser management generally lets IT allow, block, force-install, remove and audit extensions, and restrict where they may be installed from. A resolving extension is no different in this respect. It is managed with the same policies and the same tooling the organization already uses for other browser software. The extension's identifier, a unique string assigned when it is published to the browser store, is the handle used to manage it by policy.
### What happens if the registry changes its contracts and the extension is not updated?
A registry may change the address or the interface of its contracts. An extension that depends on the earlier version may then fail to resolve names until it is updated itself. This is an operational risk particular to onchain systems, and it pulls against version pinning: the pinned build may be the one that stops working. During the assessment, ask the publisher how registry changes reach the extension and how much notice is given, and plan the review cycle accordingly.
### Does using a gateway mean the organization never needs to assess an extension?
For internal access through gateway links alone, it can. But a gateway introduces its own dependency: the organization relies on the gateway operator's availability, privacy practices and continued support for the namespace in question. An extension is software to assess and manage; a gateway is a service to evaluate and monitor. Neither is safer by category. The choice follows from how the organization already governs third-party services and how much browser software management it is prepared to take on.