DNS translates names into addresses. Somebody types example.com, and something has to work out which server to actually connect to. That is the whole job, and understanding how the answer is found explains almost everything about why DNS changes behave the way they do.
How a lookup works
Four steps, and the fourth is the one that matters.
The browser asks a resolver, usually your internet provider's, or a public one like 8.8.8.8. If it already knows the answer, it returns it immediately and nothing else happens.
Otherwise the resolver asks a root server, which does not know your domain but knows who handles .com.
It asks that registry, which does not know your address but knows which nameservers are responsible for your domain.
It asks those nameservers, which hold your zone and give the real answer.
Then the resolver caches that answer for as long as the record's TTL permits, and this is where every DNS surprise comes from.
The cache explains the rest
Because answers are cached at resolvers all over the internet, a change you make is invisible to anyone still holding an old copy. Each resolver picks up the new value when its own copy expires.
That is why changes appear gradual rather than instant, why some visitors see the new site while others see the old one, and why nothing can force it. You do not control those caches.
The only lever is the TTL, and it has to be lowered before the change, because the resolvers you are waiting for cached the old record with the old TTL. Understanding DNS propagation goes over doing it properly.
Where the records actually live
Three parties, and confusing them wastes more time than anything else in DNS.
Your registrar is where the domain is registered. It holds one important setting: which nameservers are responsible.
Your nameservers hold the zone. The actual records. Often your host, sometimes a separate DNS provider.
Your hosting is the server the records point at.
These are frequently three different companies. Editing records at the wrong one is the most common wasted hour in DNS work, and the check takes seconds:
dig NS example.com
If those are not the nameservers whose zone editor you are looking at, nothing you change there is being consulted.
The record types
A points a name at an IPv4 address. AAAA does the same for IPv6. These decide whether the website loads; A and AAAA records.
CNAME points a name at another name. Cannot coexist with other records at the same name, which causes most CNAME problems, CNAME records.
MX directs email. Entirely separate from the website records, which is why one breaks without the other, MX records.
TXT holds text: SPF, DKIM, DMARC and verification strings, TXT records.
NS names the authoritative nameservers. SOA holds zone metadata. Both are managed for you and are not things to edit casually.
What DNS does not do
Worth being clear about, because it saves diagnosing the wrong thing.
DNS points at a server. It does not decide what that server sends back. A domain resolving correctly to a server that shows the wrong site is not a DNS problem; the server does not know which site to serve, and no record will change that.
DNS also does not move your website, forward URLs, or make email work by itself. It only answers the question of where to go.
The two commands worth knowing
dig example.com dig NS example.com
The first shows what a name resolves to. The second shows which nameservers are authoritative, and it is the question that resolves most confusion before it starts.
Never diagnose from a browser. Browser cache, operating system cache and resolver cache all sit between you and the truth, which is why the person who made a change is usually the last to see it work.
When something is wrong, the DNS troubleshooting guide works through the checks in the order that finds problems fastest.
For a domain that has nothing set up yet, How to Set Up DNS for a New Domain deals with the four records and the order to add them in.
The fastest way to make any of this concrete is to watch a real lookup happen. For doing that, see How to Use dig and nslookup to Check DNS.
Know which part to check when a name fails
Resolution involves several systems and a name that does not work has failed at one of them. Ask the authoritative server directly first, since that answer is the correct one with no caching involved. If it is right and a public resolver disagrees, the record is correct and the old value is still cached, which is a wait rather than a problem. If the authoritative server is wrong, no amount of waiting helps and the record needs fixing. That single distinction resolves most reports of a change not taking effect.