How DNS delegation works
Quick answer
Delegation is how a parent zone hands off authority for a name to a specific set of name servers. When you point a domain at your DNS provider's name servers, or set up a subdomain to be managed elsewhere, you're delegating: the parent zone stores NS records saying "ask these servers for anything under this name" and stops answering for that part of the tree itself.
Delegation in one sentence
Every DNS zone can hand off responsibility for part of its namespace to another set of name servers, and that handoff is called delegation. The parent zone doesn't keep a copy of the records underneath the delegated name. Instead it stores an NS record pointing at the name servers that do, and every lookup for anything under that name gets redirected there.
This happens at every level of the domain name system, not just once. It's the mechanism that lets a hierarchy with no single owner still work as one coherent lookup system.
The chain from root to your domain
A lookup for example.com walks down a chain of delegations. The root zone doesn't know the IP address for example.com, but it knows which servers are authoritative for the .com top-level domain, because the registry running .com is delegated that responsibility. Ask a .com server, and it doesn't know the IP address either, but it knows which name servers are authoritative for example.com, because your registrar published NS records delegating that domain to your chosen name servers. Only at that final step does anything actually answer with the record you wanted.
Each step is a separate delegation, and each one only needs to know the next server to ask, not the final answer. See DNS record types explained for what an NS record looks like alongside the other record types you'll meet in a zone.
Delegating a subdomain
The same mechanism works one level down. If you want shop.example.com to be managed by a different DNS provider, or a different team, than the rest of example.com, you add an NS record for shop inside the example.com zone, pointing at the name servers that should answer for it. From that point on, anything under shop.example.com is looked up at those name servers, and changes to that subdomain don't need to touch the parent zone at all. It's the same delegation pattern as a whole domain, just applied one label deeper.
The common failure: mismatched NS records
Delegation only works if the parent and the delegated side agree on who's authoritative. In practice that means the NS records set at your registrar have to match the name servers your DNS provider actually expects to answer for the zone. If they drift apart, for example a domain still lists old name servers at the registrar after moving providers, resolution can fail in ways that are hard to diagnose: some resolvers may have cached the old delegation and keep working for a while, others pick up the new one immediately, and the domain can look like it's working from one location and broken from another until every cache along the way expires.
The fix is straightforward once you know where to look: the NS records at the registrar need to exactly match what the DNS provider expects, no more, no fewer. Reverse DNS is delegated the same way, just for IP address space rather than domain names, and is managed separately from the forward zone. See How to edit reverse DNS (rDNS) for adjusting that on a Worldstream IP.