Why changes are risky
Changing nameservers does not move one record; it moves the whole zone to a different provider. Whatever the new zone lacks stops resolving the moment resolvers learn of the change: mail, subdomains, verification records and anything else the old zone held. Delegation changes spread according to the TTL of the NS records, which is often long.
Working with them
Export the old zone and recreate it fully at the new provider before the switch, compare the two record by record, lower TTLs ahead of time and check the authoritative answers from the new servers before changing the delegation. Keep the old zone alive for a while afterwards.
How to see who is in charge
dig NS example.com +short lists the delegated nameservers, for example ns1.dnsprovider.example.. Compare them with the nameservers the registrar shows: if the registrar says provider A but the zone you edit lives at provider B, your changes have no effect. Query one directly with dig @ns1.dnsprovider.example www.example.com A to see what it serves, bypassing every resolver’s cache.
Keep a written list of each client’s DNS provider, the account holder and the person who owns the login: a zone hosted in an account nobody can reach cannot be edited in an emergency.
What to check
Which provider hosts each client zone, who pays for it, and that the NS records at the registrar match the provider you think is in charge.
Sources
Read on . Standards and vendor pages change; confirm the current text before you rely on it.
- RFC 1035, Domain names: implementation and specification (www.rfc-editor.org)