How to run the check
Enter a domain, or any hostname under it. The tool works out which zone is in charge, asks that zone's parent which nameservers it hands off to, then asks those nameservers what the zone says about itself. It also looks up every nameserver's IP address and talks to each server directly, so you learn more than a plain NS lookup would tell you.
How the handoff works
DNS is a chain of handoffs. No single server knows every domain, so each level points to the next. When someone looks up example.com, they start high up at the com zone, which does not hold your records but knows where to send the question. That pointing step is called delegation: com delegates example.com to your nameservers and steps out of the way. Your nameservers are the ones that actually hold the zone and answer for it, which is what authoritative means. They are the source, not a cache passing along someone else's copy.
com→your nameservers→example.com zoneThe parent zone points at your nameservers, and your nameservers answer from inside your zone. Both sides should describe the same set of servers.
What glue is and when you need it
There is a catch when a nameserver lives inside the zone it serves. If ns1.example.com is the server for example.com, a resolver cannot find ns1.example.com without first asking a server for example.com, which is the exact thing it is trying to reach. Glue breaks that loop: the parent zone publishes the IP address of ns1.example.com directly, so the resolver gets an address instead of a dead end. A nameserver that lives outside your zone, like ns1.someprovider.net, is found through normal lookups and does not need glue in your delegation.
Reading the result
Matching parent and zone lists support a consistent handoff, but each listed server still needs a reachable address and an authoritative answer. For each server, "Answered" means it replied on that address at all. "Authoritative SOA" is the stronger check: the server not only replied, it claimed authority for this zone, which is what you actually want from a nameserver.
A server that shows up on only one side is the common warning sign. It usually means a provider move that was started but never finished: the new server was added in one place, or the old one was removed in one place, and the matching change never happened on the other side. The effect depends on which servers resolvers reach. Some queries may work while others fail, so reconcile the odd server out rather than assuming a mismatch is harmless.
Fixing a mismatch
Start at the parent side, which is your registrar's delegation, and compare it against the NS records at your DNS provider. Remove old servers from both places, add every new server to both places, and add the required glue before you switch to a nameserver that lives inside the zone. If a server is listed correctly but does not answer authoritatively, fix that server or drop it from the delegation rather than waiting for DNS caches to sort it out. A stale delegation does not heal on its own.
The checks run from stack127's server. A timeout or skipped transport is not evidence that every client will fail the same way. RFC 1034 describes zone delegation. Use the SOA checker to investigate version differences between servers, or the DNS change checker for a specific edited record.