How to point a domain to your server or app

You bought a domain, you have a site, API or dashboard running, and you want mysite.com to open your app instead of a technical address. DNS is what connects the two: in a control panel, you say where each name should point.

The process is the same on any host: the host gives you a target (a name or an IP), and you create the matching record in the domain's DNS zone. The zone is controlled by your registrar or by the DNS provider you chose, not by the host.

Where do my domain's DNS records live?#

Records live on the domain's nameservers. If you never changed anything, those are your registrar's own (GoDaddy, Namecheap, Porkbun and others). If you delegated DNS to a provider such as Cloudflare, you edit records there, and the registrar's DNS panel no longer matters.

To find out who controls the zone, run:

dig NS mysite.com +short

The names returned (for example ns1.example-dns.com) tell you which panel to use. On a machine with only nslookup:

nslookup -type=NS mysite.com

For what each record type does, see what DNS records are.

A, AAAA or CNAME: which one should I use?#

• A: points a name to an IPv4 address (203.0.113.10).
• AAAA: the IPv6 equivalent.
• CNAME: points a name to another name (app.host.example). The resolver follows that name until it finds the IP.

Rule of thumb: if your host gave you a name, use CNAME; if it gave you an IP, use A. CNAME is better when the IP can change, because the host can swap the IP without you touching DNS.

The restriction that catches everyone: per RFC 1034, when a CNAME exists at a name, no other data should exist there. The root domain (mysite.com, no prefix) always has NS and SOA records, so it cannot take a CNAME. For the root, use an A record, or a provider with CNAME flattening (or an equivalent record that some providers call ALIAS or ANAME), which resolves the target name for you and returns IPs.

How do I point a domain, step by step?#

1. Get the target from your host's panel: a name for CNAME or an IP for A.

2. Open the DNS zone at your registrar (or at your DNS provider, if you delegated).

3. Create the record. Example for the app subdomain:

   Type	Name (host)	Value	TTL
   CNAME	app	host-target.example	300

   And for the root and www:

   Type	Name (host)	Value	TTL
   A	@	203.0.113.10	300
   CNAME	www	mysite.com.	300

4. Remove conflicts: an old A or AAAA record at the same name blocks the CNAME, and the panel usually refuses to save.

5. Save and wait for propagation.

Some panels want the full name (app.mysite.com) and others only the prefix (app). If the panel appends the domain itself and you type the full name, you end up with app.mysite.com.mysite.com, a classic mistake. The values 203.0.113.10 and host-target.example above are placeholders: use what your host shows.

How do I check that the domain is pointing correctly?#

Query the record directly, without relying on the browser cache:

dig app.mysite.com CNAME +short
dig mysite.com A +short

To see what a public resolver sees, query a specific server:

dig @1.1.1.1 app.mysite.com +short

If the answer matches the target you configured, DNS is right. Then test in the browser, preferably in a private window, and with curl -I https://app.mysite.com to see the HTTP status. The HTTPS certificate is a separate step: a host can usually only issue TLS once the domain resolves to it.

How long until it takes effect?#

DNS is cached. Each resolver keeps the old answer for the record's TTL (in seconds). If the old record had a TTL of 3600, some users keep seeing the old target for up to an hour. A new name usually works within minutes, unless someone looked it up before it existed: then the resolver caches the "does not exist" answer for a time set in the zone's SOA.

Before a migration, lower the current record's TTL to 300, wait for the old TTL to expire, make the switch, and only then raise it again.

What are the most common mistakes?#

• CNAME on the root: the panel refuses it or the site disappears. Use A or ALIAS.
• Duplicated name: app.mysite.com.mysite.com, from typing the domain where the panel already completes it.
• Conflicting record: an old A at the same name as the CNAME.
• Wrong nameservers: you edit at the registrar, but the domain is delegated elsewhere. Check with dig NS.
• Forgetting www: mysite.com opens and www.mysite.com errors, or the reverse. Create both.
• Domain-not-found errors: see DNS_PROBE_FINISHED_NXDOMAIN to diagnose.

For the concepts behind all this, read what DNS is and how to use a custom domain.

How to do this on Square Cloud#

On Square Cloud, the target you get is always a name, never an IP: when you add the domain, the dashboard asks for a CNAME to cname.squareweb.app and a TXT record for validation. That is this guide's rule of thumb (you got a name, so create a CNAME), and there is a reason for it: the platform does not offer a static IP, so an A record would go stale.

For the root domain, your DNS provider must support a CNAME at the apex (flattening or ALIAS). For www, the recommended setup is a redirect to the main domain. After you create the records at your registrar, follow the validation in the dashboard in real time. Once the domain is validated, TLS is issued automatically, with no certificate for you to generate. Accented domains (Punycode) are supported, and cache purge is available.

The domain stays registered in your name, and the zone stays at your registrar or DNS provider. Custom domains are available from the Standard plan (starting at R$44.99 per month). On every plan, each web app already has a *.squareweb.app subdomain with HTTPS, handy for testing before you point the domain. See the details in custom domains and, if several apps will serve the same domain, in load balancing.