So you've got a side project. Maybe it's a personal homepage, maybe it's a hobby API, maybe it's the third iteration of your "this time I'll finish it" todo app. You need a domain. You hit the registrar, pick something reasonable, and... $12. Per year. For a project that might get five visits, all from you.

I've been there. After racking up something like 14 domains over the years (most for projects I never shipped), I started hunting for alternatives. Free TLDs like .tk and .ml are dead — Freenom stopped accepting new registrations in 2023 after the Meta lawsuit. Free subdomain services tend to die or pivot. But there's a corner of the DNS hierarchy almost nobody talks about: US locality domains.

The problem: nobody knows these exist

Quick quiz — what's the difference between example.com and example.portland.or.us?

The second one is a locality domain. The .us TLD is structured hierarchically by geography: state, then locality (city, county, town). It's defined in RFC 1480, published in 1993. That's not a typo.

The reason nobody uses these is partly that the structure is awkward, partly that registration policies vary wildly by locality, and partly that the flat .us namespace was opened up in 2002 — giving us example.us instead and making everyone forget about the hierarchical version. But the locality space still exists, and depending on where you look, you can get a name under it for free.

Root cause: the registration system is fragmented

Here's why this is annoying. The flat .us namespace is run by a single registry. You go to any registrar, pay your fee, done.

Locality domains are different. Each locality delegates its own subzone. Some are managed by city IT departments. Some by state government. Some by volunteer-run registries. Some by the contractor who currently holds the .us registry contract. Policies, prices, and processes are all over the place.

Step one is figuring out who manages your locality. Good news — you can mostly figure it out with whois.

Step 1: Find your locality's manager

Pick a city. Let's say Portland, Oregon. The locality zone would be portland.or.us. Run:

whois portland.or.us

Look for the registrant and admin contacts. You'll get an email address or a URL — that's who you talk to. If whois returns nothing useful, walk up the tree:

whois or.us
whois ci.portland.or.us  # cities often use the "ci." prefix

The ci. prefix is convention from RFC 1480 — ci for city, co for county, k12 for K-12 schools, lib for libraries. Not every locality follows it, but it's a hint when the bare locality name comes back empty.

Step 2: Check the locality's policy

This is where the path forks. Some localities will let any resident register a name under them. Some require you to be a government entity. Some haven't issued a new domain since 2007 and the contact email bounces.

The pattern I've seen: smaller and mid-sized localities are more likely to have permissive policies (they want to encourage local internet presence). Bigger cities locked things down years ago. Check the locality's official website or email whoever's listed in whois. Don't expect a same-day response — these are usually side-of-desk jobs for whoever drew the short straw.

If you strike out with one locality, try a neighboring one. I haven't tested whether residency is strictly enforced for personal use, but in practice the registries care more about whether your contact details are real than where you happen to sleep.

Step 3: Set up DNS once you have it

Say you've been granted alan.portland.or.us (hypothetical). The registry will usually let you specify nameservers. Point them at your DNS provider of choice, then set up records like any other zone:

; zone file for alan.portland.or.us
$ORIGIN alan.portland.or.us.
$TTL 3600

@       IN  SOA  ns1.example-dns.net. admin.alan.portland.or.us. (
                2026051401  ; serial — bump this when you edit
                7200        ; refresh
                3600        ; retry
                604800      ; expire
                300 )       ; minimum TTL
@       IN  NS   ns1.example-dns.net.
@       IN  NS   ns2.example-dns.net.

@       IN  A    203.0.113.10
www     IN  CNAME @
api     IN  A    203.0.113.11

Standard stuff. If you're using a managed DNS provider, paste the records into their UI and move on.

The gotchas nobody warns you about

This is where I've gotten burned, so pay attention.

Cookie scope issues

Browsers treat *.state.us as a public suffix. That means cookies set on alan.portland.or.us won't leak to bob.portland.or.us — which is good. Cookie sharing across your own subdomains works fine.

What breaks: libraries and tools that hardcode TLD assumptions. I once spent two hours debugging a session bug because a JS library was using a naive "last two segments are the apex" heuristic. The fix is checking against the Public Suffix List instead:

// bad — assumes the TLD is one segment
const apex = host.split('.').slice(-2).join('.');
// → "or.us" 🙃

// good — use the Public Suffix List
import { getDomain } from 'tldts';
const apex = getDomain('alan.portland.or.us');
// → "alan.portland.or.us"

The Public Suffix List is the authoritative source. If a tool you depend on doesn't use it, expect weirdness around cookies, OAuth redirects, and analytics dedupe.

HSTS preloading is harder

Locality domains generally aren't on the HSTS preload list the way .dev and .app are. That means the first request to your site can be plaintext, which matters if you're hosting anything sensitive. Add the HSTS header yourself and let browsers learn it on first visit:

Strict-Transport-Security: max-age=63072000; includeSubDomains

You can also submit for preloading at hstspreload.org, though the criteria are strict and a deeply nested locality domain can be a tough sell.

Certificate issuance works fine

Let's Encrypt issues for locality domains without complaint — they validate via standard ACME, no special handling. DNS-01 and HTTP-01 both work. If you want a wildcard, DNS-01 is your friend:

certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials ~/.secrets/cf.ini \
  -d "*.alan.portland.or.us" \
  -d "alan.portland.or.us"

The one issue I've seen: a few older client libraries choke on the long FQDN because of buffer-size assumptions. Use a modern stack and you'll be fine.

Prevention tips

A few rules from doing this more than once:

• Get the registration in writing. If a locality grants you a domain via email, save that email forever. There's no central registrar to appeal to if someone reassigns your name.
• Set up auto-renewal where possible. Some localities require annual confirmation. Calendar reminders save lives.
• Don't use it for anything mission-critical. A volunteer-run registry can vanish. For a side project this is fine; for a customer-facing business, pay the $12.
• Use a DNS provider with API access. When you need to rotate records fast, fighting a 1998-era zone editor inside a state government portal will ruin your week.

The locality domain space is one of those corners of the internet that exists because nobody bothered to clean it up. That's also why it's cheap and unloved enough to still be useful in 2026. Worth the half-hour of paperwork if you've got a project that deserves a real domain but not a real budget.