.bz
Availability-check reliability and the registry servers we query for .bz domains.
Our answer rate
Not enough data Generic- Answer rate
- 100.0% of attempted checks returned a definitive answer
- Check volume
- Minimal (coarse band, not a count)
- Mostly answered by
- DNS
- Still available
- 97.6% of answered .bz candidates were unregistered
- Last definitive answer
- 2026-09-21
Servers we query for .bz
Public registry infrastructure — a whois, a
dig NS bz, and one read of
IANA’s bootstrap file
return the same three values. Listed here for convenience.
- WHOIS host
- none — this registry publishes no WHOIS server
- Authoritative nameservers
-
a0.cctld.afilias-nst.info199.254.59.1a2.cctld.afilias-nst.info199.249.116.1b0.cctld.afilias-nst.org199.254.60.1b2.cctld.afilias-nst.org199.249.124.1c0.cctld.afilias-nst.info199.254.61.1d0.cctld.afilias-nst.org199.254.62.1 - RDAP endpoint
- no RDAP server — .bz is checked by DNS / WHOIS
What this measures: the share of our own availability checks that came back with a definitive answer. Nobody else publishes this, because nobody else is running bulk registry lookups at this scale and recording what came back.
What it does not measure: a registry’s uptime or quality. A low rate here can just as easily mean our requests are being rate-limited as it can mean anything about the registry itself.
These are current-state figures, not a history. We keep one record per domain, holding its most recent check — so a TLD that failed hundreds of times and then recovered reads as healthy here. A low rate means checks are failing now; a high one does not mean they always have.
Figures count domains checked, not queries — a domain checked six times counts once. Candidates we generated but never checked are excluded entirely; they are not failures. Snapshot rebuilt 2026-09-27 02:19:47.