Why your site is not loading

The name is a question, not an address

Browsers connect to IP addresses. addaly.com is not one. So before any connection happens, a chain of questions runs: your machine asks a resolver (your ISP's, or 1.1.1.1, or 8.8.8.8), which asks a root server, which points at the .com servers, which point at the authoritative nameservers for your domain, which finally give an answer.

The answer is a record:

• A — an IPv4 address. 104.21.53.18
• AAAA — an IPv6 address.
• CNAME — "ask about this other name instead".
• TXT — arbitrary text, used to prove you own the domain.
• MX — where mail goes.
• NS — which nameservers are authoritative.

Two things people confuse, constantly

The registrar is who you bought the name from — Namecheap, Hostinger, GoDaddy. Roughly $11 or ₹900 a year for a .com.

The nameservers are who answers questions about it. These are often not the same company. If you moved your domain to Cloudflare, Cloudflare's nameservers answer, and the record editor back at your registrar is a form nobody reads. Editing there and waiting for a change that never comes is the single most common wasted afternoon in this subject.

Nothing propagates

"DNS propagation" is a misleading phrase that has cost people days. Records are not pushed anywhere. They are pulled, and then cached, and every cache holds its copy for the record's TTL.

If your A record has a TTL of 3600, a resolver that asked five minutes ago will keep serving the old IP for another 55 minutes, no matter what you do. Your own machine may have asked more recently or less recently than a colleague's, which is why two people see two different sites.

So: lower the TTL to 60 seconds the day before you plan a change. Make the change, watch it take a minute instead of a day, then put the TTL back up.

Ask the question yourself

Stop guessing from a browser. The browser adds its own caching, its own HTTPS upgrade, and its own error pages.

$ dig +short addaly.com
$ dig +short addaly.com @1.1.1.1        # what a public resolver thinks
$ dig +short addaly.com @ns1.example.com  # ask the authoritative server directly
$ dig NS addaly.com +short              # who is authoritative at all

If authoritative gives the new answer and 1.1.1.1 gives the old one, you are waiting on a TTL. Wait. If authoritative gives the old answer, your change did not save, or you edited a zone nobody consults.

Separate the three failures

When "the site is down", it is one of these, and they need different fixes:

1. 1It does not resolve. dig returns nothing. A DNS problem. Check nameservers, then records.
2. 2It resolves but does not connect. You get the IP, the connection hangs or is refused. Firewall, wrong port, nothing listening.
3. 3It connects but the certificate is wrong. The browser shows a security warning, not a 404. Your host has not issued a certificate yet, usually because it is waiting on the DNS to point at it. This is a TLS problem wearing a DNS costume.
4. 4Everything works and you get someone else's 404. DNS is fine, TLS is fine, but the server does not recognise the hostname. You added the domain to DNS and forgot to add it to the application.

The apex quirk

You cannot put a CNAME on the bare domain (example.com) next to other records — the specification forbids it. That is why instructions always say "CNAME for www, A record for the apex". Providers work around it with ALIAS, ANAME, or CNAME flattening, which look like a CNAME to you and resolve to an A record for everyone else.