DNS is how a name becomes a route. Your device asks a recursive resolver, either the one your access provider runs or a public service like Cloudflare at 1.1.1.1, for the address behind a hostname. When that resolver holds no cached answer it begins at the root servers, gets referred to the servers responsible for the top-level domain, and gets referred once more to the authoritative nameservers listed in the domain's NS records. Those authoritative servers publish the zone: the set of records the owner edits, whether it lives in BIND on a machine you run yourself, in Route 53, or behind a registrar's web panel. The resolver keeps the reply for the seconds specified by the record's TTL and hands the address back, at which point the browser opens a connection to the web server. No page content has moved yet. This system only answers questions about names, and every later problem people blame on it is really a question about which zone is authoritative.
Propagation is mostly a number you chose
There is no queue of machines slowly copying your zone around the planet. Authoritative nameservers serve a new record as soon as you save it; what lingers is the previous answer sitting in resolver caches until its published lifetime runs out. The famous advice to allow up to two days is an umbrella covering long lifetimes nobody remembered to shorten and resolvers that ignore the value anyway. Shorten the lifetime a day ahead of a planned change, restore it afterwards, and the wait collapses to the figure you set.
A zone is short, and each record type earns its place. A and AAAA attach a name to an IPv4 or IPv6 address, so editing one of them is not preparation for a migration, it is the migration. CNAME aliases a name onto another name, which lets a subdomain follow a platform whose addresses change without warning; the snag is that an alias cannot sit beside other records at a zone's apex, so the bare domain normally needs an address record or a provider's flattened equivalent. MX decides where mail arrives and says nothing about where pages are served, which is why the standard disaster is a tidy-up that repoints a site and quietly takes the mailboxes with it. TXT carries SPF and DKIM policies plus verification strings. NS is the delegation itself, and therefore the first thing to check in an incident: whichever panel those records point at is the live one, no matter how many others still show a plausible-looking zone. Confirm rather than assume. Ask the public resolvers what they currently see, then ask the authoritative server directly with dig, and treat any difference between the two replies as the actual fault.