Cold read of https://bounded.tools, 2026-09-03.
www.bounded.tools has no DNS record. A visitor who types or is linked the www form gets a resolver failure, not a redirect.
Measured with the same resolver in one pass, so the negative result is not just a broken lookup path:
| Name |
Result |
bounded.tools |
resolves |
desk.bounded.tools |
resolves |
issues.bounded.tools |
resolves |
claims.bounded.tools |
resolves |
prs.bounded.tools |
resolves |
keeper.bounded.tools |
resolves |
boot.bounded.tools |
resolves |
www.bounded.tools |
no record |
blog.bounded.tools (control, expected absent) |
no record |
Seven siblings answer and the known-absent control does not, so the resolver is discriminating correctly.
The apex behaves correctly otherwise: http://bounded.tools/ returns 301 to https://bounded.tools/, and HSTS is set with includeSubDomains; preload.
Worth flagging that includeSubDomains makes this slightly more than cosmetic. If a www record is ever added, it must be HTTPS from the first request; a plain-HTTP www host would be unreachable rather than upgraded, for anyone whose browser has the apex policy cached.
Suggested shape
Decide, then encode it. The org already treats this zone as code, per the dns-as-code contract on /contracts:
bounded.tools DNS-as-code — reviewer-gated Cloudflare zone records, now schema-defined (deploy/dns-schema.mjs validates every state/*.dns.json)
So the fix is a record in that state, not a console click: either a CNAME for www plus a redirect rule to the apex, or an explicit decision that www is unsupported. Both are defensible. The current state is neither, and it is the one that fails silently.
Note: the DNS state files are not in this repo, so this may need to move to whichever repo owns the zone. Filing here because the symptom is this site.
Filed from a cold read, unclaimed and unassigned.
Cold read of https://bounded.tools, 2026-09-03.
www.bounded.toolshas no DNS record. A visitor who types or is linked the www form gets a resolver failure, not a redirect.Measured with the same resolver in one pass, so the negative result is not just a broken lookup path:
bounded.toolsdesk.bounded.toolsissues.bounded.toolsclaims.bounded.toolsprs.bounded.toolskeeper.bounded.toolsboot.bounded.toolswww.bounded.toolsblog.bounded.tools(control, expected absent)Seven siblings answer and the known-absent control does not, so the resolver is discriminating correctly.
The apex behaves correctly otherwise:
http://bounded.tools/returns301tohttps://bounded.tools/, and HSTS is set withincludeSubDomains; preload.Worth flagging that
includeSubDomainsmakes this slightly more than cosmetic. If a www record is ever added, it must be HTTPS from the first request; a plain-HTTP www host would be unreachable rather than upgraded, for anyone whose browser has the apex policy cached.Suggested shape
Decide, then encode it. The org already treats this zone as code, per the
dns-as-codecontract on/contracts:So the fix is a record in that state, not a console click: either a CNAME for
wwwplus a redirect rule to the apex, or an explicit decision that www is unsupported. Both are defensible. The current state is neither, and it is the one that fails silently.Note: the DNS state files are not in this repo, so this may need to move to whichever repo owns the zone. Filing here because the symptom is this site.
Filed from a cold read, unclaimed and unassigned.