Highport orbital control

Bringing your domain alongside

Two records, two jobs. One proves the domain is yours, the other brings traffic alongside, and nothing clears until both are in place.

Register the domain first. Create the two records we hand you. Then wait for us to see them. The Hub walks you through all three, and this page is what it is doing on your behalf. Your first site is the same ground with the publishing either side of it.

This is the longest anything on the station makes you wait, and it is not us doing the waiting. It is DNS.

Register first

Registering claims the domain for your account and hands back the exact records to create. Do it in the Hub, or call space.highport.manage.register from any AT Protocol tool.

The response carries a records array. Create what it tells you.

Do not build the records from this page. The values are specific to your domain and your account, and the response is the only authority on what they should say. What follows is the shape, so you know what you are looking at.

Your DID is your account's identifier on the network, the thing your handle points at. It is not a secret, and the ownership record works precisely because anyone can compute it. What the record proves is that you control the zone, not that you know something.

Which of the two the traffic record is depends on whether the name is an apex, and the response tells you.

The traffic value is an address of the domain's own, t- and thirteen letters and digits under highport-dns.net. It is made up when you register and belongs to this registration alone, which is what lets us move one site, to another region or away from trouble, without asking you to change anything. Registrations made before these addresses existed were given go.highport.space instead, and it still works.

The Value column is the part that has to be entered character for character. The Name column is not, because providers disagree about how a name is written. The two sections below say what to type where, one record each.

A registration you never verify is released after 168 hours. The clock starts when you register. When it runs out the domain is free for anyone to claim again.

That number is a deployment setting, not a rule of the protocol. The variable is BARD_RESERVATION_HOURS and its default is 168. The countdown on screen says "168 hours" as a fixed string instead of reading the setting, so on a deployment that has changed it the sentence and the clock disagree. The expiresAt timestamp below is the one to trust.

What comes back

{
        "domain": "example.com",
        "status": "pending",
        "records": [
          {
            "type": "TXT",
            "name": "_bard.example.com",
            "value": "did=did:plc:z72i7hdynmk6r22z27h6tvur",
            "ttl": 300,
            "purpose": "ownership",
            "required": true
          },
          {
            "type": "ALIAS",
            "name": "example.com",
            "value": "t-k3vbd7kgdlswa.highport-dns.net",
            "ttl": 300,
            "purpose": "traffic",
            "required": true
          }
        ],
        "expiresAt": "2026-09-12T14:03:11.412Z"
      }
      

The domain, the DID, the traffic address and the timestamp above are made up for illustration. The field names, the ttl of 300 seconds and the two purpose values are exact.

expiresAt is the end of the 168-hour hold. It comes back from register and from nowhere else.

To read the same thing back later, with the records, the last check and the certificate, call space.highport.manage.getDomain or open the domain's page in the Hub. It returns the records register returned, from the same function, so the two cannot drift.

What can be registered

Anything refused comes back as InvalidDomain with a sentence naming the rule it broke. example.co.uk and nick.github.io are both fine. The rule is about public suffixes, not about how many dots there are.

One account holds five registrations at a time by default. Limits and quotas has that number and the rest of them.

A name we provide

If your deployment offers names under a zone of its own, picking one skips this entire page. There is no DNS to set up, because we run the zone. register answers "status": "verified" with an empty records array, and the Hub takes you straight to the editor.

Some labels are held back under those zones: www, admin, mail, wpad and several hundred more that would read as the operator's, or that other software looks for. Ask for one and you get InvalidDomain saying so. The list applies only under a zone we run. On a domain you prove by DNS you may call things whatever you like.

Registering to a space

register takes an optional space. A domain registered to a space is served from that space's records instead of from your own account, and only the space's authority may register a domain to it. The DNS records are otherwise identical.

A domain belongs to one or the other and never both, and it cannot cross. If you want to move one, release it and register it again on the other side. A site record published from the wrong side is turned away when it arrives, with DomainNotOwned or DomainNotInSpace.

Spaces is the rest of that story.

Handing out names under your domain

A verified domain can also hand out names one label beneath it to other accounts, for their handles and their sites, with one wildcard record instead of a registration and a DNS record each. Handing out names under your domain is that whole process. While a domain does it, nobody but its owner can register a name under it.

When register refuses

Registering to a space can refuse for reasons of its own, and Spaces has those.

The ownership record

The TXT record at _bard.<your domain> is the one that proves the domain is yours. Its value names your account, so pointing DNS at us is not enough on its own. Somebody else can point their DNS here too. Only you can put your name on it.

Most DNS providers ask for the name relative to your zone, so the record whose name the response gives as _bard.example.com is entered as _bard and nothing more. Some accept the full name and normalize it themselves. Either of those is fine. Typing the full name into a relative field is not, because the provider then appends your domain to it and you get a record at _bard.example.com.example.com, which nothing will ever look at.

Save the record and then read back the name the provider displays. A name ending in your domain twice is the record in the wrong place, and it is worth checking for, because the field you typed it into still shows exactly what you meant.

The value is the part that must match character for character: did= followed by your own DID, and nothing else in the string.

The label is _bard and not _highport because bard is the name of the software this station runs, and the label is already in every zone that has ever registered here.

The label may hold more than one TXT record. We look for yours among them instead of requiring the label to hold nothing else. Some providers add the surrounding quotes for you, and a value that ends up doubly quoted will not verify.

If a second account's ownership record also answers at that label, the domain stops verifying for as long as it is there. Your own record passing is not enough while somebody else's sits beside it. A domain waiting to be verified will not verify; one already verified starts down the same clock as a domain whose record went missing. Remove the competing record, or ask whoever controls it to, and the next check finds it gone and moves on. The check is a plain reading of the zone, so nothing has to be reset by hand.

The Hub raises its own callout for this, and it is the one place the competing account is named. The one-line verdict beside it reads: Another identity's ownership record answers for this domain. Remove the competing record, or ask whoever controls it to.

_atproto.<your domain> is never accepted as proof, even though it carries a did= value of its own for a domain used as a handle. Having a handle at a domain is not asking us to host it.

The traffic record

Traffic goes to the value the response gave you: the domain's own address, like t-k3vbd7kgdlswa.highport-dns.net. A domain registered before those addresses existed points at go.highport.space, which keeps working. Its Settings tab offers the switch, and switching is one edit to this record.

On a subdomain like www.example.com or blog.example.com, that is an ordinary CNAME and you are done.

An apex domain is the awkward one. example.com with nothing in front of it cannot take a CNAME, because the DNS specification does not allow it. Your provider will offer one of these instead:

Pick whichever one your provider has. If it has none of them, put the site on a subdomain, or move the domain's DNS to a provider that does.

Names are entered here the same way they are on the ownership record. In a relative Name field a subdomain is its own label alone, so www and not www.example.com, and an apex is @ at most providers. The value is the part to copy exactly, and it is worth reading back what the provider displays afterwards.

We will never hand you an A or AAAA record, and no instruction we return names one of our addresses. An address in your zone is an address we could never change without waiting out your TTL, and everyone else's.

A domain and its www are two hostnames

Everything on this page happens one hostname at a time. example.com and www.example.com are two hostnames, so serving both means doing all of it twice. Two registrations. Two _bard. ownership records. Two traffic records, an ALIAS or its equivalent at the apex and a plain CNAME at www. And two site records, because a site record's key is the hostname it serves. Both count against your registration limit.

To serve the same pages at both, publish the same manifest under each hostname. The files are already in your account and are not uploaded again. The second record names the same ones the first does.

We cannot redirect one hostname to the other. A redirect's target has to be a path on the same site. It must begin with / and name a file that site serves, so there is no rule that sends www.example.com to example.com. If you want one name to redirect to the other instead of serving its own copy, set that up wherever your DNS provider or registrar offers forwarding, and point only the other name at us. Redirects, missing pages, and being your own handle has the rest of the redirect rules.

Clearance

Verifying a domain means checking three things:

All three run on every pass and all three are reported, whether they passed or not.

Ownership and conflict are what decide it. The traffic check reports what it sees and does not hold up verification, so a domain can verify with the traffic check failing. What the traffic record holds up is people actually reaching your site, which is the part that matters on the day. If your DNS provider proxies traffic through its own addresses, the traffic check will say it cannot see us. It is not a failure you need to fix before verifying.

A DNS lookup that errors counts as a failed check. We cannot tell "the record is not there" from "the resolver would not answer", and treating an error as neutral would mean a domain that changed hands stayed bound to its old account forever. The grace periods below are what absorb an outage, not the error handling.

When the ownership check keeps failing

Each failed check is reported with the resolver's own words. Three of them come up, and they point at different mistakes.

How often we check

You can ask for a re-check, with Check now in the Hub or space.highport.manage.verify, once every thirty seconds per domain. Asking faster returns RateLimitExceeded and a 429. There is nothing to gain by it. Between your requests we are checking anyway, often at first and then more slowly as time passes.

Six passes at ten seconds is the first minute, which is why the first step lasts that long. A fresh registration gets its first check within ten seconds of being made.

What the Hub does while you wait

The domain's page reads itself every ten seconds and stops once the registration settles. There is nothing to refresh and nothing to press.

Check now runs the same three checks immediately, from the same function the scheduled pass runs, so a forced check and a scheduled one cannot disagree. After each press it is disabled for thirty seconds, showing how long is left. It is not offered at all once the domain is serving with its certificate in place, because there is nothing left for it to change.

One verdict is shown, not three:

One sentence sits under the verdict. While the domain is waiting it reads, in full: Add the two records above at your DNS provider, then leave this page open — it re-checks on its own. Nothing else is needed from you. Once it verifies, and until something is published at it, that becomes Your domain is verified. Publish a site and it goes live at this address.

You do not have to wait for verification before publishing. A site record you write while the domain is still waiting is turned away with DomainNotOwned at first, and the check that verifies the domain queues it again, so it goes live without a republish. A record you wrote before you registered the domain at all can wait for our daily pass over verified domains, which takes up to a day. Publishing again after the domain verifies brings it up straight away.

The resolver's own words, the raw text of each failed check, sit in a closed disclosure below that sentence. Open it when you want the detail; ignore it otherwise.

The remaining time on the 168-hour hold is shown on the screen where you registered, and only there. Come back to the domain's page later and you will get the same records and the same verdict without it.

Every state, and what moves it

The schema declares a seventh, failed, that nothing in the running system writes. You will not see it.

released is the only status the Hub hides from you. A suspended domain is shown, deliberately: a takedown you cannot see is a support ticket with no answer.

It is also the only status that frees the name outright, with one short exception: when the domain had a wildcard certificate, it stays refused with DomainTaken, to you as well, until that certificate has been revoked and deleted, usually within about twenty minutes of the release. In verified, active and suspended the domain is yours, and another account asking for it is refused with DomainTaken. The two unproven states are weaker.

Unproven claims can be taken

An unproven claim, meaning pending or verifying, is a claim and not a reservation. Another account that registers the same name replaces it, and DNS then decides between you. That happens at any point, not only after the hold runs out.

A verified claim cannot be taken this way. Get the ownership record in place and the name is yours until you give it up.

When the hold runs out

At 168 hours a claim that was never proven is released. The name becomes free for anyone, including you, and the registration's history stays in our log.

Nothing else is lost. If you already wrote a site record it is still in your account, untouched, because it was never ours. Registering the name again, assuming nobody took it in between, starts the same process over.

When proof stops resolving

A domain that was verified and then loses its ownership record is on a longer clock, measured from the last time ownership was actually proven and not from a count of failures:

Put the record back inside that window and the next check picks it up. Seven days is this station's setting, and the release is at twice whatever it is.

If only one record is in place

DNS pointed here, nothing registered. A visitor's browser opens a connection, and before a certificate is obtained for any name we check that the name is registered. This one is not, so the connection fails before a page is ever requested and the visitor sees a certificate error instead of anything of yours. Register the domain and the next attempt goes through.

Registered and verified, DNS not pointed here. Ownership is what proves the domain is yours, so the domain verifies on the TXT record alone and you can publish to it. Nobody reaches it: the name still resolves wherever it did before. The traffic check will have been saying so the whole time.

In that second case you may also see Needs attention with The certificate could not be issued, followed by the reason. We try once to open a connection to your domain, and if that connection does not reach us we record the attempt as failed. It clears on its own once a certificate exists, as below, so there is nothing to press.

The certificate

Once the domain is verified, we open a connection to it ourselves, usually within a minute or two, and the certificate is obtained during that handshake. The request goes to /_bard/health, which is reserved on every host we serve, so it never touches your pages and does not appear in your traffic as a visit nobody made.

If that connection does not succeed, nothing is lost. The certificate is obtained on the first real visitor's connection instead, and the domain's page catches up on its own once that has happened.

There is nothing for you to do, nothing to renew, and nothing to pay.

Releasing a domain stops us authorizing a certificate for it from that moment on. The edge is where the whole of that machinery lives, if you want it.

Why publishing waits

You can validate a record at any time. Compose one, check it, fix what it points at, all while DNS is still making its way around the world.

Publishing is different. We will not serve a site at a domain that is not verified, and a record published to one would be turned away on arrival. So the Hub disables the publish button until the domain is verified, and tells you that is why: Your domain is not verified yet — Highport will not serve a page at a domain nobody has proved they own. Add the DNS records on the domain page first; checking again costs nothing.

Called directly, that refusal is validate answering "prepared": false with the reason DomainNotVerified. Validate before you write is the rest of it.

Releasing a domain

Releasing is the reverse of registering. The registration ends, anything serving there stops in the same moment, and the name is free for anyone to claim. Deleting your site's content is a different action that leaves the registration, the DNS records and the certificate exactly where they are. Editing, deleting and moving on has both, and the two other stops people mistake for them.

Site owners · 2 of 12