(Or: how I stopped losing track of the domains I swore I wouldn’t buy)
I used to be a serial domain-buyer.
Not in a dramatic, “lost a fortune” way — just lots of “oh, that might be useful one day” moments spread over many years. At one point, I honestly couldn’t tell you exactly what I owned, where it was registered, or what half of it pointed at.
I’m mostly better now. Mostly.
But I still own more domains than I like to admit, and I wanted a simple, honest way to see what I’ve got without:
- another SaaS subscription
- a spreadsheet that immediately goes stale
- or building a backend I’d then have to maintain forever
So I built this instead:
👉 https://davorg.dev/mydomains/
👉 Source code: https://github.com/davorg/mydomains
It’s a small, static, browser-only tool for keeping track of domains, their DNS, and where they’re hosted — and it turns out to be surprisingly useful.
What I wanted (and what I very deliberately didn’t)
I wanted something that:
- runs entirely in the browser
- stores its data locally
- can be hosted as static files
- gives me useful facts, not a false sense of certainty
I explicitly didn’t want:
- accounts
- logins
- databases
- background jobs
- “AI-powered insights” (whatever that would even mean here)
This is a tool for me. I trust myself with my own data.
If that resonates with you, read on.
What the tool does
At its core, it’s just an inventory:
- a list of domains you own
- the hostnames you care about (
@,www,mail, etc.) - some notes and keywords so future-you knows why you bought it
On top of that, it can enrich each domain with:
-
DNS data
- NS, MX, TXT for the domain
- A / AAAA / CNAME for each host
-
RDAP data
- registrar
- expiry date
- registration status
-
Best-effort guesses
- DNS provider
- hosting provider per host
Everything is opt-in and cached. Nothing happens unless you click “refresh”.
Architecture: aggressively boring (by design)
There are three files that matter:
index.htmlstyle.cssscript.js
No build step. No framework. No external dependencies beyond public HTTP APIs.
All state lives in localStorage under a single key:
const STORAGE_KEY = 'domainInventory.v1';
If you clear your browser data, it’s gone. Which is why import/export exists.
That’s not a bug — that’s the trade-off.
DNS and RDAP: best-effort, not gospel
DNS is fetched using Google’s DNS-over-HTTPS endpoint:
https://dns.google/resolve?name=example.com&type=A
RDAP is fetched via rdap.org, with a couple of TLD-specific exceptions where needed.
This immediately gives you two realities to accept:
- Not everything has RDAP
- CORS sometimes says no
The code treats RDAP as optional. If it works, great. If not, nothing breaks.
That pattern shows up a lot in this project.
Provider guessing (aka “useful lies”)
One of the more interesting parts was deciding how far to go with interpretation.
DNS provider detection
This is intentionally simple:
function guessDnsProvider(nsList) {
const nsLower = (nsList || []).map(n => n.toLowerCase());
if (nsLower.some(n => n.includes('cloudflare.com'))) {
return 'Cloudflare';
}
if (nsLower.some(n => n.includes('awsdns'))) {
return 'AWS Route 53';
}
if (nsLower.some(n => n.includes('gandi.net'))) {
return 'Gandi';
}
return 'Unknown';
}
Is it exhaustive? No.
Is it useful for my domains? Yes.
That’s a recurring theme here.
Hosting provider detection (and Cloudflare honesty)
Hosting detection looks at:
- CNAME targets
- A / AAAA addresses
- known IP ranges
- known patterns (
.github.io,.cloudfront.net,.a.run.app, etc.)
But DNS can lie — or at least obscure.
So if a host resolves to Cloudflare IPs, the tool does this:
- If it recognised the origin → “GitHub Pages (via Cloudflare)”
- Otherwise → “Unknown (via Cloudflare)”
If the data doesn’t support a confident claim, I’d rather say “I don’t know” than pretend.
Caching with intent
All fetched data is cached per domain, along with a timestamp:
dom.cache.lastChecked = new Date().toISOString();
But here’s the important bit: the cache is only cleared when it should be.
If you edit notes or keywords, nothing is invalidated.
If you change the domain name or host list, the cache is wiped:
if (nameChanged || hostsChanged) {
dom.cache = {};
}
That one small decision makes the tool feel calm instead of twitchy.
What this tool is not
It is not:
- an auto-discovery system
- a real-time monitor
- a source of legal truth about domain ownership
It assumes:
- you know which domains you own
- you know which hosts matter
- you’ll refresh things when you care
In return, it stays small, fast, and understandable.
Possible future improvements (and non-improvements)
Things I might add:
- more provider heuristics (DigitalOcean, Fly.io, etc.)
- configurable IP allow-lists per provider
- better handling of registrar quirks per TLD
- bulk refresh with throttling
Things I probably won’t:
- accounts
- sync
- background polling
- turning this into a product
The moment it needs a backend, it stops being this tool.
Why I’m happy with it
This started as a way to get a handle on my own past enthusiasm for buying domains.
It ended up as a reminder that:
- a browser is a perfectly good runtime
- not every problem needs infrastructure
- “good enough and honest” beats “comprehensive but fragile”
If you own more domains than you’d like to admit, you might find it useful too.
And if nothing else, it’s a nice excuse to build something small, tidy, and under your control.
Top comments (5)
awesome thanks posting. keep it up. didn't know about RDAP and Google dns over http. didn't get the host part though what do you mean by host is it the physical or virtual server what kind of value it should have do u have an example?
Thanks. Glad you learned something new.
I think that "host" means two different things in this blog post.
A "hostname" is a specific domain or subdomain that is configured in DNS. So, I own the domain "davecross.co.uk", but I have also configured a number of subdomains that also point to websites (for example, links.davecross.co.uk, actions.davecross.co.uk and talks.davecross.co.uk). I only need to renew the top-level domain and all of the other "hostnames" also continue to exist.
Or, I mean the "hosting" for a website. The actual server on the internet where the website lives. This can be on my VPS, on GitHub Pages or on some cloud hosting service like AWS or Google CloudRun.
Does that help? Let me know if you need any more clarification.
Its so nice of you to reply back. most people can't find the time to do so. Thanks Dave. Regards the Hosts, I got what you said. but, what confuses me that when you add a domain usually the hosts are empty and the tool doesn't allow to add them manually. so I was curios is it a common known term in the world of DNS or not. I assume no its not and you added this field to track the hosting provider whatever its. do you have an example where this filed host as per the screenshot get populated automatically? I hope the question is now more clear. if not let me know and I'll rephrase it.
You're right. And I see the confusion. In the add/edit dialog box, this field is called "subdomains".
In the main table, this just contains the number of subdomains:
I should switch it to say "Subdomains" everywhere.
Now I understand what you mean by host. yes it was confusing but now its clear. yes I suggest to rename it as mentioned specially this is a domain / DNS tool. Some ideas can be use Free IP APIs to get more live details about the IP address [Host / SubDomain] in your case. also, you could use port scanning to get more details about the sub-domain Host that if the firewall permit it. usually 443/https and 22/SSH ports can be used. if you really want to make more addition I suggest Certificate data retrieval. the server is useless if the certificate expired also good for tracking.