> ## Documentation Index
> Fetch the complete documentation index at: https://wiki.lumiweb.cc/llms.txt
> Use this file to discover all available pages before exploring further.

# When your domain goes live

> DNS propagation timeframes and how to check

Registered a domain or changed a record, but the site still won't open? Most likely **DNS propagation** is underway — a normal delay, not a malfunction. It usually finishes within **10–30 minutes**, and in rare cases takes up to **24–48 hours**. Below is how to check that it's moving.

## What DNS propagation is

DNS translates the name `example.com` into a server's IP address. When you change something (register a domain, edit a record, switch NS), the new data spreads across DNS servers worldwide **not instantly**.

Each server keeps the answer in its cache for a time set by the TTL value. Until the old answer expires, the server hands back the previous value — that's why for some people the site already opens at the new address while for others it's still at the old one. That's propagation.

<Note>
  You can't skip propagation or turn it off — you can only wait. Any service that promises "instant propagation" is misleading you.
</Note>

## How long it usually takes

| Action                          | Usually        | Maximum   |
| ------------------------------- | -------------- | --------- |
| New domain registration         | 10–30 min      | 24 h      |
| Changing NS servers             | 30 min – 4 h   | 24–48 h   |
| Adding or changing a DNS record | 5–30 min       | 24 h      |
| Enabling Cloudflare             | 30 min – 1 h   | 24 h      |
| Changing the IP in an A record  | depends on TTL | see below |

The numbers are approximate: in practice almost everything finishes within the usual time, and it rarely reaches the maximum.

### Changing the IP in an A record — a special case

When you change the IP in an A record that already exists, the speed depends on that record's **TTL**: servers worldwide hold the old IP for exactly as long as the TTL specifies.

So here's the rule: if you know in advance that you'll be changing the IP, **lower the TTL to 300 (5 minutes) a day before the change**. Then on moving day the old address expires in minutes rather than hours. After the move, you can set the TTL back.

<Tip>
  TTL is edited in the same place as the records themselves: "My Domains → domain → DNS settings". For more, see the [DNS records](/en/domains/dns) page.
</Tip>

## How to check propagation worldwide

These sites show what answer your domain returns from various points around the planet:

<CardGroup cols={2}>
  <Card title="whatsmydns.net" icon="globe" href="https://www.whatsmydns.net">
    A map of DNS propagation worldwide.
  </Card>

  <Card title="dnschecker.org" icon="map-location-dot" href="https://dnschecker.org">
    Checks from various servers, with a forced refresh.
  </Card>
</CardGroup>

Enter the domain, pick the record type (A, for example) — and you'll see a map.

<AccordionGroup>
  <Accordion title="Some servers show the new value, some the old" icon="rotate">
    This is normal; propagation is underway. Wait — different servers update at different speeds depending on the TTL.
  </Accordion>

  <Accordion title="All servers show the old value" icon="circle-exclamation">
    That means the change didn't apply. Check that you edited DNS in the right place: if the domain is delegated to someone else's NS (Cloudflare or a hosting provider, for example), the records need to be changed there, not in the Lumi bot.
  </Accordion>
</AccordionGroup>

## Checking via the console

If you prefer the command line, query the domain directly:

```bash theme={"system"}
# what your current resolver returns
dig example.com A

# what a specific server returns (Cloudflare 1.1.1.1)
dig @1.1.1.1 example.com A
```

The `ANSWER SECTION` block will have the current IP. Compare the answer from different servers — if they disagree, propagation is still underway.

## When to worry

<Steps>
  <Step title="More than 24 hours have passed">
    This is no longer an ordinary delay — time to look into it.
  </Step>

  <Step title="Take a screenshot">
    Open [dnschecker.org](https://dnschecker.org) and save a screenshot — it shows that the servers are still returning the old value.
  </Step>

  <Step title="Message support">
    [@lumisup\_robot](https://t.me/lumisup_robot) — include the domain and the screenshot. That way the specialist immediately gets the picture and can check what's happening on the registry's side.
  </Step>
</Steps>

<CardGroup cols={2}>
  <Card title="Connect to a site" icon="link" href="/en/domains/connect">
    How to point a domain at a server — via NS or an A record.
  </Card>

  <Card title="DNS records" icon="list" href="/en/domains/dns">
    Record types, TTL, and common setup mistakes.
  </Card>
</CardGroup>