Connecting a domain you already own

Today, connecting a domain is a page of instructions and a free-text message to support. The instructions are correct. But nothing is tracked: you tell us you've made the change, and until someone looks, that's all anyone knows. Between "sent" and "live" you see nothing.

The proposal replaces that with one tracked thing — a domain connection — that both you and the operator looking after it can see. Same object, same states, different controls. It rests on three commitments.

1. Name the email risk before giving any DNS instruction. Adding one record is safe for your mail. Handing your whole domain to a website builder's "connect this domain" wizard is not — that replaces your nameservers, and your mail records go with them. Today the product never mentions email at all. Add a record, don't hand over the whole domain.
2. Every fact on screen says where it came from. One of exactly four: You told us, We checked at …, Operator recorded, or Waiting. If we haven't checked something, the screen says so rather than implying we have.
3. The mail baseline is a gate, not a notice. If your mail records changed between the snapshot we took at the start and the check we run at the end, the connection stops and an operator has to look. This is the one place the design deliberately slows down.

The proposal adds a check against public DNS — what any resolver on the internet can answer for your domain. That is a different thing from your provider's settings, which is an account we have no access to and never will.

It is deliberately narrow. It reports presence, count and shape — "2 mail-delivery records present, unchanged" — and never the contents of a record. It exists to answer one question: did anything happen to your mail while you were pointing your website at us.

This capability does not exist in the product today. Everywhere it appears in this prototype it is marked as proposed, and the data behind it is fabricated.

Every meaningful region of every page carries a basis. Regions marked observed mirror behaviour that exists in the running product. Regions marked proposed are new and do not exist today.

The dark bar at the top of this page is the study apparatus, not part of the product. Its Outline proposed regions toggle is on by default: it draws a dashed purple rule and a small Proposed corner tag around everything new. Observed regions are never outlined. Turn it off to see the pages as a customer or operator would.

The two portals share one state, held in this browser. Open them in two windows next to each other and they stay in step — an action on one appears on the other without a reload.

1. Open the client portal in one window and the ops portal in another.
2. Leave the scenario on Added one record. Press Reset once so you start clean.
3. In the client window, work through the connection: answer the email question, choose the address, start the connection, add the record, confirm and submit.
4. Watch the ops window. The request appears as a typed domain connection, not a free-text message.
5. In the study bar press Simulate: DNS caught up, then in ops run the recheck.
6. Add the hostname, request the certificate, press Simulate: Certificate issued, then promote the Server Name. The connection goes live in both windows.
7. Press Reset, switch the scenario to Nameservers replaced, and run the same steps. The recheck holds the connection and the promote control stays unavailable.

• Whether a certificate can be issued before the domain resolves to the node. If it can, the order could be inverted — issue first, then have the customer change DNS — and the window where a visitor might see a certificate warning would close. Nobody verified this. The prototype therefore keeps the observed order and shows the window honestly. Treat the inversion as an open question, not a feature.
• Only the www. label gets connected. The flow ends with www.northwind-supplies.example answering. Someone who types northwind-supplies.example on its own still reaches nothing, and after the first instruction card the proposal never mentions the bare domain again. The customer's goal is the domain they own, not one label of it — this narrows it, and narrowing it is a decision the proposal doesn't make out loud.
• The customer can't choose when the window opens. The window is shown, but the choice isn't built. There's no scheduling, no lower-your-TTL-first step, and no way to say you'll do it tonight instead of now.
• The customer's own requests list is unchanged. Only the operator's side gets the typed row. On the customer's side the connection is visible in Domains, but their Support requests area still holds what it held before — nothing about this connection is typed there.
• There's still no way in from the Overview. Connecting a domain isn't one of the things the client Overview offers. Once a connection exists it appears there; a customer arriving with the task still has to find Domains inside an environment first.
• What the ops Web Forwarding section is for. Neither exploration opened it, so nobody here knows whether it is already the product's answer to a bare domain. This proposal doesn't touch it and doesn't guess at it.
• What happens to a domain already answering somewhere else. The flow here assumes the domain isn't currently serving a site that someone would notice going dark. A cutover from a live site is a different problem and isn't modelled.
• Who fixes a replaced zone, and how. The gate stops the connection and says an operator must look. What that operator is able to do next depends on the customer's provider, and the prototype doesn't pretend to know.
• How long any of it takes. No turnaround time, no service commitment and no queue position appears anywhere in this prototype, because none was observed and none may be invented.