Nameservers (NS) are the servers that hold your domain's DNS records and answer the internet's questions such as "which IP hosts this site" and "where should mail go". When a domain is registered, the registry records which nameservers are authoritative for it. Changing NS moves DNS control from one provider to another: from that moment every record is read from the new servers. That is why it is a process that needs preparation, not just an edit of one field.
NS versus DNS records
People often confuse changing NS with changing an A record. An A record maps one name to one IP address and lives inside the DNS zone. NS records say where the zone itself lives. Switch NS to a new provider and every record at the old one, including the site address, MX, SPF and DKIM TXT records and subdomains, stops mattering instantly. If the new servers lack them, both the site and email go down. The rule is simple: fully prepare the zone at the new provider first, then change NS.
Step 1: inventory your current records
Most DNS servers refuse full zone transfers (AXFR), so check important records manually and save the old panel's record list if possible:
for t in A AAAA MX TXT CAA; do
echo "== $t"; dig +short klinika-misol.uz $t
done
dig +short www.klinika-misol.uz
dig +short _dmarc.klinika-misol.uz TXTDKIM records sit under a selector name such as default._domainkey; get the exact name from your mail service. Do not forget verification TXT records for search engines and other services.
Step 2: build the zone on the new nameservers
The new provider gives you two or more nameservers, usually like ns1.provayder.uz. Add the domain there and enter every record from step 1. If the site moves too, point the A record to the new server; if mail stays, keep MX and related records unchanged. Then query the new server directly, which works even before delegation:
dig @ns1.provayder.uz klinika-misol.uz SOA +short
dig @ns1.provayder.uz klinika-misol.uz MX +shortAn empty answer or REFUSED means the zone is missing or misspelled. Do not change NS until this works.
Step 3: lower TTL in advance
TTL controls how long resolvers cache a record. A day before the move, lower long TTLs in the old zone to around 300 seconds. This does not speed up the NS record itself, which the registry controls, but it shortens the time users spend between old and new data. Raise it again afterwards.
Step 4: change NS at the registrar
Nameservers are changed only where the domain is registered. sayt.uz customers do it in the cabinet under Domains by entering the new hostnames and saving. Keep these rules in mind:
- enter at least two nameservers, ideally on separate machines;
- copy and paste the hostnames, because a single typo breaks the whole domain;
- no trailing dot, spaces or
http://, only the bare hostname; - never mix old and new providers' nameservers.
If the nameservers live under the domain itself, such as ns1.klinika-misol.uz, the registrar also needs their IP addresses, known as glue records. If DNSSEC is enabled, remove the DS record first or set up signing at the new provider, otherwise validating resolvers will fail to resolve the domain.
Step 5: wait for propagation and verify
After the registry update, some users still reach the old servers until resolvers expire their cache. This usually takes a few hours but can stretch to a day or two. Monitor it with:
dig NS klinika-misol.uz +short
dig +trace klinika-misol.uz
nslookup -type=NS klinika-misol.uz 8.8.8.8dig +trace follows the query from the root servers and shows exactly which nameservers the registry hands out. If trace shows the new servers but your browser still shows the old site, that is just a local or ISP cache.
Example: a clinic in Samarkand
A private clinic in Samarkand moved its site to new hosting. The first time, the administrator copied only the site files and switched NS immediately. The site came up the next day, but mail stopped arriving because the new zone had no MX or SPF records, and patient appointment requests went exactly to that mailbox. A day of email was lost. For the second domain they followed the order above: inventory, new zone, dig @ns1 check, lower TTL, then NS change. Nothing broke.
After the switch
Keep the old zone for several days, since resolvers with cached data still query it. SSL certificates on the new server are issued only once DNS points there, so check HTTPS after propagation. Finally, test sending and receiving mail, subdomains and third-party verifications one by one.