Connecting a domain to your AI app, in plain language
Connecting a domain is three things. You buy a name in your own name. At the seller of that name, you fill in two lines that your host gives you. And you wait until the rest of the internet has taken over those lines. The two lines are called records. One says which address the bare name points to, the other where a subdomain such as www should go. Your host gives you both, word for word.
This article explains what happens when someone types your name, why it matters who owns the domain, and what the records mean. After that: how HTTPS is added, why a change is not visible everywhere straight away, and which mistakes are the most common. Without you needing to know how DNS works on the inside.
What happens when you connect a domain?
When someone types your name, their browser asks the domain name system (DNS) where that name points. The answer is the address of a server, and your project runs on that server. Connecting a domain is nothing more than filling in that answer: you tell the system that from now on your name points to the server of your host.
You do not fill that in at your host but at the party where you bought the name, the registrar. For your name, the registrar keeps a small table of lines, and each line is a record. Your host tells you which lines need to go in. You copy them over. After that it is a matter of waiting until the system, which is spread across the whole world, has taken over the new lines.
So there are three parties: you (the owner of the name), the registrar (where the lines are kept) and the host (where the page runs). Whoever keeps those three apart understands ninety percent of what can go wrong.
- Typing a name is a question to DNS: where does this point.
- The answer is in records at your registrar; your host says what goes in them.
- Three parties: you, the registrar, the host. Each does one thing.
Who owns the domain, and why does that matter?
Whoever it is registered to at the registrar, and that should be you. Not your build tool, not a friend who sorted it out for you, not an agency. Whoever owns the domain owns your address: they can let it expire, move it or point it at something else, and you can do nothing about it. That is why a domain is the first step after ownership of your code, and not something you will sort out later.
Some build tools offer to buy the domain for you. That is convenient, and it is a choice that can get in your way later: if you leave the tool, the domain has to come along, and that is a transfer with a waiting time and a risk. Buy it yourself, at a registrar you know, with an email address you will still read in five years. Turn on automatic renewal. An expired domain is the fastest end there is for a project.
Keep the login details of the registrar in the same place as the other keys of your project, and not in the code. Whoever can get into your registrar can redirect your whole address.
- The domain is in your name, at a registrar you choose yourself.
- Automatic renewal on; an email address you keep reading.
- Access to the registrar is access to your address: treat it that way.
What are an A record and a CNAME?
An A record ties a name to an address in numbers, the IPv4 address of a server. It is the direct form: your name, this address. An AAAA record does the same for the newer IPv6. A CNAME ties a name to another name: www.yourname.nl points to a name of your host, and that name then points on to the address. An alias, in other words, and the advantage is that your host can change the address without you having to adjust anything.
In practice your host usually gives you exactly these two: an A record for the bare name (often shown as an at sign) and a CNAME for www. Sometimes you get two A records, sometimes only a CNAME. Follow what your host says; that takes precedence over any article, including this one.
There are more kinds. MX records determine where your email goes, TXT records carry text that other systems read, for example to prove that you are the owner. You leave those alone if they are already there. An email address that stops working because someone removed the MX record while connecting a website is a classic.
- A: name to address. AAAA: the same for IPv6. CNAME: name to another name.
- Your host specifies which ones you need; follow that literally.
- Leave MX and TXT alone; they belong to your email and your proofs.
What does your host give you, and what do you do with it?
Every host has a screen where you add your own domain. You type your name, and the host shows what you need to set at your registrar: the type of record, the name (the at sign or www) and the value (an address or a name of the host). Sometimes with a short check, and sometimes with an extra TXT record to prove that the name is yours.
At your registrar you look for the management of DNS records, often under a heading such as DNS, records or zone management. There you add the lines, exactly as the host shows them, including any dot at the end of a name if there is one. If there is already an A record for the bare name, for example from a parking page, you replace it; two A records pointing to different places make your site unreachable every other time.
Save, and go back to the host. Most hosts check by themselves whether the records are visible yet and then prepare the certificate. That is the moment to go and do something else.
- Host: add the domain, read off the records.
- Registrar: DNS management, copy the records literally, replace old A records.
- Back to the host, and wait.
How does the padlock get there?
The padlock in the browser means that the traffic between visitor and server is encrypted, and that an independent party has established that the server belongs to your name. That takes a certificate. You used to buy one and install it yourself; now almost every host arranges it for you as soon as your records are right, free of charge and with automatic renewal.
So usually you do not have to do anything for it, except check that it is there. Open your site with https:// in front and see whether the browser gives a warning. Also check whether a visitor who types http:// is automatically sent to the encrypted version; most hosts do that, and it is a setting you can turn on if not.
If the certificate does not appear, the cause is almost always that the records are not visible everywhere yet. In that case wait, and try again later, before you change anything.
- The certificate comes from your host, as soon as the records are right.
- Check
https://and the redirect fromhttp://. - If it does not appear: wait, do not tinker.
Why does it take a while, and how do you check it?
Because DNS is remembered all over the world. Every server that has ever looked up your name keeps the answer for a while, and how long is stated in the record itself as the TTL, the time to live. Until that time has passed, such a server gives the old answer. That is why your site may already work for you and not yet for a friend, or the other way round. That is not an error; that is the system.
It is usually done within an hour, sometimes it takes longer. You do not check it by opening your site over and over, because your own computer remembers the old answer too. Use a public DNS lookup service, type your name, and see which address comes back. If it matches what your host specified, the rest is a matter of time.
If you want to keep the waiting time short for a future move, you lower the TTL a day in advance. For a first connection it does not matter.
- DNS remembers answers; the TTL in the record says for how long.
- Check with a public lookup service, not with your own browser.
- Usually within an hour, sometimes longer; patience is the right action here.
Which mistakes are the most common?
Buying the name in someone else’s name: see above. Putting the record in the wrong place, at the host instead of at the registrar, or at an old registrar you had forgotten about. Leaving an old A record next to the new one. Removing an MX record so that your email stops. A typo in the value, especially a missing or extra dot. And tinkering while the system is still busy with the previous change, so that you no longer know which version is actually there now.
The remedy is always the same: make one change, save, check with a lookup service, wait. Write down what you did and when. If it still does not work after a day, something is wrong in the records themselves, and you compare them line by line with what the host shows.
And once it works: set up the redirect from the bare name to www or the other way round, so that your site exists at one address. That is the last step, and at the same time the start of the next one: the data.
- Wrong owner, wrong place, double A record, vanished MX, typo, tinkering too early.
- One change at a time, save, check, wait, write it down.
- Once it works: choose one address and send the other to it.
Sources
Checked on 5 September 2026. What your host and your registrar specify takes precedence over everything here; this article explains what you read there.
Further reading
Three places that connect to this.
From first prompt to tax return.
The platform opens later. Questions or comments can be sent to info@basestep.io.