Do I have the right idea going into a DNS migration?

See also: r/dns >hosted on godaddy Ew, yuck, not *the* worst, but certainly one best to be gotten away from. See also: [https://www.wiki.balug.org/wiki/doku.php?id=system:registrars#godaddycom](https://www.wiki.balug.org/wiki/doku.php?id=system:registrars#godaddycom) >Move the name servers over to godaddy [nsXX.domaincontrol.com](http://nsXX.domaincontrol.com) >[nsYY.domaincontrol.com](http://nsYY.domaincontrol.com) and manually add the records 1 by 1? >Then wait for propogation? Ew, yuck, I thought you were moving *away* from GoDaddy. Well, whatever floats your boat. In any case, it ought go about like this to avoid fsckups: I'm going to presume it's a TLD registered via registrar, e.g. like reddit.com., or example.com., and that you're migrating the DNS hosting, not changing to a different registrar. First of all, if you're using DNSSEC, you need pay extra attention to handle that properly, or you can fsck yourself over harder than the more general ways one can fsck oneself over with DNS. Most notably DS record(s). Those specify the key(s) that can be used to sign the domain. So, if DS record(s) are present (those reside in the parent zone), you need to either have DNS data signed by same key(s) on the DNS server(s) one is moving to, or add DS record(s) to cover key(s) server(s) moving to are / will be signing with, or disable DNSSEC (by removing the DS records). In all cases be aware of the relevant TTL and SOA MINIMUM values, the former indicates how long that data may be cached up to, and the latter how long for "negative" caching - basically if the data/record isn't there, that may be cached and continue to use that information without rechecking to see if that situation has changed. Then you get your new DNS servers all set up and hosting all your data, including, if/as applicable, DNSSEC signed with key(s) corresponding to DS record(s) (at least one of them if DNSSEC is being used). Be sure to fully test and validate the data on the new DNS servers before even thinking about switching. Before switching, you can lower some TTLs, etc., but that won't really do all that much good in general. Most notably, TTLs for *authority* (not to be confused with authoritative) NS, glue records, and DS are typically beyond one's control, and not atypically as long as 48 hours. So, unless you've also got other things you need to change at the same time, might just be best to leave TTLs and SOA minimums and such, as they are. Before switching, your new namservers should have NS records for the new namservers, and for any that are within that zone, also corresponding A and/or AAAA records. Starting the transition, update parent, adding the new authority NS records and any relevant corresponding glue records, and remove authority NS records of the old nameservers - if you want to play it slightly safer, you can delay removing the authority NS records for a bit, but once reasonably sanity checked, should remove those - as the transition won't really be fully started until those are also removed. Then you wait out the relevant TTL(s), most notably of *authority* NS records (and DS, if applicable, and possibly also glue, e.g. if same names are used but IPs changed) - whatever those were, e.g. 48 hours, you wait them out. During transition, you can make routine DNS changes, but you need change on both old and new until transition completes, and don't mess with NS, glue, SOA, nor (if applicable) DS through transition - those shouldn't be getting change (and at this point are mostly distinct on the two sets of nameservers). After the relevant transition period (as dictated by the TTL(s)), best to well check all is working as expected, and can then decommission the old nameservers. If at this point, there are vestigial DS records (for keys used by old, but not new), those can be removed, and any obsoleted glue records should be removed. That's it. Do it right, easy peasy, fsck it up like many do, and you'll be in a world of hurt.