You type a friendly name like benali.com, and DNS points your browser toward the right server. Buying a domain doesn’t make your site live; you still have to tell the lookup system where the site lives.
Think of the front desk directory in an office building. You know the company name, not the suite number. The directory says “Benali is on floor 12, suite 1204.” It isn’t the office; it’s what tells you where to go. A domain is the friendly name, the server address is where the site lives, and DNS connects them. Buying a domain is like reserving the name in the directory; you still point it at the office by setting DNS records.
How it shows up
You’ll hear DNS during deployment. Your site may be ready on a host like Vercel while the domain still points somewhere old, or email works but the website doesn’t. Different records have different jobs: one points the site to a host, one helps email prove your messages are legitimate, one routes traffic through a cdn for speed. DNS also takes time to update, which people call propagation: copies of the directory around the city don’t all refresh at once, so for a while some people see the new address and some the old. This matters with AI tools because an agent can build the site and still not control where the domain points without the right access. It may report the cloud deployment succeeded while the public address still needs DNS work.
Why you care
The practical question is simple: where should this name point, and who controls that setting? A working site is useless if the name people know points to the wrong door.