BrandFence

Secure the domains your attacker wants — proactive brand defense powered by the name.com CORE API.

Comment

Inspiration

Most domain tools help companies manage domains they already own. BrandFence starts with a different question:

What dangerous domain could someone else own next?

A brand can be impersonated without its real domain ever being compromised. Lookalike domains using words such as login, account, payment, or verify — along with typos, visual confusables, and alternate TLDs — can create convincing impersonation opportunities.

BrandFence turns defensive domain registration into a prioritized, budget-aware, auditable security workflow.

What it does

BrandFence generates a bounded set of potential brand-impersonation domains and uses the name.com CORE API to determine which candidates are actually registrable and what they currently cost.

Each candidate receives a deterministic, explainable Exposure Priority based on:

  • Confusability
  • Impersonation intent
  • Brand preservation
  • TLD relevance
  • Attack simplicity

This score is a transparent prioritization policy — not a prediction of phishing probability.

Given a fixed protection budget, BrandFence selects the highest-priority registrable set that can actually be afforded.

When the user chooses Secure my brand, BrandFence:

  1. Revalidates availability and current price immediately before registration.
  2. Registers the selected domains through the name.com CORE API.
  3. Applies defensive domain policy.
  4. Confirms domain lock, auto-renew, and privacy.
  5. Creates SPF block-all and DMARC reject records.
  6. Configures URL forwarding to the official domain.
  7. Reads the resulting state back from name.com.
  8. Produces a Defense Receipt containing only states verified through API read-back.

The core transformation is:

REGISTRABLE → PRIORITIZED → BUDGET-SELECTED → REVALIDATED → REGISTERED → HARDENED → API VERIFIED

Why name.com is essential

The name.com CORE API is not an add-on to BrandFence — it is the execution layer the product depends on.

Without name.com, BrandFence could generate hypothetical lookalikes, but it could not determine which opportunities are actually registrable, obtain real pricing, acquire the highest-priority domains, configure their defensive state, or verify the result.

BrandFence combines multiple name.com capabilities into one continuous defensive transaction:

ZoneCheck → definitive availability & pricing → revalidation → registration → domain policy → DNS → URL forwarding → API read-back verification

This is what makes the project possible.

Availability becomes threat-surface discovery.

Registration becomes defensive remediation.

DNS and domain policy become post-acquisition hardening.

API read-back becomes proof that the requested protection was actually applied.

Instead of using a registrar only to manage domains a brand already owns, BrandFence uses name.com to secure the domains an impersonator could own next.

How we built it

BrandFence is built with React, TypeScript, Vite/vinext, Cloudflare Workers, and the name.com CORE API.

The live demo runs against the real name.com Development/Test sandbox, not mocked registrar data.

The integration uses name.com for:

  • ZoneCheck
  • Definitive domain availability
  • Current registration pricing
  • Pre-purchase revalidation
  • Domain registration
  • Domain state and policy
  • DNS records
  • URL forwarding
  • Final API read-back verification

Before each registration, BrandFence rechecks availability and price to reduce stale purchase decisions.

Registration requests also use idempotency protection so an automatic retry does not unintentionally create duplicate transactions.

Credentials remain server-side and are never exposed to the browser.

Challenges we ran into

The hardest part was making a real registrar transaction safe, reliable, and demonstrable instead of building a mocked hackathon flow.

We had to handle:

  • Preliminary ZoneCheck versus definitive availability
  • Live sandbox pricing
  • Availability and price changes between discovery and execution
  • Revalidation immediately before registration
  • Idempotent registration requests
  • Sandbox-specific domain-policy behavior
  • Avoiding redundant setting updates
  • DNS creation and verification
  • URL forwarding and verification
  • API read-back of the final defensive state
  • Secure server-side credential handling
  • Portable deployment outside the original development environment

We also deliberately avoided presenting Exposure Priority as an attack probability. The system explains why one opportunity is prioritized over another without pretending it can predict whether a particular domain will actually be used for phishing.

Accomplishments that we're proud of

BrandFence completes a real end-to-end name.com sandbox workflow:

discover → check → price → prioritize → optimize → revalidate → register → harden → forward → verify

During the live demo, BrandFence takes a fixed $50 protection budget, identifies registrable impersonation opportunities using real name.com sandbox results and pricing, chooses an affordable defensive set, and executes the protection workflow.

The final Defense Receipt is based on API read-back rather than simply changing the interface to green.

For each successfully protected domain, BrandFence can verify states including:

REGISTERED ✓
LOCKED ✓
AUTO-RENEW ✓
PRIVACY ✓
SPF BLOCK-ALL ✓
DMARC REJECT ✓
FORWARDING CONFIGURED ✓
API VERIFIED ✓

We also built automated tests covering protection logic, registration payloads, idempotency behavior, security boundaries, and credential-exposure regressions.

What we learned

Registrar APIs can be much more than domain-search or portfolio-management backends.

By combining availability, pricing, registration, domain policy, DNS, forwarding, and verification, the name.com CORE API can become part of a proactive brand-defense workflow.

We also learned that automating a real transaction requires more than simply calling a purchase endpoint.

Transparent prioritization, bounded budgets, last-second revalidation, idempotency, server-side secrets, defensive configuration, and final read-back verification are all essential if an automated protection workflow is going to be trustworthy.

What's next for BrandFence

Today, BrandFence protects a bounded set of registrable impersonation opportunities.

With more time and support, it could evolve into continuous domain defense with:

  • Continuous monitoring for newly available lookalikes
  • Expanded IDN and homoglyph coverage
  • Portfolio-wide protection across multiple brands
  • Historical exposure tracking
  • Alerts when high-priority opportunities become available
  • Adaptive defensive-budget recommendations

The long-term goal is to transform the registrar from a place where companies simply buy domains into a proactive security layer for their brands.

BrandFence — Secure the domains your attacker wants.

Built With

Share this project:

Updates

Submission history